I was fascinated when I read the new Mozilla development roadmap yesterday. When mozilla was in it’s late 0.9.x’s I got quite interested in how the project works, and so seeing their new plans is cool. I’m all for the move away from a monolithic application suite to having a gecko-runtime-environment, since I think it’ll for them to clean up a few areas that are currently a bit bodged – separate processes is one of them, profile shenanigans is another. Since they are moving to a plugin architecture for what have until now been fully integrated parts of the suite, it’ll hopefully force improvement of the way the rest of the plugins work. And then, perhaps, plugins on linux won’t suck quite as badly as they do at the moment (editing permissions on parts of the chrome since I run mozilla as a user, but have to install the plugin as root, is a nasty bodge, and I think they know it). I’ll also be interested in something that I haven’t seen mentioned yet – the use of gecko in little ‘toy’ programs (ie not mahoosive embeded things like the Oeone desktop). When the GRE is sorted out, it should be pretty easy to write little desktop tools for specific things, using a hugely powerful xml / html rendering engine as the backend – perhaps a bus-route planner or weather charts (or maybe, perchance, a calendar or irc client) – specific little programs with their own interface (XUL, natch) that get around some of the proplems of trying to present every web application as a website.

Heavily intertwinned with watching an open-source software product evolve is watching the way it interacts with certain part of the community. Perhaps the most important avenue of interaction is through bug reporting databases, but I’m concerned that there is a limit to their scalability. Not due to anything technical, but due to the signal noise ratios that seem pandemic in the Open Source community. When a project is particularly large, such as Mozilla or Mandrake, there are enough people who think it is their right to demand fixes to bugs that it makes it hard to use the bug-reporting systems properly. In my experience, there seems to be a fair crowd of people who’s sole participation in mozilla is bitching about their pet problems not being fixed. I read another one today, in which some-young-guy was claiming it ‘unacceptable’ that a bug he filed a few years back still hasn’t been fixed. Unfortunate, perhaps, but the mozilla developers don’t owe anyone anything. He also seemed confused about the role of paid developers in the mozilla organisation – they are being paid to work on the code, true enough, but they still don’t have any obligations to anyone other than their employer. So how this guy worked out that it is ‘unacceptable’ is a bit weird. But common – MandrakeClubs package voting system (where you get to vote for what programs should be compiled to be in each version of mandrake, or added later) is getting pretty full up with people trying to hijack the system for other purposes – demanding the distribution on 650mb (or 700mb) cds, recompiling the distribution for different architectures, that kind of thing.

The Mozilla developers have come up with elaborate ways of trying to deal with the noise – priorities, severities, dependences, the old ‘make this release not suck’ bug-tracking bugs, which have evolved into the mozilla1.4blocker? system, keywords and whiteboards, but they barely seem to cope. For the code, there was proliferate cvs access, so then code reviews were required, and then super-reviews to make sure that each bit fitted in with the rest of the project, and drivers, and branch drivers, to steer the project. And then bonzai, the web interface to watch the tinderboxes – computers that compile and recompile mozilla twenty four hours a day, to make sure that none of the checkins break the tree. And then there’s all the codewords (lxr, bonzai, tinderbox, trees and everything else I’ve just mentioned), designed to stop people poking their grubby fingers into the machinery. Perhaps not designed that way, but certainly evolved as such – and it makes the project harder to understand, and harder to get involved in. Perphaps the lack of understanding, and the barriers to entry, lead to bugzilla being so abused…

So if you want to get involved with Mozilla, how do you go about it? Basically, you can’t. You could file bug reports (but there’s millions of other people doing so, so face it – you’re unlikely to be the first to report that problem, it’ll just be another dupe), you could help mark dupes (but with tens of thousands (actually 200,000 in total) of bugs, rfes, wontfixes, wfms (it’s those mozilla-codewords again) finding dupes is not something you could do as a hobby), or more practically just stick to some advocacy. Unless that is, you’re a star programmer, in which case dive right in – but be prepared to deal with all the whiners that are tagging along for the ride.