<aside>

Building a commercial company around an open source project gives you an immediate audience, but it doesn’t give you immediate access to that audience. You need to find a way to reach them. For example, you can’t expect a project maintainer to give you access to their email distribution list just because you are building around the same project. They may have no initial interest in partnering with you or promoting your product.

Some ways to reach your built-in open source audience:

  1. Community contributions: Spend time making meaningful contributions to the project and helping other contributors out.
  2. Services instead of alternatives: Provide services to the project through hosting the project or working on the specific needs of businesses using the project.
  3. Content marketing: Write about the project and how you’re contributing to it, using it, or planning to improve it. It gives the project and your company visibility with the audience.
  4. Hacker news: Join Hacker News and start engaging with relevant conversations and creating content the community would find interesting enough to share and comment on. Use “Show HN” to share something you’ve made that people can interact with. “Ask HN” when you have questions the HN community can help you out with.

Improve the open source code faster than before

A common community concern when companies form around open source projects is that development will slow down as resources get diverted to proprietary features. It’s important that the open source part of the codebase expands more rapidly than it did before the company existed. Most of the people at your company are net new. As long as one of them sometimes adds something to the open source codebase, the open source codebase should be better off.

Focus on value creation over reputation management

Many founders get paralyzed by concerns about how the community will perceive their commercialization efforts. The best way to maintain community trust is to consistently deliver value through your open source contributions and maintain transparency in your approach. If you're contributing meaningfully to the open source project and being transparent about your business model, the community will generally respond positively.

Telemetry is opt-in by default

Telemetry should be on by default, with an option for users to opt out. Otherwise, most users won’t enable it. Telemetry collection must be completely transparent:

  1. Document exactly what you collect, why you collect it, and how it benefits users.
  2. Provide clear opt-out mechanisms and never hide data collection behind unclear documentation.
  3. Write a blog post explaining your telemetry approach. Detail what data you collect, what you don't collect, and how it helps you improve the product.
  4. Make it easy to disable. Show that you respect user privacy and aren't trying to hide anything.

Include a value-exchange

When adding telemetry to an open source project, you need to include a value exchange for the user. For example, when users have telemetry turned on, it checks if they are on the latest version, and users get automatic vulnerability alerts.

<aside>

Example message

We see # installations getting hacked, so we’re showing vulnerabilities in the interface. You can enable these proprietary features if you share more data with us. Enable telemetry to get automatic notifications when there’s a security vulnerability.

</aside>