Are you maintaining software, or a package?

The first question is whether you are asking about maintaining something in the Debian sense, or the GNOME sense?

A Debian package maintainer:

• Tracks upstream development, and ensures new releases of software are packaged and uploaded in a timely manner
• Work with distribution users and other maintainers to identify bugs and integration issues
• Ensure bugs and feature requests against upstream software are reported upstream, and bugs fixed upstream are propagated to the distribution packages
• Fix any packaging related issues, and maintain any distribution-specific patches which have not (yet) been accepted or released upstream

A GNOME project maintainer:

• Makes regular releases of the software they maintain (typically a .tar.gz with “./configure; make; make install” to build)
• Are the primary guardians of the roadmap for the module, and sets the priorities for the project
• Works with packagers, documenters, translators and other contributors to the software to ensure clear communication of release schedules and  priorities
• Acts as a central point of contact for release planning, bug reports and patch review and integration
• A typical maintainer is also the primary developer of the software in question, but this is not necessarily the case

Obviously, these two jobs are very different. One places a high priority on coding & communication, another on integration, testing, and communication.

So how much time does maintaining software take?

Well, how long is a piece of string?

To give opposite extremes as examples: Donald Knuth probably spends a median time of 0 hours per week maintaining TeX and Metafont. On the other hand, Linux Torvalds has worked full time maintaining the Linux kernel for at least the past 15 years, and has been increasingly delegating large chunks of maintenance to lieutenants. The maintenance of the Linux kernel is a full time job for perhaps dozens of people.

On a typical piece of GNOME software (let’s take Brasero as an example) much of the work is simplified by following the GNOME release schedule – the schedule codifies string freezes and interface freezes to simplify the co-ordination of translation and documentation. In addition, outside of translation commits, Brasero has had contributions from its maintainer, Philippe Rouquier, and 6 other developers in the last 3 months. Most of these changes are related to the upcoming GTK+ 3 API changes, and involve members of the GTK+ 3 team helping projects migrate.

In total since the 2.32.0 release, there have been 55 commits relating to translations, 50 commits from Philippe, 9 from Luis Medina, co-maintainer of the module, and there were 4 commits by other developers. Of Philippe’s 50 commits, 14 were related to release management or packaging (“Update NEWS file”), 5 were committing patches by other developers that had gone through a review process, and the remainder were features, bug fixes or related to the move to the new GTK+. Of Luis’s commits, 2 were packaging related, and 2 were committing patches by other developers.

This is a lot of detail, but the point I am making is that the “maintenance” part of the work is relatively small, and that the bigger part of maintenance is actually sending out the announcements, paying attention to bug reports and performing timely patch review. I would be interested to know how much time Philippe has spent working on Brasero over the past release cycle. I would guess that he has spent a few hours (somewhere between 5 and 10) a week.

On the other hand, the Debian maintainer for the Brasero package has a different job. There are 6 bugs currently forwarded upstream from the Debian bug tracker, and another 35 or so awaiting some final determination. A number of these look like packaging bugs (“you need version X of dependency Y installed”). The last release packaged and uploaded was 2.30.3-2, dating from November, and there have been 4 releases packaged in the past 8 months, none by the maintainer.

A typical Debian maintainer is a “Debian developer” for several packages. Pedro Fragoso, the Debian maintainer of Brasero, maintains 5 packages. I think it is fair to say that the amount of time a package maintainer spends maintaining an individual package is quite low, unless it is extremely popular. Perhaps a few hours a month. But the package maintainer has little or no say (beyond interacting with the project maintainer and forwarding on bug reports & feature requests) in what happens upstream, or which features have a high priority.

What’s in a word?

It’s clear that a package maintainer is not the same thing as a project maintainer. So when Sivan asked on the MeeGo developer list how he could become a maintainer, he clarified later to say that what he was really asking was “How can I affect change in MeeGo?” To do that, you need to write some code that changes a module, or a number of modules, and then you need to get that code into MeeGo.

How that happens, in all its gory details, is the next instalment in this series of at least 2 articles: The Lifecycle of a Patch (or: Working Upstream).

Lexicon:

• Upstream: The place where the thing you package comes from. For example, Ubuntu’s upstream for gedit is gnome.org
• Downstream: Any distributors who take what you release and re-package it before redistributing
• Distribution: A collection of software packages that are organised into a product, with integration testing

Governance comes in many shapes & sizes of course. My favourite governance stories are about federating individuals, who manage to channel community efforts, maintain a meritocracy where code talks, and yet don’t come across as authoritarians.

Outside of Linus (who’s a good example), Ton Roosendaal of Blender has this kind of presence. Talking to Ton, it is easy to see that he cares about Blender and about the Blender Community. The care and attention that he brings to projects like “Elephants Dream” and “Big Buck Bunny”, or to the supporting documentation and conferences he organises for the community, illustrate the esteem in which he holds his users and his developer community. Even the way the Blender Foundation came into being was amazing.

One of my favourite communities is Inkscape. When they broke from Sodipodi, there was this acrimonious flame war, and something of a bitter taste in people’s mouth. So what Bryce Harrington, Nathan Hurst, MenTaLguY and Ted Gould did when they split was decide to throw open the doors, and accept code from all comers. They set a direction and some ambitious goals, but they were very clear from the start – come right in, you’re welcome. And this gave the project some great results, especially early on when it was still establishing itself. Bryce describes one of them in this article.

The success of the Inkscape project’s governance model is borne out by its ability to escape founder’s syndrome – Bryce, Nathan and Ted have now backed away from the project to some extent, they’re still there as wise heads, but they have passed off the direction of the project to other capable people.

I think the way that Drizzle was born bears some resemblance to this, and I really like the way they have consciously broken down the walls which were necessarily up around MySQL. Brian Aker’s been something of an inspiration on this. His mission statement at the announcement of the project was astounding.

Subversion‘s governance model is an exemplar of best practices too. Set a clear project scope (“Subversion is a compelling alternative to CVS”), clear goals, establish transparent and fair community processes, and open up the gates. Anything within the scope of the project is fair game. And once again, code talks. This story, from Karl Fogel’s “Producing OSS” illustrated the robustness of their governance, and the confidence the project’s leaders had in their ability to influence the project.

The Maemo Community Council has the potential to be a very good governance structure, I think.  The idea of a governing body of the community, by the community, for the community, whose goal is to canalise the efforts of a disparate group into something coherent, and to provide a legitimate point f contact for technical decision-makers in Nokia, is a novel one, and hasn’t been tried, as far as I can tell, by other companies.

Counter-examples of good governance are all around, I won’t name any in particular to protect the guilty. But many of them stem from a misguided belief in absolute free speech, to the detriment of the quality of discourse and code in the project (“we are all created equal”) which results in very chatty, but unproductive, individuals taking senior positions in the community, or a sort of shyness of the founder or leader, who doesn’t believe that it’s his place to set a direction and tone.In company-run projects, excessive control or influence is an equally toxic characteristic. Companies who retain a veto on community decisions are companies who do not trust their communities.

Dave Neary is reading all kinds of maemo content as we speak: developer documentation, mailing list archives, web pages at maemo.org… He has a good reason for that: Nokia is funding some of his time to work as the content guy for the maemo community. Just like Niels Breet, he is being paid to follow your agenda and move forward those tasks and topics that interest you more.

Dave is a good organizer, communicator, writer and DIY professional, with proven tracks in the GIMP, GNOME and OpenWengo communities. While Niels concentrates on the web applications and server infrastructure, Dave takes care of the content in the website, and the ways for you to help improving it and get the ownership. Last year we made some steps in this direction with the social news and the revamped downloads. Now the revamped wiki plan and the fact of having someone listening and thinking how to go further should bring us to a next level.

I am looking forward to working with the maemo community and Nokia to make their collaboration rock.