1 Familiar tools
2 Discourage poisonous people
3 Document everything
4 Accessible online meetings
5 Minimize legalese
6 Expert liaison
7 Governance simplification
8 Treat licenses with respect
9 Promote outside committers
(Source: Josh Berkus as best as I can remember his list from my chicken scratch notes – Used under Creative Commons License)
However, I’d like to respectfully disagree with Josh’s patent-pending list.
I’ll going to go out on a limb and suggest that Josh’s presentation, while amusing and interesting, is not as relevant to the OSS movement as we’d like to think. OSS projects of much lore began as truly open multi-vendor / multi-third-party efforts. This was true of kernel.org, many (but not all) Apache projects, and many (but not all) Eclipse projects. But today, the name of the OSS game is 180 degrees opposite from multi-vendor efforts.
If you’re a startup attempting to build an OSS-based business, you will likely ignore #4, #5, #7 and especially #9. If you don’t want to ignore these steps, rest assured that your VC will “encourage” you to do so. You can ignore these steps because they have minimal impact on your ability to grow a successful OSS business or successful OSS community. You don’t want a multi-vendor project; you want a community of users who congregate around a code base that you control. Don’t believe me? Classify vendors like MySQL, SugarCRM, Zimbra, JBoss (not Red Hat – their business is based around a multi-vendor project), Alfresco, SpringSource, Hyperic, etc. against steps #4, #5, #7 and #9.
Let’s not fool ourselves into thinking that OSS success hinges on the same things that were required when the breadth of multi-vendor and/or third-party participation was the key criteria for a “successful” OSS project.
Like it or not, OSS success is beginning to be measured along the same metric that society (rightly or wrongly) measures success…how much money you can make…and making money starts with power/control (of the project).