IE This is not the first business model issue OSS has dealt with.
For example: It seems ridiculous now, but at one point authors were significantly squeezed by commercial distros offering support and feature work directly to customers for their packages.
(And this was even a similar kind of disintermediation applied to authors as you see now - people only cared what they got from redhat, not from the original author)
One interesting constant is that most of the projects that felt a need to change licensing to react to business model issues over the years are dead ;) . Not all of them, mind you. But the failure rate seems really really high.
The underlying issue here in this one is that people (apparently so far!) want to use AWS/GCP/etc more than they want to use mongo, redis, cockroach, or any particular technology.
No license change will fix that. In that case, AWS actually controls your customer more than you do. Unless something comes along that is "better enough" that people are willing to buck AWS to use it, this approach of relicensing fails.
(and the customers certainly don't care about your licensing scheme)
> No license change will fix that.
Well, perhaps not a licence change, but if it's good enough that it's The One the provider wants, but it can't offer it under the terms of the licence, then paying for it under a separate licence could be a win for both parties.
e.g. AWS creating OpenDistro for Elasticsearch and adding core elastic stack functionality for free (Auth/TLS/Alerting) by integrating and adapting existing OS components.
This would have the benefit of allowing GCP to continue offering all the open source databases, which is great for gaining customers who already use these popular tools.
For the scale of the required exit, they would need a very large support contract, and at that point it would be easier for Google / Amazon to just build their own solution, hire their own people to provide support and development, or just let market forces do their thing.
The fundamental shift now is that a lot of open source software is on shaky ground, having been built by VC money searching a profit. This is the same force plaguing NPM and the JS community. The piper must be paid at any cost, even if it means compromising the open source part of the project
The failure rate for all projects is pretty high, though.
Just like parachutists who open their reserve chute suffer more injuries than ones who don't :)
Something similar was discussed a few weeks ago with respect to procps [0] and the struggles of maintaining Open Source projects.
That's a really extreme way to think about this.
Consider this example: I lose 1 Utility Point for every new provider I need to contract with, set up monitoring for, set up billing etc. This balloons to losing 2 UP if that provider's in a different public cloud, but since many let you choose an AWS region, this is probably not a problem. I gain 5 UP from using Cockroach, because it saves me engineering time. And I gain 1 additional UP from using latest Cockroach because they're making real optimization breakthroughs.
So pre-license-change, AWS Cockroach that tracks the latest release might net 6 UP, and Cockroach Cloud run by the company might only net 5 UP because of that cost of a new provider.
But post-license change, Cockroach Cloud would be tied, because now I'm comparing the cost of a new provider against the cost of latest developments. And every single blog post I see about Cockroach developments pushes me in that direction.
It's a really great move, though kind of a loss to open source. I wish the Cockroach folks the best.
I would argue this is probably how most CTO's think about it unless forced at gunpoint to do otherwise.
It's hard to put a price tag on knowing that an open source project your business depends on is well-funded enough that it's unlikely to disappear or be difficult to support.
They should have thought about that before benefitting from it being open source.
They have thought about it! That's why they are using the BSL.
I note that they are using a time-delayed open source approach (after 3 years it becomes open source) which I understand Stallman has endorsed in the past.
Starting an open source project, taking contributions from the community and getting popularity and traction because you're open source, and then closing it again because you're so popular Amazon might "steal" your revenue? That's just abusing the community.
Someone could fork CoackroachDB and continue working on the open source license.
Clients rarely care what backend is actually running, which is why the clouds can offer the same APIs like Postgres and MongoDB backed by their own custom software.
There's nothing stopping people from using BSL-licensed software on AWS/GCP/etc., as long as they aren't running it for the purposes of offering a hosted version of that software. And Amazon/Google/etc. still really wants to offer hosted CockroachDB, they can purchase a license, which helps fund development, and would probably be a financial rounding error to an outfit like AWS.
> Unless something comes along that is "better enough" that people are willing to buck AWS to use it, this approach of relicensing fails.
> (and the customers certainly don't care about your licensing scheme)
I think you're misinterpreting how this license works and what it actually restricts, or you've overestimated the number of users this will affect. Most customers don't have to care; for the common use ("I want to install CockroachDB on AWS/GCP/my own server and use it as a data store for my product"), the licensing change is immaterial and they can use the software in the same way as they could when it was Apache-licensed.
The only way this backfires is if Amazon creates a clean-room CockroachDB workalike and offers it as a hosted service. Even then, it's not a slam dunk: for example, I'd very much prefer to run redis myself on bare EC2 instances than use AWS ElastiCache, as the latter just generally doesn't meet my availability requirements. I've also once migrated a service from redis to DynamoDB and had a terrible experience during and after, so switching to a theoretical workalike isn't without its costs and risks.
There is. This is no longer an OSI license, which means it's no longer on the automatic whitelist. Using CockroachDB now requires running through legal, which really makes me reconsider just using the hosted whatever offering, despite the issues.
Or offers a managed service of one of the open source products competing in the same space. Or acquires one of the existing proprietary alternatives and offers it as a managed service. Perhaps even while paying Cockroach’s license fees, offering the most popular hosted Cockroach, and still encouraging customers to shift over time to lower-cost alternatives (Amazon already does this with Windows and SQL Server; no one trick pony first-party SaaS platform is going to be anywhere near what Microsoft has deployed against AWS.)
We are slowly getting back to the shareware and PD days, specially since many kinds of FOSS applications are hard to monetize, e.g. desktop apps.
I trust the creator to run a hosted service better than a generic cloud provider, but most don't which is a failure of their own making. A few companies like Redis Labs and MongoDB have figured this out but most are still stuck writing code when customers are asking for managed services. I don't know why they don't adapt.
The APIs are all public. The company can build whatever integrations they want to offer. For example, many already use EC2, VPCs, S3, Lambda, Kinesis, etc. to extend their databases into a client's architecture, and it's no different than what AWS provides.
If this is a million dollar idea, I'm just going to give it away I guess, so here goes nothing in explaining it!
Imagine an AWS/Google Cloud like company that only sells B2B, so Cockroach for instance, could pay this company to host their own cloud offerings, plus sell through other cloud offerings of the said B2B service but under their marketing umbrella. The B2B service gets a nice chunk for administration et. el plus some fixed percentage of gross (maybe? i dunno what it'd look like).
I think if you contractually obligate yourself as a business to never sell cloud services directly (only via partners like, in this instance of theory, cockroachDB, but it could redis, mongo, whatever), it'd be a fairly stable and comfortable arrangement.
Could also be a way for other SAAS companies to buy into infrastructure without indirectly funding a potential competitor too.
Maybe its too complicated to achieve, though.
There are several companies that do managed services like Aiven, IBM's Compose, ObjectRocket, etc so it's possible for them to get involved like this... and it looks like ObjectRocket just did that for CockroachDB: https://www.objectrocket.com/managed-cockroachdb/
I don't see why a startup would have such a problem with it, especially when they control the software as well.
Disclosure: I build EC2.
Seeing that neither Redis Labs nor Mongo are profitable, they haven’t quite “figured it out.”
Vendor management is a different issue. There's always a risk but if you cant trust any companies smaller than AWS then none of this applies anyway.
Even multiple AWS regions is not that simple, as some other comment mentioned, not all services are in all regions (or are available but at a lower reliability level)
I'm not saying it's trivial, but if they managed to support it across several AWS (and GCP) regions, then I'm not sure what's stopping them for expanding to others. I would imagine it's more of an ROI issue rather than a technical limitation.
In any case, I don't mean to diss Redis Labs. Quite the contrary. I'm keen to see them expand to other regions so I can use their services.
For my OSS project, I include the k8s yaml files in the project repo along with a simple CLI script to make it even easier to deploy. Scaling a service on K8s is very easy if the service is was explicitly designed for K8s.
Basically give the open source project a 30% cut if you're going to resell it (or fork and resell it). It might be hard to do now since with AWS since with ES Amazon just forked whatever version was already permissively licensed, but it may be interesting to create a new license to protect against this for new OSS projects.
[1] https://www.gnu.org/philosophy/open-source-misses-the-point....
Open Source and Free Software are, as your link points out from the latter side, divergent ideologies, but they aren't substantively different in terms of concrete meaning when it comes to licensing. It is absolutely not the case that “many things” are Open Source but not Free Software, though many projects producing software which is both Free and Open Source adhere to only one of those ideologies, at least as the projects dominant ideology.
I believe the correct term for those licenses is "shared source" not open source.
Well, you also have to take the game theory of incentives into account.
Let's say you develop a new database called NextGenCockroachDB with a required 30% royalty license. That type of license will alter the behavior of people evaluating it and may very well prevent it from being adopted at all. If there's no critical mass of the market using it, the 30% royalty becomes a moot point.
The whole market of choices available to economic participants has to be analyzed. If potential buyers have an option to substitute a db with 30% fee with another open source db with $0 license, they will be incentivized to avoid paying 30%.
If an open source db requires royalty payments from cloud platforms, it will need to have amazing technology that nobody else can duplicate.
Once your company surpasses $100MM in revenue you have to negotiate licensing terms.
0. If company is profitable and licensing costs > overall salaries + monetary value of controlling roadmap.
No, such a requirement makes it not OSS.
Elastic is an exception though, I think Lucene would be a better addition to that list.
There simply has been no time where a startup doing SaaS of open source software (whether it's own or someone else's) had a strong route to profitability; this isn't an emergent property of evolving market conditions.
It's perhaps being acutely recognized because there was a particular time when companies started around open source software and, either initially or after a period with no clear business model, adopted “we’ll do SaaS of our core open source offering” as the whole, or a central piece, of their business model, and pretty quickly realized why, despite hosted SaaS being a commercial reality longer than cloud computing has even been an idea, SaaS of a particular open source software product—while sometimes part of the business of a broader SaaS provider—has never been a common successful standalone business model supporting companies centered around the open source offering, and certainly not for company is looking for the kind of growth modern VC-backed startups hope for.
They like to spin stories about AWS being predatory, evolving conditions in the cloud market, and attacking open source, but the real issue isn't with AWS, or cloud computing except insofar as that happens to the modern place where hosted SaaS is found, but that they've adopted a combination of SaaS-centric business model and growth expectations that would never have been realistic with open source software (and which I suspect they will next discover isn't much more realistic with their new relatively liberal proprietary license model either.)
> If you think that the Cockroach Labs, Redis Labs, Mongos, Elastics, etc., of the world provide a net benefit to the software world, I think you have to contend with the fact that there is going to be fewer such companies in the future if AWS keeps eating their lunch.
Software that serves as underlying infrastructure for other software has value to end-users that is with reduced by risks associated with being proprietary, and but also has value to it't is reduced by the non-exclusivity that exists when it is not. That's fairly obvious, and an intrinsic problem for such software being efficiently provided in a basically capitalist system, but unless one’s ideological preconceptions make it difficult to accept that capitalism may not always be as perfectly efficient as it would seem to be in theory under the kind of ideal assumptions sometimes encountered in Econ 101 classes, or unless one has invested in firms without business models which ignore this dilemma, I don't see how that is anything to “contend” lwith.