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.

Profit, not usage, is a measure of success

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.

How open source does not win—by being cheaper

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