September 2, 2003

Camino 0.7.5?

A number of people have floated the idea of a Camino 0.7.5 to take the place of the nebulous 0.8 release that seems to not have a solid date, a solid feature set, or a solid commitment of time from anyone.

One of the tenents of a bazaar-style model of open source development is "release early and often, delegate everything you can, be open to the point of promiscuity (-ESR, CatB)." Camino has gathered its success, in all honesty, by giving at least the first two ideas the proverbial finger.

Initially, Camino (then Chimera) did release early and often and it garnered a loyal following who couldn't wait to get their hands on the next release. The problem stems from our own success. Camino 0.7 was so stable and polished that people came to treat it as they would a 1.0 product. Releasing another version of lesser quality would be seen as a black-eye to the project as a whole, that quality was slipping, and what once was a promising product was now beginning to collapse under its own weight.

Secondly, While "listen to your users" has a wonderful ring to it, Mozilla is a perfect example of what happens when you delegate UI to a self-selecting group of developers. Camino needs strong direction and someone in charge who has no qualms about saying "that sucks, fuck off". Bad ideas aren't suddenly good ideas just because they come from the open-source community. The project has succeeded because those of us in charge had a singular vision to keep it simple. Apple saw the benefit themselves and Safari shares the same belief.

What we haven't done lately is communicate, to be open and slutty with our direction. We haven't done a good job promoting Camino since 0.7 shipped. That's where we can take a cue from the Firebird Browser team. A roadmap is needed, as is a "Why Use Camino Over Safari?" webpage. We need to get people interested again. Will 0.7.5 help that? Maybe it would, but it could be equally as dangerous.

Right now it seems we're stuck in a catch-22: we can't gather developer interest without shipping a version and we can't ship a version without developer interest. We're triaging bugs because being able to point developers to a single list that we can drive to zarro boogs is, in my opinion, the best way to engage the development community, and what this project has been lacking since AOL began to fund its development. Now that AOL has fully withdrawn all support (even for Gecko itself), we need developers more than ever. I understand that the end-users on the various lists don't give a donkey about bug triage, they simply want new bits to play with. I just don't think we can get them bits without focused development.

Pehaps I need to start doing a road-show, armed with a "why the trunk sucks less" web page and why people should start pulling nightly builds and giving them a test drive. Could that be more important than bug triage, or the same, just different?

Posted by pinkerton at September 2, 2003 9:25 PM