Thread by @LachlanEvenson

1/There are also a different set of risks and challenges with the OSS business model. I’ll share some that I experienced while working at an OSS startup during my time @opendeis 🧵

https://twitter.com/tracymiranda/status/1483547539353788419

2/Customers want to know “why buy the cow when I can get the milk for free?”. Is your product so much more compelling than what a skilled team can piece together using OSS?

3/Customers/community members don’t want to unknowingly build your product unpaid via OSS. Separate your product from the OSS project and make it clear so they can choose to opt-in

4/Withholding features for product in established OSS projects especially if the community is already asking for the same thing is generally looked down upon. Again it’s important to define where the project ends and where the product starts.

5/If it’s this easy for you to create something then it’s just as easy for someone else to do and follow the same playbook. They will be smaller and can execute faster than you.

6/OSS projects and product can coexist if your up front about what you’re doing and where. Changing the rules over time to support your business model is also generally frowned upon by the community.

7/The margins on professional services or supporting OSS aren’t typically big enough to get VCs excited.

8/There is almost always an incumbent that it’s best to partner with than go it alone.

9/Collaboration over competition. Project over company is a far more durable way to succeed in OSS.

10/Standards take time to build. They do not bend to your companies’ deliverables or timelines. You need to put in the work. There’s no way to supercharge.

11/Claiming you are the de facto standard does not mean that you are. Just as having a flag doesn’t make you a country or give you ownership over land. Looking at the meaning of de facto it states “in fact, whether by right or not”.

12/Build durable relationships with customers, community members, partners and even folks with dissenting opinions always helps avoiding an echo chamber of building things that only your company thinks are important.