Distributed Bugs-R-Us

I have a decent idea for an open source application. This could be one of the most important pieces of software to assist open source in a long time. I don’t have ideas often for software apps but when I do, normally they’re good ones.However, I don’t have the expertise to program this either. The only thing I have is an idea for bugtracker software…and it operates on the distributed journalism model of digg.

The idea was inspired by the article “10,000 bugs away from World Domination“, specifically these few words:

“My diagnosis is that the problem with Linux is that it doesn’t have anyone pushing to get the newbie bugs fixed first. At Microsoft, we had Program Managers and one of their responsibilities was to be customer advocates to prioritize the bugs for the devs to fix. In many open source groups, it sometimes appears that bugs get fixed when the dev decides to work on it, not because an important user scenario is broken. The Wi-Fi tool was broken in Gnome for any months, but the bugs just sat there languishing in the database. Microsoft or Apple would not have shipped a Wi-Fi UI that was completely broken in that way.”

The author is 100% correct. And since open source communities don’t have program managers that can focus the time needed to prioritize bug fixes, we can make the community become that program manager. Read on for specifics on how to do this.

The software itself would be a simple UI for bug tracking…it can be built on top of any number of current bugtracker softwares (ie mantis, bugzilla, bugzero). The kicker is this…make the bugs pop on a distributed list similar to digg where the community can read the bug, decide if it is something that should be addressed immediately or put on the shelf for a while, and vote accordingly. Then have the software prioritize bugs based on the number of votes received and the length of time since submission. Now I don’t have the specifics…just the main idea. But to me, this seems like a very decent idea because bugs that mean a lot to newbies would be fixed first and foremost if the UI were right and we could tie this into a CMS. Care would have to be given to doing it right where a strong community vote would determine the prioritization. Instead of the complicated explanation of what the bug is…the line could read what the bug effects. It is my opinion that this will help with categorization as well and duplicate bugs (they’ll attract the same amount of attention aka votes).

In the article, “10,000 bugs away from World Domination” (quoted above), the author hits a grand slam home run…if the top 1,000 bugs were fixed in the Linux Desktop, world domination may not be far behind.

If anyone thinks this idea for a distributed model bug tracker would work…and if you have the time to take it on…I will host the project for free on my servers and provide any CMS/bugtracker/groupware needed and will even assist with some management of the overall project. Please leave comments below if you are interested.

This content is published under the Attribution-Noncommercial-Share Alike 3.0 Unported license.

Author: devnet

devnet has been a project manager for a Fortune 500 company, a Unix and Linux administrator, a Technical Writer, a System Analyst, and a Systems Engineer during his 20+ years working with Technology.

10 thoughts on “Distributed Bugs-R-Us”

  1. Not the same man…I’ve used them all..and while they do allow you to prioritize bugs…they don’t have it set in a ‘diggable’ fashion for the community to vote bugfixes into play.
    I’m thinking that more new user centric bug fixes would be the ones that are addressed first if a digg-style bug tracker were used.

  2. This is an interesting idea! I’m not sure if its workable, whether we should add it to a particular distro’s bug system or build something outside but I do like the idea. Lets think about it some more.

  3. Don’t forget to add RSS feeds in the same fashion as DIGG or better yet, make categories for votes: Highest rated, Medium rated, Lowest rated.
    People can then either add all 3 of them or those they wish to concentrate on.
    Also a link within the RSS feeds which will allow to “digg” it from the RSS feed programs, so now if it gets “digg”ed enough while it is in one category (For example, in the lowest rated category) then next time the RSS program will grab from the lowest rated category and “move” (It will just appear in both in reality, but for those only having medium rated category, it would be as if it just now got there) it to the medium rated category.

  4. I’ll try to program something during holidays, which will start at 27.04.06. I am not PHP & MySql expert but I’ll try to do my best. My idea is to for start parse bugzilla and then incorporate something in bugzilla to add bugs on these page too. And then the bugs are availible for voting.

  5. In theory it’s a good idea. The problems are that:
    1) People are lazy,
    2) People are selfish.
    You assume that once we have used social intelligence to prioritize the bug list, the devs will then work on the bugs in that order. Not so. The devs work on whatever they *want* to work on.

  6. Majority of them yes. But maybe when one bug has a lot of votes, some comercial Linux distro sees that this bug is what a lot of people wants to be fixed and they point their developers to fix it. Maybe 🙂

Comments are closed.