Release early, release often

One of open-source guru Eric Raymond's favorite sayings is "Release early, release often". This appeared originally in his seminal work The Cathedral and the Bazaar, which should be required reading for anyone doing open source development.

This has relevance to the current state of the Phoenix Viewer project. The release of 1.5.2.725 - what we're calling a release candidate, mainly in self-defense - was delayed by quite a bit of time relative to our previous schedule of releases. We kept adding features and fixing bugs and introducing more bugs and adding features and introducing more bugs and fixing bugs. Part of the reason there is that the release was delayed for a while, waiting first on my fix of a nasty texture upload issue, and then the completion of the parcel Windlight settings feature.

Regardless of the reason, the end result was the same: we wound up having to do a lot of debugging, and releasing with bugs we'd rather have fixed.

The answer is in Eric's dictum. Releasing early and often both tends to compartmentalize the addition of features and the corresponding bugs, and also tends to make bug resolution easier and closer to the introduction of whatever caused the bug. On top of that, it also reduces the pressure to just push something out before it's really ready, by keeping users happy that features are being introduced and bugs fixed on an ongoing basis.

A case in point here is the support for Display Names. The original feature was added by a developer scratching his own itch. As I've said before, that's the norm in open source development. The feature was originally added to just show the display name int he user's tag and profile, and tested that way. One user submitted a patch, after that version went out in beta test, to extend the reach into local chat windows - but we couldn't add it, at that point, because we were trying to lock it down tighter for the formal release of what became 725.

Then we had a couple of showstopper bug reports - including one that was submitted to us that we agreed to fix before the release, but that apparently didn't satisfy the user, who submitted an abuse report with Linden Lab over it! (I really, really hope I don't find out who that idiot is. He caused a lot of needless pain and agony.) Those delayed the release even further, and got in the way of proper beta testing as we quickly approached the deadline we'd publicly set. The result was a release candidate that isn't bad, but has a few noticeable bugs that really should have been caught before release.

The answer is to release much more often. No, I'm not advocating public betas. What I am advocating is that we release whenever a major bug is fixed or a significant new feature is added and tested. This shouldn't necessarily happen on any fixed schedule, but rather as we get the work actually done. Releasing to a fixed schedule leads to putting things out before they're ready, and rushing to do so - with less-than-optimal results.

What of Firestorm? We're faced here with two conflicting demands: a group of users who want it, and a group of users who will only use it if it's been sufficiently de-sucked. The fear is that waiting long enough to satisfy the latter will cause the former to go off to something else, while satisfying the former runs the risk of the latter trying it, saying "This is just like Viewer 2! This sucks!" and never trying again.

I would argue that we should err, once again, on the side of releasing early and often. We should also make it plain to the latter camp that Firestorm is very much a work in progress, and that nothing is nailed down until the users are happy - so, like the weather in Houston, if you don't like it, just wait 10 minutes and it'll change. That has two benefits: it gets us people actually finding bugs, which is the true power of doing open source development, and it shows the user base in a concrete manner that we are indeed listening to their concerns and working to fix them.

Will we irritate people? Yeah. I think we're going to do that any way we cut it, and that this approach will cause the least total irritation in the user community of anything we might do.