Death of an open-source business model
joemorrison.medium.com
joemorrison.medium.com
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.
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.
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.
Open source is about an open community, open contributions, the multiplier you get from contributions from multiple companies. That way open source is a win-win. Companies benefit from each other's contributions.
It's _not_ about just showing the code or a free-for-all.
Once you have free and non-free tiers it's already broken. The incentives no longer align.
I'm being paid in part to work on the open source projects that we utilize for our service(s). Some of those we started, some of those we're contributing to, but we _own_ none of them. We handed them off to external entities (Apache and others) for governance and we actively encourage others to participate.
I would be interested to see if a permissive core with dual-licensed (AGPL+ commercial) extensions would work, for something like GitLab. It's not that big of a step on top of their current model where the proprietary bits are still source-available.
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.
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.
Consider:
- Company releases the Secret Sauce as open source under a highly permissive (non-reciprocal) license
- Secret Sauce coalesces a large, engaged community around it
- Company pays the bills with support, consulting, and other complementary products/services as it bootstraps itself
- Company releases v2 under a traditional non-open license
Everyone profits from this arrangement, potentially. Small users get good, free software to bootstrap projects. Big companies build stuff on top. And in the end, Company takes a portion of the open source audience with it into v2.
Finding that audience and getting them to pay attention is not easy at all. Think of Open Core as the car that gets you there, to borrow a quote from "The Comeback."
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 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.
At my last start-up the first things to go out the window when we wanted to stop burning money were the commercial Aerospike and Nginx licenses. That was five years ago.
The most durable model for commercially-funded open source is as a stratagem for commoditizing someone's complement. If you want to stick it to Apple, fund Android. If you want to stick it to Oracle, fund PostgreSQL. If you want to stick it to Microsoft, fund LibreOffice. If you want to stick it to Sun -- er, Oracle -- fund Linux.
No doubt about that. If you give away the source for free that doesn't produce any cash-flow. If you sell services you sell services.
The value-add proposition of "open source companies" I think is they know the software so you can hire them to do things with it, and they can adapt their open source software if needed as they go along. So that is a service-model. Open Source licenses can help companies that do this.
Open Source is its own worst enemy. At some point an OS project becomes so GOOD that you don't need to be its developer to use it and adapt it or build Cloud-services around it. Further if they need the expertise of the original developers they can simply hire them. The ethos of open source doesn't forbid you from having an employer. An ethical OS-hacker should be happy getting a salary from whichever company lets him or her write Open Source software. That includes companies like Amazon and Microsoft and IBM who then sell the right to use that software on their Cloud.
If this is the correct ethical model then we should not blame Amazon or Google, they do contribute to copyleft Open Source projects. We should blame smaller companies like MongoDB etc. who do not offer "pure" Open Source licenses.
So I'm thinking it's not so much the Open Source Business Model that is in crisis. It is the Open Source Ethical Model, which needs to reflect upon itself in the time of Cloud.
Is it really more ethical to work for Amazon writing Open Source, than writing Non-Open-Source for a small company which wants to make sure it is not crushed by Amazon?
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.
> Today a page about the new Common Clause license in the Redis Labs web site was interpreted as if Redis itself switched license. This is not the case, Redis is, and will remain, BSD licensed.
> What is happening instead is that certain Redis modules, developed inside Redis Labs, are now released under the Common Clause (using Apache license as a base license). This means that basically certain enterprise add-ons…
That is from a few years ago, but I believe it's still true, and basic redis is still FreeBSD. This isn't a slight of hand where "basic redis core" is open source but not really useful by itself, I think the majority of redis installs have never been using those "enterprise add-ons".
I don't think this is necessarily a problem for the author's theory in general, which I am generally sympathetic to as accurately describing something going on in the software world right now, but I think it's misinformation about redis.
But it doesn't change the essence of the argument posited by the author. The redis modules in question were originally AGPL. Redis Labs relicensed them to Apache+Commons Clause. Both Redis Labs and Mongo reacted to pressure by relicensing software.
I agree it doesn't really disprove his general story (which I agree is a trend), it doesn't have to be universal to be a trend, a very strong trend even, there can be special unusual circumstances behind redis, or it can just not yet have succumbed but be on the way, or it can just be an unexplained exception to a strong trend.
It just makes redis not a great example to choose, and it makes his article misleading giving people the wrong idea about what's going on with redis.
OSS companies like Mongo, DataBricks, and Confluent run popular cloud services. They all seem to be doing fine for this reason. I don't see a lot of proof that changing their licensing was a root cause of their success.
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!"
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.
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.
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.
There are a lot of people who assume that the biggest value of using open-source project that it is free. Additionally there are a lot of idealists who think about oss as foss.
Open-source is not dead, it just trying to find a sustainable model for survival. None of the active OSS projects you know exist without money flow. Even if you have hyped project now, without money it will be dead in a year.
More and more companies consider open-source as default option, because there are a better tools right now to make business out of it. And everyone essentially wins from it.
Yes, old models of OSS are mostly dead. But new ones are alive more than ever.
There is an interesting model at Google cloud, where I can deploy and use a Grafana stack for moderate $50/month. Looks like Grafana gets a solid chunk of these money - they are advertising it on their own website.
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 you don't do it, someone like Amazon will. If you want to make that difficult or impossible, use a copyleft license. The choice of a permissive license implies things that you have to think about upfront.
Severely restrictive? I'm amazed at how bad (undeserved imho) reputation Commons Clause license got. The new Redis tools' license is basically the same, just less clear. The same with MongoDB and MariaDB's licenses. In effect, they all forbid selling to 3rd parties - and yet, being less clear, they are deemed 'OK' while Commons Clause, clear and to the point, is frowned upon.
I firmly believe that both proprietary and FOSS licenses are extremes and that a new batch of "cloud protection licenses" will help develop software that will protect core users' freedoms and still allow maintainers to work on in fulltime. Commons Clause was simply ahead of its time - I'm waiting for its descendants to prosper.
Now I'm seeing cloud providers built on top of my project with almost no significant changes (other than I guess bypassing my licensing mechanism) and they contribute nothing in terms of support or code.
Now I'm building out the cloud service and am slowly moving away from this being an open source project to more like a project that has some code that you can see and a public issue tracker.
I have several pitch decks/one pagers ready to go and written up for VCs but have been hesitant due the reasoning in this article.
But there is soon coming a time when I will have to pull the trigger and send those emails.
Separately comes the business model. If a business intends on selling a hosted version of their product, as most open source database companies seem to want to do, that product needs to compete on its own merits. Can the business truly offer a better hosting experience on someone else's cloud than those cloud providers themselves?
I think maybe we conflate the two because we want everything. We want to create open source products that a community contributes to and supports but that only the originating company can monetize. It just doesn't work that way.
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)
I'm not familiar with Mapbox JS toolkit but maybe the problem was that the free version was too useful already, so only a few of the free users saw the need to upgrade? In that case I can understand why they put it under a commercial license, because providing free support for the project can be a burden.
Among the thousands of open-source projects, the ones championed as a successful business make a tiny proportion i.e. the exception not the norm.
Meanwhile the SaaS business model continues to eat the software market. A model that gives users less control than the desktop software model.
Open-source software has been critical to the success of the SaaS model. You could argue SaaS is the true success of the 'open-source business model'. Just not the way open-source advocates expected it to be.
If you have the skills to advance technology and no capital to invest to acquire other technical solutions you may need, you can get a job and use that money to pay what
Expecting free work from people rarely work, there are just not enough motivated individuals willing to work and maintain something for free.
Most open source I rely on is either backed by a giant company which uses it as a way to attract talents (and retain talents, by letting their employee work on their favourite project on company time) or it's unmaintained. If it's unmaintained I either need to do the work myself or hire someone, which introduces a myriad of variables. I'd rather hire the author but often he's busy with his real job and doesn't think he can live off its project.
If it wasn't for the OSS movement and the sheer amount of free work we would have a network of company buying OSS solutions and, most likely, more distributed, smaller companies that produce and resell proprietary software.
But open source does not necessarily mean:
- that the bulk of the work is done by people at their leisure, unpaid;
- that commercial use for free is necessarily easy or possible; dual licensing has a long history.
- that large companies have no interest in maintaining, advancing, financing, or starting open-source projects: currently the opposite is true.
With open source, developers are paid for ∆V -- the amount of value added to a project. Companies are paid $0 in most models but it's backed by a monetization model that's non-zero. Basically, more work == more value == more pay.
With proprietary software, developers are still paid ∆V, but companies are paid for V∆t -- value times the duration of usage. While some of this is just compensation for risking investor money, the ultimate model is rent-seeking and lock-in. This is extractive because the company keeps getting paid even when they don't add value.
You may raise concern that volunteer developers don't get compensation, but use that a problem for a voluntary activity? People program as a hobby, to scratch an itch, to develop mastery, to solve a problem they already have, to advance an ideology, or for a chance at recognition/popularity. Only that last one is anything near a problem, and it's the same boat as first time authors or artists.
AWS uses the crud out of open source. They admittedly "steal" it in that they fork it internally, applying patches, add UI, and then sell it. They still depend highly on basically all the open source software in the world.
That Amazon does this is a rallying call for new licensing schemes. Large monopolistic companies such as Amazon need to be legally shut out of this type of abuse of open source software. So long as we go "It's fine. You have to allow this to truly embrace open source" then we will continue to see Amazon try to shut down all "open core companies" that they can by outright stealing their IP.
Open source is not developed primarily by hobbyists or aficionados. Most open source imo comes from closed source projects being open sourced by companies in order to gain free testing, free work ( contributions ), and more market share ( exposure / interest )
Heralding the death of open-source seems like nonsense just to grab attention. I agree that the large companies are trying to crush open-core companies that are small, but it is obvious they are doing this and there will be a backlash from those of us who don't appreciate their meddling.
I’m not entirely convinced by my own argument, but I’m having trouble seeing the world as on the whole a worse place with AWS in it.
The only reason they ever release things to open source is to try to get people to use their paid services. Eg: attention. They view open source only as an advertisement and nothing more.
The problem isn't that they use open source. It is that they spend a lot of dev times fixing all the bugs and then don't contribute them back upstream. They have sooo many internal patches that should go back but they go "if we contributed them back people wouldn't use our more reliable paid service based on that".
They are the exact opposite of the healthy hacker mentality that has brought Linux to the state it is today. Fuck Amazon * 100.
The world isn't a better place in any way with them. Their services aren't cheap in any sense.
Also, behind the scenes all those services you think are "ultra stable" are actual unstable and flaky as hell. Ask anyone who has worked at Amazon for more than a year and they'll tell you that it is constantly in pants on fire mode. All engineers are required to be on call because they have that many fires every single fucking day.
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."
+Yes, I know.
- 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.