This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Open infrastructure and contribution models
Matt Aslett of the 451 Group has provided a great example of some powerful yet overlooked aspects of some of the most successful open-source projects. The example is a utility called memcached, an in-memory caching daemon to speed up web applications.
The first, oh so obvious yet oh so overlooked aspect: As John Mark Walker noted just today, you have to offer something compelling that others want. Memcached does something people really want: "speed up the performance of dynamic Web applications." Everyone wants that–everyone. On the other hand, if you've got some software even you don't want, you're not likely to create a lively community around it.
Secondly, the recent flood of corporate backers are not tripping over each other in order to sell memcached, but rather to ensure that memcached is available to accelerate their actual product. It's infrastructure. It's an enabler. As I pointed out in Open Core, Open Complement, most of the most effective open-source projects are actually about infrastructure: Linux, MySQL, JBoss, Apache HTTPD, PHP, GCC, Subversion. An infrastructure project enables many users, and hence draws many contributers. Opening your core limits your community's potential audience to just your market; opening your complements limits the audience even further, to the programming-proficient members of your market. But opening key infrastructure widens the audience.
Finally, memcached is drawing this flood of interest and contribution because of its very permissive license, the BSD license. This license is among the least restrictive, most commercial-friendly, of all the open-source licenses. We'll see people charging for their version of memcached; that's allowed. We'll see variant versions; that's allowed. We'll see contributions back to the core implementation, forks, and proprietary variants; all allowed. In the world of "commercial open source," it's not the GPL that ensures the most freedom for the licensed software, but the BSD (and the fairly similar Creative Commons – Attribution). GPL was originally about preventing commercial exploitation, and lately has become popular as the open half of a dual licensing model, but those are both prevention strategies, not enablement. BSD and CC-A are about enablement.
If you're innersourcing, applying the techniques of open source development to enhance your internal process, the same rules apply:
- You have to give away something people want
- You'll have the largest audience by innersourcing infrastructure
- You'll have the largest audience, community, and contributer list if you let go of control