Thread by @stephenrwalli

For the Open Source Business Model challenged: There are projects and products. Projects have communities. Products have customers. Communities have time and no money. Customers have money and no time. Different conversations. Different metrics. 1/n

There is no conversion rate from community into customer. Early adopting community members are not @geoffreyamoore early adopting customers. Don't make this mistake. 2/n

Using open source licensed projects as components in your product build is good engineering economics. To 'build vs buy' you've added 'borrow and share'. Sharing isn't altruism. You have to share because you're otherwise living on an expensive, brittle fork. 3/n

If you DON'T own the project & it is a critical component in the product (e.g. the Linux kernel in RHEL) you probably want to invest 8%-12% in the upstream project. Everyone else needs to be focused on customer-facing solutions. 4/n

If you DO own the project, get comfortable with:
1. The cost to build project on-ramps (users, devs, contributors)
2. The project community will make your product solutions sticky.
3. The engineering skill to manage product trees separately 5/n

4. Owning >50% of upstream if the project is a complement to core product.
5. Owning more if the project is a critical component of core product.
6. It confuses customers if you park your identity brand on the project. 6/n

The OSD provides the broadest surface area for engineering collaboration in any project. You still need to invest to build the on-ramps (users, devs, contributors) to have a successful project (measured in contribution flow).
What are your 10-minute rules? 7/n

Narrow the OSD and you narrow the collaboration. This might seem like an idea if a company has made mistakes in the rules and ratios, but it is no longer the OSD. Move on. One needs to understand the relationship betw open source projects & business. 8/n

For @fred_fertang, @ahachete, @OpenCoreSummit, @mjasay, @andrewolliance. I couldn't write it any shorter. 9/9