back
2 comments
There's a large number of dead projects in the distributed bug tracking field. There's a few live ones as well. See http://travisbrown.ca/blog.html#TooMuchAboutDistributedBugTr... for my summary of the situation.

I think distributed bug tracking hasn't caught on in the same way distributed version control has because while distributed version control depends only on how individual programmers work, distributed bug tracking depends on the organization of the entire project.

If you look at companies which develop software there are obvious workflow advantages to a DVCS, but it's still a centralized management structure which demands uniform visibility and control over the work the employees are doing. This is a case which argues against distributed bug tracking done in the same fashion as a DVCS, though just like a DVCS it can be used in a centralized manner which merely makes bug tracking faster for the developer.

If you look at open source projects many of them might have a bug tracker, but it's mostly a place where user bugs go to die. Much more typical with herding the volunteers cats is that the mailing list is the prime place to try to win developers over to fix your bug. If you don't succeed then you can try again later, but it might just be that the developers decided that your issue isn't worth solving. In such organizations a bug tracker won't get used anyway, so why bother figuring out distributed bug tracking?

Distributed bug tracking is a good fit with small projects because it reduces the necessary infrastructure. It can be made to work in other project types, but it's less obviously a win there.

Nothing new. There are already implementations of such trackers, like ticgit, SD (App::SD on CPAN), Bugs Everywhere or ditz. Heck, they were included in Debian Squeeze three years ago, and Debian is not known for jumping on every new shiny thing!