Constructing the Bazaar: Taking advantage of the open-source development model in your project
November 6, 2007 Leave a comment
A great post by Juergen about the Open Source development model. If you truly want external community participation, it’s not enough to just throw code over the wall – you have to make participation as easy as possible.
Think distributed and think part-time to enable the Bazaar
And this then provides us with the answer to our initial question: Why do so many open-source projects not have the active community of external contributors they are hoping for? Because they have been largely developed by co-located teams of hired software engineers, 100% dedicated to the project, managed and organized like any traditional software development effort. This seems to be especially true for the new crop of ‘custom build’ open-source companies, which would like to take advantage of the open-source business model. They might hope to also enjoy the advantages of the open-source development model one day, but achieving that requires a conscious effort.
Here are a few things to keep in mind then:
* Do not be seduced by the simplicity and ease of communication that you have in your co-located team.
* Always consider what it would take for any new, external developer to jump in quickly and become productive, even if this developer can only use much less direct communication channels.
* Consider that external developers can only work part-time on your project, and do not have the time to follow long discussions or become truly familiar with your system down to the last module.
* Always remind yourself to focus on the distinct and simple (!) modules in your design and reflect them in your code accordingly. External developers may only have time to dive deep into one or two of the modules, not the entire system. Minimize extensive system understanding as a prerequisite.
* Always make sure the modules and their APIs are defined and documented clearly.
* Use code reviews to prevent any more direct usage of a module’s code that would circumvent the APIs in any way.
* Enforcing encapsulation via the programming language is not sufficient in this situation: Particularly insidious and hard to spot is the code that relies on knowledge about the internals of another module, even if it does not take short-cuts around the APIs. This problem can be caused by APIs that are designed with the assumption that the user of the API knows a few internals of the module. In co-located teams with effortless and direct communication, this is a trap one can fall into easily. Therefore, we need to strive to build our code with true knowledge isolation in mind.
Conclusion
If these points are not considered on a daily basis, the code does not have the level of modularity and simple APIs that are needed to facility bazaar-style development. Even the best intentions of new, external developers can be frustrated by unnecessary prerequisites. And as anyone trying to build a community knows: The most important ingredient is to make it easy to join and get started. In our case here this means: Make it easy to be productive and achieve the rewarding feeling of success.
As Juergen mentions, this is something that’s taught in the most entry level of classes. It really is something we all know. It’s all too easy to take shortcuts though, especially when deadlines are looming and a quick chat with a person in another team lets you use undocumented internals to save time. Being cognizant of this trap will serve you well, and save time, in the long run.
–jeremy
Jeremy's Blog 