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:
  1. Less time for GIMP development for key resources
  2. Features are being developed on the main branch
  3. 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...

Finally a small notice; I have replaced BuildBot with Jenkins for our nightly tarball builds. The new URLs are:
babl-git-master.tar.bz2 (HTTP) (FTP)
gegl-git-master.tar.bz2 (HTTP) (FTP)
gimp-git-master.tar.bz2 (HTTP) (FTP)

posted by Martin Nordholts @ 8:49 AM spacer

75 Comments:

At February 18, 2011 9:11 AM , spacer  Søren Sandmann said...

Developing features on branches is a very good idea, but also consider time-based releases. If a new GIMP release came out every six months, and a development snapshot every month, maybe more buzz would be generated around GIMP leading to more developers.

 
At February 18, 2011 11:20 AM , spacer  Anonymous said...

@ Sören

I think this is acutally what he wats.
Currently an time-based release schedule is impossible. What if a major change is not done in time? If it lives in a feature-branch, you just have to ignore that branch until next release, however if it lives in main, how do you ignore something that will cause a broken release?

 
At February 18, 2011 11:29 AM , spacer  yagraph said...

Thanks for your work on GIMP, Martin.

I completly agree with your analysis, but I'd like to add a little more :
as an user (designer), I can't help with coding, but I may test an reports bugs, maybe do some translations ...
But actually I can't : last dev release I've seen officilly annouced is 2.7.1 last summer. If I make a bug report based on 2.7.1 it will probably be outdated.

Release early, release often : I think we frequently underestimate how it is important. I know packaging alpha, beta, RC release is not fun, but it have to be done for the health of the project.

I know testers could compile from source... but honnestly users don't do that. It's like coding : not our world.

Test release are important for testers and early adopters, and your potential contributors are there. Starting to contribute a project is often bug reports...

 
At February 18, 2011 12:35 PM , spacer  Tshepang Lekhonkhobe said...

I would expect that the motivation for a volunteer to contribute code is so that they can use it is much stronger than so that other could use it. Since these contributors run development versions (either VCS or unstable releases), why would they be demotivated by seeing their shiny new features taking 'forever' to ship, to a degree that they'd leave? Do you mind explaining this a bit, and maybe point out if I'm mistaken?

 
At February 18, 2011 1:38 PM , spacer  Cyrille Berger said...

@Tshepang it is also very rewarding for the contributor to have its feature used by other users and receiving praise for them, among the line of "awesome feature it changes my life" ! I am exaggerating a bit, but users happiness is often a good motivator for people to contribute.

 
At February 18, 2011 2:12 PM , spacer  René said...

Recommended reading for getting people excited about working with an efficient branching model:

nvie.com/posts/a-successful-git-branching-model/

 
At February 18, 2011 2:56 PM , spacer  shevegen said...

I happily test unstable branches and give feedback when possible.
(And on blogs as well)

I agree that for point (1) and (2) not much can be done - the developers have to sort that out and agree on a way forward.

But about (3), and I know what you mean by volunteer developers wanting to work on what is fun (who wants to code something that is boring ...) I wonder if it would not be better if the users would be more involved. There are actually MANY Gimp users out there. Thousands of tutorials for Gimp and whole Gimp communities. So how is it that there is a lack of developers *for* Gimp?

Clearly, despite having some problems, there are MANY MANY people out there who love Gimp and use it.

If you look at Git, and Github, they were and still are a huge success. Many users of Git are also contributing to Git in one way or the other.

The better this contribution of your target audience, the better for the project. It keeps people/users motivated and motivated users can be the best developers as well!

Gimp is far from being dead but it is in a crisis.

PS: A name change would really not be bad for Gimp 3.0 ... saying "gimp" is kind of weird... How about slogans like "pimp my gimp"! ;-)

 
At February 18, 2011 3:28 PM , spacer  Alexandre said...

@shevegen

Congratulations! Are you exactly the millionth person to want GIMP changing its name. How do I contact you to get you the prize?

 
At February 18, 2011 3:31 PM , spacer  Gil Forcada said...

Sure points (1) and (3) are in a user level and not much can be done, but with (2) ... having strong, and by strong I mean STRONG polices about how to contribute to a feature, how to create feature branches, how to request master merging ...

An starting move could be to move (where possible) all features-not-yet-finished to branches, remove those commits from master and then create a release (a 2.6.x.y.z if needed).

From that point onwards just remove all commits from master that are not either bugfixes or feature-merges developed in parallel.

This way master will be always shippable and thus alphas, betas, RC and so on could be as automated as possible to give early testers a chance to try and report bugs.

Clearly from your report the main lack is polices and community management.

 
At February 18, 2011 3:31 PM , spacer  mmiicc said...

Sure, name will be changed to GINP (Gimp Is Not Photoshop) :P

 
At February 18, 2011 3:59 PM , spacer  Anonymous said...

Maybe you should have someone other than the mascot coordinating development.

developer.gimp.org/faq.html#id455286

 
At February 18, 2011 4:08 PM , spacer  Ramón Miranda said...

Hi since i am not a Coder, i can only encourage for your efforts,.I know it is hard to work in something that is not fun.but keep up the good work! gimp users are growing as i see on deviantart and other sites. we are all waiting the 2.8 but we need more pattience and understand these 3 key points. Let me know if i can help you in anyway. take care martin

 
At February 18, 2011 4:54 PM , spacer  Anonymous said...

Reasons why Gimp has a problem:

1.) ASSHAT DEVELOPERS: I am a good C coder with design skills. I was banned from the dev list because I wanted to work on Photoshop key bindings and suggested a name change, like 40 or 50% of the list wanted. 2 or 3 key developers like Sven would shut down any conversations they didn't like.

2.) NAME CHANGE: Much of the world sees the name "Gimp" and has associations with it. No matter how much certain people say this isn't so in "their" language or "their country", it doesn't make it not so in English or anywhere where people have seen "Pulp Fiction" or have handicapped people.

3.) Lack of usable debug builds with SIngle Window Mode and big visible steps towards color management and 12/16-bit color and/or RAW. Make it easy like Krita!

4.) Photoshop workalike - Yes, Gimp does bitmapped images, so it's PS. Just admit it, devs. Make it work like that in lots of easy to do ways and you'll create excitement.

 
At February 18, 2011 5:19 PM , spacer  BabboNatale said...

agree with 3 and 4

 
At February 18, 2011 5:27 PM , spacer  Anonymous said...

You complain about people starting new projects and then mention a move to a new project of your own?

Do you see the irony in that statement?

 
At February 18, 2011 5:53 PM , spacer  klang said...

nvie.com/posts/a-successful-git-branching-model/

New features should ALWAYS be developed on a branch, that way, they are easy to forget about when the developer who got the brilliant idea for the feature in the first place moves on to the next exciting thing (see problem number 3)

A release candidate for the next release of a software product is difficult enough to control in a professional, paid, permanent position scenario. How in Hell can anybody hope to control an open source project without rigid rules about the overall state and baseline for the project?

 
At February 18, 2011 6:23 PM , spacer  Anonymous said...

1. Fuck name changes. I thought the name was silly, then I grew up - get over it.

2. The interface is fine. If you really can't work with out one unified single window maybe computers aren't for you. It's very easy to set it up like one big window. Drag, drop, resize. You're a big boy now - act like it.

3. I think PS is crap. I hate the PS layout. I <3 the gimp layout, way more intuitive for me. I know where everything is in the gimp. Please dont change that unless you're going to make it better.

4. Thanks for making and maintaining the gimp, I've used it for 5+ years, love it and recommend it to friends.

 
At February 18, 2011 6:50 PM , spacer  tmt said...

I follow gimp developement for years. I think from your post, that your developement methodology is like we had in our early gamedev years twelve years ago. No strict rules, coding/branching policies, not even good teamwork and importance based feature/bugfixing milestones.

I know, how it works, when it works well, because I work for a really good company, which releases product within tight schedules.

If some devs see gimp as a playground, then they're totally losing the point. gimp got far bigger than that. And from the cinepaint, gimppainter spinoffs, I think that there are some head developers who're just can't keep up with the products importance in the open source world.

 
At February 18, 2011 6:53 PM , spacer  Anonymous said...

Imho another burden is the usage of C. Writing desktop apps in C doesn't feel right considering modern programming concepts like object orientation, garbage collection and parallel computing.
Using C for desktop apps is like hiking in slippers.

 
At February 18, 2011 7:31 PM , spacer  Anonymous said...

>1. Fuck name changes. I thought the name was silly, then I grew up - get over it.

>2. The interface is fine. If you really can't work with out one unified single window maybe computers aren't for you. It's very easy to set it up like one big window. Drag, drop, resize. You're a big boy now - act like it.

It's vitrol like this that makes people not want to be a developer or participate on a project. Your opinion is not the only opinion, and it may not even be the correct opinion without some civil debate. You are not being civil.

 
At February 18, 2011 7:33 PM , spacer  AbeOwitz said...

I've been using GIMP for over 10 years, it is awesome! I love the interface, it is intuitive and logical yet flexible.

Nice job with 2.7 development so far! (following via git regularly.)

I appreciate the hard work of the GIMP team! I wish I could contribute, but I'm struggling with learning C/C++ on Linux. :/

It could use a new name.

 
At February 18, 2011 8:25 PM , spacer  Anonymous said...

Getting more developers is easy: Make the codebase more friendly and get some documentation in there. I haven't looked at the codebase since 2.4 but back then it was something terrible to look at, the only worse offender I have come across yet is OpenOffice.

 
At February 18, 2011 8:38 PM , spacer  towolf said...

I don’t think it needs a new name, and I don’t think it needs to be like Photoshop. (Photoshop has basically multiple subwindows too. It just comes with its own desktop-like background window.)

Gimp needs to get released with the backlogged features now. I want to see and use the innovations.

 
At February 18, 2011 8:58 PM , spacer  Bill said...

We need three branches of gimp development. A branch for stable releases, one for testing, and one for experimental. The stable branch will have only a few well defined goal to complete. The experimental branch will develop new features to be included in future releases.

It is more productive to have a few well defined goals to concentrate on at one time vs jumping back and forth.

 
At February 18, 2011 10:41 PM , spacer  n-pigeon said...

very good idea! :)

 
At February 19, 2011 12:39 AM , spacer  Anonymous said...

Fourth reason nobody is contributing: it really is an inexcusably-terrible piece of software. I grew up writing graphics programs; I hate Adobe with a passion. But between the awkward UI widgets and the arbitrary differences from industry-standard layouts, features, functions and terminology -- it's a miracle it's made it as far as it has. It's awkward on Windows, it's heinous on Mac. Firefox has gone from ugly to beautiful to ugly again meanwhile Gimp and it's horrible toolkit and bad name soldiers on, barely changed. No innovation, no must-have feature... just a clumbsy Photoshop 6.0. Except Photoshop 6 does more and runs under Wine.

 
At February 19, 2011 2:24 AM , spacer  Anonymous said...

GIMP is magical. Considering the number of developers and relative lack of longterm leadership, it's truly magical.
You guys should approach some of the moneyed distros and ask for either: 1. funds for bounties (good for very clear/contained goals), 2.request help from some devs in their spare time or at the cent of the company/organization.
If no one else would help I'd imagine Gnome has some money it could throw towards you for some bounties (again, these can work but the goals need to be very clear and not require a tremendous amt of knowledge of the codebase -- things like further gegl integration might work, or implementing the interface using gtk3, etc).
Best of luck.

 
At February 19, 2011 3:13 AM , spacer  Anonymous said...

I don't work on GIMP but I would say part of (3) is not just about praise. Getting a feature a developer has been working on out to users as soon as possible means they get bug reports and suggestions while the feature is still fresh in their mind and they are still engaged with the project.

Personally, if I write something that (aside from me using it) just disappears into a black hole for six months, I am likely to go off and work on something else as soon as it is in a state where it is good enough for my purposes. If I get quick feedback, both the feature itself is likely to be of higher quality and I am likely to stay more involved.

I think a lot of developers come to projects to do the old "scratch an itch" thing and add something they want, but few have a long list of itches, they need users saying "oooh shiny, but can it do X and Y as well?". And

gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.