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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
IMHO "open core" is not a good idea in the first place.
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.
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.
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.
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.
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...
> 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.
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.
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.
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.
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.
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.
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.
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.
Could it be that, rather than the death of a particular variety of open source ("Open Core"), that the author has in fact described yet another open source business model? One that specifically extends Open Core?
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."
> 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.
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.
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.
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?
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.
> 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).
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. :)
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).
It's not clear to me that open-source-as-a-business-model was ever vibrant enough that it makes sense to say it has now died. Open-source-as-a-funding-model was surely a thing, but turning open source into a source of consistent and growing free cash flow has been much more rare.
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.
> turning open source into a source of consistent and growing free cash flow
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?
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.
> 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.
But then redis is essentially still the "open core" model he is saying is dead.
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.
What's "going on in software" is that most businesses don't want to devote a lot of resources to operating software themselves in the cloud. If you sell popular software and don't provide a cloud service, you are basically opening up an opportunity for somebody else to do it. Public clouds tend to jump on this because it sells underlying infrastructure in addition to the management value add.
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.
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...
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.
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...
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 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 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-...
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.
I work with open-source for the last 8 years, as a business owner and as contributor.
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.
It is not a "cloud" that damages open core projects, it is Wal-Martesque cloud providers. If you are buying lots of infrastructure from AWS, there's just no reason to buy MongoDB or Redis from their creators: you would just put more load on your accounting, monitoring and cost controlling and will have nothing extra in return, except pride for supporting open source.
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.
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 don't think anyone should have a realistic expectation of making money directly from an open source project. You have to be strategic and tactical in how you approach the problem of monetizing.
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.
> Redis adopted a strategy of adding a severely restrictive “commons clause” to updated versions of their existing open source tools,...
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.
As a maintainer of a a relatively tiny "open source" project, I've been going through the same thing over the last few months. People relied on the project, ok let's go open-core 99% is free, a few obscure features require a license key.
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.
I think the business model and the software license often get conflated like this. Once you release software with an open source license, users are free to do what they wish as long as it's within the bounds of the license.
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.
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"
(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 core makes sense if you can provide a "light" version of your product that is already useful, and most professional users of your free product will eventually get into a situation where the "pro" version will save them money or will have a feature they dearly need, so they upgrade.
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.
Open source doesn't work and I'm glad the world is starting to understand.
It promotes unfair compensation (or lack thereof).
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.
I think you've successfully argued against your own point.
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.
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?
Post logic: Here is an example of a company taking their software closed sourced after previously being open. Also, AWS.
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.
Let me play devils advocate for a minute. Maybe what Amazon is doing is just fine. If they had to roll all of their services from scratch themselves, they’d be massively more expensive and dramatically less compatible with everything else. The fact that Amazon and many other hosting companies can offer cheap commodity services based on familiar building blocks is a huge benefit to the world enabled by open source. That’s exactly what open source is about, making the world a better place.
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.
What Amazon is doing is not fine in any way. Having seen their dev process from the inside it is an absolute nightmare. They give zero shits about the wellfare of their devs nor about their contribution to open source.
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.
I worked there. I can assure you that they contribute very very very very little in terms of what they use. They also have very strict gatekeeping about what they allow to become open source. I've seen multiple projects get prevented from going into open source despite their devs requesting it. Fuck Amazon.
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.
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.
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.