Safe as Milk

What’s involved in maintaining a package?

Reposted from Neary Consulting

An interesting question was asked on a MeeGo mailing list recently: What does it mean to be a maintainer of something? How much time does it take to maintain software? It resulted in a short discussion which went down a few back alleys, and I think has some useful general information for people working with projects like MeeGo, which are part software development, part distribution.

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, Linus 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.

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. His influence comes primarily from the fact that he is representing a larger user base and can indicate which bugs his distro’s users are running into and reporting regularly, or which feature requests are generating a lot of feedback.

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).

Community Building Guide

I wrote another guest article for the VisionMobile blog last week, which just went live yesterday, titled “Open Source community building: a guide to getting it right”.

Exerpt:

Community software development can be a powerful accelerator of adoption and development for your products, and can be a hugely rewarding experience. Working with existing community projects can save you time and money, allowing you to get to market faster, with a better product, than is otherwise possible. The old dilemma of “build or buy” has definitively changed, to “build, buy or share”.

Whether you’re developing for Android, MeeGo , Linaro or Qt, understanding community development is important. After embracing open development practices, investing resources wisely, and growing your reputation over time, you can cultivate healthy give-and-take relationships, where everyone ends up a winner. The key to success is considering communities as partners in your product development.

By avoiding the common pitfalls, and making the appropriate investment of time and effort, you will reap the rewards. Like the gardener tending his plants, with the right raw materials, tools and resources, a thousand flowers will bloom.

After focusing recently on a lot of the things that people do wrong, I wanted to identify some of the positive things that companies can do to improve their community development experiences: try to fit in, be careful who you pick to work in the community, and ensure that your developers are engaging the project well. If you are trying to grow a community development project around a piece of software, then you should ensure that you lower the barriers to entry for new contributors, ensure that you create a fair and just environment where everyone is subject to the same rules, and don’t let the project starve for lack of attention to things like patch review, communication, public roadmapping and mentoring.

The original title of the article was “Here be dragons: Best practices for community development” – I’ll let you decide whether the VisionMobile editors made a good decision to change it or not.

Thought of the day

When I was growing up in the small village of Bangor Erris in the West of Ireland, we had a bitter rivalry with people from Belmullet, the next town over. In sports, and in school, it was always “them” and “us”.

I went to boarding school in a much bigger town, Ballinasloe. It’s fair to say that not everyone in Ballinasloe knew everyone else. Our idea of “them” and “us” changed – “we” were the boarders, the townies, the bus students. There were even smaller factions – Creagh, Ahascragh, Kiltormer, …

Malcolm Gladwell mentions Dunbar’s Number, the magic figure of 150 as the maximum size of a village in the Tipping Point – the same figure is cited in David Wong’s article “the Monkeysphere”. Beyond around 150 people, groups start to segment into smaller clans, identifying differences and similarities on ever smaller scales. Towns don’t organically grow with huge rates of change, but companies, projects and industries do. And as these grow, our self-identification evolves with them. You go from being “a Google guy” to “a Google Mountain View guy” to “a Google AdWords guy” or “a Google Docs guy”.

When GNOME was young, “us” was GNOME, “them” was KDE. But GNOME has turned into a bigger town, and “us”  is different now. How do GNOME developers self-identify now? By employer (Red Hat, Collabora, Novell, …), by area of participation (l10n, docs, art), by geography? And how can we recognise these sub-communities and start building bridges between them?

Flashback to 2007: “GNOME will be a platform or a big tent”

I was more than a little amused when (in a vanity exercise) I re-read Joe Brockmeier’s 2007 profile of me while I was OpenWengo community manager. Among the topics we talked about was where I saw GNOME going, and I said this:

Neary says he thinks GNOME will either grow into different projects — such as a One Laptop Per Child (OLPC) GNOME, a Home and Small Office GNOME, and Enterprise GNOME — or the project will shrink to the GNOME development platform, “which will then be re-used by third parties to build the interfaces they’re interested in on top of it.

“We have already started to see this trend. Distributors cherry-pick the applications they are interested in for their own desktop projects, which are then themed and targeted for their core audience. The variety of platforms and human interfaces being built upon the GNOME platform is dazzling. These go from small-form-factor interfaces like the Nokia N800 and the Maemo application framework and OpenMoko and GPE through to innovative interfaces like Sugar from OLPC, which is totally unfamiliar to someone used to the GNOME desktop, but which is undeniably GNOME-based.”

It isn’t just the embedded or odd form-factor devices that are customizing GNOME, says Neary. “Even the major distributions have modified the GNOME interface to suit their needs. The openSUSE, Red Hat Enterprise, and Ubuntu desktops all behave in different ways, and have different target audiences.”

From memory, I don’t recall mentioning Home & Small Office or Enterprise GNOME, but I certainly remember saying that I thought we should adopt Sugar as “GNOME Education”, maybe Maemo as “GNOME Mobile”, moblin as “GNOME Netbook”, etc.

So it looks like the latter scenario has started to come to pass. The GNOME project is concentrating on defining the core platform and distributors are building usecase-specific or brand-differentiating user interfaces on top. Is it too late for GNOME to embrace this trend, or have we become technology suppliers only?

A modest proposal re. Unity

Having slept on it since writing my initial reactions yesterday I now have a proposal for Canonical & GNOME, which I hope the people concerned will consider.

Yesterday, I said “the best possible outcome I can see is that one of the two projects will become an obvious choice within a year or so”. So my proposal is this: let’s have a bake-off, Unity vs GNOME Shell, under the big tent of the GNOME project.

What needs to happen? Unity would have to agree to sync to the GNOME release schedule. Canonical will need to drop their copyright assignment requirement for Unity, and should ideally commit to using some of GNOME’s infrastructure. How much will need to be discussed. I’m sure that the Unity developers will want to continue to use Launchpad for bug tracking and bzr for source control, but perhaps the development mailing list could move to gnome.org, and the Unity website could be gnome.org/projects/unity or unity.gnome.org instead of unity.ubuntu.com?

GNOME will have to accept Launchpad as a platform for the development of GNOME software – there are potential integration issues, it is a headache using Launchpad & Bugzilla, co-ordinating Rosetta & upstream translation teams, and so on. But right now there is a general feeling that gnome.org is for “official” GNOME software, and Launchpad is for Ubuntu. We need to change that perception if we hope to be inclusive of Canonical and the greater Ubuntu developer community in GNOME. In fact, broadening the definition of what we call GNOME software was a key plank in the release team platform for 3.0 – resolving this question (and the equivalent question for projects hosted on Google Code and Sourceforge) will go a long way to growing the big tent. The GNOME project should also work to make it easy to switch from one shell to the other.

Developers who feel drawn to one philosophy or the other should work to make sure that their vision is the best it can be by September 2011. And at that point, presumably at the Desktop Summit in Berlin, GNOME, as a project, should choose one of the two, and put our full weight behind it.

This is potentially naïve on my part. Over the years, we have allowed a lot of animosity to build up between Canonical and Red Hat, among others. As a community, we’ve stood passively by while this has happened. Some will point to efforts to engage which were rebuffed. Others will point to a lack of real commitment to engage.

In situations like this, no-one is 100% right, no-one is 100% wrong. All we can do is look at the current situation, and ask ourselves: how do we get to where we want to go, from where we are? We have two choices – we can, like the Mayoman asked for directions to Galway by tourists, respond “If I was going to Galway I wouldn’t start from here at all”, or we can roll up our sleeves and try to make things a little better.

So – how about it? Is this a non-starter, or is it worth starting some conversations about it?

Ubuntu to move to Unity as default desktop for 11.04

At this stage, most people will have heard the news: Ubuntu 11.04 will ship with Unity as the default desktop shell. This raises a few questions: what does this mean for GNOME, and the adoption of GNOME Shell? Will this further affect the relationship between Canonical developers and others working on the same problems?

First things first: what Canonical is doing here is not new, by any means. Novell developed the slab on their own, based on their user testing and to their own design, before proposing it for inclusion in GNOME once it was released in Suse Linux Enterprise Desktop. Nokia have developed custom user interfaces on top of the standard Linux desktop shell for the past 5 years, built with GNOME technologies, and have actively participated in the development of core components through the GNOME project – they are now developing a custom interface based on Qt, for smartphones, using the same standard desktop stack. OpenMoko did the same thing with the Freerunner. Intel built a custom shell for netbooks in the Moblin project, which is now the netbook interface for MeeGo. OLPC built a custom designed user interface for educational computing devices. GNOME allows and enables this kind of work, because of the great platform and infrastructure we have provided over the years to all Linux software developers.

In such illustrious company, forgive me if I think that Canonical’s management has seriously underestimated the difficulty of the task in front of them.

At the time, the slab further damaged the relationship of Novell developers and the GNOME project – Dan Winship wrote a scathing mail to a GNOME list when asked why Novell had not worked in the open on such a significant development, saying in short that it was impossible to work in the open in the project – the logical conclusion of the siege mentality bred by the negativity around Mono development and the numerous acrimonious debates at the time.

Nokia have had repeated issues coming to terms with open development, and reconciling the need to differentiate and the desire to create an open collaborative project. Their conclusion – to increase the openness of their software platform and collaborate in the MeeGo project – bears witness to the difficulties they have had over the past five years developing a high quality, innovative mobile user experience alone.

OpenMoko repeatedly ran into performance and flexibility issues, and frequently changed software strategy, to the point where the project was no longer viable. Their success was in creating a vibrant independent developer community, which has allowed their dream to live on in projects like Hackable Devices, and its distribution Hackable:1.

Intel have followed a similar path to Nokia – creating an independent vendor-let user interface project, having trouble getting a high quality product out the door, and they are now in the process of opening up and collaborating on the netbook user interface through the MeeGo project.

OLPC had many teething problems with the Sugar desktop environment. Bugs, stability and performance issues plagued the project for many months, to the point where they abandoned the development of the stack as the primary target platform for the devices. The project lives on in Sugar Labs, thans to a broad and vibrant developer community.

There is not one out-and-out success story of a company building a great high-quality custom user interface on the standard Linux stack, except Android, which is hardly a model of collaborative software development.

Is this because of problems in out platform? A lack of developer tools? Insufficient documentation? Perhaps – but if that’s the case, don’t all of the aforementioned have a shared interest in improving those raw materials?

There is another possibility which seems to me more plausible: building a rock solid and functional desktop is hard. Really hard.

So why do people do it? Because working with old code is painful. After years of use, and bug fixes, and nasty hacks, the code gets to look ugly. Really ugly. I’ve been in the situation myself – you’re working on crusty, crumbling, slow code from 10 years ago, and you say to yourself “I could write better than this in a weekend”. And you do get to a decent proof-of-concept in a few days. And then you have to harden it. And you spend months and months fixing bugs until finally it does everything the old code did, better, and a few new things, but it took you 2 years of development. And it looks just as hairy as the old code did. As Joel Spolsky wrote: “there is absolutely no reason to believe that you are going to do a better job than you did the first time”.

Astute readers might notice that I did not include Red Hat and GNOME Shell in the list of “custom user interfaces” in my list. That is because of the way this project started, and is being developed. The project grew from the ideas of the Pyro Desktop and the Online Desktop & BigBoard, both show-cased at GUADEC back in 2007 in Birmingham, the core design grew from a User Experience Hackfest in 2008 which happened during the Boston Summit, and has evolved in a public wiki. The source code has been public from the start, with a public mailing list, and a designer who has been openly communicating design thinking, and crying out for outside contributors.

I have been telling people for a while that transparency does not equal democracy, that it is possible to have a coherent design in a community-developed project – all you need is a designer that the developers trust who can communicate what is important about his design, who is not afraid to adapt his design based on feedback, but who has the last word on what gets written.

Canonical, and other vendors, do this by appointing a designer, and basically forcing developers to implement what he comes up with. But there’s no reason it can’t be done in the community – as it has been in the past (Seth Nickell’s design of the desktop file chooser, mostly implemented by Federico Mena Quintero, comes to mind).

I fear, however, that this is just another step in a pattern which has been coming for a while. Jeff Waugh said it well today on Twitter: “Unity as default shell == brand before community, differentiation before collaboration.” Canonical values the Ubuntu brand, as they should – but in recent times there has been a move to favour that brand over a better core product that all can share. Unity and Ayatana are merely the most recent in a chain of projects pointing in that direction. Canonical has long had to defend a relatively low contribution level to upstream projects, preferring to position themselves as an integrator, adding fit & finish. Even for public projects like 100 paper cuts, I have been told that there has been limited success in getting patches integrated upstream – I have heard anecdotal accounts of patches that were “evil hacks”, or fixes which were expeditiously made to Ubuntu or worked around a symptom without fixing the root cause. I can’t attest to this – a spot check of 5 paper cuts showed me one Ubuntu-specific fix, one “CLOSED INVALID”, one fix which was rejected, and two fixes integrated upstream.

Back in July, when the GNOME census came out, I commented on Jono Bacon’s blog entry on the subject:

Canonical’s strategy is to develop new features for the desktop, which have not (yet) been included in GNOME.

This is a strategy which has back-fired on a couple of people in the past – it’s not enough to work on something and then propose it for GNOME as a “take it or leave it” choice – the GNOME developers often have feedback on design decisions and request some changes which you mighht not be prepared to make in developed software, but which might be OK to make in a spec […]

One thing I really want to avoid is the creation of a siege mentality of “Canonical vs Rest of the World”, which is counter-productive to the goal of increasing the contribution of Canonical to core GNOME. It’s good to be aware that Canonical are not maintaining core modules, and look for easy ways we can help that happen. Proposing new modules is one path toward that, and contributing to the maintenance of some modules which need it is another.

Unfortunately, this choice of Unity as the desktop user interface, instead of supporting the steadily progressing GNOME Shell project and trying to influence the direction of that project, is another step on the path to the siege mentality. This move will inevitably garner some support from within Ubuntu, and much criticism from the rest of the GNOME ecosystem, further isolating Canonical and the Ubuntu community from the rest of the free desktop development community.

The best possible outcome I can see is that one of the two projects will become an obvious choice within a year or so – and at that point either GNOME will adopt Unity (if Canonical drop the copyright assignment requirement) or Canonical will adopt GNOME Shell (if, as I expect, Canonical struggle to get Unity to the quality standard their users expect). A worst case scenario would see both projects suffer from the competition, putting the free software desktop another two years behind in its quest to beat Apple & Microsoft on features & functionality.

GNOME Census report released

I was delighted to see that the GNOME Census presentation I gave yesterday at GUADEC has gotten a lot of attention. And I’m pleased to announce a change of plan from what I presented yesterday: The report is now available under a Creative Commons license.

Why the change of heart? My intention was never to make a fortune with the report, my main priority was covering my costs and time spent. And after 24 hours, I’ve achieved that. I have had several press requests for the full report, and requests from clients to be allowed to use the report both with press and with their clients.

This solution is the best for all involved, I think – I have covered my costs, the community (and everyone else) gets their hands on the report with analysis as soon as possible, and my clients are happy to have the report available under a license which allows them to use it freely.

You can download the full report now for free.

GNOME Training confirmed!

A few days ago, I took the risk of setting off alarm bells on the GNOME developer training sessions planned for GUADEC this year. It was a risk, and comments from the naysayers reminded me that it’s easier to do nothing than it is to take a risk. I’m happy to say that the risk paid off.

Thanks to all who spread the word, a couple of prospects I was aware of confirmed their presence on the course, and I received a new group booking. The training is now feasible, and we are confirming that it will happen. There is still room on the course, and I expect to sell a few more spots in the coming days.

I did get one interesting suggestion in a Twitter reply to the announcement, and I’ve adopted it. If you are interested in attending one or two of the modules (say, community processes and the GNOME platform overview, but not the practical session or Linux developer tools), you can do so for the much lower price of €400 per module and €750 for two modules, not including a GUADEC registration.

Anyone who would like to avail of this offer, please contact me, and we will take care of getting you signed up.

Thank you all for your help and support!

GNOME Developer Training in danger

The take-up on the GNOME Developer Training sessions at GUADEC (pdf brochure) has been below expectations. Without going into the details, we’re in a situation where running the training would cost the foundation and the organisers more money than canceling.

If we have not had a number of people sign up for the training by Wednesday evening, we will unfortunately be in the situation where we will have to cancel the session. The GUADEC organisers sign the final contracts with the university for room reservations on July 1st, and that will increase our costs substantially, so that is our deadline for viability.

I hesitated for a long time before writing this blog. It’s never nice to have to admit that something you thought was a good idea, that you put together and made a reality, might not work out.

Many people have, over the years, said that the lack of training options was a major flaw with GNOME. With this training offering, we gave people what they were asking for, with a two day training course plus the flagship GNOME conference for less than you would pay to attend another technical conference. If we cancel this training session, there will likely not be another. The credibility of the foundation (and, I suppose, my credibility) will take a hit.

I decided to let people know in advance that the session is likely to be canceled, to have a chance to stop that from happening. I have confidence that the GNOME community can come to the rescue here, in some sense.

I am sure that there is interest out there. Perhaps people have not yet gotten budget commitments to send developers along, but that they’re still working on it. Perhaps there are people who really should know about the training who don’t yet, because I haven’t managed to get in touch with them. Perhaps a couple of people were planning on signing up, but haven’t gotten around to it yet.

If you are in one of these categories, please get in contact with me soon. If you know someone who would benefit from the training, please let them know, and point them to the brochure and web page. If I have a relatively small number of commitments to attend by Thursday, the training will go ahead.

Thanks everyone for your help and support – I will keep you posted to any new developments.

GNOME Developer Training at GUADEC

I’m delighted to announce the availability of GNOME Developer Training at GUADEC this year. It’s been brewing for a while, but you can now register for the training sessions on the GUADEC website.

Fernando Herrera, Claudio Saavedra, Alberto Garcia and myself will be running the two-day course, covering the basics of a Linux development environment and developer tools, the GNOME stack, including freedesktop.org components, and the social aspects of working with a free software project, being a good community citizen, getting your code upstream, and gaining influence in projects you work with.

The developer tools section will go beyond getting you compiling the software to also present mobile development environments, and the tools you can use to profile your apps, or diagnose I/O or memory issues, dealing with the vast majority of performance issues developers encounter.

This is the first time I have seen a training course which treats the soft science of working with free software communities, and given the number of times that people working in companies have told me that they need help in this area, I believe that this is satisfying a real need.

We are keeping the numbers down to ensure that the highest quality training & individual attention is provided – only 20 places are available. The pricing for the training course is very competitive for this type of course – €1500 per person, including training, meals and printed training materials, and a professional registration to GUADEC, worth €250.

If you register before June 15th, you can even get an additional discount – the early bird registration price is only €1200 per person.

I’m really excited about this, and I hope others will be too. This is the first time that we will have done training like this in conjunction with GUADEC, and I really hope that this will bring some new developers to the conference for the week, as well as being a valuable addition to the GUADEC event.