Andy Tucker's Weblog

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:

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.

Comments:

There's always 4a, where the development is community-based but the initial community is seeded with the original (internal) community as the key community members. The real question to consider IMO is how an "outsider" can become a committer. The states you mention are all observable "in the wild" but when you're transitioning from 'closed' to 'open' the key is the method by which the governance recognises and honours previously excluded (or new) experts.

Posted by Simon Phipps on November 12, 2004 at 04:36 PM PST #

I think that's the same as what I meant by 3; the initial developer establishes the basic governance model, with the intent of attracting and engaging a community that can operate as peers. There are obviously gray areas in between, as well. I'll get into the committer question in a future entry.

Posted by Andy Tucker on November 12, 2004 at 05:12 PM PST #

OK, fair enough. I think it's important to recognise the "communityness" of the existing developers - the process of going open source seems more a cultural re-alignment than anything. You're not <em>starting</em> a community, you're exposing it and offering the possibility of change or even growth. I think that both of those are a genuine challenge for a corporate development team.

Posted by Simon Phipps on November 12, 2004 at 05:17 PM PST #

I agree with Simon about how you expose the project to the communitty developers. I think that this process is more simple: 1) GPL/LGPL the code, 2) Create one OSolaris Foundation (not only with Sun members) and OSolaris Advisory board, 3) Release as often model, 4) Develop one managed services business around it....Good luck!

Posted by Adriano on November 13, 2004 at 03:16 AM PST #