Not all of them are "open core" in the sense that they have a core product and proprietary extensions (some just opensource everything they make), but a number of relevant companies around FOSS products: Gitlab, MariaDB Corporation, Blindside Networks (Big Blue Button), Qt Company, Mattermost Inc.
Which is all to say, if you write that post, I for one will read it :)
When Six Apart made Movable Type's license more restrictive in 2004, a portion of the userbase jumped over to WordPress. Another thing in WP's favor was ease of hosting, due to being written in PHP, vs Movable Type's Perl. This all led to a lot of momentum for WP; Automattic was founded after that, in 2005.
Confluent (Kafka), Redis Labs, Eucalyptus Systems Inc. (AWS clone, acquired by HP), Instructure (Canvas)
In that regard, "open core" (or open source for that matter) was never a business model — the business model always was bait and switch. Open was the bait.
But likely I have always been a little suspicious of "open source" and likely I am now over-simplifying.
Databricks has shown that you don't need a crazy license to win. I disagree with this article from my personal experiences and my industry experience but I respect you writing it. The business model is clearly alive though. Those companies that I listed have raised 100-200M in the past year at high velocities.
in terms of revenue justifying big valuations, how many healthy companies are there, really? ("spend $20M to make $3M..." = not healthy) What about ratio of OSS successes vs closed successes, esp w/ efficiency?
e.g., the biggest co there is databricks (and i continue to root for them!), and contrast w/ snowflake who started in a similar period, grew 10-20X bigger, and started more simply (get a clone of redshift without doing business w/ aws). worse, databricks took a lot of phd students many years with a lot of big corp funding before the vc's got involved: that's a high bar an oss co must hit vs not for adjacent high-growth spaces.
the good news for oss founders is VC's are warming to investing here, and sometimes, even before OSS traction. irrespective of profitability, the founders have a better chance of flipping it to be someone else's problem.
not necessarily as clear cut for community-minded co's though that want to be financially healthy for their community. it seems the bigger and more numerous successes are non-oss, and despite the many oss attempts, the big sustainable oss successes have to doubly succeed at what is already hard. If going OSS increased chance of success -- and didn't actively challenge success -- I'd expect relatively more successes by now. I wish all this wasn't so but it's hard to unsee...
Getting funding from investors sucks. It comes with expectations of growth. Mongo still hasn't turned a profit. To the extent that they are a saas business with saas economics that's common, but still. They clearly read the writing on the wall and declined to fund AWS's R&D costs for free.
I'm curious about what exactly you mean by these two sentences. Particularly the second one.
Is this circle you speak of the one where a company announces an open source product and once the goodwill—that open source development gives it—ensures a number of contributors and early adopters, helping the project grow until the company thinks it's good enough to monetize, at such point they close it down and start charging everyone; then they start a new open source product with the extra money, rinse and repeat?
Keep in mind that for projects like that, even if they are open source, the vast majority of contributions come from the primary investor. And other contributors can always fork.
It is not anything special about open source. For any product, early adopters are almost expected to get hurt or lose interest as the product matures. It's a part of the product's life cycle that's in any startup book. Crossing the chasm is hard not only for the business but also for the original user base. Yet, successful businesses are destined to do it. I am sorry for the ones that become dissappointed, but they too get something out of it along the ride.
> It's a part of the product's life cycle that's in any startup book.
There are many start-ups truly committed to open source development. Conversely, there are many who are not but are pretty upfront and honest about how they are not. I don't judge either one as I'd rather not be a zealot, and one ought to do what one ought to do.
However, there are also some companies (thankfully a minority, as far as I can tell) who are not really committed whatsoever to open source, but still pretend to be (often using marketing speak like "the ideology is in our blood") for the sake of good publicity. Those I don't like, but then again most of them are large corporations, so it's not like there's much one can do in that area.
More likely MongoDB promised future revenue in order to attract those investors and then couldn’t figure out how to get there.
- if your company makes >X revenue a year, give us some of it.
Ofc, they (FSF/OSI/DFSG) would have to relax their FOSS definition(s), but with more projects dying in this way hopefully more FOSS organisations will take heed and think about this.
Ofc, the wording of the license has to be precise enough to avoid something like fobbing off the servers to technically be controlled by subsidiaries with 0 revenue.
Ofc, the license would have to figure out how to share revenue with major contributors too.
Contributors already contribute to for-profit open source projects without themselves getting paid, so this license would make the situation strictly better for them.
(1) Ignore the problem -- your license has no teeth.
(2) Hold the larger corp responsible for payment anyway -- pretty sure this can't be accomplished purely within copyright law, and if it can then it's still not great because implementation details of the hosting company now matter in terms of the larger company's liabilities.
(3) Hold the hosting company responsible -- fine enough, that can probably be a valid term in your license. Suppose another company inserts themselves in the middle though; does your license exclude them because they're transitively connected to megacorp, or do we again find that your license has no teeth? The first case is an issue because now you're exposed to risk from your customers' customers, over whom you have no control.
Not every piece of software can be meaningfully hosted and resold by a chain of corporate entities, but it's not exactly an uncommon behavior in the wild either.
Include these companies in the definition?
> What do you do?
Generally, there will be situations that are hard to define in a license, as is the revenue sharing part of it - and that's probably why no such license exists yet. The easiest way around this is for a blanket catch-all clause such as "you have 1 year to start negotiations with us, after which this license automatically expires".
If you choose >X correctly, there are only a small number of companies with >X revenue in the world, so you only have to negotiate with that many companies. The idea is not supposed to extract money from small companies or individuals.
> pretty sure this can't be accomplished purely within copyright law,
AGPLv3 is enforceable by contract law, same as other EULAs that big tech companies frequently employ.
Surely not by name if they don't exist yet? And the rest of the bullets were pointing at why it's difficult to pinpoint them with additional terms.
> The easiest way around this is for a blanket catch-all clause such as "you have 1 year to start negotiations with us, after which this license automatically expires".
Which is great if you have some kind of legal foothold on megacorp, but if they're sufficiently legally isolated from you via intermediaries then additional clauses won't help.
> AGPLv3 is enforceable by contract law
In some jurisdictions (and copyright law in most others), but it doesn't magically hold third-parties responsible. It holds first-party users of your license responsible in a way which transitively affects third parties (copyleft being the mechanism). You might then claim that you could just do that for this contract too, but that's precisely my 3rd point above; doing so is unnecessarily restrictive to <X randocorps.
Elaborating on those restrictions, if randocorp is directly responsible for transitive users then they take on a huge risk whenever they have any customer because that customer might acquire megacorp as a customer at any point in time unbeknownst to them. If randocorp is not responsible for transitive users, then the mechanism for generating a connection between you and megacorp needs to be something like copyleft, but critically it has to somehow apply to contracts and interactions beyond copyright. At least it does if I'm understanding you correctly -- hypothetically, if you build a search tool, randocorp hosts the search tool, and megacorp buys searches from randocorp, would you like them to be targeted by the revenue sharing portion of your >X licenses? Anyway, assuming that's what you meant, copyleft by itself doesn't suffice, and you'd need something significantly more invasive than AGPLv3 to accomplish your goals.
Whatever scenario you imagine where some $bigtech benefits from using the software, there is some identifiable chain of events from where the software was produced, which can, with some effort, be defined and specified in a general way in the license, in terms of a contract that allows each party in the chain to supply to the next party in the chain.
From that perspective they will never be an independent third party, and therefore you can specify that in a contract. So I don't see a theoretical problem to this, just a practical one of specifying this both precisely enough to be enforceable, and general enough to cover all real cases.
But there's more. I followed the MongoDB case a bit and it's not exactly how many make it sound like. MongoDB was doing fine as a company. It wasn't like they were unable to pay their programmers because AWS offered a hosted MongoDB.
In the months before that controversial license change they got plenty of funding from investors.
It looked all more like investors created expectations of future revenue and they became cold feet if they could meet those expectations.
It remains to be seen how this will work out in the long run. I'd personally consider everything that depends on MongoDB to be toxic. With that license it won't be shiped in standard linux distros, other projects are less likely to build on it.