The incompatibility of open core and profit

Open core is the only way to really monetize open-source software. You see this issue with core-js, you see it with mold linker, which went "open core" in a desperate attempt to get more funding.

At the end of the day we must remember that people need to make money and most simply don't have the time or desire to make open-source for free. And until more people actually get adequately paid for making open-source, open core should not only be tolerated but encouraged. Because the alternative is open-source projects dying or people just not making open-source at all.

Now there are definitely people and companies that put "open" on things which are not open* (e.g. OpenAI, or any ML company which claims a model is open-source but does not distribute the weights). But if a project has 100% of the code public and an open-source license, the project is "open-source" and the owner can't just take it back. If they try, or try to steer the project in a proprietary direction, the community can fork.

So open-source with paid auxillary services, support and training, and a GPL (maybe not AGPL) license is still open-source and IMO completely fine. Ultimately, the ability to fork and self-host is what differentiates real open-source from fake.

* Because on the other hand, providing a facade of open source is usually also the only way for many to popularize a commercial library. For many reasons, solo developers and businesses don't want to use closed-source binaries. Some other SE projects e.g. languages are like this as well. So we have genuine people just trying to make a living and greedy executives abusing buzzwords both choosing "open core".

Open core in data isn't even close to new: We've had companies contributing to OSS databases, while selling extensions with a bunch of extra features, back when noSQL was all the rage. Back then, I was called to rescue a large distributed system where the architect had bought on the commercial offering, and managed to rely on basically every single feature in it. He hired his engineers from the conference circuit, including some that had written books, thinking this was giving him a good talent. And yet, the system wasn't working well at all: Almost everyting appeared to work on unit tests, but nothing worked well in production for hard to track down reasons.

Given the instability, I started by mistrusting everything in the system, and it didn't take me too long to realize that every single extension feature from the for-pay distributed database wasn't actually doing what it said on the tin, or it performs orders of magnitude worse than anyone expected. Only the open-sourced features, which had been used in production all over the place, and had received sufficient patches to be reliable. Everything that we were actually paying for was mostly worthless, and needed to be engineered around. The real value of open source here had been a very large user base that guaranteed a semblance of quality. Since for-pay features were available only to the few for-pay customers, the company was faking it until they made it... and there was a lot of faking.

This is the ultimate problem of open core v profit: the quality of the OSS has to be rally high to get any actual open acceptance, but every second spent on the OSS system is one you aren't spending on the parts that get you revenue. If you make the OSS system too hard to use, there's little value from the OSS bits, but if all you are missing is a tool or two, someone can build open replacements, which might actually beat yours anyway.

It's not absolutely impossible to end up with a working company like this that is more than a glorified consultancy, but the success rates are just very low. The fact that this is true, and well known, also makes people purchasing tools be wary of the model, you don't want to build your infrastructure around a tool that quickly goes on life support. So all in all, going for this model is quite the gamble.

I've been thinking about this problem a lot, since I'm trying to figure out how to sustain our open source project. Our project is complex enough that it requires a few full-time people to maintain it. Our current funding comes from a grant, which is not sustainable in the long term.

I'm philosophically opposed to open core because tying revenue to proprietary features seems like the wrong incentive structure, I can't imagine how you'd avoid conflicts of interest. Plus, I'm building open source software because I believe in user freedom, so proprietary features leave an icky taste in my mouth.

My theory so far is that the open core model makes sense for VC-backed companies that are targeting enterprise customers. Most open core products seem targeted at enterprises, not small businesses or individuals. I assume this is because only enterprise deals can make the amount of money that VCs expect from investment. Of course, this leads to enterprise features being prioritized, which sucks for smaller organizations or people using the software.

I'd like my project to focus on meeting the needs of everyday people. I think we need more consumer focused open source software that is so well designed that it will displace proprietary SaaS software, where the incentive is to provide a service that customers get locked into. Software should be a tool, not a service.

The only project that I can think of doing a great job here is WordPress. WordPress is very easy to use, Automattic builds it, but they are not the only ones to make money from it, and I think the incentives are well-aligned.

I'm hoping I can find a similar funding model where I can build a sustainable project for everyday users without going after the enterprise market and all the sacrifices that entails. We are a non profit now and that keeps our incentives aligned with users.

I might be willing to buy that open core/open source and the standard VC funded "startup" esq business model are incompatible.

But I don't think open core and open source are incompatible with profit or with sustainable business models. Sure, the nature of open source might preclude you from breaking into the millions of dollars of revenue / funding (I dont buy that though, to be honest) but even if thats true those 100x return VC backed buisness models are very, very rare in the buisness world. Thats not how most buisnesses are run, and that's not the same as profit. To be profitable all you need is to make enough to pay the bills.

If you want to write neat software and share it with the world while also making enough money to live comfortably I think that's totally doable. Have seen many independent devs and small businesses doing interesting work in FOSS and making more then enough to live on.

This is maybe one of the most important discussions we could have today and kudos for the bold contribution. So many existing and future risks and opportunities we face are strongly coupled with digitization and choices on how software is developed and used matter a lot to what sort of world is emerging.

This widespread relevance of software is part of the problem: the scope is so wide it spans an enormous range of needs and business models. Given that the financial system itself is becoming almosy fully a digital artifact it is a legitimate question whether e.g., money itself should be "open source"? Whatever one thinks about the cryptobro universe, that proposition cannot be unseen. If money itself is up for redesign (and if you follow the so-called CBDC discussion that is very much the case), what is ultimately our objective? What legally defined organizational structures are available and how do they incentivise delivering on the objective?

The other part of the problem is that it by far not just about source code. Actually nobody has any use for code in pure isolation. The value proposition is always somehow coupled with data and code coming to life so to speak by operating on data. Whether open data or private data. Which opens yet another can of worms around privacy, commercial secrecy, copyright, IP etc.

My humble punchline is that the open source journey is neither easy nor simple and it will get even messier. But the general principle of "doing well by doing good" is valid, it is what binds us all and the alternative is almost certainly a dystopia.

One of the biggest pain points in monetization of open source is that the large companies such as Amazon and Microsoft are in a better position to provide support and cloud hosting for open source projects than even the original developer. That is because because it is open source, the big company is able to see exactly how the internals of the service work. However, the internals of the cloud service are still opaque to open source cloud hosting company. Thus the cloud company is in a better position to optimize and debug the open source product.

In addition, companies like having “one throat to choke”. It is a nightmare for business when different vendors all blame each other. If the service is hosted by the cloud company, there is one neck to choke since they own the entire experience.

In addition, good software engineering practices reduce the moat of the original open source company. APIs and documentation and tests for an open source project should allow an experience software developer who is unfamiliar with the project to quickly come up to speed. Thus, the large company can rapidly acquire expertise in the open source tool if they want to.

Paradoxically, these issues apply most to venture capital startups where there is an expectation of massive valuation and return on investment. A “lifestyle” business supporting open source software is very doable mainly because the returns, while large for the person, and not big enough to attract the large companies. An example of such a successful open source business is I think SQLite where, from Hwaci makes a decent amount of money supporting SQLite, but not enough to attract unwanted attention.

The author is the CEO of one of the companies they say has the solution to this "problem". I guess they technically say that in a footnote, but it's pretty far below the fold.

How can you criticize hosted cloud services for maybe not being open source enough, but then suggest closed source services with an open source interface as somehow being a better alternative?

How can you criticize dual licensing, but then suggest "source available" as an alternative?

> Saying that “Open Source = Good, Proprietary = Bad” is too simplistic. Adopting this mentality leads to businesses that take advantage of unsuspecting victims.

I agree wholeheartedly with the first sentence! But I don't think the author provided any convincing examples to support the claim that open core businesses are somehow taking advantage of users. Yeah, users should be careful not to unintentionally lock themselves into a SaaS that is _technically_ open source. Hard for me to see how _any_ of the author's proposed alternatives are better in that regard.

Open core makes sense to simplify the sales funnel, especially in areas with a strong open-source culture. Most data engineers are quite skeptical towards closed-source software, so packaging something as open-source makes it easy for people to interact with it. Then, if companies already use the tool it's often an easy pitch to sell the enterprise version. Look at Hashicorp for example, people invest hundreds or thousands of hours writing Terraform configs, so when the company finally feels the pain of managing it at scale the decision to upgrade to an enterprise plan is a no-brainer, as otherwise you'd have to either write the functionality yourself or abandon all your existing work and start over with a different system.

So the value of open-core is that companies can get locked into a product without knowning it and without you doing any real sales effort. And when the time comes to sell the enterprise edition you'll have lots of champions within the company that navigate the most difficult aspects of the sales process for your (i.e. identify the decision makers, pitch to them, get management onboard). If you can make this work it's like magic. The other risk is of course that you'll make your open-source version too useful so companies will rarely upgrade, or that someone will just snatch up your work and build their own stuff on top, though that seems less relevant.

This article seems pretty devoid of basic microeconomics? All of this is pretty simple. Unless you go non-profit (which is probably a better move for a lot of these things) you have to stare directly in the face of the following: What are we willing to tell the people -- you can't have X unless you pay for it.

in the long run, you can only get paid for what has a marginal cost; which usually ain't code OR data; so then it's "labor." That's support, maintenance, customization, someone you can call to get help, etc.

I'm puzzled by this article.

It criticizes the open core model by listing some hypothetical ways that it can skew incentives, but completely ignores and delegates to a footnote all the success stories it has made possible. It's missing the entire point of why open core, _when done right_, is a good thing for both users and the business.

In the case of sanity.io, how is it beneficial to the user that the editor is OSS, when their data—the most valuable part of a CMS—is kept behind a proprietary service they need to subscribe to? It's using OSS as a hook to get users tied into a proprietary product.

Secondly, the source available model is indeed not open source, nor, more importantly, free software. Users have no assurance that the software they're using is actually built from the source they have access to. Crucially, they have no rights to modify, distribute or even build the software. This is the antithesis of free software.

Releasing only OSS components is also hardly useful. Sure, developers might benefit from using certain libraries, but the core value of the full product remains locked away. There is no incentive for companies to keep developing these components, since the business doesn't rely on them directly.

All of these approaches are much inferior to the open core model.

When done correctly, with an open core, users have access to a _fully functional and featureful_ product that exists standalone as free software. Only certain features, typically intended for advanced users or enterprise customers, are offered as a commercial product. This can be accomplished in many ways: cloud SaaS, commercial extensions, priority support, etc.

The crucial aspect of making open core successful is that the OSS product should be, as the name suggests, _core_ to the business. This way the incentive will always be to develop this component, which will benefit both your OSS users and paying customers.

There are many companies who've done this successfully: GitLab, Elastic, Redis, Hashicorp, Grafana, etc. These are loved by OSS users and customers alike, and they're certainly not "relatively new in the grand scheme of business".

The reality is that open core is the most successful model to make free software sustainable. There are far too many projects that failed because the developers weren't able to monetize them properly. It's worth celebrating that we have as many successful OSS projects as we do today, and in large part this is thanks to the open core model.

The fundamental friction here is that a lot of software has a short shelf life in terms of value. But it still needs to be maintained. And you can't really build new software without relying on a lot of commodity but low value software. Most software that gets shipped these days is largely open source. Even the likes of Apple, MS, Oracle, etc. that sell a lot of proprietary software use and depend on a lot of open source components.

That's why the world runs on open source software. It's the cheapest way to share the responsibility of this common core of software. The only way really. Doing everything in house is stupidly expensive. Where open core companies fail is in attempting to monopolize their core of software. It's all the downsides of open (people copy your stuff) but without the upsides (you do all the work, at great expense). And by trying to mitigate the downsides, they actually make the problem worse.

The problem with open source companies is that most of their software rapidly loses its value after they start exploiting it. The type of open source company that insists on restrictive licensing (e.g. AGPL) and transfers of copyright tend to fail to create a software community around their stacks that would make them long term successful. That doesn't mean open source is bad for business, but just that that particular style of doing business isn't great. You throw out the baby with the bathwater. You incentivize your users to find (or worse build) alternative solutions. Basically, such companies being successful merely creates the financial incentive for others to do similar things. Launching such companies is easy with VC capital. Keeping them long term relevant and profitable isn't because inevitably a cheaper, more open competitor emerges.

That's why e.g. the Apache licensed ecosystem is highly successful. It regularly spawns new companies and they build on each other's success. And they end up sharing a lot of code. Which then becomes a shared commodity. Such is the nature of software. VCs don't like this because this doesn't produce a whole lot of ridiculously profitable unicorns. But it does create a lot of value. And there is plenty of money that can be made by developers working on such software. Which is why there is so much of it. OSS isn't charity mostly and there are a lot of well paid developers working on it.

There is no incompatibility between Open Core and profit. There is an incompability between FOSS and profit but the motives of "Open Core" are transparent and always have been. It's always been a marketing scheme to entice people into using the full product once your business scales and I don't see the problem with wanting people to buy-in if they are using in at that scale.. I also think the "solutions" presented here are optimistic at best.

Seems like a tradeoff between fixed assets versus variable assets. Writing code that doesn't change for years is a fixed asset. UX is a fixed asset. Somewhat like the construction cost of putting up a building. Maintaining the code and data is a variable asset. Somewhat like maintaining the building. Variable costs scale with the number of users.

With OSS, fixed assets are often overvalued. All of the R&D to get the UX and algorithms working well is easily copied. So, monetization relies on variable costs. Frequent updates. Data hosting. Ironically, buggy and obscure code helps monetization.

I almost became a developer of a successful database product. I attended one of their conferences. That's when I learned that the company made half of its money from consulting. It rammed home a joke I heard from an employee at Lotus Development: job security through obscurity. I left the conference dissuaded.

I recall a game developer had a deferred software release. You could download last year's game engine. But, to have access to the current engine (and thus influence its direction), you had to pay.

I'm starting a startup, and our model will be similar, but not properly open core.

We will have a fully open source library and a source-available server which will be closer to "open source, but you pay for more than 100 accounts. After X years, agpl". This can't be open source because it breaks the definition on free redistribution and no discrimination.

This will require us to create a new license, but while I believe in open source, offering only support is not sustainable, and we have seen too many companies basically stealing the work of others and not giving back anything.

Yes, there are developers and even companies sustained not by the code itself, but they are a drop in the ocean of normal companies for multiple reasons.

Our license is still in development (we don't even have a demo yet), but if anyone knows of discussions on the subject, any idea, any pointer is appreciated.

The big question here is how to construe the relationships between these parties:

    1. The company that is the original and primary developer of a product's source code
    2. Users, either a) other companies, or b) an individual using the product personally
    3. Competitors that would use the source code to sell an identical product

To have a chance of maintaining a sustainable community you typically exclude 3, and 2 pays 1 (modulo segmentation/whitelabeling). The problem is users don't want to give any one developer complete power over their systems and their knowledge to be used as leverage against them, so they want some compensation that guarantees this doesn't happen. I'd say this is the basic market economics-oriented reason why Free/Libre Open Source Software (FLOSS) and Open Source licenses exist; its purpose is to be that compensation and guarantee that freedom.

The problem is that the design of Open Source licenses have over-corrected and resulted in communities that are unsustainable and unable to bring software up to the level of fit and finish that users have come to expect from closed-source products whose lock-in could be leveraged to exploit users.

Open Core doesn't work because it yanks the incentives out of alignment and by construction causes a conflict of purpose.

I suspect a MariaDB Business Source License (BSL)-style license [1] is probably the best tradeoff for a company and community relationship. The basic idea is to start as one type of source available license, and then after a period of time the license of parts of the code 'decay' into a second, typically more libre license. This pushes the company to continuously innovate so their license is worth the cost, and if the company goes totally sideways users are assured that they can pick up the pieces after some fixed delay. Time is the correct dimension in which to solve this problem.

[1]: https://mariadb.com/bsl11/

> It’s simply not economically viable to continue adding functionality to a product that does not generate any revenue.

I'd gently push back on this. If the primary purpose of the open source component of an open core project is to acquire new free users (top of funnel for paid users), then it provides some value. Any work spent keeping the open source experience good is essentially marketing spend and may make sense depending on the ROI. Agreed the incentive is to eventually get those users converted to paid users, but that's not inherently a bad thing IMO. Acknowledge there are better and worse ways to go about incentivizing users to convert to paid.

Overall I enjoyed the post. The latter half felt a bit less concise but intro was strong.

>>From my perspective, blindly rallying behind a business with an open core business model is a recipe for disaster that may lead to future disappointment and failure.

Interestingly the mental thoughts of each party affects the outcome. i.e. Let's say until now 90% of open source projects were fully truly open. Once a large percent say 40%+ are open core as a trick to lure users into a later high cost trap. At some point users will become wise to the trick and open-core will no longer have marketing value. It's similar to food adverts saying "no added sugar", I actually take it as a negative and assume they have a lot of natural sugar or have added something else e.g. salt/fat.

The deeper incompatibility is between open-core and non-profit.

There's a sort of "embrace, extend, extinguish" type of rivalry between the open elements and that which is closed.

You generally end up with fairly vital or significant functionality that gets excluded from the core version.

I think that the most viable way to make a profit is probably from support and consulting around an upstreamed enterprise edition of the software - but even then, something needs to be done to stop the big fish from eating your lunch.

Open Core basically means try-before-you-buy. That is a great deal for the customer, they will know for free whether they can actually benefit from the product. If they can it means it brings them monetary value. If they get "hooked" into that monetary value, it is not a problem.

It is good that people realize Open Core is part of marketing not some highly ethical save the rainforests project. If they are companies they have a duty to know what they are buying, Caveat Emptor.

> Open core is a relatively new model

Sure, if twenty years ago is relatively new. Since that doesn’t seem to be the way “modern devs” prefer to think regarding “age”, I’m going to have to stop reading here.

Ex: MySQL was, technically, open core 20 years ago, they weren’t the only ones, and it didn’t turn out to be a major disaster despite some stupid decisions.

Amazon may make more money with MySQL than anyone else on the planet, but “open core” certainly was compatible with a sustainable business.

How do you give people a product that maximizes freedom and privacy without going bankrupt?

It seems like the only way to make money in this industry is to strategically cripple your product or exploit your users in some way. It’s deeply dysfunctional and twisted.

I can’t do my best work and make a living. I have to create something that is worse in some way than what I could create or nobody will pay for it.

What about creating an open core business around a pre-existing open source project?

I see Open Core Ventures (ala gitlab) trying to do that with FreeCAD. If there already exists a strong community, if the core project benefits from contributions, and the company diverges with proprietary offerings, the main project still wins, right?

I know this seems unrealistic, but rather than change how Open Source works, maybe we should change the rest of society to work more like Open Source?

It could be argued that if 'software is eating the world' and the software is Open Source, then maybe we're heading towards an Open Source world?

Another sad fact, is some open-core projects reject user contributions that add features rivalling the paid product... as you'd expect I guess

Open-core is a red flag to me. Don't expect the OS product to get better over time, more often it gets worse...

By "Open Core" are they referring to "Open Source"?

Interesting look at a tough problem (OSS business models). I'm not sure I buy the solutions, but it sure doesn't hurt to take another look at the issue.

So the article is blaming people who work on software for needing money to feed their families?

> When you break down the go-to-market strategy, it’s easy to see that open core is just freemium with extra steps. The goal is to get as many people reliant on the open source product as possible so they can eventually be monetized.

> The free product you use is propped up by the deep pockets of venture capitalists, and at some point, rent is going to come due. Open core companies need to make a significant return for investors or it will not have been worth it. It may not be tomorrow. It may take 5 years. But rest assured, the pressure will take hold at some point.

> When that inevitably happens, the most likely outcome is that the open source product will stagnate and be “good enough” while the majority of development focus goes towards the money maker. New features only get added to the cloud product.

> Of course, companies will make promises that this will never happen. But these promises exist to assuage the concerns of the current moment, not to guarantee a future state. It’s important to keep up appearances after all.

Sooo what is says is that Open Core goals are mostly to get your users hooked under pretense the software is "open source", while putting just enough features behind the proprietary part that you have no choice using it once your product grows ?

Tokens, ser!