The incompatibility of open core and profit(bytesdataaction.substack.com)
bytesdataaction.substack.com
The incompatibility of open core and profit
https://bytesdataaction.substack.com/p/open-core-profit
97 comments
> until more people actually get adequately paid for making open-source, open core should not only be tolerated but encouraged
Come on, did you actually read the article or skim the first paragraphs?
The authors point is that open core is not a model that enables small time developers to fund their projects.
…it’s a deceptive, deliberate marketing strategy funded by venture capital to run a loss leader and capture market share, then bait-and-switch to a cloud hosted product.
It’s been shown to be successful, and new companies are cynically adopting it as “free marketing”.
Even when the initial ideals are honest, the model is fundamentally incompatible with running a for-profit enterprise due to obvious (and explicitly pointed out in the article) misaligned incentives.
Don’t encourage it. It’s deceitful. If you’re doing it, you’re being a dick. :(
Being honest from the beginning as per the examples at the end of the article are what we should encourage.
Come on, did you actually read the article or skim the first paragraphs?
The authors point is that open core is not a model that enables small time developers to fund their projects.
…it’s a deceptive, deliberate marketing strategy funded by venture capital to run a loss leader and capture market share, then bait-and-switch to a cloud hosted product.
It’s been shown to be successful, and new companies are cynically adopting it as “free marketing”.
Even when the initial ideals are honest, the model is fundamentally incompatible with running a for-profit enterprise due to obvious (and explicitly pointed out in the article) misaligned incentives.
Don’t encourage it. It’s deceitful. If you’re doing it, you’re being a dick. :(
Being honest from the beginning as per the examples at the end of the article are what we should encourage.
The author almost unravels their own argument at the end:
> I just believe that more businesses can find ways to make open source contributions core to their business, without resorting to the typical open core strategy. There’s a lot of nuance in creating better aligned incentives.
Their problem really is just with _this particular behavioral pattern of VC-raising startups whose software is open-core_, which is why they criticize "The Open Core Strategy". They are not against open-core in itself, just that it is incompatible with the profit incentives these companies have, where it quite literally turns into calculating ROI for "how many new users will see this new feature in the Core product and then be converted into paid users within 6 months".
Also, based only off of the description for shipyard they mention here, it sounds like you either can't execute low code templates offline, or can't fork the project without recreating both the UI and the execution logic, both of which seem to violate the spirit of free software.
> I just believe that more businesses can find ways to make open source contributions core to their business, without resorting to the typical open core strategy. There’s a lot of nuance in creating better aligned incentives.
Their problem really is just with _this particular behavioral pattern of VC-raising startups whose software is open-core_, which is why they criticize "The Open Core Strategy". They are not against open-core in itself, just that it is incompatible with the profit incentives these companies have, where it quite literally turns into calculating ROI for "how many new users will see this new feature in the Core product and then be converted into paid users within 6 months".
Also, based only off of the description for shipyard they mention here, it sounds like you either can't execute low code templates offline, or can't fork the project without recreating both the UI and the execution logic, both of which seem to violate the spirit of free software.
>Their problem really is just with _this particular behavioral pattern of VC-raising startups whose software is open-core_, which is why they criticize "The Open Core Strategy". They are not against open-core in itself, just that it is incompatible with the profit incentives these companies have
100%. I want more people to figure out ways to make open source work with the business model. Typical open core tends to end up in a situation where you're serving two masters, but one pays you. Which one would you rather work for?
>it sounds like you either can't execute low code templates offline, or can't fork the project without recreating both the UI and the execution logic, both of which seem to violate the spirit of free software.
Must have been poorly worded then. Our low-code templates are just visual wrappers around Python CLIs that contain no proprietary platform logic. You don't need our UI to run them locally.
100%. I want more people to figure out ways to make open source work with the business model. Typical open core tends to end up in a situation where you're serving two masters, but one pays you. Which one would you rather work for?
>it sounds like you either can't execute low code templates offline, or can't fork the project without recreating both the UI and the execution logic, both of which seem to violate the spirit of free software.
Must have been poorly worded then. Our low-code templates are just visual wrappers around Python CLIs that contain no proprietary platform logic. You don't need our UI to run them locally.
I fear the end game of a fully propieatary software world is that the only real way people interact with computers is app stores, programming is not something people can learn online anymore (but it used to). not even command line, just app stores. the new "hello world" in this dystopia is "go to app store, buy hello world the app, done".
Is it better to keep everything proprietary?
People exist who do open source for a living outside the open core bubble. Take a listen to this video [0] from Paul Ramsey who has built a successful career working on PostGIS (database for geospatial information). It covers his thoughts on the future of open source (spoiler: its not open core).
[0] http://blog.cleverelephant.ca/2019/05/foss4g-keynote-2019.ht...
[0] http://blog.cleverelephant.ca/2019/05/foss4g-keynote-2019.ht...
TLDR?
Attempt at a summary (a very good talk!):
1. Open source produces immense value and ironically locks itself out of capturing the value. In the last 20 years, open source has become the oxygen of software development. Cloud providers do what proprietary software vendors did 20 years ago.
2. "IP is free, support for $$" like Red hat is a viable business model but captures only a very small part of the overall value. The much larger part is captured by private sector selling SaaS, Cloud infra vendors. Software has become a commodity, it is user-facing services that capture value today.
3. The value capturing works fine for the companies but little to nothing of that value flows back to the people who write or maintain the software. This needs to be overcome. Openness is important but we need to value it, and governments as biggest buyers of services play a role. If we valued openness more consequently, it would lead to more opportunities for open source developers to capture value by offering user-facing services.
2. "IP is free, support for $$" like Red hat is a viable business model but captures only a very small part of the overall value. The much larger part is captured by private sector selling SaaS, Cloud infra vendors. Software has become a commodity, it is user-facing services that capture value today.
3. The value capturing works fine for the companies but little to nothing of that value flows back to the people who write or maintain the software. This needs to be overcome. Openness is important but we need to value it, and governments as biggest buyers of services play a role. If we valued openness more consequently, it would lead to more opportunities for open source developers to capture value by offering user-facing services.
I don't see any alternatives to open core there(?). Points 1 and 3 just mention the usual problems with OSS, not solutions.
> "IP is free, support for $$" like Red hat is a viable business model but captures only a very small part of the overall value. The much larger part is captured by private sector selling SaaS, Cloud infra vendors.
Isn't this the value captured by open core? Support is only part of premium services, while companies are free to choose any additional revenue stream (SaaS, extensions, integrations, etc.).
> "IP is free, support for $$" like Red hat is a viable business model but captures only a very small part of the overall value. The much larger part is captured by private sector selling SaaS, Cloud infra vendors.
Isn't this the value captured by open core? Support is only part of premium services, while companies are free to choose any additional revenue stream (SaaS, extensions, integrations, etc.).
I also think that the talk can be seen as suggesting that open core is the preferable way to make a living from OSS - as long as openness is preserved (service implementations can be exchanged, client can pull out their data etc).
My interpretation of why the talk was mentioned as an argument contra open core: - the talk does have criticism for value extraction that does not preserve openness (as the OP says: promises of interop etc are not kept, lock-in... is it really meaningfully "open"?), and that it is not necessarily sustainable or fair for OSS developers ("who pays the postgres committers"). This latter point certainly gets more nuanced for open core, but can still be relevant e.g. when you depend on some library you are interested in its being maintained, having security vulnerabilities identified and patched etc.
My interpretation of why the talk was mentioned as an argument contra open core: - the talk does have criticism for value extraction that does not preserve openness (as the OP says: promises of interop etc are not kept, lock-in... is it really meaningfully "open"?), and that it is not necessarily sustainable or fair for OSS developers ("who pays the postgres committers"). This latter point certainly gets more nuanced for open core, but can still be relevant e.g. when you depend on some library you are interested in its being maintained, having security vulnerabilities identified and patched etc.
The story the essay paints is that for "open core" to be profitable, eventually the company will have to make the "free" version basically unattractive compared to the paid one. It is described as basically a "freemium" model.
So what is the difference between this and if it just weren't open source at all? I see the marketing benefit to the producers of having people consider it "open source", even though eventually they'll be locked in and have to pay for the value they want.
What is the benefit to the consumer? Real question. I'm not certain there is none. Perhaps the open core being truly open source, at least other developers can look at that code as a learning resource, or even fork it into something else? (Note that requires it being really open source, that is legally forkable under a really open source license that will allow it to achieve a life of it's own. Entities trying to do "open core" where the core is licensed under a non-OSI-approved license... we could talk about that). I could be persuaded that makes it better than if it were just proprietary license altogether? Anything else?
So what is the difference between this and if it just weren't open source at all? I see the marketing benefit to the producers of having people consider it "open source", even though eventually they'll be locked in and have to pay for the value they want.
What is the benefit to the consumer? Real question. I'm not certain there is none. Perhaps the open core being truly open source, at least other developers can look at that code as a learning resource, or even fork it into something else? (Note that requires it being really open source, that is legally forkable under a really open source license that will allow it to achieve a life of it's own. Entities trying to do "open core" where the core is licensed under a non-OSI-approved license... we could talk about that). I could be persuaded that makes it better than if it were just proprietary license altogether? Anything else?
> Open core is the only way to really monetize open-source software.
Red Hat has built a business on free software without resorting to open core. Why can't anyone else (according to you)?
Red Hat has built a business on free software without resorting to open core. Why can't anyone else (according to you)?
Kitware has as well. The vast majority of the work done is open. There are, however, customer-specific builds for some things, but typically only "special sauce" stuff is specific to those builds and is much closer to "customer purchased development of a specific plugin" than anything like open core.
FD: Kitware employee
FD: Kitware employee
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.
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'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.
The best I've been able to come up is that freedom 0 applies only to humans. If a non-human entity is running the software, viz. some sort of corporation, then it is not allowed to without a (expensive) license.
I want to make the world better for people, not for Amazon.
I want to make the world better for people, not for Amazon.
I’m a fan of the Sustainable Use license [0] for this reason, for some projects!
[0]: https://docs.n8n.io/choose-n8n/faircode-license/
[0]: https://docs.n8n.io/choose-n8n/faircode-license/
Corporations don't exist. Amazon is made of people: shareholders and staff.
Software doesn't run itself and corporations don't run software: human beings do.
There's no such thing as a non-human entity running software.
Software doesn't run itself and corporations don't run software: human beings do.
There's no such thing as a non-human entity running software.
>Corporations don't exist. Amazon is made of people: shareholders and staff.
>Software doesn't run itself and corporations don't run software: human beings do.
>There's no such thing as a non-human entity running software.
People don't exist they are made up of cells.
Humans don't run themselves: cells do.
There is no such thing as a non-cell entity running humans.
>Software doesn't run itself and corporations don't run software: human beings do.
>There's no such thing as a non-human entity running software.
People don't exist they are made up of cells.
Humans don't run themselves: cells do.
There is no such thing as a non-cell entity running humans.
> People don't exist they are made up of cells.
> Humans don't run themselves: cells do.
> There is no such thing as a non-cell entity running humans.
Biology don't exist, they are made of atoms
Cells dont run themselvs, atoms do.
There is no such thing as a non atom entity running cells.
We has a species have a hard time trusting atoms, they make up everything.
> Humans don't run themselves: cells do.
> There is no such thing as a non-cell entity running humans.
Biology don't exist, they are made of atoms
Cells dont run themselvs, atoms do.
There is no such thing as a non atom entity running cells.
We has a species have a hard time trusting atoms, they make up everything.
And they say HN has no sense of humour.
[deleted]
From his/her wording I assume they mean some unspecified threshold before a group of people is considered a corporation. From my limited understanding I think it could be useful to have a license that is only for free for organizations made of (for example) 10 people or less.
The license is only granted to natural born persons.
The only people who don't grasp this simple fact are the ones who have never worked in a corporation. They very much own and run things legally. Which is why when the liquidation man comes a knocking you don't lose your shirt for owning stock in Enron.
The only people who don't grasp this simple fact are the ones who have never worked in a corporation. They very much own and run things legally. Which is why when the liquidation man comes a knocking you don't lose your shirt for owning stock in Enron.
Now let's say somebody in a corp uses the software for some minor task. Are they allowed? Is it the person or the corp "using" it?
If the latter, let's say me and my buddy both use the software individually, legally. We sit in the same room. Ok? We are together working on some non-profit project not involving the software. Ok? Now we use the software for it. Ok? Niw we make a profit. Ok?
Where do you draw the line?
RMS would be pretty opposed to these ideas.
If the latter, let's say me and my buddy both use the software individually, legally. We sit in the same room. Ok? We are together working on some non-profit project not involving the software. Ok? Now we use the software for it. Ok? Niw we make a profit. Ok?
Where do you draw the line?
RMS would be pretty opposed to these ideas.
> Now let's say somebody in a corp uses the software for some minor task. Are they allowed? Is it the person or the corp "using" it?
Not allowed.
>If the latter, let's say me and my buddy both use the software individually, legally. We sit in the same room. Ok? We are together working on some non-profit project not involving the software. Ok? Now we use the software for it. Ok? Niw we make a profit. Ok?
All allowed.
The answer to all those questions are pretty simple and straight forward. I'm not sure why you're trying to muddy the waters here.
>RMS would be pretty opposed to these ideas.
RMS has failed catastrophically in his goal of letting users have access to the source code of the applications they use. I don't really care for what he has to say.
Not allowed.
>If the latter, let's say me and my buddy both use the software individually, legally. We sit in the same room. Ok? We are together working on some non-profit project not involving the software. Ok? Now we use the software for it. Ok? Niw we make a profit. Ok?
All allowed.
The answer to all those questions are pretty simple and straight forward. I'm not sure why you're trying to muddy the waters here.
>RMS would be pretty opposed to these ideas.
RMS has failed catastrophically in his goal of letting users have access to the source code of the applications they use. I don't really care for what he has to say.
>RMS has failed catastrophically in his goal of letting users have access to the source code of the applications they use. I don't really care for what he has to say
I don't know how you can say that unless you have impossibly high standards. If it wasn't for the GPL, Intel and AMD would have had zero incentive to opensource their drivers. NVIDIA and arm drivers are still proprietary but panfrost is in development. In an alternative timeline it is plausible that none of this would have happened.
I don't know how you can say that unless you have impossibly high standards. If it wasn't for the GPL, Intel and AMD would have had zero incentive to opensource their drivers. NVIDIA and arm drivers are still proprietary but panfrost is in development. In an alternative timeline it is plausible that none of this would have happened.
> 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.
It's interesting you mention this - Even Elastic started with this same model but then had some conflicts with Amazon being able to monetise ElasticSearch much more than Elastic themselves - so they eventually changed license and then Amazon forked into OpenSearch.. Here's the link for more context - https://www.elastic.co/blog/why-license-change-aws
Btw, wishing you best with your project!
It's interesting you mention this - Even Elastic started with this same model but then had some conflicts with Amazon being able to monetise ElasticSearch much more than Elastic themselves - so they eventually changed license and then Amazon forked into OpenSearch.. Here's the link for more context - https://www.elastic.co/blog/why-license-change-aws
Btw, wishing you best with your project!
> I've been thinking about this problem a lot, since I'm trying to figure out how to sustain our open source project.
It’s worrying, and maybe telling, that you don’t mention whom the project benefits. Who are the people who want this project to exist? Those are the people who would be willing to pay to ensure its continued existence and maintenance. Exactly what form that takes is mostly psychological, and will therefore depend on what types of other expenses those people are used to paying, and how they usually pay them.
It’s worrying, and maybe telling, that you don’t mention whom the project benefits. Who are the people who want this project to exist? Those are the people who would be willing to pay to ensure its continued existence and maintenance. Exactly what form that takes is mostly psychological, and will therefore depend on what types of other expenses those people are used to paying, and how they usually pay them.
> It’s worrying, and maybe telling, that you don’t mention whom the project benefits.
I was trying to avoid talking about the specifics of the project (I didn't want to come across as self-promotional).
We only did our first release this week, so no one is invested in the project (yet). We have hypotheses about who it benefits but haven't had enough time to test them. Our current goal is to build a user base and that will give us the information we need to work on long term sustainability.
I was trying to avoid talking about the specifics of the project (I didn't want to come across as self-promotional).
We only did our first release this week, so no one is invested in the project (yet). We have hypotheses about who it benefits but haven't had enough time to test them. Our current goal is to build a user base and that will give us the information we need to work on long term sustainability.
> no one is invested in the project (yet). We have hypotheses about who it benefits but haven't had enough time to test them.
You mean to say you built an entire project, large enough to need “a few full-time people” to maintain it, without ever getting feedback from actual users? Chance alone almost guarantees that you built the wrong thing and nobody will want to use it.
You mean to say you built an entire project, large enough to need “a few full-time people” to maintain it, without ever getting feedback from actual users? Chance alone almost guarantees that you built the wrong thing and nobody will want to use it.
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.
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.
If your value can be completely replicated by cloning your repo and self hosting then I think that’s maximally useful for open source but leaves no reason for you to exist. Meanwhile if you can open source your software and protect your profits then your software isn’t actually that valuable.
I suppose there may be some exceptions but generally speaking I think it’s an inverse relationship. And it’s basically the same “problem” of open source maintainers not being able to make a living off open source. It feels like we’re in denial about free software being free.
I suppose there may be some exceptions but generally speaking I think it’s an inverse relationship. And it’s basically the same “problem” of open source maintainers not being able to make a living off open source. It feels like we’re in denial about free software being free.
Aren't dual licensing and support contracts kinda solutions to these problems? They're certainly not perfect though.
For the latter, Not everything has a high enough recurring engineering cost to make reasonable money.
Lots of things simply have high non recurring initial developmemt cost.
Lots of things are also done enough at some point. Not everything requires constant new things.
In these cases the main value over replacement is upfront dev cost of whatever features they need (not what you provide)
That is probably not going to make you money, even if it took you a long time, as it is a fairly fixed cost
open source also sucks at making products rather than projects, and then complains they can't often make money doing it. That is actually true outside open source too.
Lots of things simply have high non recurring initial developmemt cost.
Lots of things are also done enough at some point. Not everything requires constant new things.
In these cases the main value over replacement is upfront dev cost of whatever features they need (not what you provide)
That is probably not going to make you money, even if it took you a long time, as it is a fairly fixed cost
open source also sucks at making products rather than projects, and then complains they can't often make money doing it. That is actually true outside open source too.
> It feels like we’re in denial about free software being free.
As always, it's free as in freedom, but also free as in your company taking a beer from the cold hands of the solo maintainer.
As always, it's free as in freedom, but also free as in your company taking a beer from the cold hands of the solo maintainer.
Maybe I misinterpreted this, but I think they're saying the person in denial is the maintainer. As in, if you want to get paid for something, don't give it away for free.
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.
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.
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.
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.
Just want to clarify - I do not think we have the solution to this problem nor do I claim that cloud services are not open source enough. Rather, I decided to take one (of many) possible avenues that I believe is more upfront and honest about our relationship with open source that directly aligns with our business incentives.
The difference to me is honesty and intent from the outset. Open core companies tend to lean into "we'll figure out how to monetize later" which inherently means it's harder to trust what they say now because their incentives are guaranteed to shift towards monetization eventually. The other models bake in monetization from the start, so you know what you're getting into when you start using the product.
The difference to me is honesty and intent from the outset. Open core companies tend to lean into "we'll figure out how to monetize later" which inherently means it's harder to trust what they say now because their incentives are guaranteed to shift towards monetization eventually. The other models bake in monetization from the start, so you know what you're getting into when you start using the product.
> Open core companies tend to lean into "we'll figure out how to monetize later" which inherently means it's harder to trust what they say now because their incentives are guaranteed to shift towards monetization eventually.
How is this guaranteed? If the OSS product is truly core to the business, the incentive will always be to make it as best as possible, which will benefit both OSS users and commercial customers.
This "shift towards monetization" either doesn't happen, or if it does, has no negative effect for OSS users, who will only benefit from the company having more resources to invest in growing the team, more frequent updates, better support, etc.
I can name countless products that have done this right, yet can't think of any that haven't. Can you mention some? Your article lists a few along with their funding data, as if this is somehow inherently a bad thing.
Chances are that companies that did this wrongly had much larger problems, and took advantage of their users in other ways as well. This isn't an issue with the open core model, but with these companies.
> The other models bake in monetization from the start, so you know what you're getting into when you start using the product.
The thing is that none of the alternatives you propose have any benefits for the user. They're either not free software (source available), the OSS component is not standalone and is intrinsically tied to a proprietary service, which serves more like a commercial hook, or the OSS components are noncritical to the business, which doesn't incentivize maintenance.
This is a very opportunistic view of OSS, and is no better than companies that do open core wrongly.
How is this guaranteed? If the OSS product is truly core to the business, the incentive will always be to make it as best as possible, which will benefit both OSS users and commercial customers.
This "shift towards monetization" either doesn't happen, or if it does, has no negative effect for OSS users, who will only benefit from the company having more resources to invest in growing the team, more frequent updates, better support, etc.
I can name countless products that have done this right, yet can't think of any that haven't. Can you mention some? Your article lists a few along with their funding data, as if this is somehow inherently a bad thing.
Chances are that companies that did this wrongly had much larger problems, and took advantage of their users in other ways as well. This isn't an issue with the open core model, but with these companies.
> The other models bake in monetization from the start, so you know what you're getting into when you start using the product.
The thing is that none of the alternatives you propose have any benefits for the user. They're either not free software (source available), the OSS component is not standalone and is intrinsically tied to a proprietary service, which serves more like a commercial hook, or the OSS components are noncritical to the business, which doesn't incentivize maintenance.
This is a very opportunistic view of OSS, and is no better than companies that do open core wrongly.
> I can name countless products that have done this right, yet can't think of any that haven't. Can you mention some? Your article lists a few along with their funding data, as if this is somehow inherently a bad thing.
Elsewhere in the thread there are a couple examples: https://news.ycombinator.com/item?id=35026270
I think part of the problem is that once you rely on premium tier features like LDAP, you're hooked and now the fact that it's open core has about zero relevance to you.
Although it still has some relevance. A child comment on that link I posted talks about going back to the open core by using an oauth workaround for LDAP. So it does seem like the open core might be worth something.
Elsewhere in the thread there are a couple examples: https://news.ycombinator.com/item?id=35026270
I think part of the problem is that once you rely on premium tier features like LDAP, you're hooked and now the fact that it's open core has about zero relevance to you.
Although it still has some relevance. A child comment on that link I posted talks about going back to the open core by using an oauth workaround for LDAP. So it does seem like the open core might be worth something.
Nagware and price gouging are not problems exclusive to the open core model, though, so it's unfair to criticize it as being responsible for this. Especially when the proposed alternatives in the article offer much less benefits to the user.
> I think part of the problem is that once you rely on premium tier features like LDAP, you're hooked and now the fact that it's open core has about zero relevance to you.
For a product like Mattermost, I can see how LDAP is a premium tier feature. If you're using OSS products in an enterprise environment, you can surely afford to support its development, so I don't see how you're on the hook in any way. Your support is making the software available to users who don't need or can't afford these features, which is a net positive. Besides, it gives you the freedoms to modify the software in any way that suits you, which you wouldn't get by paying for a proprietary product. If a certain feature is so important to you, and you refuse to pay the original developers for it, you can always choose to develop it internally for yourself, as that user's company did.
> I think part of the problem is that once you rely on premium tier features like LDAP, you're hooked and now the fact that it's open core has about zero relevance to you.
For a product like Mattermost, I can see how LDAP is a premium tier feature. If you're using OSS products in an enterprise environment, you can surely afford to support its development, so I don't see how you're on the hook in any way. Your support is making the software available to users who don't need or can't afford these features, which is a net positive. Besides, it gives you the freedoms to modify the software in any way that suits you, which you wouldn't get by paying for a proprietary product. If a certain feature is so important to you, and you refuse to pay the original developers for it, you can always choose to develop it internally for yourself, as that user's company did.
After thinking some more, if what you're saying mostly boils down to "there are serious issues with open core cloud offerings" then I agree.
I work on embedded products, so for my purposes open core usually means "you're getting free beer, but you might not get free updates". We've also paid for commercial licenses of dual-licensed projects and I think that model works pretty well.
Once we're talking about services, if you're not willing or able to operate the service yourself (at the scale you need...) then the open core seems pretty useless as a check on the company's ability to squeeze you for more cash.
On the other hand, it doesn't seem to me like explicitly commercial services solve those problems. Just because a closed source service has a pricing model I accept as fair today, doesn't mean it will tomorrow. But I guess there's something to be said that there was never any pretense otherwise.
I work on embedded products, so for my purposes open core usually means "you're getting free beer, but you might not get free updates". We've also paid for commercial licenses of dual-licensed projects and I think that model works pretty well.
Once we're talking about services, if you're not willing or able to operate the service yourself (at the scale you need...) then the open core seems pretty useless as a check on the company's ability to squeeze you for more cash.
On the other hand, it doesn't seem to me like explicitly commercial services solve those problems. Just because a closed source service has a pricing model I accept as fair today, doesn't mean it will tomorrow. But I guess there's something to be said that there was never any pretense otherwise.
>Once we're talking about services, if you're not willing or able to operate the service yourself (at the scale you need...) then the open core seems pretty useless as a check on the company's ability to squeeze you for more cash.
But if you aren't willing, then the service provides value and if you aren't able to, then there is the conflict of interest in that the opencore company might sabotage scaling the opensource version but if we ignore that possibility (after all, you should simply avoid the product, if the opensource version is inferior) then you are again paying for the value of someone else taking care of your problems.
Calling this "squeezing" is strange.
But if you aren't willing, then the service provides value and if you aren't able to, then there is the conflict of interest in that the opencore company might sabotage scaling the opensource version but if we ignore that possibility (after all, you should simply avoid the product, if the opensource version is inferior) then you are again paying for the value of someone else taking care of your problems.
Calling this "squeezing" is strange.
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.
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.
> 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.
I see the obvious value to the people selling the software!
Is there any value to the consumer, or is it basically just a trick?
I see the obvious value to the people selling the software!
Is there any value to the consumer, or is it basically just a trick?
I mean you get software for free, isn't that value? I know e.g. tons of people / companies using Terraform that get enormous value out of that without ever paying for it. Personally I run Gitlab CE for my company and that also gave me tons of value for free, so I don't think it's a trick.
If you curtail your software so much that no one can use it without paying you won't get much traction, you have to provide something that's useful enough for 90 % of the users without paying.
If you curtail your software so much that no one can use it without paying you won't get much traction, you have to provide something that's useful enough for 90 % of the users without paying.
I'm talking about the scenario you describe where the free version is meant to lock in the customer and funnel them to the paid version.
I mean, you just said: "companies can get locked into a product without knowning it and without you doing any real sales effort." You can see how that sounds like trying to trick the consumer? But you don't see trying to get companies locked into a product without knowing it as a trick?
I guess thats the normally quiet part out loud. As a customer/consumer, getting tricked into getting locked into a product, where you intentionally try to make the free version _not_ good enough for me (but not obvious to me at first) so I have to go to the paid once locked in -- which is what the OP is describing too, I think you accurately described it -- this isn't feeling like a benefit to me?
But ok, maybe there's some benefit, let's go with that for a second. That benefit of the "freemium" model, the free initial offering, is there with or without the free initial offer having an open source license.
The reason to actually give it an open source license (or something you claim is open source) is just because it's good marketting, it makes it even easier to lock companies into the product without knowing it, because of their wrong assumptions about what open source means?
I mean, you just said: "companies can get locked into a product without knowning it and without you doing any real sales effort." You can see how that sounds like trying to trick the consumer? But you don't see trying to get companies locked into a product without knowing it as a trick?
I guess thats the normally quiet part out loud. As a customer/consumer, getting tricked into getting locked into a product, where you intentionally try to make the free version _not_ good enough for me (but not obvious to me at first) so I have to go to the paid once locked in -- which is what the OP is describing too, I think you accurately described it -- this isn't feeling like a benefit to me?
But ok, maybe there's some benefit, let's go with that for a second. That benefit of the "freemium" model, the free initial offering, is there with or without the free initial offer having an open source license.
The reason to actually give it an open source license (or something you claim is open source) is just because it's good marketting, it makes it even easier to lock companies into the product without knowing it, because of their wrong assumptions about what open source means?
[deleted]
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.
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.
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.
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.
> There is an incompability between FOSS and profit
Red Hat says hi.
Red Hat says hi.
Red Hat uses a very similar business model providing managed enterprise features on top of open source.
What software programs or features does Red Hat not make available under a FOSS license?
They’re called “IBM” now.
They wouldn't have gotten acquired by IBM if they couldn't make a profit.
IBM could use the Red Hat Enterprise customer base to sell consulting services to. If the projected profits from consulting is large enough, no profits from Red Hat is needed.
There are a small handful of exceptions. Many were in the exactly the right place at the right time. That’s not a repeatable strategy. I wouldn’t start RedHat today.
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.
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.
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:
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/
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
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.
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.
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.
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.
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.
I disagree that open core is just marketing or OSS shareware.
When done correctly, it offers a fully functional, featureful and standalone product most users can benefit from. Only specific noncritical features, meant for advanced or corporate users, are offered commercially.
When done correctly, it offers a fully functional, featureful and standalone product most users can benefit from. Only specific noncritical features, meant for advanced or corporate users, are offered commercially.
> 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.
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.
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.
The worse part is, marketing said: We are the best.
The issue is having something to do with real transparency. It's underrated.
The issue is having something to do with real transparency. It's underrated.
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 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?
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...
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"?
The open-core model is a business model for the monetization of commercially produced open-source software. Coined by Andrew Lampitt in 2008,[1] the open-core model primarily involves offering a "core" or feature-limited version of a software product as free and open-source software, while offering "commercial" versions or add-ons as proprietary software.[2][3]
From here -> https://en.m.wikipedia.org/wiki/Open-core_model
From here -> https://en.m.wikipedia.org/wiki/Open-core_model
Among other problems, this article seems to be using a much broader definition of open core than everyone else. Business models like support or SaaS are not usually considered to be open core.
Open core is open source + proprietary add ons. Gitlab is probably the best example. There is an open source gitlab which you can use and host, but the commercial product you pay for has a whole lot of additional features which big orgs need
For a moment I thought it was referring to the Hackintosh bootloader of the same name.
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.
Author here. Would love to hear what solutions you would suggest! I only mentioned those I'm aware of that I find admirable (which is not the same thing as them actually working).
I don't have any solutions, unfortunately. I have written some thoughts here: https://www.mooreds.com/wordpress/archives/3438
But I feel like we need a new model of economics to get the incentives right. Zero marginal cost goods are a new thing.
But I feel like we need a new model of economics to get the incentives right. Zero marginal cost goods are a new thing.
So the article is blaming people who work on software for needing money to feed their families?
[deleted]
> 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.
> 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 ?
Yes, but that read is a bit cynical. I think it's totally reasonable to create some tool that any college student or tinkerer can use to get a cool idea off the ground, but also want to get paid when it's leveraged to significant financial success. Pure open source is nice, but in practice it means corporate sponsorship or ramen lifestyle, both of which, it seems to me, have worse downsides than the loss of ideological purity in small companies trying to make a living building great tech.
> Yes, but that read is a bit cynical
Is it? I've found that all open core projects I've used over time gradually lock more and more features away with each update and usually end up being more expensive than the closed source alternative.
The latest example is RocketChat which a year ago had a couple of features and one or two gentle reminders to upgrade to enterprise, but now it's getting really naggy. And when I did contact them for enterprise pricing, which is not clearly available, it ended up being way more than we could pay and a lot more than Slack (can't remember exactly now but something like $10/user if we included the bridges to WhatsApp and Messenger).
Can you give any counterexamples of popular, growing open core projects that don't lock away more features over time?
Is it? I've found that all open core projects I've used over time gradually lock more and more features away with each update and usually end up being more expensive than the closed source alternative.
The latest example is RocketChat which a year ago had a couple of features and one or two gentle reminders to upgrade to enterprise, but now it's getting really naggy. And when I did contact them for enterprise pricing, which is not clearly available, it ended up being way more than we could pay and a lot more than Slack (can't remember exactly now but something like $10/user if we included the bridges to WhatsApp and Messenger).
Can you give any counterexamples of popular, growing open core projects that don't lock away more features over time?
> The latest example is RocketChat which a year ago had a couple of features and one or two gentle reminders to upgrade to enterprise, but now it's getting really naggy. And when I did contact them for enterprise pricing, which is not clearly available, it ended up being way more than we could pay and a lot more than Slack (can't remember exactly now but something like $10/user if we included the bridges to WhatsApp and Messenger).
We had exact same experience with Mattermost. We needed only LDAP auth from enterprise side but it was good product so we were fine paying iirc $2.5/mo/user for it. They doubled the price ("we add more features that you don't use to this level, so pay us more"), we got pissed and our dev just whipped github-like auth page (OC version allows authenticating with gitlab) and we pointed it to that.
Now I see they doubled it again and at $10, when our O365 accounts cost $6.50/mo it would be impossible sell
We had exact same experience with Mattermost. We needed only LDAP auth from enterprise side but it was good product so we were fine paying iirc $2.5/mo/user for it. They doubled the price ("we add more features that you don't use to this level, so pay us more"), we got pissed and our dev just whipped github-like auth page (OC version allows authenticating with gitlab) and we pointed it to that.
Now I see they doubled it again and at $10, when our O365 accounts cost $6.50/mo it would be impossible sell
[deleted]
Redis is technically open core, with Redis Enterprise supposedly gating 'simple' scaling, multi-tenancy, and a (I assume) plug-and-play k8s integration https://redis.io/docs/about/redis-enterprise/
I think OSS have kind of problem with "too good" software.
If your business is produce software and work as consulting company for it, software that is very good and easy to use is actively reducing your market, because frankly people don't need any help to use it.
Take ES for example. Running big-ish cluster isn't that hard with a bit of googling and experimenting, so there is little reason to ever bother with support contract.
If your business is produce software and work as consulting company for it, software that is very good and easy to use is actively reducing your market, because frankly people don't need any help to use it.
Take ES for example. Running big-ish cluster isn't that hard with a bit of googling and experimenting, so there is little reason to ever bother with support contract.
Right but on contribution side it basically taking unpaid labour then selling it to their paid customers. That part I have problem with.
And you don't need open source model if you just want to give smaller might-be-a-customer a free, limited version.
I guess it depends on what exactly is behind the paywall. Some have very weird limits, like Mattermost where you can use Gitlab for authorization in open core but for LDAP you need enterprise.
We actually paid for it and were pretty happy with it but at some point they decided to double the price under excuse "but we added features"(that we did not use) to that version. So one Rails dev added a dummy "gitlab" oauth page for auth that's connected to our LDAP and we just switched to open core version...
...aand since then they doubled the price again. So suffice to say I'm a bit soured on open core model, when they tried to upsell us to more than we pay for O365 account for same features.
I'm not saying it's all bad, for example VictoriaMetrics looks like it have very reasonable model (although lack of pricing on their page is... annoying), but it is model ripe for abuse, especially if company gets bought.
And you don't need open source model if you just want to give smaller might-be-a-customer a free, limited version.
I guess it depends on what exactly is behind the paywall. Some have very weird limits, like Mattermost where you can use Gitlab for authorization in open core but for LDAP you need enterprise.
We actually paid for it and were pretty happy with it but at some point they decided to double the price under excuse "but we added features"(that we did not use) to that version. So one Rails dev added a dummy "gitlab" oauth page for auth that's connected to our LDAP and we just switched to open core version...
...aand since then they doubled the price again. So suffice to say I'm a bit soured on open core model, when they tried to upsell us to more than we pay for O365 account for same features.
I'm not saying it's all bad, for example VictoriaMetrics looks like it have very reasonable model (although lack of pricing on their page is... annoying), but it is model ripe for abuse, especially if company gets bought.
Tokens, ser!
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".