Ben Collins-Sussman and Brian “Fitz” Fitzpatrick talk in
this Google Talk about the business reasons behind open sourcing code, as well as how to successfully build a community around the code. In this entry I collected their arguments.
Reasons for going Open Source
- Better product
- real relationship with users
- PR
- goodwill from techies
- gratis contributions
- disrupt market (especially if product is good)
Community Health
Without a community, a project is only dead text. Important indicators for the health of a project are the usage, but not the number of one-time evaluation downloads, the number of active developers, and a constant flow of improvements and releases.
How to make it right
First Ben and Fitz’ talk about the different models how corporate Open Source projects are initiated. The biggest problem they identify: control. Without relinquishing control to the community, there is no common trust base built. But this trust base is the thing that attracts high quality contributors. Therefore they recommend to really create a separate organisation to govern the project.
A example: Ben and Fitz worked for
Collabnet, the primary sponsor and founder of the
Subversion project. When Collabnet hires a new programmer to work on Subversion, he had to submit patches to the mailing list for review and “prove” himself to the community before receiving commit rights. Doing it any other way would alienate contributors from outside of the company, since they are under privileged now. Going the long way for employees too, sends a message that everyone can join the community and eventually receive commit rights. This creates a trusting environment.
Word of warning
While opening the development process brings strong long-term benefits, it has to be said too, that no short term improvements should be expected. Also, founders must pay attention that the goals of the company and the community are aligned and stay that way. This can be facilitated by writing an up-front mission statement which acts as a filter for all parties.
When hiring new programmes to work in the project special care has to be taken, that they can integrate into the community and are able to work in the greater team.
Good Feedback == Improved Productivity
Using Fitz’ words: “If they’re running the wrong code, it doesn’t matter how much they are writing.” (19:30) The tight feedback loop and direct contact with users in open source projects focusses developers much more on the really needed features and really troublesome bugs.
“Build Your Community”
Under this heading, the two gave tips and tricks how to build a successful open source community. The most important factor seems to be the right choice of founding members and the establishment of a strong, respectful culture.
A successful project needs goals to attract users and contributors. Typically the founders benefit from these goals only indirectly and in the long run. To help attract the right people, a published mission statement is important. The statement should clearly communicate the core ideas and focus the community members by defining a scope.
Another important step is the preparation of the founding team (especially developers). Ben and Fitz recommend the
Producing Open Source Software book from their former colleague
Karl Fogel. Beside the obvious points, like communicating the structure and mechanisms of the new community, it is important to get the developers to realize that external feedback is intended to improve the product and is no personal attack.
The neccessary public infrastructure is at least a mailing list, a repository and a bug tracker. Internal mailing lists are dangerous, because they undermine the community trust and prohibit communication of internal efforts to the public. For the public mailing lists, it’s important to start with only one list to focus communication and contributors.
After the setup of the infrastructure, the last step is to publish the project and create interest in the various pertinent media to attract developers and users. As one of the very few shortcomings of this talk, they glossed over this topic only very superficially.
Conclusion
A interesting and funny talk about the genesis of open source projects in the commercial context. Packed full with tales and practical recommendations, Ben and Fitz navigate the listener through the challenges of such a founding.
