Tips for an Open Source Process

Governance is the word for open source in 2011. Governance breaks down to two topics, structures and process.

The same elements that make for a stable democratic system also make for good open source governance. This doesn't mean you need a balance of powers, or a judicial branch. It means you need the rules of governance clearly stated, and a process that will allow the best ideas to get prompt action from those running the project.

This is true regardless of the type of project you're running, assuming you care about getting something out of your community. Not every project cares. If you see open source as a feature, something that just lets you distribute free and gain customers by dialing downloaders for dollars, then governance and process may not matter to you. On the other hand, community-driven projects badly need a process to give everyone a chance to participate fully. Corporate communities need process negotiated so the companies involved have their prerogatives protected.

Want to know why everyone hearts Apache these days? It's because they concentrated on process up-front, before almost anyone else, and they have it down cold. When you've got a bunch of great minds sharing values, structures and process as well as code, you've got the development version of Camelot.

Most projects are more like block clubs than like states or cities, in that getting people involved in the process matters most. It's pretty simple. Appoint a community manager. Empower them to not only respond to every incoming email, but to get on every social network possible, covering not just your software but the whole category, and encourage feedback. What's most important is for those who connect with you to feel you've connected with them.

Once you have more feedback than one person can handle, then you start needing a process. Focus attention on those who are contributing code, or who want to. As code comes in make sure there is someone on the technical team who can look at the contributions and evaluate them. Try not to reject any. Post them. Someone else might like them.

Once you have enough supporters to make a difference, you need boards. A technical board for the biggest contributors of code and bug fixes, both individuals and companies. An advisory board of companies and community members who can help direct the software's path. At this point the community manager is a liaison between the advisory board and the community. Remember that you're trying to not only drive offers of code, but beta testing and bug reports.

And now you really need a process. You need processes for choosing these boards, for replacing the members, for defining their power over your corporate strategy. You also need a policy for handling copyrights, and a process for negotiating with those who won't assign them centrally (if that is what people choose to do).

You need to make some choices. How much strategic control are you willing to give up? It's important that you consider these choices carefully, and at the right time. Focus on detailed process before there's a need and you're spinning your wheels. Wait until the mob is at the gates and you're hosed – this is how projects are destroyed.

Do all this through a wiki. Be transparent. Be honest and open about both what you're doing and why you're doing it. The broader the participation in your process the better off you're going to be.

Yes, there will be trolls. Part of having a process is having a system for dealing with people who want to do nothing but complain.

The end of the wiki process should be a set of documents defining your governance standards. Then it's simply a matter of following them, including a process for changing them.

In this way you can avoid forks of your code, encourage the growth of the code base, and hopefully grow what turns into a good business, regardless of what license you choose to employ.

Not every project works this way. Five years ago many companies felt that a license could substitute for a process. You had a lot of GPL licensed projects that were little different, process-wise, from Oracle and Microsoft.

Oh, and consider the comments are below part of this process.