The Ultimate Guide to Open Sourcing Your Project: Why, What, How, When, and Who

There is no guide book on why, what, how, when, and who(??) to open source a project, so I wanted to write a short one for anyone who is in the position I was in 3 months ago.

I figured this out by studying a bunch of repos and talking to founders who successfully turned OS repos into hundreds of millions of dollars. You get to skip all those steps and read this summary instead. Congratulations.

WHY

Open source is a viable, and probably necessary, strategy for any developer-focused products. The three main "whys":

• Devs generally want to know what's going on under the hood with a product they're using. Maybe this is for fun or maybe this is because they want to tweak some things to make it compatible with their stack.
• Devs want to play with a product before integrating it into a production workload. Paywalls are antithetical to the developer community, so let them drive the car.
• Devs want assurances that if you go out of business, they can still keep their product running. This is in practice the least relevant in many cases, but spiritually the most relevant. Devs want to minimize vulnerabilities, so even if they go to prod on your cloud, the OS helps them sleep at night.

WHAT

It's all about giving devs what they need to feel comfortable familiarizing themselves with your project. Ideally it's useful, easy to try, and similar to the product you're commercializing.

Gabber is an inference provider for TTS, STT, and Omni/VLMs + an orchestration engine for quickly prototyping and productionizing realtime, multi-modal apps on those models. We open-sourced the orchestration engine.

Our CTO Neil has spent 10 years building media orchestration systems (most recently he started LiveKit Agents), so this was the "cool" part of our product.

The orchestration engine allows devs to build realtime apps locally, so they can experience building and getting value from Gabber. If they want to run inference, they can do that, but most teams don't want to.

HOW

Do you go MIT, Apache, Sustainable Use License (SUL)? And what do you do once you've got the repo ready?

MIT - basically wide open. Anyone can steal your code, patent it, and make it theirs. This gets you the most feel good points among devs, but also exposes you to the most risk. (used by many)

Apache - wide open, but other people can't patent your code. (used by most)

SUL (often called "code-available") - open for everything but direct commercialization. People can build whatever they want on your product, but they can't commercialize without talking to you. (used by n8n and Gabber)

Once you decide on this, you, uh, share it with devs.

Find people with the problem you solve (or at least an appreciation for it) and tell them about it. Technical write ups, videos, demos. For us we got a couple million views across Twitter and Reddit simply showing the product to people who like Open Source and AI. HackerNews is also a pretty common place to launch.

WHEN

Timing is pretty standard. You definitely can open-source something early on, but unless the "pitch" of the idea is really compelling (or you're a famous developer), people will want something they can play with. tl;dr don't market a README unless it's a really good README.

You will want to at least have an MVP of your product ready before launching. For us, we had a version of Gabber than ran locally with minimal bugs, along with a couple example apps to ensure it's easy to get started with. This we felt was "enough" for developers to appreciate and hopefully get invested in our project.

And finally, before launching, make sure the front of the house is in order. We checked out a couple of our favorite open-source projects and saw they had excellent READMEs and files labeled with licensing information where relevant. Your goal is to drive interest, and that equation is equal parts top of funnel and conversion. Don't mess up the conversion part.

WHO

I know I joked about this earlier, but I think this section will have the most non-obvious information.

With Dev Tools, developer trust is everything. This isn't SaaS. This isn't consumer. We aren't selling stuffed animals. All of those things are have simple problem -> solution loops.

Dev tools are not always so clear. Developers have a lot of problems, and problems can be complex. Every stack is different, every team has different restrictions and compliance needs. For you to win the business of a developer, you need them to tie your product to a problem they have, but you also need them to have conviction that your thing can actually solve their specific version of the problem (and do so without any headaches now or down the road).

You can try to market your tool to developers, but I can promise you that you want other developers to market for you.

This is why open-source projects exist in the first place. Some people just like sharing, in fact I think most people do (present company included), but the businesses who open source also understand this trust angle, which is why I believe EVERY tool marketed to developers in any capacity should have some open source angle.

Temporal, n8n, LiveKit, Vercel/next.js, Neon, Django, Postgres. These companies have one thing in common (and pretty much just one thing in common) - they're marketed to developers.

If you don't open source, someone else will and they'll at least win the hearts of developers, and that counts for a lot.

SHOULD YOU OPEN SOURCE?

Probably.

But honestly, it can't hurt. There are rare cases where a company will steal from another company, but this almost never happens, and this is the fastest way to destroy your reputation in the developer community.

We've seen some YC startups get caught being a fork of some other project, and while lame, it's rare. For the instances it does happen, open source won't magically create a business, so if you fail to commercialize your product, your product was never going to make it anyway.

For those worried about commercializing, you can start with an SUL like n8n or Gabber, and over time transition to Apache (or make previous versions of your software Apache).

There's no right way to build a start up, but not open sourcing at least some non-insignificant as a dev tool might be a wrong move if you need developers on your side.

Let me know what you think of this on twitter @jackndwyer and if you want to check out how we put together our repo, check it out:

Repo: Gabber Github