I tend to agree, although I probably wouldn't state it in exactly the way you have. Open core's main goal is to sell proprietary software using the open source version as a loss leader.
Having said that, I think there are some companies/individuals who truly believe that open core is a good way of funding free software development. I have even heard Bruce Parens claim that dual licensing is practically the only reasonable business model for free software. This was quite a long time ago (on Slashdot of all places), so I have no idea if he still feels that way, but I mention it only to point out that the issue is far from clear to a lot of people -- even those in the open source community.
Red Hat is almost unique in their business model and they are one of the very few companies who actively try to make money doing custom development contracts. I have argued many times in the past that people should look at what Cygnus Software did and try to emulate it. You may remember that Red Hat acquired Cygnus Software for $600 million and installed Michael Tiemann in various executive positions. Although Cygnus (after having taken VC money) ended up doing some open core work, they happily abandoned it after they were acquired by Red Hat.
I've asked the questions in my original post to several open source and open core companies (possibly most notably GitLab) and have received almost the exact same answer from each of them. I'm hoping to receive an answer here (and I won't try to spoil the response by priming it with what I've received before). My main goal is to at least understand why businesses choose to go open core, why they feel that custom development contracts are not feasible, why they can't build a business of hosting and other similar services alone, etc. It may be a widely held belief simply because businesses are not ready to follow the example of Red Hat, or it may be the case that Red Hat really is special. I'd like to understand as best as I can which it is -- and since I don't run an open source/free software business, the best I can do is to ask those who do.
Sourcegraph CEO here. I share your interest in open-source business models, going back quite a while. My public middle school back in 1999 had a mock investment club, and students voted on which stocks to invest in. (It's funny looking back on this.) I campaigned for RedHat and VA Linux, and we ended up "buying" those (and some JDS Uniphase, naturally).
I plan to write more about this, but here's the summary of why we went open core.
- Hosting is less viable for developer tools, especially those that are intended for companies above ~30 engineers, because those companies usually want their code to stay on-premises. Selling hosting means you'd only sell to small companies.
- Now, compared to 10-20 years ago, customers perceive software needing custom development as bad. Expectations are higher for the product to just work out of the box. They might not ever use it if they can't quickly see that it solves their problem (without getting custom development).
- Doing custom development probably entails a top-down sale, not a bottom-up sale. Compared to 10-20 years ago, bottom-up (having a single dev bring your product in and then spreading from there) is much easier. Bottom-up means that, especially in the early days, you can focus on building the product/eng teams instead of the sales/marketing team.
- Custom development doesn't scale, and we think every dev will be using Sourcegraph (or something like it, if we mess up :) in 5 years. We can only get there by building a product that works for almost everyone, not one that works really well only for a few companies.
- Open core is easy to understand because (if you ignore the availability and open-sourceness of the code, which is purely a benefit) it is just like freemium, which is a well understood concept.
I'm just stating our decision process in choosing open core. I make no claims that these are universally true.
If someone out there is thinking to themselves, "I'd love to pay Sourcegraph to build custom features for my company", then please reach out. At the very least, your desire for those features would be a strong vote in favor of prioritizing them on our roadmap.
Thank you very much for these great answers! It's really helped me understand some more issues that I didn't understand before. I really appreciate the amount of time you took to think through that and write a reply.
As a complete aside, I actually had inside knowledge of the JDS - Uniphase merger (a friend of mine who worked there inadvertently allowed me to see something that made it was clear that it was happening a day or so before). It took all my self control not to buy up a lot of JDS stock. I always wonder if I would have gotten in trouble (or gotten my friend in trouble)...
"Open core" and dual licensing are two completely separate business models. They should not be conflated.
Open core business models depends on selling non-free software. Normally all or nearly all development is done by a singular company. The core software could probably just as easily have been free-of-charge, and everything else would have been completely identical. (But on the other hand, if you're not making money, you might as well publish source code in this day and age.)
Dual licensing business models are much more like selling free software than selling non-free software, with that difference that large parts of your potential customers are not interested in copyleft. This is often the case for the embedded world for example. Here it's much more common to find multi-stakeholder communities, since copyleft can bring a much more level playing field.
As a business model dual licensing means having a free software license (which may or may not be copy-left) and a proprietary software license. Having 2 or more free software licenses is not a business model, even if it is handy for letting people get around the GPL. There is no reason to pay for the second free software license. Otherwise you could just use MIT or the equivalent and be rolling in money. Obviously it doesn't work that way. Pedantically, "dual licensing" means to have 2 licenses. Companies are willing to pay for the proprietary software license because they want to use that code with their own proprietary code.
The only potential difference between that and "open core" is that open core generally talks about applications. Dual licensing a library allows people to use that library in proprietary software. But let's not kid ourselves -- that library is proprietary. That's the whole point.
Can you point to a project with dual licencing where all or nearly all of the development is not done by a singular company. This is rare (if it even happens at all), because you need to have copyright assignment in order to relicense the software under the proprietary license. Any other changes essentially causes a fork in the free vs. proprietary version. This is precisely the same reason why open core and other dual licensed projects tend to be controlled by a single entity. Unless you fork, there is no way to contribute without having to go through the controlling entity.
Potentially, you have in mind that many dual licensed libraries do not offer more features in the proprietary version as compared to the free version. With open core applications, where the license is less important (or not important) to the customer, you need to add different functionality to get them to buy the proprietary version. So I'll grant you that.
I'm not aware of any common difference in terminology usage. Open core is dual licensing. The fact that applications tend to diverge between then free and proprietary versions is due to the fact that nobody wants to link it to another application -- they just want to use it. In order to get people to pay for the proprietary version you need to add more features. But that's not a difference in strategy, it's just a reality of the thing you are selling. Libraries usually don't bother making different feature sets because there is no need -- people are willing to pay for the proprietary version without the extra work.
What no, open core is not dual licensing, at least, not by what is meant here with "dual licensing".
Dual licensing is about selling exceptions. Selling copyleft exceptions. There's no dual licensing without copyleft, because there is no exception to sell. And yes, it requires a single copyright holder. FFTW is an example of dual licensing. Octave gets FFTW because we like copyleft and Matlab gets FFTW because they like to pay to hide their code.
But it doesn't just have to be a library. MongoDB also sells exceptions because people are irrationally afraid of the AGPL.
I think you were confused by software like Firefox which is dual or triple-licensed and all recipients get to pick which license they want to follow, but that's not what was being discussed here.
Sigh... you are right about the copyleft thing. I'm not sure where my head was. Just so I get this right: you're saying that "open core" is essentially having a copyleft license and a proprietary license, while "dual licensing" is having a copyleft license and another non-copyleft free software license? If so, I can understand what you are saying :-)
Open core is freemium. You can use the base under a free license but if you want fancy features, those are under a non-free license.
Selling exceptions (or what someone else called, "dual licensing") means everyone gets the same software, both free and non-free, but people who don't want copyleft have to pay.
Having said that, I think there are some companies/individuals who truly believe that open core is a good way of funding free software development. I have even heard Bruce Parens claim that dual licensing is practically the only reasonable business model for free software. This was quite a long time ago (on Slashdot of all places), so I have no idea if he still feels that way, but I mention it only to point out that the issue is far from clear to a lot of people -- even those in the open source community.
Red Hat is almost unique in their business model and they are one of the very few companies who actively try to make money doing custom development contracts. I have argued many times in the past that people should look at what Cygnus Software did and try to emulate it. You may remember that Red Hat acquired Cygnus Software for $600 million and installed Michael Tiemann in various executive positions. Although Cygnus (after having taken VC money) ended up doing some open core work, they happily abandoned it after they were acquired by Red Hat.
I've asked the questions in my original post to several open source and open core companies (possibly most notably GitLab) and have received almost the exact same answer from each of them. I'm hoping to receive an answer here (and I won't try to spoil the response by priming it with what I've received before). My main goal is to at least understand why businesses choose to go open core, why they feel that custom development contracts are not feasible, why they can't build a business of hosting and other similar services alone, etc. It may be a widely held belief simply because businesses are not ready to follow the example of Red Hat, or it may be the case that Red Hat really is special. I'd like to understand as best as I can which it is -- and since I don't run an open source/free software business, the best I can do is to ask those who do.