-
-
Notifications
You must be signed in to change notification settings - Fork 320
Open Source does not win by being cheaper
I cannot count the number of times I’ve heard, “This product is X, but open source.”
And I’ll admit it—I’ve done the same when describing Lago. When I’m not in the “startup pitch” mood, I default to, “We’re Stripe Billing, but open source”. Or my co-founder might say, “We’re like an open-source Chargebee.” Frankly, it gets the job done.
Of course, if that’s all there was to us, we would have failed by now. What we’ve learned is that open-source tools can’t rely on being an open-source alternative to an already successful business. A developer can’t just imitate a product, tag on an MIT license, and call it a day. As awesome as open source is, in a vacuum, it’s not enough to succeed.
To be clear, I’m talking about open-source projects that compete with popular paid solutions. Commercial open source, so to speak. Some community-driven, sponsored products—like React, TypeORM, or VSCode—have different priorities. They are either bankrolled by a larger organization (e.g., Meta for React) or rely on donations to fund development (e.g., TypeORM). They aren’t businesses at heart.
But open-source companies, like us, need to be more than just an open-source alternative to succeed. They either need a concrete reason for why they are open source or have to surpass their competitors.
Excluding non-profit projects that are sponsored by donations or parent organizations, a typical open-source business needs profit to be the ultimate north star.
For some, this might be a tough pill to swallow. But a for-profit business exists for profit. Definitionally and practically. Profit is what allows the company to hire employees, grow, and sustain itself—it is quite literally what funds ongoing development. And there’s nothing wrong with that; the fact that businesses can be profitable while building free software is a great thing. It’s not that open-source companies aspire to gouge customers—but they do aspire to remain in business.
This is precisely what has enabled MongoDB to grow into one of the largest databases with over 4,600 employees. (Granted, MongoDB eventually switched to a special SSPL license to add specific restrictions on Cloud Providers from distributing a service without contributing to the project, which isn’t OSI approved, but is open-source practically).
But why make this point? Well, splitting the hair between profit and usage is important to measuring long-term success. If a project gets great adoption but cannot drive revenue, it will die. Some wishful thinking might argue that the community will take over, but there’s been little evidence to indicate this happens.
Catering to the price-conscious is a losing battle.
Imagine a buddy who wants to create an open-source version of Amplitude. She argues that Amplitude is pretty expensive, particularly prohibitive for some early-stage companies, and larger companies could save a fortune by using an open-source version.
In theory, sure. While this pitch might resonate with early-stage companies, those same price-conscious early-stage companies will either use an open-source version or a free tier. That is not enough to sustain the business. Building a cheaper alternative is typically a ticket to future bankruptcy.
What about larger companies? With some caveats, larger companies aren’t worried about going out of business because their Amplitude is too expensive. They might be price-conscious in terms of negotiating a contract in context of their budget, but most SaaS software is just a line item at the end of the day. What matters more is that the solution is (a) a good solution, (b) around for the long haul, and (c) easy to manage. And, unfortunately, deploying an open-source solution can be tricky to manage.
The caveat is if the solution is a massive cost on the overall budget, then a corporation may seek out a more price-friendly solution; there are plenty of companies that needed to kick Oracle when their database costs skyrocketed due to usage. But most open-source solutions aren’t replacing a top-three line item, and therefore price isn’t the north star deciding factor.
A great case for an open-source solution is when a transparency problem is present. What is a transparency problem? It’s when a solution being closed source creates distrust between the client and vendor.
Let’s return to the previous example—open-source Amplitude. That product actually does exist, and it is winning: PostHog. Growing with Airbus, DHL, and Staples as clients, PostHog combines a few product SaaS solutions together and is open source. It’s actually super open source—even the blog source code and roadmap is available publicly. We’ve modeled a lot of our open-source mantras after them.
PostHog is positioned as a better product than its competitors because analytics tools need to process sensitive client data such as IP addresses, names, session recordings, etc. In a world of increasing data regulations (e.g., GDPR and CCPA), it can be daunting for third parties to store that data. So PostHog provides an alternative—either (a) self-host an analytics solution yourself or (b) hire PostHog as a third party to do it, but with transparency into how that data is stored and how possibly migrating to self-hosted in the future would work.
This split is important. Even if the most privacy-conscious technique is to self-host the open-source solution (which often leads to no revenue for the developer), many companies will still opt for a hosted model. But they do so now with assurances of how the software works—line by line—and the process of migrating to a self-hosted model in the future if necessary. It’s not that open-source companies win by preventing the need for a third party; they win by allowing for the open audit of how it works.
Nowadays, there are many early open-source solutions taking advantage of these selling points. Medplum is an open-source electronic health record platform competing with closed-source incumbents; being open-source gives users assurance of exactly what is and isn’t supported by the platform. SuperTokens is an open-source alternative to authentication solutions like Auth0; logins deal with sensitive data including names, emails, and passwords, and by being open source, Supertokens is able to capture more trust. TableFlow is an open-source alternative to CSV import platforms like Flatfile; once again, the imported data is sensitive.
One of the biggest ones is Minio, which is an open-source alternative to AWS S3 storage. Given that S3 often stores customer PII (either inadvertently via screenshots or actual structured JSON files), Minio is a great alternative to companies mindful of who has access to user data. Of course, AWS claims that AWS personnel doesn’t have direct access to customer data, but by being closed-source, that statement is just a function of trust.
The list goes on and on. We could say the same about our own story; we deal with billing and product usage information, which is pretty high on the list of sensitive content. By being open source, we’re able to better build trust among our users.
One of the big benefits of open source is that it opens the development of niche features to the community. While the core product is typically maintained by a central engineering team, integrations or plugins are often built by community developers and then occasionally merged into the main branch. Conversely, closed-source solutions struggle with this because they rely on their engineering team
This is particularly advantageous for open-source companies building systems that require lots of connections with other libraries, frameworks, or applications. For instance, Airbyte, an open-source ELT platform, blew up because of community-driven additions to its connectors. The same could be said about Elastic, an even bigger originally open-source company that hosts a bastion of data integrations.
One of the founders I’ve met is Advait Ruia of Supertokens. For them, extensibility was a core part of their value proposition, as their community members are able to build integrations with uncommon authentication providers, benefiting everyone.
Both of the above issues contribute to commercial open-source being a better product in the long run. But by tapping the community for feedback and help, open-source projects can also accelerate past closed-source solutions. PostHog—who raised a $15M Series B—started as an alternative to Amplitude and FullStory, but has accelerated into a massive, encompassing solution that even competes with LaunchDarkly and Pendo. This happened over the last few years, and they heavily credit their community as one of the core reasons.
Open-source projects—not just commercial open source—have served as a critical driver for the improvement of products for decades. However, some software is going to remain closed source. It’s just the nature of first-mover advantage. But when transparency and extensibility are an issue, an open-source successor becomes a real threat.