Friday, February 18, 2011
Why GIMP 2.8 is not released yet
Back in January 2010 I estimated the release date of GIMP 2.8 to December 2010. It is now February 2011 and there is still a lot of things left to do. In this post I will give my view of why this is.
The way I see it, there are three main reasons we have not been able to release GIMP 2.8 yet. I want to stress that I don't mean to put blame on anyone, I am just making observations. The reasons are:
- Less time for GIMP development for key resources
- Features are being developed on the main branch
- A tendency among developers to repeatedly start working on new things
The first reason is not something you can do anything about in a project developed entirely on a volunteer basis. The work and family situation for people changes all the time. Sometimes there is time over for GIMP development, sometimes there isn't. This is not a problem per se, but it becomes a problem if a developer that gets less time for GIMP development has an incomplete feature on the main branch. It blocks releases and in the worst case it also blocks development of other features.
The second reason is that we develop features directly on the main branch. That this is a problem is highly related to that developers come and go. In fact, it is the reason we have long development cycles overall. There is almost always a feature on the main branch that is incomplete. This has the sad side effect that if someone contributes a complete feature in the beginning of a development cycle, it will literally take years before that features reaches a wide audience. An important factor in making it fun for people to contribute to GIMP is thus lost: quickly getting feedback and hopefully praises from our large user base. I believe this is one of the reasons GIMP has so few contributors.
The third reason is also not something you can do anything about in a project by volunteers. People will work on what they find fun and rewarding, and sometimes you get bored working on old things, especially if you bump into problems. This is again only a problem if the work is big and happens directly on the main branch. We end up with a lot of started but not finished work.
The solution to all our problems is the same. We need to begin developing big features on feature branches and merge them to the main branch when they are ready. Changing our way of working is not going to be easy, because it requires a different mindset for everyone involved. But if we don't do it, our long development cycles will make GIMP remain unattractive for new contributors and even ourselves.
Just like in January 2010, the plan now is to get GIMP 2.8 development under control again with a schedule. This time however, it will not be through a spreadsheet version controlled along with the GIMP source code, but through a web based tool I have been working on for the last few months. That is a topic for another blog post though...
Muerto por dentro
Clásico
Frikazo
