#4: Plan, execute, DELIVER
Wednesday, December 27th, 2006This is one post in a series, describing challenges we need to overcome to make free software ubiquitous on the desktop.
We are a somewhat chaotic crowd, the software libre army. Thousands of projects (hundreds of thousands, if you consider Sourceforge as a reference point). Hundreds of thousands of contributing developers from virtually every country and timezone. We are a very loosely coupled bunch.
To a certain extent this loose coupling is beneficial. Work goes on in one part of the free software universe entirely oblivious to work elsewhere, despite the fact that both pieces of work will ultimately land up on an Ubuntu disk. Keeping everything orthogonal is very nice – very UNIX. It means that people don’t have to keep too much in their heads. And that’s worked well.
But sometimes I wish it were easier to keep track of changes and have a slightly clearer view of progress across that whole galaxy. For example, it would be nice at the beginning of an Ubuntu release cycle to have a really confident picture of which projects will produce stable releases during those few months when we can incorporate new upstream versions. It would be even better if, during the release cycle, we knew immediately if there was a *change* in what was going to be released.
This predictability is one of the major reasons we picked Gnome for the first Ubuntu desktop release – we knew with some confidence when it would be possible to ship a clean, fresh “chunk”. And Gnome has been a superb partner in that.
This coordination could go deeper than simply the planning of releases, and release management. One of the big advantages I’ll bet Microsoft has is that they have a single bug tracking system for developers from Office to the Kernel, with everything in between as well. That means that all their developers can have high-bandwidth conversations about any bug in the system. Compare that with the balkanised free software world, where I have to create a Bugzilla account any time I want to work directly with a new upstream. I hope Launchpad’s bug collaboration features will make it easier to coordinate between those bugzilla’s, at least for projects that are using Launchpad or where the bug has already been filed in Bugzilla (LP can link to other bug trackers).
Bugs, feature planning, release management, translation, testing and QA… these are all areas where we need to improve the level of collaboration BETWEEN projects. I think Launchpad is a good start but there’s a long way to go before we’re in the same position that the competition is in – seamless conversations between all developers.