Bugtrackers - a special kind of hell

Stefan Schick's personal Blog

In search for principles

Bugtrackers - a special kind of hell

Posted on
open source free software software engineering

Recently my priorities shifted from work for money to more leisure time, hobbies and contributing to causes important to me. As I am still developing software during work, I didn’t want to write code during my free time, too. Instead I thought it would be a good idea to contribute to open source by cleaning up bugtrackers, triaging bugs and discussing solutions.

So I looked around and found some bugtrackers for software I use. Much to my disgust I found that nearly every bugtracker has thousands of open tickets, many open for years without change. It feels like a special kind of hell. Maybe I am only using the wrong software?

Some examples (At the time of writing):

Now you may ask, what is the cause for all this? I think these are the main reasons:

There are not enough people to help triage and fix bugs. Only a tiny fraction of the people using open source software, have the knowledge to contribute. Of these a even smaller subset is actually contributing. Also most of the contributors do so in there free time. This naturally limits the time they can spend on open source software.

Features are more fun to develop than fixing bugs. Most contributors do this stuff in their free time. Therefore their tasks should be enjoyable in some way. Developing new features is a task that falls in this category. Triaging and fixing bugs on the other hand is more of a necessary evil.

No proper tracking what is fixed. Source code gets changed very often. Sometimes a new feature gets implemented, sometimes a bug gets fixed. Code that caused a bug gets refactored, used third party libraries with problematic behavior get updated. But these code changes have side effects. Over time this has an impact on the tickets in the bugtracker. Bugs become obsolete or non-reproducible. No one notices, that the status quo has changed and the tickets stay open.

No incentives or support from commercial companies that use the software. This is a big one. Commercial companies use open source software on a regular basis. This software saves them money, increases their revenue or is even a part of their product. Unfortunately these companies rarely support the software project in question, let alone provide a compensation for the developers. On the contrary, the developers are very often supporting the companies by answering E-Mails and fixing bugs that might be specific to this single company.

What can we do about it?

Prefer stability over new features. For software, stability isn’t a selling point. It is considered a given, even tough this often isn’t the case. There is a lot of bad software out there. I think that bug fixing should take priority before implementing new features. This doesn’t mean, that all bugs have to be fixed, before new features are implemented. But it means, that the number of bugs should be kept low. When in doubt, fix the bug and implement the feature later.

Contribute yourself by triaging, testing and tracking of bugs. This is the most straightforward one. If no one else is doing the job, then do it yourself. This is one of the great things about open source. If you don’t like something you are free to change it. In our case this would be cleaning up the bugtracker.

Encourage others and thank them for their effort. People that sacrifice their free time to improve software, fix or triage bugs should be encouraged to continue their work. Also if someone is contributing we should thank them for their work. There is nothing worse for your motivation if everything you do gets ignored or criticized.

Pay people for working the bug tracker. This can be done by donation. Through this you make these people less dependent on a day job and help them to free up more time for work on open source software.

Commercial users should pay a fee or contribute. If you have a company and use open source software, there are many great ways to support. One of them is by giving your own employees time to contribute to open source software. The other is by offering a support contract to the main contributors of the project. This way you support the project, speed up development and help your own company because you make sure the project stays actively maintained.

My proposal

In my own quest to support open source, I decided to work through bugtrackers. I help cleaning them up and would welcome you to do the same. Currently I am raging in the ArchLinux Bugtracker. Let’s see how far I get, or if it is a fools errand. Stay tuned, I will report my progress.

If you know of a project that needs some more attention to its bugtracker, then send me an email and I will consider it for future cleanup sessions.