I was reading a post [0] by Brian Cantrill that predicted this would be the result of licences like the SSPL. I instinctively disagreed with him, but it turns out he was right:
"The cloud services providers are currently reproprietarizing all of computing — they are making their own CPUs for crying out loud! — reimplementing the bits of your software that they need in the name of the service that their customers want (and will pay for!) won’t even move the needle in terms of their effort."
I liked that post - this especially near the end, referring to Adam Jacob and some of his posts.
> Adam has endured the challenges of the open core model, and is refreshingly frank about its economic and psychic tradeoffs. And if he doesn’t make it explicit, Adam’s fundamental optimism serves to remind us, too, that any perceived “danger” to open source is overblown: open source is going to endure, as no company is going to be able to repeal the economics of software. That said, as we collectively internalize that open source is not a business model on its own, we will likely see fewer VC-funded open source companies (though I’m honestly not sure that that’s a bad thing).
Years ago I realized that a hidden driver for the growth of cloud is this. The cloud is DRM, and almost uncrackable DRM at that since you have neither the code nor the hardware.
Basically. The one who controls the servers is King.
The code needed to run those servers is the secret sauce and a huge competitive advantage, but with open source software you're giving away the secret sauce and the business victory goes to the one with the most business friendly servers
(There are many dimensions to "business friendly", a big one of which is "it's easy for us to start using this additional service since we're already paying this company for other services")
> ...for those open source companies that still harbor magical beliefs, let me put this to you as directly as possible: cloud services providers are emphatically not going to license your proprietary software. I mean, you knew that, right?
MongoDB Inc cannot make Amazon pay commercial license fees. That is not a thing that will happen. They have a lever in front of them with two positions, one of which is "large cloud companies might use your software for free", and the other is "large cloud companies will not use your software at all". They didn't like the first option, so they gave the lever a yank, but they're not going to like the second option, and there is no third option.
The way out is not to try and build a business on the assumption that people who have no interest, requirement or reason to give you large amounts of money will inexplicably do so anyhow. :)
This thread already has people eyeing up DocumentDB's pricing and comparing it favourably to MongoDB's competing Atlas service, and it's almost unthinkable to suggest that Atlas can compete on price with Amazon. The way to win this game is not to play; the rules are not in your favour.
> They have a lever in front of them with two positions, one of which is "large cloud companies might use your software for free", and the other is "large cloud companies will not use your software at all".
Was that even the goal? My impression of the licensing change was not that they expected to Amazon to pay fees for offering a hosted MongoDB service. It was instead to lock Amazon out, and keep MongoDB Inc. as the only "cloud provider" of a hosted MongoDB service (perhaps still on top of AWS but with separate management interface).
> My impression of the licensing change was not that they expected to Amazon to pay fees for offering a hosted MongoDB service. It was instead to lock Amazon out, and keep MongoDB Inc. as the only "cloud provider" of a hosted MongoDB service.
Oh absolutely. I don't think they really thought they could force Amazon to license MongoDB, but I do think they believed they could force Amazon to not offer something that competed directly with Atlas.
That hasn't worked out for them very well.
(Not that I think leaving the license alone would have worked out any better. To the best of my knowledge, the MySQL, Postgres, Redis, and Memcache projects have not particularly benefited from Amazon building RDS and Elasticache on top of them, and I see no reason to think Amazon would have contributed a bunch of great patches upstream for MongoDB either.)
I think PostgreSQL does benefit from Amazon RDS and Google Cloud SQL indirectly.
Unlike MongoDB, it is a real volunteer-led open-source projects, and the goal is to provide an excellent database to users rather than make money. Having easy-to-use cloud hosted versions available helps with attracting users, mindshare, and perhaps in the long run developers to the project itself. Having cloud hosted versions from big vendors means that it's easy to justify "we'll use PostgreSQL for this project" to management or clients.
I hope like hell that horrible precedent doesn't stand; if you find yourself on Oracle's side you may want to rethink some of your priors. Regardless of the rights and wrongs of this specific issue, some solutions are worse than the problems they solve.
No, because the API was made open source as it’s just part of the MongoDB source code. Future changes to the API made under Mongo’s new license would in theory be eligible for such protection - but what that means in practice is anyone’s guess. For starters they would need to be “substantial”. I can’t imagine Mongo going down that road.
They always were the OK guys in that argument. Google invented a whole new VM and bastardized the language just to get out of a $1/device licensing fee for mobile uses. The Java ecosystem has been irreparably harmed by Dalvik and its lack of support for more modern versions of Java.
On another note, anyone that doesn't think API design is a creative endeavor and worthy of protection probably has never made a great API before. It may be OK to accept that and also let other people use the API for free but I think ruling that it isn't is BS.
You could describe inventions as "facts" too, are you saying that inventions shouldn't be patentable as well?
Maybe the fundamental properties of the universe aren't copyrightable/trademarkable/patentable, but what you CHOOSE to do with those - what API you design or what widget you build out of it certainly is.
Patents and copyrights are two very different things, though. I don't know if APIs are patentable, but that's a very different question. Has anybody ever successfully patented an API?
> The Java ecosystem has been irreparably harmed by Dalvik and its lack of support for more modern versions of Java.
So if ReactOS gets popular but doesn't support Windows 10 APIs, will it be harming the windows ecosystem? If popular implementations of a tool exist that don't chase other (official or not) implementations' features but still get lots of users, that probably means that the popular implementations provide other benefits.
Pricing for smaller workloads is better on MongoDB Atlas right now. The DocumentDB performance pays of for super large collections and really high read/write workloads.
As a DevOps consultant; if Amazon is already setup as a vendor, I would just use DocumentDB. Setting up a vendor can be a major hassle and is not worth the saving of a few $$ per month. It's also much cheaper than spinning up and managing a EC2 instance with MongoDB installed on it since most of the operational knowledge can be deferred to AWS.
There's no secret formula to stop people from competing with you. If MongoDB Inc is successful, it should be because they run a good document-database-as-a-service people want to use, not because they earn indefinite seigniorage from launching a popular open source project.
> If MongoDB Inc is successful, it should be because they run a good document-database-as-a-service people want to use
Unfortunately, something that is good, and something people want to use, are not the same thing. People will use AWS's offering even if it is worse and harder to use, because it is bundled as part of AWS. That is a safe option (it can't be that bad if AWS has released it) and an easy one (no need to think about what to use, you are using AWS already.
Being a big provider of virtual machines puts them in a very strong position to sell loads of other stuff.
I've been using Atlas for over a year now and I don't have any complaints. It was super quick to set up and I've never had a single issue in terms of performance or availability.
The problem is VC backed companies expecting ridiculous multiples.
There are thousands of very successful and profitable software companies that make proprietary products and offer managed services, training, support, etc. It's a great business, but it's not going to offer 100x wild startup growth.
These companies would all do fine if they bootstrapped or took a small seed/loan instead of taking on 100s of millions.
Stop assuming the value in the development ecosystem belongs to you (and should be extractable as money). It doesn't.
Realistically, the next step you will see, unless something changes, is that they will start going after people for API duplication. They have precedent (currently) on their side in the US.
None of the reasonable players will touch this, but you can be sure some VC backed "open source" player will be willing to touch this 3rd rail in exchange for a Series A.
> Realistically, the next step you will see, unless something changes, is that they will start going after people for API duplication. They have precedent (currently) on their side in the US.
IANAL, but since they already released the API as open-source under the Apache 2.0 license, this avenue is closed off to them.
Arguendo: Cloud providers seem to be assuming that the development ecosystem belongs to them. They are extracting tons of money. Why don’t they just accept that hosting storage and compute will become commodity services, driving margins toward zero, and give up?
Plenty of reasonable players will touch Oracle v. Google going forward. I’m as eager to debate the opinion as other counsel. But procedural history demonstrates directly, not theoretically, that it’s effective against tech giants.
In the matter of API Owner v. Google, if API Owner touches that “third rail”, Google gets the shock.
The linked blog sorts of hints at it, but the way out is to not try to build business models around people paying directly for some sort of license.
Successful open source does not require someone making money off developing it. It is successful when it is something that helps a profitable company but is not core to their business; then, they benefit from making it open source and having everyone contribute to its development and maintenance.
Or, you make money off support and consulting.
The key take away is, you aren't going to make money off selling licenses for open source. Which is good, I think.
SSPL, the new license for Mongo, isn’t written to force developers already using Mongo to build apps to pay license fees. It’s designed to stop cloud companies from offering managed Mongo with closed service rigging.
I suppose Mongo could sell exceptions to cloud companies, the way other companies dual license libraries or frameworks. But even Mongo’s bread and butter paid deals aren’t primarily about alternative license rights for open code. They’re about closed add-on code and services, as you describe.
Dual licensing, on its own, is an old and plenty good model for funding development of open source code. I’ve heard wind of dual licensing deals done decades and decades ago, maybe even before GPLv2.
Right, but the point of the article the GP linked was that expecting a cloud company to pay for a license for add-on code... instead, they are just going to write their own versions to work with the open source parts.
You’re right about the article. But the SSPL approach is different from what we’ve seen from Redis Labs, Elastic, Cofluent, and Cockroach. SSPL applies to Mongo’s “open core” itself. The other companies have applied new terms to previously “closed shell” add-ons.
The question is whether giants will pay the cost of reimplementing entire stacks, core and shell. I don’t have the time myself, so I’ll have to wait on a report about how compatible AWS DocumentDB really is.
Given AWS history, I’d expect they’ll get most of the popular functionality, most of the way, but gotchas will abound, and they’ll never hit 100%. Switching cost of code won’t bottom out unless DocumentDB takes lead mindshare, which closed clones rarely manage.
Not sure this would fall under SSPL in any case. It's clear that what Amazon is doing is using Postgres under the hood, not really mongo. So I'm not sure how that would work if you make an interface shim to make postgres look like mongo, are you then subject to the mongo license? the postgres license? the apache 2.0 mongo api license? all of them? what if clauses of them are mutually exclusive? etc etc etc.
Just at a cursory glance it certainly seems like only the apache 2.0 mongo api license would apply. But I guess mongo could try to force the sspl on amazon?
[0] http://dtrace.org/blogs/bmc/2018/12/14/open-source-confronts...