On new features and open source development

The next version of Phoenix will get a few features backported from Viewer 2:

• Display Names (just added yesterday!)
• Multi-attachments
• Along with that, RLVa version 2

There are two features that are in Viewer 2 that won't be available in Phoenix, period: meshes and multi-wearables (more than one item of clothing on a given layer). I discussed mesh at some length in an earlier entry. I don't know if multi-wearables is all that important, or difficult to add, but unless someone comes up with a drop-in patch for it, we probably won't do it.

There's been a lot of argument, both publicly and within the Phoenix developer community, about whether we should concentrate on fixing bugs and freeze new feature additions. The argument goes that we need to freeze Phoenix's feature set and spend scarce developer time on fixing bugs and stabilizing the code so that we can turn our attention to Firestorm, the Viewer 2-derived replacement. This argument misses the point.

One very clear lesson from the history of open source development is that developers scratch their own itches. Open source developers on a project such as Phoenix are unpaid volunteers. They work on the code because they want to, because they enjoy it, and because it increases their good reputation in whatever community they're working in and serving.

I've managed another open source project, one that's well known within the community that can make use of it, for over a decade. I understand what makes open source developers tick. If that weren't enough, I also, as I've alluded to previously, have been good friends with open source guru Eric Raymond for two decades or so. If I have cultural questions, I pick up the phone and call him and ask.

The history is clear: The most successful open source projects are those where developers are free to do as they want, where project management is done with a light touch, and where people understand that developers are contributing out of the goodness of their heart on their free, donated time. Trying to run a volunteer open source project on the same lines as a business, where employees can be told "do this if you still want a job", leads to a dead project fast. The landscape is littered with examples.

You can only impose a feature freeze on a project such as Phoenix for a limited time, and only right before a new release. Otherwise, developers will simply ignore it and go on. It's possible to extend that period, but only if the consensus of the developers is that it is a good idea. A six-month feature freeze is probably not going to fly, especially in a project where that's an appreciable fraction of the entire history.

Display names support is a good example here. The developer who added it to Phoenix did so in about a day and a half, because he couldn't stand the idea of display names on Linden Lab's website that would not show up in the viewer. He had a very strong motivation to add the feature. Telling him not to would either have been ignored or else caused his resignation from the team.

Key lesson 1: Deliberately chasing off productive volunteers kills organizations. This is true in any volunteer organization, not just open source projects.

Key lesson 2: There's a bit of military wisdom that applies here: "Never give an order you know will not be obeyed." If you tell someone to do something, knowing they will not do so, you not only cause resentments all the way around, and not only don't get done what you need done, you also damage your authority and their confidence in your leadership, with rapidly disastrous effects.

The end result was a good thing. Phoenix will support display names. That will make the feature much more useful to the users of SL. (I'll ignore for the moment the entire controversy surrounding it.) It will also help others to implement it in their viewers. Instead of complaining about it, the right answer is to thank the developer who did it, include it in the program, and go on.

Yes, feature freezes before releases are good practice. At some point, you have to buckle down and fix bugs and get the release as stable as possible before unleashing it on an unsuspecting world. However, you also have to recognize their inherent limitations in a volunteer open source project.