Open Source
Open source has become like a religion. When in fact, it's a business decision.
Open source took the world by storm. Or at least so it seems. Software development was started in an open-source manner in the 1950s when different labs collaborated on building the early pieces of programs. In the 70s, Unix was created by Bell Labs, arguably the most critical open-source project. It was also the 70s where proprietary software got its roots. However, it’s wrong to assume that software was not “free” from the early days. The 80s saw the GNU Project being started, which gave rise to the GNU General Public License, the first widely adopted open-source license that the Linux project started using in 1991. It was only in 1998 that the term “Open Source” was coined as an attempt to get businesses to adopt software and call it something fancier than “free software”. Since open source has been used as a label to market regular software products, consider yourself more righteous than a standard closed-source SaaS product. Let’s dig deeper into the why.
Many new startups have now decided to open-source their source code. Looking at the latest YC batch, roughly a third or so of the companies focusing on developers as a target group are open source. Approximately 5% of all companies from the batch are open source, including many that do not target engineers. Most startups are doing it to go along with the trend and defend themselves against another group of college grads applying to YC with your product’s Open Source X version. A great example of this would be Helicone, which started as a closed-sourced LLM monitoring tool, and once YC had accepted a few open-source versions of the same thing, they also decided to go open-source.
There are valid reasons for being open-source. The one already mentioned, just avoiding competition of open source versions of the same product, is primarily a fad. I would strongly argue that most companies adopt the best tool out there, not a shittier open-source version. Supabase is winning over developers from Firebase because they have a better product, not because they are open source. Being OS allowed them to capture a lot of marketing hype, but that’s all there is. Where open source does shine, though, is helping with hiring. Engineers often prefer working for open-source companies, and finding new employees amongst your contributors helps with the hiring funnel. If someone is a great OS contributor, they will likely also make a great full-time engineer. Another positive factor in the B2B enterprise space is creating trust with your open-source solution concerning security practices and continuity. Some deals might be easier to close if you tell the buyers they can look at the code to ensure it’s secure (they never do and mostly still want a SOC II, but it can help) and tell them they can self-host if you go out of business. Does it make a huge difference? No. While there are upsides to being public with your code, there are also downsides that people rarely don’t talk enough about.
The biggest downside to being open-source is converting your users to paid customers. Many OS projects initially start down-market and get a lot of adoption amongst hobby hackers and early-stage startups who would not make great customers anyway. Making revenue from those users is often a challenging process. While GitHub sponsors, etc, do help with making some money from sponsors, it’s rarely enough to pay even a single full-time engineer a salary. So, while many open-source projects create a ton of value for the engineering community, they rarely capture any significant part of it. I know too many great builders that got a few thousand stars for their repos but dropped the effort after six to twelve months since they failed to monetize their projects. So what’s the alternative?
The alternative is returning to the roots and making money before building anything. It’s fun to build cool shit and get lots of GitHub stars for the thing that you are building. Stars, however, are a terrible approximation of creating value. Thus, to avoid the issue of false signs of progress, builders should focus on making revenue instead. There is always a chance to open source your repo later if that’s important for you. If they paid for your closed-source project, they will also pay for your open-source project!
So, what’s my advice to builders deciding whether to build open source? One, I would not open source before you have made sure you can make money with what you are building. Second, I would not go the OS route too early. It’s cool to have people report a bunch of errors and feature requests, but it can also lead you down the wrong path. In the early stages of company building, listening to valuable feedback is more important than listening to everyone. Feedback from paying customers is gold. Feedback from solo hackers can lead you down building stuff that does not matter at all. Ignoring requests and bug reports can be mentally tough, though, since being responsive and “listening to customers” feels productive. Ignoring the instinct at an early stage can be very helpful.
It’s important to note that going open source is more or less a one-way door. Close sourcing an existing solution with users can piss off people very hard. I have rarely seen it being done successfully. Second, if you go OS, do so smartly and know what you are trying to get out of it. Avoiding open source X competition from YC batches is not a good answer. Finally, if you think of best-in-class software products (Linear, Figma, Framer), none is public. It’s just another testament that nothing great has been built by a committee.