You know the feeling? You join the dev-channel, grab yourself a ticket in trac and start to reproduce. And while reproduceable you analyze what’s the root of the bug. But while digging through core-code you stumble over multiple areas you think which must be touched to fix the issue. And then you discover unfixed related bugs and so on and so forth.
Finally you end up with the assumption that you just opened a can of worms and you’re unable to move any further. But you had the best intentions to just fix a bug and help with the project. What went wrong here? As with any program that is having a legacy code base (as WordPress does) there can be multiple things that are just going wrong. Over the last week I concentrated on one facet of that big bunch of problems the project is facing: the number of open bugs. I did this because I have the feeling that the immense number of bugs are eating the project’s developer resources up and prevent more and more people from actually providing patches. Since WordPress is an open source project this does just mean that it prevents you from using the software.
So I wanted to know how many bugs there are actually open and how that evolved over time. To get the number of currently open bugs is quite easy, you can just query the trac system (1316 open tickets while I’m writing this). But how did that evolve over time? How many bugs are “normal” in the project? To answer this, it is a need to gather the historical data as well. Since the trac software does not provide such a kind of data in a custom query, I needed to create a script that gathered the data and did the analysis of it. Finally today I was able to finish it after having problems to get the exactly correct numbers:
From what I’ve learned so far is, that the overall developers in the project can not cope with the number of bugs the software has. As the graph is showing drastically over time there are more bugs than could be fixed and the number of bugs are constantly growing. Today we have 1316 open tickets, a new all-time high as my stats are showing.
This raises questions about the root(s) of this situation and how to deal with it in the future. Even if the graph is showing a concrete picture, it is not so easy to figure out the right actions to be taken in the project. The first impression to just “fix all open bugs” as you can hear the one or other developer now more and more often just does not really help because this goal can not be achieved (we can not get all bugs fixed, that won’t work). Even I sympathize with the underlying idea, I must admit that I do not think it’s that easily made. I strongly believe that taking care of the bugs is only one side and it must be combined with other actions to help the project to become healthy again.