> if you give your secret sauce away for free, and it gets popular enough, cloud providers will inevitably spin up competitive services using your very own code against you.
For some reason, the author never mentioned AGPL. What's wrong with using this license if you want to defend your open-source business model?
AGPL doesn't allow you to say "I want AWS to pay me if they use my software". As long as AWS abides the rules of the AGPL they can use your software as much as they like and create offerings based on it.
AGPL does help with this. An early example was when Google's search interface answered unit conversion queries using GNU Units. They fixed a bug internally and didn't flow the bug back upstream. Since they weren't distributing Units, but were only executing it as a service, their behavior was strictly conforming to the letter of the GPL. The failure to respect the spirit of the GPL was a factor in AGPL's development.
AGPL code is strictly forbidden for use inside the company now, partially because they consider private modifications to open-source software to be a competitive advantage.
This is debated. Some people say that AWS will never touch AGPL software which accomplishes the goal of not getting AWSed while remaining OSI certified.
AWS specifically might not, but I can say with some certainty that cloud providers can host AGPL software. It's not impossible that Compose (the now IBM-owned cloud database hosting company) pulled in more revenue from RethinkDB than RethinkDB, Inc., did.
Yeah, it's a matter of risk. Rightly or wrongly you could get hit with a lawsuit that says "we have infected your entire control plane; open-source it or die" and every cloud provider has to weigh that for themselves.
Or follow the license and provide their changes for maintainers to merge upstream, making the original project better. Isn't that the point of GPL licenses to begin with?
Mapbox releases Mapbox GL JS v2 under a proprietary license whereas v1 (presumably) was under an "open core" business model. (Mapbox v1 and v2 are graphics card enhanced mapping libraries?).
The author of the article's thesis is that this is "an end of an era" of Open Core business models (putting core technology under a free/libre licensing and charging for extra proprietary features).
I'm very curious as to what other people here on HN have to say about it. Gitlab, a prominent company that follows an Open Core model, is a YCombinator alum, no?
I feel like Gitlab will try to pull an Atlassian in the future. They already said they are changing focus to their cloud-based offering over the on-prem version.
I worry you're right, and while I think it's bad for what it signals about business model viability, I'm not sure it's bad for how I use GitLab.
Do the couple dozen devs at my company really need an internally-hosted version, or should we just pay for the cloud offering and supply our own runners? Seems easy to frame as a wash.
Working at GitLab, but I want to focus on this part of your comment in general:
> Do the couple dozen devs at my company really need an internally-hosted version?
From personal experience and knowledge through friends: Everyone writes code. Universities, Governments, Governmental agencies, political parties, etc.
A lot of them do not want to host in the cloud, especially in Germany, considering that the cloud (depending on the provider you are looking at) means hosting outside of Germany with all that entails privacy and regulation wise.
That's a great point. I'm in the US, so this isn't an issue for us in the same way, though I've heard fears of "we can't put code in the cloud, what if it gets out!".
My response is "what's your threat model?". For a small company, our only security advantage is being a small target; there's no way we're competing with the Gitlab.com team on security.
> our only security advantage is being a small target
1. If a 3-letter agency requests access to your on-prem data you'll know about the request and know which data is compromised.
2. You now have to trust your hosting provider. This is almost the same as being a small target, but not quite because you need to worry about all of their employees AND all of your own. There are 1k+ employees to attempt to compromise at Gitlab, and you have no control over or contracts with any of them.
3. Expanding on 2, given the disconnect between Gitlab and your own organization you open yourself up to new kinds of attacks like social engineering an account takeover, or expanding an email breach to a source code breach.
I don't think any of that matters for most people, but your attack surface area is increased with current cloud tech.
It comes down to whether your company can accept the risks inherent in hosting essential data at a third party site that necessarily provides a bigher attack surface than anything hosted behind the company firewall, but is also monitored by a (dedicated) security team.
On-prem is your trump card in case Gitlab cloud decides to leave you out in the cold.
Without on-prem, you're cut out of your source code service and will have to do a potentially hasty migration to an entirely new platform (which brings its own issues inherent in any migration project).
Our Open Core business model is part of our 3 year strategy [1] and something I consider one of our key strengths. As a member of the Community Relations team, I may be a bit biased. :)
We acknowledge the risk of "Fork and Commoditize" [2] on our list of biggest risks but believe that risk is reduced because we're application software instead of infrastructure software.
Hi John--thanks for sharing these links. I do wonder if there is a fundamental difference between applications and infrastructure. Maybe it's the fact that applications tend to involve a greater share of non-engineering users (and therefore a greater reliance on someone else to host and manage the service)? Food for thought. GitLab is a great company, and I've read a lot of your strategy documents; it's a wonder you publish so much in the open, and I'm grateful for it.
We detail the differences between infrastructure and applications in link #2 in my previous comment. If you have any suggestions on how we can improve that section, I'd encourage you to create a MR to update the page. Just click the "Edit in Web IDE" link at the bottom to get started. :)
> believe that risk is reduced because we're application software instead of infrastructure software.
Why do you believe this? My project uses self-hosted gitlab (ancient version) and I frankly have a very hard time seeing it as anything other than infrastructure. Maybe we just don't push our use of gitlab a lot (to be fair, we don't push it at all).
I disagree with this article’s premise that all software is services-based. There are lots of open-core business models that can’t be eaten by the cloud providers, because they aren’t services to be spun up.
Almost all of the CNCF-based businesses are complex plug-in models that the CPs can’t just make a button for.
AWS has a hosted version of Kubernetes and Envoy now, and those are both CNCF projects. Other CNCF projects like NATS and Argo have equivalents on AWS today.
Even if they're complex and not one-button click to drop in, the cloud providers seem keen on running managed versions of these projects.
What projects come to mind as being "immune" to this problem, out of curiosity?
I'm curious about this too; I'd love some counter-examples and that was a big reason for me taking the rather arrogant stance of claiming "cloud killed open core." I selfishly wanted to rile up smart folks who could prove me wrong.
Almost by definition the projects that are immune to this are the projects that are not yet popular enough. It’s not a coincidence that it’s Kubernetes and Envoy that are the most popular CNCF projects.
I think CNCF, or more generally, Linux Foundation projects are better characterized as public goods. Basically a bunch of companies, many whom are competitors with each other, get together to improve the commodified base upon which they depend. Saves a lot of $$$ that would otherwise be wasted in wheel reinvention or spent on license fees.
For the particular case of AWS now offering Kubernetes, is that:
- A win for AWS, since they can leech code without contributing back
or
- A win for Kubernetes contributors and users vs AWS, since now customers have the option of moving their Kubernetes workloads from AWS to other providers.
In the back of the head this gives me an idea for a marketplace startup for software utilities but I know it's been tried before and died. I don't know how to align the incentives of creators to where we can make a marketplace where open source is lucrative by design.
But I don't think it's impossible, just the social hurdles haven't been cleared yet. Not much technology to throw down on the problem.
Not really what I'm thinking, I see these attempts at funding maintainers pop up each year and I think they all share the same problem and take the wrong approach.
I wish there was a FOSS license with a clause along the lines of:
- 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.
> "if your company makes >X revenue a year, give us some of it."
That would just be a proprietary license with source availability. It would also dry up any community contributions since contributors are generally not going to help a for-profit project without themselves getting paid.
Sure, the license would have to figure out how to share revenue with major contributors too.
> contributors are generally not going to help a for-profit project without themselves getting paid.
Contributors already contribute to for-profit open source projects without themselves getting paid. This license would make the situation strictly better for them.
I feel there's a few cases cited here to make a case that an entired business model is dying, but it doesn't look to me that this is an overall trend. You can't extrapolate from "5 projects didn't fare well with this, so it's not working".
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.
I wrote it last night; I didn't have time to research every "open core" company I could think of to figure out a chronology of their licensing strategy. I decided to publish it based on a limited number of case studies to gin up discussion and hopefully learn from other people about counter-examples. Do you know of any?
Of course by mentioning any name here I risk that they might be a future candidate of closing down and you say "gotcha" :-)
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.
Thanks, those are great examples. I've considered writing about Mattermost before, as I think it's a fascinating pattern that I haven't seen much elsewhere. Attack an existing, high-profile app by cloning it in the open but then additionally build a for-profit company around the clone. Truly a galaxy brain strategy.
I’ve been interested in this pattern as well. I’d contend that GitLab is another good example, and even argue that Automattic is too (IIRC Movable Type was already a successful proprietary blogging platform when WordPress came along)
Which is all to say, if you write that post, I for one will read it :)
I don't think Automattic really fits the same pattern. Although Movable Type was one of the earliest and most successful source-available blogging platforms, there were a bunch of others soon after. They all had similarities in functionality, by nature of being blogging software, but they weren't exactly "clones". WordPress was actually a fork of another early blogging software, b2/cafelog.
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.
Also--thanks for going on the record. You are right that you might be criticized in the future by nit-pickers, but it's much more satisfying to take public stances and find out what you're made of (in my opinion).
Big Blue Button is outstanding for any educators looking for tools. Full disclosure that it was built at the school I attended, we had a lot of profs use it and it was by far my favourite way to do distance learning.
I'm stupid in this space, but as an outsider, is this "the end of an era" because it looks like MapBox is simply pulling the tried and true "bait and switch" which has been around forever.
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.
Literally tons within the data ecosystem. dbt, Great Expectations, Dagster, Seldon. The list goes on. My employer Tecton has an "open core" called Feast and we are doing great. Mattermost, PostHog also come to mind.
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.
vc $'s may be seriously clouding the analysis here.
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...
Based on HN's cheerleading when some projects abandon open source (for example the top comment of https://news.ycombinator.com/item?id=19488642 ), the overall trend may be the user base not caring about open source in the same way people cared 5-10 years ago
When we at Handsontable switched to a proprietary license, it wasn't met with much enthusiasm from the existing open source users. But it helped us to get better deals. We invested part of the proceeds in another open source project - HyperFormula. The ideology is still in our blood and we keep the open source circle of life running. But I am happy that this new open source project is not on a collision course with revenue.
> The ideology is still in our blood and we keep the open source circle of life running.
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?
I hope this does not sound cynical. When we release a new open source project, we are not sure what the project will turn into. We put it out, hoping to get some reaction from the world. If there is no reaction, we will only invest a bare minimum for our own use. When there is some reaction, the community might find its sweet spot. When there is huge enthusiasm, which is the least likely, we might decide to seek ways to invest more and get our returns.
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.
So the answer to my question was "yes" then, thank you. I don't know what I would call that practice but it is not any kind of "open source circle of life".
> 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.
> In the months before that controversial license change they got plenty of funding from investors.
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 wish there was a FOSS license with a clause along the lines of:
- 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.
You can write such a license if you want (or hire a lawyer to write it), but it's not FOSS and it never will be. Why is it important to you that such a license is recognized as FOSS?
Like laws, definitions change with changing times and circumstances. I am a Debian Developer and very happy to discuss this with other members of the community. Why is it important to you that such a license is not recognised as FOSS?
I can't imagine it would go down well at all with Debian users if random packages (in the free or the nonfree repo) came with clauses saying you now owe royalties to random parties. If you installed 10 packages on your company's server that each ask for 20% royalty, your company now would owe 200% royalties. It would just make the distro unusable by companies.
That's simply not true. ">X revenue a year" would affect nobody except the largest tech companies. Apart from this, it would strictly benefit existing users, because it means the projects that are properly contributing to the FOSS ecosystem, including importantly its diversity, are getting a fair share of income.
Seems problematic. You've excluded subsidiaries, but what about companies which aren't controlled by the larger corp? They can buy hosting from whomever from companies they don't control in the slightest, and if there's a market for your software it seems likely those would spring up on their own. What do you do?
(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.
> what about companies which aren't controlled by the larger corp?
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.
> it doesn't magically hold third-parties responsible
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.
if only there was a way to make cloud providers charge a per second usage charge for software used...
And an open source licence that could support that...
I've been thinking about this in my spare time for a while, under the working title "General Magic License"+. I think it's a good way (the only way) to reason about the whole "who pays for open source development?" problem.
If you can define the terms of that license, and figure out how to get licensors to follow the terms, and copyright owners to license their code under it, then <boom>. Also it may be possible to prove the converse -- that it's impossible to define such a license. Then we can all get back to work on proprietary software, or at least know we're not going to get paid.
Self-hosting of software is what is changing. The open-core model is really built around maintaining installations of software on your own hardware (or virtual hardware). "Paying for pro" made sense in that world. With many things you would have installed and maintained on your own hardware moving to a SaaS model and PaaS model, there's really not much of an opportunity to "sell the pro version" outside large enterprises who are 10 years behind the curve. My latest startup owns zero servers. Costs scale on user count (for office stuff) or utilization. Licenses? I get calls from software vendors, and it's hard to even understand what they are selling because I don't buy licenses anymore.
Quick takeaways about open source business models:
- Dual licensing: Well, poison. Who's want to sign away their copyrights so that some company can make a buck? It's essentially proprietary software that also happens to be available open source under some as-tedious-as-possible licensing terms.
- Open core: Essentially proprietary software with an open source loss leader. Or for the supermarket chain variant of this business model: "We're opening a new supermarket! Free plastic buckets to the first 1000 customers", causing hours-long queues of people that really want a $2 plastic bucket for free. And as we've seen, it's not much of a protection against big cloud providers with armies of programmers that can easily recreate whatever proprietary juice you have added on top, adapted to their particular environment.
- Public goods: Like Linux Foundation projects like the Linux kernel or Kubernetes. Can work, but is not the direct core value of any of the companies participating. Similarly, a company in some other industry may share some code as open source in order to reduce the maintenance burden.
- Free software product: The flag bearer being Redhat. Code itself may all be open source, but a company call sell a particular version of it with support, training etc. Might not get the growth numbers and scale that gets VC's excited (as can be seen in the blog post the parent linked to), but can be sustainable.
In dual license, you offer the product alternatively under an open source license, or a commercial license. Typically the open source license is chosen to as onerous and scary as possible to force companies to buy the commercial license. And it requires you to hold all the copyrights so that you can relicense it, giving most contributors cold feet. A typical example of this is MySQL or Qt, or the various server-side licenses adopted by MongoDB etc (though those are onerous enough to not be certified open source by the OSI, but the principle remains the same).
In a free software product, the code itself is available under an open source license, often one that doesn't prevent use by companies. The product is some particular version of the code built, QA'd, vetted and supported by the vendor. The typical example being RHEL. But in addition to RedHat, this model can be used also by single-product companies.
Almost every one of these models is based on differentiated licensing. I want your software, but different features/licensing. There's really not much of a difference between open core and "dual licensing". I think for open source, there are only a few revenue models that really matter:
* Aggregators - Redhat and AWS (and cloud providers). They sell and deliver collections of open source software, driving value from configuration and easier deployment.
* Differentiated licensing - Toss all the variations on pay for something other than the GPL version or additional features into this bucket. It's a model that is rapidly becoming obsolete.
* PaaS / Saas - host it for the client. Value is delivered by better operations. Competitors often are aggregators in the form of cloud vendors.
* Support & Services - Free software, paid support, paid consulting. This limits the market to larger companies or at least people who need a much higher level of support. Competitors can be other contributors to the code base.
* App Store Delivery - I'm seeing lots of GPL software where the authors are putting the "official version" in app stores (lots of this going on in Windows) and charging for it. Competitors can be anyone who can build and deliver the app, but since many apps need a back end, the hosting of app data can be a moat.
Redis is given as one of the examples of "open core" failing. But even if you treat the new Redis source available license as completely proprietary, Redis is still open core, since the core is still licensed with BSD 3-clause. It is just that some of the extensions that used to be open source are now proprietary.
I'd say good riddance. Open core to me always felt more "openwashing" than honest attempt to build free software project/community. Part of the feeling arises from the fact that when teenager me first started learning about foss software, Linux, GNU etc one of the things that made such a great impression was that there was no feature gating, no "enterprise editions", nothing locked away. Instead I had all the power in the world on my fingertips. The idea of being built by hackers for hackers to fill their needs resonated to me a lot, not having marketing or product driven development but scratching your own itches. Open core fits very poorly to that worldview.
edit: This comment might have started out bit harsh, apologies. I did not mean to imply malice on the companies that tried to make open core work, but rather bit of naivete or misunderstanding regarding open source and building business around that.
Is there a reason that a new style of licence that prevents the "fork and suffocate" approach of these large companies can't be ratified as fitting with core open source values?
Being dogmatic about the definition of open source, and not allowing that to evolve over time, feels like hard times ahead.
(IMO) The only people who really care about open source are us, the philanthropic builders of said software.
If we shout down those in our community who question the status quo, by simply stating "it's not open source", then we lose those people.
Given the hard stance we see on open source, it's very seldom that the reply to that is "but why can't it be".
An analogy that springs to mind is jslint (bear with me here..). A great idea that had true belief at heart, but was just too strict for mass adoption.
JSLint started a wave of enforcement that was needed, yet the far more flexible jshint (and subsequent eslint) won out in the long run.
I'm fully onboard with truly open source, and think there will always be a place for it. But feel that being all or nothing suffocates the discussion.
Nothing is stopping you from using your own source available license. Mongo did it, and they're doing okay.
It seems like you're arguing something different: You (general you) want the distinction and, more importantly, goodwill that the "open source" label gives you, but without actually having to fit the parameters of "open source".
Open source is a trademarked term by OSI, and it doesn't allow licences that discriminate based on user (even cloud mega corps) to call themselves open source.
The Businesses source licence https://mariadb.com/bsl11/ tries to make dual licencing easier, but isn't "open source", the term is "source available"
This seems to me more like another case of "death of a business model caused by revenue maximization strategy". "Open-core" does not have "non-viable" or even "must-be-bait-and-switch" stamped all over it. But if the organization using it decides that its primary goal is revenue maximization (and/or significant growth), then it becomes much more questionable how it will fare.
But isn't that the goal of any business, I hear you cry? No, it certainly is not. There are thousands of small businesses even just in the USA that are happy to work within the limitations of their situation and initial desires.
It's not necessarily the organization and its founders who have revenue maximization as a primary goal. The other factor is hundreds of millions of dollars of VC money, and VCs are definitely all about revenue maximization. MapBox has raised quarter of a billion.
The conundrum is how does a company develop software as complex as MapBox without relying on VC cash to get the ball rolling.
So, you’re running a small restaurant, and are fine with it staying small, as long as you can make a living. You publish all your recipes under a permissive license.
A restaurant chain starts selling your dishes, using your name, but, because of their scale, cheaper than you can afford to.
If you still manage to make money, you may be fine with that, but that’s where the correspondence breaks.
In real life, that restaurant chain offers a better product, not because its dishes are better, but because its restaurants are in better locations (have faster network connections), are closer to cinemas and theaters (they offer a zillion other products), etc., and, unlike with restaurants, you can’t make money by branding yourself as “the original”.
I don’t see that smaller restaurant staying in business, unless it starts making new recipes it keeps for itself.
There are loads of small pizza places that make money and they don't have some "special"/"magic" pizza recipe. There are also loads of pizza chains that make money as well selling basically the same product. I am not pizza lover, for me it is just another dish so maybe I am wrong.
>You publish all your recipes under a permissive license.
(Setting aside the fact that it's an analogy and recipes aren't covered by copyright...) Why does it have to be a permissive license?
>A restaurant chain starts selling your dishes, using your name, but, because of their scale, cheaper than you can afford to.
Why is it okay for them to use your name? You can release free software but not let just anyone use your trademark. (See: Firefox, Red Hat, etc.)
>I don’t see that smaller restaurant staying in business, unless it starts making new recipes it keeps for itself.
Well in the case of actual small restaurants, clearly publishing a recipe book isn't necessarily catastrophic; after all, many do. Stretching the analogy this far doesn't make the point very well.
so the end consumer benefits. I think that's an acceptable outcome tbh.
> unless [the small restaurant] starts making new recipes it keeps for itself.
which is why it doesn't make sense to give away the recipes in the first place. If restaurant's value proposition is _merely_ the recipe, and you give it away, but expect customers to be charitable and still give you money, then the business is a failing one (even if temporarily solvent).
But if your small restaurant has qualities that can't be replicated in a chain, then you have a business model (even if temporarily insolvent - you just have to hang on and not bankrupt...), and you can "afford" to give away the recipe and chalk it up to marketing expense.
This is why there's barely any real businesses selling open source games - there's hardly any differentiator there. But for enterprise/productivity applications, i think there may be - for example, professional services associated with the product, or customizations etc.
Very good point and I'd go a step further: There are lots of organizations that are not even businesses in the first place who can sustainably fund open source work.
Postgres came out of UC Berkeley. GNU stuff like emacs and gcc came out of MIT. VLC came out of École Centrale Paris. SecureDrop is developed by the Free Software Foundation. Tor was originally funded by the Open Technology Fund (USG). Firefox is from a nonprofit funded by Google advertising and born from the ashes of a commercial failure. Etc etc etc.
There may or may not be an open source business model, but there does not have to be one at all for open source to thrive.
Furthermore, commercial involvement in open-source doesn't require an "open source business model" which will placate VC-level ambitions.
For instance, the extremely popular model of a company hiring core maintainers (or other experts) for an open source project which is critical to business success continues to be viable.
The business can make its money a different way; so long as the ROI justifies open source involvement, it will happen.
In the future contributors might insist on a DCO instead of an CLA so that it is impossible for the project to change from open source to a closed license. Debian insisted on that when switching to GitLab https://about.gitlab.com/blog/2017/11/01/gitlab-switches-to-...
As much as I want open source software to be good, commercial software has the inherent advantage of having hierarchies and teams that are all powered by compensation. We could really use some kind of platform in the open source community built around (a) making it easy to fund projects, AND (b) making those projects organizable, with a team lead and contributors.
Counterpoint to that, all the tools I use most often and am most delighted by are published under a GPL or other FOSS license (Bash, Linux, Emacs, Firefox, Inkscape, etc) whereas the ones I am most constantly frustrated by, angry at, and find the most fault with are closed source proprietary company developed (Anything that starts with MS, VMWare Fusion, etc)
Firefox is developed by a company with hierarchies. Those other ones have the advantage of being very old and lots of time to iterate on them. Open source produces lots of gems, the problem is that it is very slow moving and IMO the effectiveness is cut in 10 by duplication of effort and lack of coordination. For every successful open source project, there are about 20 stubs and 5-10 less successful open source programs that do basically the same thing.
Agreed. Hierarchies are an advantage only if the people on top of the hierarchy are either unusually right or unusually good at hiring and deferring to people who know better than they do.
Big questions: Who pays for credit processing, auditing etc.? One platform or many? Are the managing people allowed to make a profit? How do you ensure that important but boring projects get money as well?
See the ubuntu software store, elementary OS, patreon/liberapay, ....
If you sell the software, you could in theory form a team with hired individuals, etc. It’s not proprietary software that has some advantage; the act of keeping the source proprietary does nothing to help with logistics of development, that’s what charging money does.
As for the questions, I don’t have the solution, I am limited to knowing what the problems are unfortunately.
"(a) making it easy to fund projects"
I don't know how it is in the US, but in EU you need a regular invoice for a business expense. So if a company wants to support an open-source project today, they need an invoice from the authors. Now try to get this from the author of your favorite GitHub open-source library... And for large corporations you need to get a quote / an offer so that a business decision may be made and budget may get allocated... Now try to get an offer from the author...
What about non-profit organizations, donations, charity funds? I doubt that there is absolutely no way for EU based companies and people to support open source projects snd teams behind them
In my country a company can legally donate if: a) organization is on a list of approved non-profit organizations or b) you sign a contract with organization where the purpose of donations is clearly defined. Usually authors of open-source projects are not "approved non-profits" so you must have a contract with them...
At one one place I work we successfully contracted the authors of random GitHub projects to add features we needed, so it is definitely doable. I've also had companies/folks contact me randomly about improvements to open source projects I've worked on. For larger projects there are usually lots of consulting companies able to do that too.
But… there's nothing wrong with the business model, no? It's not that they aren't making money by selling an enhanced version of the software, it's that they aren't making as much money as cloud services? Or did I misunderstand?
Seriously though, this article makes some assumptions I’m not sure about. One of them is that Mapbox’s move will be successful. I’m not sure it will be, most users of Mapbox probably won’t upgrade to the new version or will upgrade to whatever fork becomes most popular. In the meantime this is going to make people a lot warier of using them as a tile server and give impetus to their competitors in that market space. It’s quite possible they’ll start to see declining revenues pretty soon.
The success of their strategy is tied to the greatly expanded 3D capabilities of version two. It’s really cool and the demos are super sexy but for the vast majority of use cases 2D maps are a better fit. Given the distrust they’ve generated and the massive increase in licensing cost attached to their new model for many customers, there are now some extremely compelling reasons for customers to drop them.
My interpretation is the opposite. MongoDB is clearly successful - they are a public company worth 16 billion dollars. And they proving the success of the open core business model.
For 99% of use cases, MongoDB is open source. You can see the code, you can make modifications, you can use it for free in your business, you can share your changes with others, you can integrate it into your products and services. Yeah, you can't use it if you're working at AWS, but for most people it's just fine.
For founders creating new open source companies, it's a great strategy to go the route of MongoDB. Start off open source and sell services. If you run into big enough problems with direct competitors using your own software, you can modify the license to exclude them.
This is far better than the status quo in, say, 2010, when the conventional wisdom was that if you're providing a service it shouldn't involve any open source at all.
I'd replace mongo with redis in your comment. Redis truly is open core, but mongo no longer is. Now it's source available, and has been removed from the repos of many distros.
Calling mongo open source now just dilutes what "open source" actually means. The organization even removed the submission of its license for approval by the OSI.
It's source available, and it's up to each person to decide whether that's good or bad.
That’s true, but Redis and MongoDB are at different points in their growth. Redis is worth around 1 billion, and they are still private. I would not be surprised if Redis usage continues to grow, which attracts more competitors, and they eventually shift to a “99% open” model more similar to MongoDB.
I know that there's a formal definition of capitalized "Open Source" by the OSI, but I'm also not enchanted by that being the only definition for lower-case "open source". I think that the lower case open source is really more about a general approach to software (or intellectual property in general, really). Some people want to use terms like "libre" to refer to projects that have most of the practical characteristics of open source projects, but not an OSI-approved license, but I kind of think that the lower-case version of the term is important because it's reached a point of basically a colloquialism.
There's room for a grey area, but I think that the parent's comment about how Mongo's license relates to the overwhelming majority of it's community to use it (in that, functionally, it doesn't) still pushes farther towards open source than it does proprietary with source-available.
People forget that the OSI and the people behind it neither own, nor invented, the term 'open source.' They want to give you the impression that they do and they did, but they don't and they didn't.
But at least this much is not true - we can see it being used, in context, at least as far back as 1996. I think people involved in this project at the time say it was a common term back then as well, but I can't find a reference for that now.
The Caldera announcement you’re referring to does not use "open source" as a term. They write "open (source code) model", not "(open source) (code model)". It’s an important distinction.
And yes, Christine indeed invented the term, and folks from OSI gave it the current meaning by clearly defining it.
I'm afraid this just isn't true. Ask other people around at the time:
> I joined Caldera in November of 1995, and we certainly used "open source" broadly at that time. We were building software. I can't imagine a world where we did not use the specific phrase "open source software". And we were not alone. The term "Open Source" was used broadly by Linus Torvalds (who at the time was a student...I had dinner with Linus and his then-girlfriend Ute in Germany while he was still a student), John "Mad Dog" Hall who was a major voice in the community (he worked at COMPAQ at the time), and many, many others.
So where are all the examples on public mailing lists and Usenet of them using this? I'm afraid I simply don't trust people's hazy memories of conversations from years ago.
How many examples do you need to prove that something existed? Isn't one enough? When you see a fossil of a dinosaur skeleton in a museum do you say 'well hang on are there any more or just one?'
And it was rejected because it was a simple descriptive term. You can't take ownership of a simple descriptive term.
Bottom line facts are: OSDI don't own it - that's a fact - and they didn't use it first - that's a fact.
I didn't claim it didn't exist so your strawman is irrelevant. If there was only a single dinosaur skeleton in existence I certainly wouldn't be claiming they were common animals.
The fact is it was barely used until the OSI introduced it as a term at which point it became popular. You seem to have a personal problem with that.
Yes it is. Just because a phrase was used once or twice in some obscure post in the past, doesn't mean that someone can't come up with it independantly.
> a common term back then as well, but I can't find a reference for that now.
Because it wasn't a common term at all. If it was, you'd be able to find thousands of examples of usage, from all over the early web and (especially) Usenet. How many examples do you actually have. Two or three?
In the application to software, Bruce Perrens most definitely did define ther term, based on the Debian Free Software Guidelines, and the Free Software Foundation's Three Freedoms definition of Free Software, in June 1997:
The term was not previously used with regard to software, though the intelligence community have used the phrase "open sources" to refer to unclassified information.b
I don't see a good reason to view it as akin to a power-grab. It's profoundly unhelpful when terms are diluted and muddied. We should use the OSI's definition not because they say so, and not for legalistic reasons like trademarks, but because it's important to have meaningfully precise language.
It's right that when a thread is submitted of a project falsely claiming to be open source, the HN community unfailingly tears it to shreds. We don't want the term to be cheapened into becoming meaningless. I don't see that the origins of the term are relevant.
Personally I tend to capitalise, I typically use Free and Open Source software to be more clear that I'm referring to free software as defined by the FSF, and open source as defined by the OSI. It's unfortunate that I've found this to be necessary, to close the door on obtuse misuse of these terms.
Mongo is also proving the success of vendor lock-in: you (or the engineers before you, and the engineers before them) make a mess in Mongo, because there are no relations and no schemas [0], and it becomes really difficult to get off it.
The effort required just to get your data in a state that's clean enough to consider moving to the RDBMS you should have started with can be overwhelming.
Then you have to rewrite your queries out of their custom query language.
Is it Mongo's fault you made a mess in your database? No, of course not. And their dashboard is actually pretty nice. But you are massively locked-in.
Source: own a production Mongo DB with years of accumulated mess in it. Desperate to get off it. Paying customer of Mongo's hosting (it's one less Mongo thing to deal with, at least).
[0] There is schema support now, but it's only JSON schema and it's relatively new in the scheme [sorry] of things
This isn't really vendor lock-in, though. It's simply a technical/design lock-in. Going from unstructured to structured data presents problems, and if you do that, it's rightfully up to you to fix.
It is different from the vendor lock-in that prevents one from migrating from AWS to Google Cloud because all of your code uses their APIs and libraries specifically.
However, the effect is the same, of course. You are locked in! It's not necessarily a bad thing, but this is why you must choose your poison carefully.
> This isn't really vendor lock-in, though. It's simply a technical/design lock-in. Going from unstructured to structured data presents problems, and if you do that, it's rightfully up to you to fix.
This is true, but it's also kind of vendor lock-in because there's a whole query language and aggregation pipeline for Mongo that's completely different to other databases. If I was using an RDBMS and was switching from MySQL to Postgres I think I would likely have a much easier time, because fundamentally it's all SQL (I know, there are differences between Postgres and MySQL, but it's a lot less, and a good ORM will smooth some of it out for you - at least initially)
I think this is basically equivalent to your example of not being able to easily move from AWS to Google Cloud because of their different APIs.
I very much prefer to use RDBMS first and the rest as the last resort. Still I do not believe that quality of data design could be enforced just by the fact of using RDBMS. I sometimes encountered RDBMS schemas that look like they were designed by lunatics.
Postgresql supports JSON-in-db out of the box, so I'm not sure that there's any real lockin wrt. Mongo. It's just that those who care about not being tied to a single vendor are less likely to use something like Mongo in the first place.
RDBMS doesn't work for some of the complex hierarchical data I have to deal with. Shredding it out into a 3NF relational schema would require joining 20+ tables in every query to do anything useful. No thanks. Use the right database type for the job.
I took the opposite route in 2010, and it didn't work out well for me. We sold it as a premium product, and it was hard to get adoption. Which made it hard to actually prove the benefits we claimed should exist.
That's not proof that we'd have fared better if we had open-sourced it. We took exactly the opposite route of MongoDB, with very stringent schemas to ensure data quality. That required a large up-front investment in time, and that was a hard sell too. The whole world went in the opposite direction, of schemaless databases and machine learning for "eh, good enough" answers.
Still, I'll always wonder if we wouldn't have failed so spectacularly if we'd open sourced it. The idea was a pretty good one, and we wrote some remarkable software to make it happen.
The company was called Highfleet. We built ontology-based databases. Not OWL ontologies; we were actually doing ontologies before OWL. We were briefly and tangentially involved, but we thought they had picked the wrong level of ontology. We had a full-featured logic language for really strong definitions, so that you have strong guarantees about data quality and good ways to reason about data integration between databases.
In the end we never found the right use case for it. The advantages were all in maintenance rather than development, and even people who could be talked around to it wouldn't see the payoff. There were a trillion other problems, and maybe better management than me could have made it work.
I wish there was a FOSS license with a clause along the lines of:
- 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.
Laws and definitions have to change with the changing times - the technological economy is different today than it was 20 years ago when tech companies weren't so big or able to throw their weight around. Staying true to the original spirit of FOSS and sharing, means that we have to find ways to support independent FOSS business.
The loudest arguments I hear at forcing the FOSS definition to remain static and blind to revenue, is from big tech companies or wealthy people being paid by big tech companies, because it benefits them. People working for a small FOSS companies understand the realities of competing in today's tech environment, and understand that revenue-sharing far from stifling FOSS, will allow it to flourish properly.
That license is specifically targeted in favour of small businesses for some reason, omitting individuals etc. This potential FOSS license I am talking about would only target against big tech companies.
Is this going to be fixed/known price? then you are describing "source available" model. I don't think we need another word for it -- it exists, and it works pretty well (even Microsoft uses it sometimes)
Or are you describing some sort of system where the authors get the fixed share (%) of user's company revenue? I think this is not going to work very well... just imagine a big company which is not focused on computers. Or a computer startup which wants to be bought by FAANG for billions of dollars.
Yes, game projects absolutely use Hollywood accounting. Dev studios pop up for one project, and often close at launch, and some other legal entity gets all the subs after that. And so on. Game dev financing is infamously horrid.
Unreal, though, is in a different negotiating position with the game publishers than, say, an open-source software with a new pay-us-if-you-make-money clause. Its the distinction between source-available (like Unreal Engine) and open-source which the article tries to make?
Timescale's new license is an interesting move in this direction.
Is there a way to structure a license so that this kind of accounting is much harder?
In Hollywood’s case, it’s pretty clear when movies are making money (same with games to a large degree), but I don’t know if there’s a way for “tool” companies to leverage that.
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.
222 comments
[ 2.7 ms ] story [ 250 ms ] threadFor some reason, the author never mentioned AGPL. What's wrong with using this license if you want to defend your open-source business model?
AGPL code is strictly forbidden for use inside the company now, partially because they consider private modifications to open-source software to be a competitive advantage.
The author of the article's thesis is that this is "an end of an era" of Open Core business models (putting core technology under a free/libre licensing and charging for extra proprietary features).
I'm very curious as to what other people here on HN have to say about it. Gitlab, a prominent company that follows an Open Core model, is a YCombinator alum, no?
Do the couple dozen devs at my company really need an internally-hosted version, or should we just pay for the cloud offering and supply our own runners? Seems easy to frame as a wash.
> Do the couple dozen devs at my company really need an internally-hosted version?
From personal experience and knowledge through friends: Everyone writes code. Universities, Governments, Governmental agencies, political parties, etc.
A lot of them do not want to host in the cloud, especially in Germany, considering that the cloud (depending on the provider you are looking at) means hosting outside of Germany with all that entails privacy and regulation wise.
My response is "what's your threat model?". For a small company, our only security advantage is being a small target; there's no way we're competing with the Gitlab.com team on security.
1. If a 3-letter agency requests access to your on-prem data you'll know about the request and know which data is compromised.
2. You now have to trust your hosting provider. This is almost the same as being a small target, but not quite because you need to worry about all of their employees AND all of your own. There are 1k+ employees to attempt to compromise at Gitlab, and you have no control over or contracts with any of them.
3. Expanding on 2, given the disconnect between Gitlab and your own organization you open yourself up to new kinds of attacks like social engineering an account takeover, or expanding an email breach to a source code breach.
I don't think any of that matters for most people, but your attack surface area is increased with current cloud tech.
Without on-prem, you're cut out of your source code service and will have to do a potentially hasty migration to an entirely new platform (which brings its own issues inherent in any migration project).
Our Open Core business model is part of our 3 year strategy [1] and something I consider one of our key strengths. As a member of the Community Relations team, I may be a bit biased. :)
We acknowledge the risk of "Fork and Commoditize" [2] on our list of biggest risks but believe that risk is reduced because we're application software instead of infrastructure software.
1 - https://about.gitlab.com/company/strategy/#2-build-on-our-op... 2 - https://about.gitlab.com/handbook/leadership/biggest-risks/#....
We detail the differences between infrastructure and applications in link #2 in my previous comment. If you have any suggestions on how we can improve that section, I'd encourage you to create a MR to update the page. Just click the "Edit in Web IDE" link at the bottom to get started. :)
Why do you believe this? My project uses self-hosted gitlab (ancient version) and I frankly have a very hard time seeing it as anything other than infrastructure. Maybe we just don't push our use of gitlab a lot (to be fair, we don't push it at all).
GitLab's co-founder and CEO goes into the details in this talk: https://www.heavybit.com/library/video/commercial-open-sourc...
To your point on your usage - it's certainly possible that folks use GitLab in different ways and that our thesis does not apply to each use case.
Almost all of the CNCF-based businesses are complex plug-in models that the CPs can’t just make a button for.
Even if they're complex and not one-button click to drop in, the cloud providers seem keen on running managed versions of these projects.
What projects come to mind as being "immune" to this problem, out of curiosity?
For the particular case of AWS now offering Kubernetes, is that:
- A win for AWS, since they can leech code without contributing back
or
- A win for Kubernetes contributors and users vs AWS, since now customers have the option of moving their Kubernetes workloads from AWS to other providers.
And if someone wants to make the same category of product free and open source, that's cool too. Live and let live.
But I don't think it's impossible, just the social hurdles haven't been cleared yet. Not much technology to throw down on the problem.
- 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.
That would just be a proprietary license with source availability. It would also dry up any community contributions since contributors are generally not going to help a for-profit project without themselves getting paid.
> contributors are generally not going to help a for-profit project without themselves getting paid.
Contributors already contribute to for-profit open source projects without themselves getting paid. This license would make the situation strictly better for them.
if you want people read your article, just yell that something they love is dead. works every time.
I'd write an article about VR, entitled: "Death of monitors."
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.
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...
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.
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.
- 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.
+Yes, I know.
Quick takeaways about open source business models:
- Dual licensing: Well, poison. Who's want to sign away their copyrights so that some company can make a buck? It's essentially proprietary software that also happens to be available open source under some as-tedious-as-possible licensing terms.
- Open core: Essentially proprietary software with an open source loss leader. Or for the supermarket chain variant of this business model: "We're opening a new supermarket! Free plastic buckets to the first 1000 customers", causing hours-long queues of people that really want a $2 plastic bucket for free. And as we've seen, it's not much of a protection against big cloud providers with armies of programmers that can easily recreate whatever proprietary juice you have added on top, adapted to their particular environment.
- Public goods: Like Linux Foundation projects like the Linux kernel or Kubernetes. Can work, but is not the direct core value of any of the companies participating. Similarly, a company in some other industry may share some code as open source in order to reduce the maintenance burden.
- Free software product: The flag bearer being Redhat. Code itself may all be open source, but a company call sell a particular version of it with support, training etc. Might not get the growth numbers and scale that gets VC's excited (as can be seen in the blog post the parent linked to), but can be sustainable.
In a free software product, the code itself is available under an open source license, often one that doesn't prevent use by companies. The product is some particular version of the code built, QA'd, vetted and supported by the vendor. The typical example being RHEL. But in addition to RedHat, this model can be used also by single-product companies.
For more detail see e.g. https://sfosc.org/docs/book/business-models/
* Aggregators - Redhat and AWS (and cloud providers). They sell and deliver collections of open source software, driving value from configuration and easier deployment.
* Differentiated licensing - Toss all the variations on pay for something other than the GPL version or additional features into this bucket. It's a model that is rapidly becoming obsolete.
* PaaS / Saas - host it for the client. Value is delivered by better operations. Competitors often are aggregators in the form of cloud vendors.
* Support & Services - Free software, paid support, paid consulting. This limits the market to larger companies or at least people who need a much higher level of support. Competitors can be other contributors to the code base.
* App Store Delivery - I'm seeing lots of GPL software where the authors are putting the "official version" in app stores (lots of this going on in Windows) and charging for it. Competitors can be anyone who can build and deliver the app, but since many apps need a back end, the hosting of app data can be a moat.
edit: This comment might have started out bit harsh, apologies. I did not mean to imply malice on the companies that tried to make open core work, but rather bit of naivete or misunderstanding regarding open source and building business around that.
Is there a reason that a new style of licence that prevents the "fork and suffocate" approach of these large companies can't be ratified as fitting with core open source values?
Being dogmatic about the definition of open source, and not allowing that to evolve over time, feels like hard times ahead.
(IMO) The only people who really care about open source are us, the philanthropic builders of said software.
If we shout down those in our community who question the status quo, by simply stating "it's not open source", then we lose those people.
Given the hard stance we see on open source, it's very seldom that the reply to that is "but why can't it be".
An analogy that springs to mind is jslint (bear with me here..). A great idea that had true belief at heart, but was just too strict for mass adoption.
JSLint started a wave of enforcement that was needed, yet the far more flexible jshint (and subsequent eslint) won out in the long run.
I'm fully onboard with truly open source, and think there will always be a place for it. But feel that being all or nothing suffocates the discussion.
It seems like you're arguing something different: You (general you) want the distinction and, more importantly, goodwill that the "open source" label gives you, but without actually having to fit the parameters of "open source".
I'm just asking why an innocent question along the lines of "couldn't we.." gets immediately shut down as "No, That's not open source".
What is ultimately wrong with having real world limitations to a licence?
Nothing? Again, Mongo is doing it, and seems to be fine.
Conversely, why do you need to call those licenses with "real world limitations" open source?
The Businesses source licence https://mariadb.com/bsl11/ tries to make dual licencing easier, but isn't "open source", the term is "source available"
This is a lie. You're lying.
> "Open Source" is not and cannot become a trademark.
https://opensource.org/pressreleases/certified-open-source.p...
I was probably misremembering something I read on Slashdot in the 90s.
I don't think you're lying about saying I'm lying... you're just wrong (as I know my own intent)
But isn't that the goal of any business, I hear you cry? No, it certainly is not. There are thousands of small businesses even just in the USA that are happy to work within the limitations of their situation and initial desires.
The conundrum is how does a company develop software as complex as MapBox without relying on VC cash to get the ball rolling.
A restaurant chain starts selling your dishes, using your name, but, because of their scale, cheaper than you can afford to.
If you still manage to make money, you may be fine with that, but that’s where the correspondence breaks.
In real life, that restaurant chain offers a better product, not because its dishes are better, but because its restaurants are in better locations (have faster network connections), are closer to cinemas and theaters (they offer a zillion other products), etc., and, unlike with restaurants, you can’t make money by branding yourself as “the original”.
I don’t see that smaller restaurant staying in business, unless it starts making new recipes it keeps for itself.
There are loads of small pizza places that make money and they don't have some "special"/"magic" pizza recipe. There are also loads of pizza chains that make money as well selling basically the same product. I am not pizza lover, for me it is just another dish so maybe I am wrong.
these small pizzarias tend to make good pizza - much better than the chains do.
(Setting aside the fact that it's an analogy and recipes aren't covered by copyright...) Why does it have to be a permissive license?
>A restaurant chain starts selling your dishes, using your name, but, because of their scale, cheaper than you can afford to.
Why is it okay for them to use your name? You can release free software but not let just anyone use your trademark. (See: Firefox, Red Hat, etc.)
>I don’t see that smaller restaurant staying in business, unless it starts making new recipes it keeps for itself.
Well in the case of actual small restaurants, clearly publishing a recipe book isn't necessarily catastrophic; after all, many do. Stretching the analogy this far doesn't make the point very well.
so the end consumer benefits. I think that's an acceptable outcome tbh.
> unless [the small restaurant] starts making new recipes it keeps for itself.
which is why it doesn't make sense to give away the recipes in the first place. If restaurant's value proposition is _merely_ the recipe, and you give it away, but expect customers to be charitable and still give you money, then the business is a failing one (even if temporarily solvent).
But if your small restaurant has qualities that can't be replicated in a chain, then you have a business model (even if temporarily insolvent - you just have to hang on and not bankrupt...), and you can "afford" to give away the recipe and chalk it up to marketing expense.
This is why there's barely any real businesses selling open source games - there's hardly any differentiator there. But for enterprise/productivity applications, i think there may be - for example, professional services associated with the product, or customizations etc.
Postgres came out of UC Berkeley. GNU stuff like emacs and gcc came out of MIT. VLC came out of École Centrale Paris. SecureDrop is developed by the Free Software Foundation. Tor was originally funded by the Open Technology Fund (USG). Firefox is from a nonprofit funded by Google advertising and born from the ashes of a commercial failure. Etc etc etc.
There may or may not be an open source business model, but there does not have to be one at all for open source to thrive.
For instance, the extremely popular model of a company hiring core maintainers (or other experts) for an open source project which is critical to business success continues to be viable.
The business can make its money a different way; so long as the ROI justifies open source involvement, it will happen.
See the ubuntu software store, elementary OS, patreon/liberapay, ....
Edit: Also "commercial" is the wrong word. You mean proprietary. You are very much encouraged to sell free software https://www.gnu.org/philosophy/selling.html
As for the questions, I don’t have the solution, I am limited to knowing what the problems are unfortunately.
Upd: GH has announced they can do too https://github.blog/2020-12-08-new-from-universe-2020-dark-m... "Starting today, investing in open source is as easy as just adding it to your GitHub bill!"
Seriously though, this article makes some assumptions I’m not sure about. One of them is that Mapbox’s move will be successful. I’m not sure it will be, most users of Mapbox probably won’t upgrade to the new version or will upgrade to whatever fork becomes most popular. In the meantime this is going to make people a lot warier of using them as a tile server and give impetus to their competitors in that market space. It’s quite possible they’ll start to see declining revenues pretty soon.
The success of their strategy is tied to the greatly expanded 3D capabilities of version two. It’s really cool and the demos are super sexy but for the vast majority of use cases 2D maps are a better fit. Given the distrust they’ve generated and the massive increase in licensing cost attached to their new model for many customers, there are now some extremely compelling reasons for customers to drop them.
For 99% of use cases, MongoDB is open source. You can see the code, you can make modifications, you can use it for free in your business, you can share your changes with others, you can integrate it into your products and services. Yeah, you can't use it if you're working at AWS, but for most people it's just fine.
For founders creating new open source companies, it's a great strategy to go the route of MongoDB. Start off open source and sell services. If you run into big enough problems with direct competitors using your own software, you can modify the license to exclude them.
This is far better than the status quo in, say, 2010, when the conventional wisdom was that if you're providing a service it shouldn't involve any open source at all.
Calling mongo open source now just dilutes what "open source" actually means. The organization even removed the submission of its license for approval by the OSI.
It's source available, and it's up to each person to decide whether that's good or bad.
I wasn't aware the licensing is more restrictive now.
There's room for a grey area, but I think that the parent's comment about how Mongo's license relates to the overwhelming majority of it's community to use it (in that, functionally, it doesn't) still pushes farther towards open source than it does proprietary with source-available.
Christine Peterson claims to have invented the term in 1998.
https://opensource.com/article/18/2/coining-term-open-source...
But at least this much is not true - we can see it being used, in context, at least as far back as 1996. I think people involved in this project at the time say it was a common term back then as well, but I can't find a reference for that now.
http://www.xent.com/FoRK-archive/fall96/0269.html
And they certainly don't own it - they wrote a whole article on their own website still available about how they don't own it!
https://opensource.org/pressreleases/certified-open-source.p...
And yes, Christine indeed invented the term, and folks from OSI gave it the current meaning by clearly defining it.
> I joined Caldera in November of 1995, and we certainly used "open source" broadly at that time. We were building software. I can't imagine a world where we did not use the specific phrase "open source software". And we were not alone. The term "Open Source" was used broadly by Linus Torvalds (who at the time was a student...I had dinner with Linus and his then-girlfriend Ute in Germany while he was still a student), John "Mad Dog" Hall who was a major voice in the community (he worked at COMPAQ at the time), and many, many others.
https://webcache.googleusercontent.com/search?q=cache:-i7au3...
Here's one
http://www.xent.com/FoRK-archive/fall96/0269.html
Also - even the USPTO rejected their claim as a trademark.
Rejected after they'd made the term popular.
And it was rejected because it was a simple descriptive term. You can't take ownership of a simple descriptive term.
Bottom line facts are: OSDI don't own it - that's a fact - and they didn't use it first - that's a fact.
The fact is it was barely used until the OSI introduced it as a term at which point it became popular. You seem to have a personal problem with that.
Yes it is. Just because a phrase was used once or twice in some obscure post in the past, doesn't mean that someone can't come up with it independantly.
> a common term back then as well, but I can't find a reference for that now.
Because it wasn't a common term at all. If it was, you'd be able to find thousands of examples of usage, from all over the early web and (especially) Usenet. How many examples do you actually have. Two or three?
In the application to software, Bruce Perrens most definitely did define ther term, based on the Debian Free Software Guidelines, and the Free Software Foundation's Three Freedoms definition of Free Software, in June 1997:
https://opensource.org/docs/osd
https://www.debian.org/social_contract#guidelines
https://perens.com/2017/09/26/on-usage-of-the-phrase-open-so...
The term was not previously used with regard to software, though the intelligence community have used the phrase "open sources" to refer to unclassified information.b
This is just not a true thing to say. See my other replies for examples from before 1997.
It's right that when a thread is submitted of a project falsely claiming to be open source, the HN community unfailingly tears it to shreds. We don't want the term to be cheapened into becoming meaningless. I don't see that the origins of the term are relevant.
Personally I tend to capitalise, I typically use Free and Open Source software to be more clear that I'm referring to free software as defined by the FSF, and open source as defined by the OSI. It's unfortunate that I've found this to be necessary, to close the door on obtuse misuse of these terms.
It's still better than free software, which invariably makes the uninitiated think of freeware.
The effort required just to get your data in a state that's clean enough to consider moving to the RDBMS you should have started with can be overwhelming.
Then you have to rewrite your queries out of their custom query language.
Is it Mongo's fault you made a mess in your database? No, of course not. And their dashboard is actually pretty nice. But you are massively locked-in.
Source: own a production Mongo DB with years of accumulated mess in it. Desperate to get off it. Paying customer of Mongo's hosting (it's one less Mongo thing to deal with, at least).
[0] There is schema support now, but it's only JSON schema and it's relatively new in the scheme [sorry] of things
It is different from the vendor lock-in that prevents one from migrating from AWS to Google Cloud because all of your code uses their APIs and libraries specifically.
However, the effect is the same, of course. You are locked in! It's not necessarily a bad thing, but this is why you must choose your poison carefully.
This is true, but it's also kind of vendor lock-in because there's a whole query language and aggregation pipeline for Mongo that's completely different to other databases. If I was using an RDBMS and was switching from MySQL to Postgres I think I would likely have a much easier time, because fundamentally it's all SQL (I know, there are differences between Postgres and MySQL, but it's a lot less, and a good ORM will smooth some of it out for you - at least initially)
I think this is basically equivalent to your example of not being able to easily move from AWS to Google Cloud because of their different APIs.
It doesn't seem like SQL-to-Mongo is impossible to implement, because there is third-party tooling for that (which I haven't tried): https://studio3t.com/knowledge-base/articles/sql-query/
I can’t conceptualize a dataset that could survive(/be performant) in a document store, but not a graph.
That's not proof that we'd have fared better if we had open-sourced it. We took exactly the opposite route of MongoDB, with very stringent schemas to ensure data quality. That required a large up-front investment in time, and that was a hard sell too. The whole world went in the opposite direction, of schemaless databases and machine learning for "eh, good enough" answers.
Still, I'll always wonder if we wouldn't have failed so spectacularly if we'd open sourced it. The idea was a pretty good one, and we wrote some remarkable software to make it happen.
In the end we never found the right use case for it. The advantages were all in maintenance rather than development, and even people who could be talked around to it wouldn't see the payoff. There were a trillion other problems, and maybe better management than me could have made it work.
- 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.
Laws and definitions have to change with the changing times - the technological economy is different today than it was 20 years ago when tech companies weren't so big or able to throw their weight around. Staying true to the original spirit of FOSS and sharing, means that we have to find ways to support independent FOSS business.
The loudest arguments I hear at forcing the FOSS definition to remain static and blind to revenue, is from big tech companies or wealthy people being paid by big tech companies, because it benefits them. People working for a small FOSS companies understand the realities of competing in today's tech environment, and understand that revenue-sharing far from stifling FOSS, will allow it to flourish properly.
https://polyformproject.org/licenses/small-business/1.0.0
Or are you describing some sort of system where the authors get the fixed share (%) of user's company revenue? I think this is not going to work very well... just imagine a big company which is not focused on computers. Or a computer startup which wants to be bought by FAANG for billions of dollars.
This license would be exactly like today's FOSS, except to force large tech companies to the negotiating table to share revenue.
This would just lead to Hollywood-accounting, where a AWS-Tools subsidiary does all the software at a loss, and AWS-Cloud is just a user etc.
https://www.unrealengine.com/en-US/download
Unreal, though, is in a different negotiating position with the game publishers than, say, an open-source software with a new pay-us-if-you-make-money clause. Its the distinction between source-available (like Unreal Engine) and open-source which the article tries to make?
Timescale's new license is an interesting move in this direction.
In Hollywood’s case, it’s pretty clear when movies are making money (same with games to a large degree), but I don’t know if there’s a way for “tool” companies to leverage that.
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.