gnome 3.0 for application developers

I wanted to write a little post on what it means for application developers to try to get ready for GNOME 3.0. Many people might already realize what I try to outline here, but I think it’s still good to show. This will be specifically about gedit (naturally), but I think it will apply to any applications trying to survive in the storm that is GNOME 3.0.

I have been developing for gedit since around 2006 (this is 2.14). I would not say I’m the most active developer at all times, but the fact is that gedit is almost solely being developed by volunteers (we see little to none contributions from financed developers). This is of course true for many open source projects. gedit seems like a simple enough little application, but it’s still quite extensive.

Our normal development cycles are relatively uneventful. We introduce a small set of new features, fix some bugs, etc. We also always try to ensure that current HEAD of development is “stable”. This means that I have always used current HEAD in a production environment, that’s right, production! This means it gets a lot of testing, because it is the application I work with most every day. We are not usually early adopters of new technologies, which helps this level of stability.

This changed with GNOME 3.0. We decided we would try to adopt to the changes as early as possible, so that in the end we actually have gedit ready to be shipped. This meant however, amongst other things, the following:

• A lot of work to port from “old” technologies (gconf – gsettings, pygtk – pygi)
• Half of the time I’m just trying to get jhbuild to work again
• gedit is continuously broken due to API changes or broken dependencies
• No real testing because it’s unusable in a production environment
• Regressions are almost inevitable
• No real change for end users!

Now, I of course understand also the advantages of trying to get this to work, but it has been largely demotivating for our little team. To illustrate a bit the impact of this, I had git crunch some numbers on our development cycles.

On this plot you can see the sum of all added and removed lines (excluding translations) over all commits in a particular development cycle. As you can see, we have seen a significant increase of activity in this cycle. Of course, not all of this can be attributed to GNOME 3.0, but there is an undeniable effect. If we zoom in to the last two development cycles, we can see who the person is that we really need to thank:

That’s right, Ignacio is clearly our hero! Anyway, I just want to point out that this cycle has been particularly hard for application developers, especially those that try to adopt early so that they are actually ready by the time GNOME 3.0 lands. And then to think, for the end user, there will be basicly no change at all…

P.S. Note that if you apply a simple COCOMO to this (you take an “organic” type of project, for 80 KLOC (which is probably an overestimation, but still)), you get some 20 months of volunteered work done by a team of 12 for this cycle… wow…