Saturday November 13, 2004

Busy next week

Attempting to make up for going quiet the past couple of months...

On the 15th, I'm going to be at the Solaris 10 launch in San Jose, talking about zones (aka Solaris Containers) and general Solaris 10 stuff. A number of other Solaris engineers (and bloggers) will be there as well, talking about new features in S10 and doing demos for anyone interested. On the 16th, I'll be talking at ApacheCon about Solaris, open source, and operating systems futures (trying not to sound too pompous). The rest of the week I'll be at the LISA conference. We'll have a booth running Wednesday and Thursday (though I won't make it there until Thursday), a BOF session Thursday night, and Dan will be presenting a paper we wrote on zones on Friday. If you're attending any of these, look me up.

Friday November 12, 2004

Open development models

I've been thinking for some time about different models for how the initial developer of a technology (such as a company that has previously developed the technology under a proprietary model) can interact with an open source community. There seem to be a number of alternatives:

1. Internal development: the initial developer makes source available for new versions, but does not significantly encourage community development. Users can send suggested changes back as part of bug reports, but have no real involvement with the actual development of the code. Any external site is usually focused on users rather than developers. This is really closed development with an open source code base.

2. Community sponsorship: the initial developer pushes out source updates periodically, but sponsors a community site for open development on that source base. Community originated changes may be pulled back into mainline code base on a case-by-case basis, but in general the community site acts as a separate, independent, branch of the source.

3. Initial-developer-led development: the initial developer leads an inclusive development effort, including participating in that effort in an open and transparent fashion. The initial developer helps establish "ground rules" for the community, but encourages participation (including in decision making) by others.

4. Community-led development: the initial developer either gives up involvement entirely or participates as simply one of many developers, without a significant leadership role.

Although code is available as open source in each of these options, they represent a wide variation in terms of who can participate in development, and how such development is managed. In the case of options 1 and 2, internal development processes by the initial developer are essentially unchanged, and external participation is limited. Option 3 involves merging internal and external development processes, balancing between the goals of the initial developer and the requirements of external development. Finally, option 4 adopts external development processes without concern for the processes or goals of the initial developer.

I think each of these can work given different goals and priorities, but option 3 seems to be the only one that really represents collaborative development between the initial developer and a wider community. Thus, although in some ways this is likely to be the most difficult path (since it represents a balance between different goals and viewpoints), it can also be the most valuable for all concerned.

I'll talk later about the issue of extending and adapting development processes to work with a larger community.