I think most people are aware of the occasional contributions from the behemoths. Sometimes, entire projects. But charity is not a sustainable business model. When you provide a service offering the marginal returns go to the provider. In the B2B world, that’s a golden deal for these companies. Normally, you’d have a rev share or something like it. So it’s very understandable there’s a shift in the industry. It’s probably for the better for everyone.
The beef I have here is that Redis also takes credit for community work. Most of the heavy lifting came from antirez, who created and ran the project up until 2020. (It's worth conceding that Redis did compensate antirez). At that time Redis created an open governing board that took over, with a majority of contributions coming from the community during this time (~25% of contributions came from Redis engineers, ~75% from the community, including ~3% that came from me personally). They own the trademark and the repository, so they can do what they want, but I take issue with the optics that this is really AWS or GCPs or some other vendors fault that Redis decided to blind side it's development community. Redis gave some of us a heads up this was happening, but most people are finding out by a blog post that Redis dissolved the previous open-governance (a fact they barely address in the blog post). We had to drop weeks of work on the floor because we could not longer finish it.
The core team has the following remit:
* Managing the core Redis code and documentation
* Managing new Redis releases
* Maintaining a high-level technical direction/roadmap
* Providing a fast response, including fixes/patches, to address security vulnerabilities and other major issues
* Project governance decisions and changes
* Coordination of Redis core with the rest of the Redis ecosystem
* Managing the membership of the core team
It seems clear to me (speaking only for myself) that the core team didn't have a say in project governance decisions and changes here. :-(
I’m obviously talking about corporate FOSS contributions overall, not any individual contributor. There’s also a difference being on FAANG payroll vs maintaining without financial stability, which is the reality for most FOSS maintainers.
They get paid for it. Don't try to spin this as if it's someone people working on it in their spare time out of the goodness of their heart. It's just their job.
Amazon simultaneously wants to be "part of the community" but also extract the maximum amount of profit via AWS. Amazon can just do a deal with Redis to share a percentage of the profits from their Redis usage. They don't have to, but they could. But no, they insist on having it for free, and we should be grateful that benevolent Amazon with their $23 billion operating income (from AWS) deems Redis worthy for a contributor or two (which is of course entirely in their own interest). Give me a break.
Amazon Inc. wants to maximize profits. Okay fair. I'm not against capitalism. But it holds others to a different standard by insisting they only (not Amazon) should be beholden to some different type of post-capitalist post-scarcity "let's all share together in community" type of model and cries crocodile tears when they model of extracting the maximum in profits while giving the minimum in return blows up in their face. You reap what you sow.
Amazon needs to either hold everyone to the same standard as they have for themselves or stop whining.
> They get paid for it. Don't try to spin this as if it's someone people working on it in their spare time out of the goodness of their heart. It's just their job.
No, you can't have this both ways. I'm the main contributor from AWS, and I've worked many times on weekends because I care about open source. I like helping people, I don't need to be paid to do it. Many of the AWS folks that made changes were normal engineers that were excited to be part of Redis. https://github.com/redis/redis/pull/10419 and https://github.com/redis/redis/pull/8621 are both examples of features someone from AWS built in their free time. We're all upset about this. Not because Redis deserves to get paid, it's that they acted like they were being good stewards of the open-source community and then they changed their mind.
I'm sure you do, but that changes nothing about the problematic nature of Amazon's relationship with a lot of projects it interacts with, which is really what this is about: "Amazon thinks that by throwing some contributions at a project offsets for depriving a project of its main revenue". Well, it doesn't. My landlord and Tesco doesn't accept code contributions as payment. This is why this keeps happening again and again with all sort of projects. You reap what you sow.
> My landlord and Tesco doesn't accept code contributions as payment
Your landlord and Tesco aren't an open source project.
If for instance I get paid $X to specifically work on Redis by Y. The open source project now has effectively a full time engineer they aren't paying for, one that likely would not be a full time engineer for redis otherwise.
You cannot have "Amazon engineers contribute to redis" and "Amazon pays redis $X every month" and Amazon is only an example here, it could be Costco or IKEA or whatever.
So your argument is that instead of having OSS contributions from some of the best engineers in the world, redis (and other now OSS software) should compete with FAANG to pay those engineers.
Guaranteed one of the FAANG companies would just develop the tools internally instead if paying redis.
> You cannot have "Amazon engineers contribute to redis" and "Amazon pays redis $X every month" and Amazon is only an example here, it could be Costco or IKEA or whatever.
Wouldn't be better for both Redis, community and OSS movement if
1) Redis was fully OSS
2) AWS has a deal with Redis Labs were they share some X% of the revenue of their income for managed Redis (ElastiCache)
3) Redis Labs with that revenue can hire more maintainers
3a) Redis Labs with that revenue can pursue a competitive offering to ElastiCache (booom!)
4) AWS can still hire their developers and try to make them core maintainers to steer Redis development into implementing features they want/need
It's really impossible for me to paint AWS as the good citizen here and Redis Labs as the villain.
EDIT: I also wonder what history would have been if antirez started or moved to an AGPL3 licensing early on.
All this hinges in redis being a for profit with OSS software and not competing with AWS, that isn't happening though AWS won't happily fund their competitors and definitely wont contribute developer time to it.
Redis is partly where it is because of large FAANG companies contributing to redis, that cannot be discounted.
I don't have the time but go strip out all commits from FAANG companies employee and see if redis would be the product it is currently.
I'm not saying AWS is right but at the same time that is what redis decided to allow when they used the model they did. Now that they see they could be making a ton of money they want to retroactively change their licensing which is arguably also bad.
It's a money grab both ways which is what I have an issue with.
I'm pretty sure we will see AWS fork redis just before the license change and keep developing from there. They could even also then have all new code be proprietary as far as the current license allows that.
My argument is the industry in general is probably going to be worse of after this move than before.
> Redis is partly where it is because of large FAANG companies contributing to redis, that cannot be discounted.
Redis is offered as a managed offering by AWS and other because it was already very popular between developers that were clients or potential clients of cloud vendors. That it is/was used also by FAANG companies doesn't change a thing in this part of the story. (And no, I don't believe Redis is popular because it was used by FAANG companies which also contributed back)
AWS has no problem with running and contributing to AGPL projects. This entire wave of taking OSS closed started with Mongo switching away from AGPL for the same reasons that Redis is doing it today.
All of these companies trying to sell OSS are unhappy that AWS is competing with them on maintenance. AWS is more or less fully living up to the ideals of OSS - they share the code, they contribute to the core, they share processes and so on (to a greater or lesser extent). That's why the FSF or SFC have no problems with AWS.
However, these companies don't want to collaborate with AWS on building Redis or Mongo or whatever. They want AWS to be their customer, or at least to stop being their competitor. And FOSS has never been about preventing others from becoming your competitors.
> All of these companies trying to sell OSS are unhappy that AWS is competing with them on maintenance. AWS is more or less fully living up to the ideals of OSS - they share the code, they contribute to the core, they share processes and so on (to a greater or lesser extent).
Can you point me to the code describing some of the secret sauce used by AWS? If AWS was a real good OSS citizen, they would use FLOSS software and create FLOSS automation to operate it at scale, no? We have hundreds of such tools out there: Linux kernel, IPVS, keepealived, HAProxy, Kubernetes etc etc etc. These are all plumbing that are FLOSS. Why isn't AWS publishing their own plumbing as FLOSS so I can potentially run a mini-AWS in my datacenter?
I was only talking about their Redis service or Mongodb service. As far as I know, they are sharing their contributions as required by the license (or even beyond, in the case of Redis' former BSD license).
> instead of having OSS contributions from some of the best engineers in the world, redis (and other now OSS software) should compete with FAANG to pay those engineers.
This already happens. Amazon is never the main contributor. That blog post talks about 33 commits for MariaDB for 2023. Like, that's great and all, but that project doesn't run on those 33 commits. It's the same with Elastic; when they did their license change I looked a bit at the commit history, and something like >95% was by Elastic.
And all these projects that did license changes are fine.
> At that time Redis created an open governing board that took over, with a majority of contributions coming from the community during this time (~25% of contributions came from Redis engineers, ~75% from the community, including ~3% that came from me personally).
So, while I believe you're true in the general case, you appear to be wrong about Redis in particular.
I question whether AWS is depriving Redis of their revenue. You just can’t pay every single open source author for their work, too much overhead in maintaining all the contracts, especially if the software is offered as a service. You need the billing in place, certifications, support contracts, data sharing agreements, etc. As a company you want to optimize the number of business partners you have to deal with, and this is the value AWS offers, not Redis.
Who is this ‘we’ - you are speaking about people who want the good bits of redis but not the responsibility of helping it sustain a business model built on open source? Your enabling of AWS’s corporate FOSS-washing hasn’t helped redis sustain the model you want it to.
>We're all upset about this. Not because Redis deserves to get paid, it's that they acted like they were being good stewards of the open-source community and then they changed their mind.
I'm an open-source zealot and I have no beef with the SSPL.
Redis is still an open-source project for 99.99999999999% of entities on Earth. The only people crying foul about this are tech giants and the corporate drones at the OSI. Sorry if this sounds harsh, but normal people don't care about either of you.
I'm not going to shed a tear for your trillion $ market cap company being asked to contribute a little more in exchange for all the wealth they siphon from the rest of the world.
If the tech giant you're cheerleading for is such a fan of open-source, why don't they open-source the management layer like the SSPL asks? This would resolve this beef overnight, right?
The SSPLv1 has fatal flaws that were identified by the open source community during its review for OSI approval. Some of those flaws were attempted to be addressed in the SSPLv2 draft that was never finalized, which is an acknowledgment that the flaws exist.
There isn’t really any way for someone who wanted to offer software licensed under SSPLv1 to comply with the obligations of the license in good faith. This is what makes those obligations a “constructive restriction” [1].
There are some conditions that don't fit with the OSD (in the view of some, opinions are divided). That's fine. It's allowed to have licenses that don't fit with the OSD. These licenses are not flawed in any objective sense.
The important thing here is that distributions are gonna start moving the packages to non-free repos or removing it altogether. So you'll have to get it as if were a closed source project anyways.
There is no spin here. There are people that work for Amazon that work on FOSS projects out of the goodness of their heart, just like folks who are independent developers, or folks who work for startups, or folks who are just getting started.
When a FOSS maintainer tells you they sometimes do work on the weekends for the love of the community [1] you believe them. The evidence (with timestamps!) is there for all to see in the pull requests and commit history.
I think the industry's criticism of AWS is understandable, msw. I believe it is time for AWS to come up with a more sustainable method to support the open-source community. By sustainable, I mean financial support and dedicated resources for contributing back to open source. Given your position, I hope you can initiate this type of change. Allocating 0.5 or 1% of AWS's revenue or even profit from each service that utilizes open-source software is unlikely to significantly affect the financial statements, yet it would represent a significant contribution to the open-source community.
What I meant is a systematic approach to review and reconsider the support mechanisms for all of AWS's current open-source offerings, including those that AWS uses behind the scenes but does not disclose to the public, not just a few services or examples.
Countering a criticism of how Amazon interacts with the projects it uses to drive a large section of its profit with "don't dimish the work FOSS maintainers!" absolutely is a spin. Or some other bad-faith behaviour. It sure as hell isn't a meaningful engagement with the core issues, is it?
> There are people that work for Amazon that work on FOSS projects out of the goodness of their heart
So they work for free then?
Didn't think so.
They just have a job they like. That's great. But lots of people have jobs they like. And lots of people work on weekends. But don't try to spin this as an act of altruism, because it's not.
Without denying the good intentions and inputs of the individuals going above and beyond to contribute - AWS as a whole contribute peanuts to these projects relative to what they make from them - they have it in their power to make these projects sustainable via healthy revenue sharing but don’t.
You write as if you have all the facts, but I doubt you do.
There are services with varying partnership terms, and there have been services launched with an intent to build long term mutually beneficial relationships that help ensure FOSS projects are well resourced.
“AWS, working with Grafana Labs, will be contributing licensing revenue and code to help make Grafana even better, not just for the AWS service, but also for open source users and Grafana Cloud customers.”
You’re just showing your ignorance of redis. The project is sustainable without the company as the vast majority of work on the project is done by those who don’t work for the company.
What isn’t currently sustainable is the company. That’s all.
In that case you will have to excuse my conflating this special case with the multitude of other projects the same thing has happened to in the past and will likely continue happening to. I will watch with interest on how the contributors self-organise and prevent the exact same thing happening to whatever fork comes out.
RedisLabs actually was a somewhat hostile takeover of the project by a complete outsider. It commercialized Redis prior, kept trying to trademark the project name, change the company name to RedisDB to confuse users. A few of those attempts were halted by antirez and the community, but after they had thousands of customers he relented. At the time he complained about his own financial challenges and reluctance, but it gave him a just reward at the cost of legitimizing RedisLabs. The history of that company was always as exploitive to Redis OSS and feigning being good citizens. While you may be right in general, this is actually a case of those exploiting OSS winning.
> They get paid for it. Don't try to spin this as if it's someone people working on it in their spare time out of the goodness of their heart. It's just their job.
I know devs doing exactly this today. Devs who when the actions of their employer would have forced them to diverge from being able to do so, stuck to their convictions so much that they chose to terminate that employet contract so they could continue to do exactly that "in their spare time out of the goodness of their heart."
I will fully admit that I am not that kind of individual, I lack the capacity to contribute meaningfully in that way, but there are certainly many out there in our industry who are.
So when cloud providers like AWS are contributing to an open source project that they also host, I wouldn't call it "charity". The self-interest is obvious.
The problem is that it may not match the self-interest of other contributors. Especially when there is a "main" company that owns the IP of the open source that is not them.
But note how Amazon forked ElasticSearch when it became no longer open source, to their "OpenSearch" OpenSearch is Apache-licensed. Amazon engineers maintain it. This is not charity exactly, Amazon makes money from selling hosting of it.
In the "classic" age of open source, most projects were collaborations, where different people who got paid by differnet employers worked on it on company time, because their employers used it for their operatons. And were willing to pay to contribute to the software they used. Most of these were not in the business of selling software. They did not expect to make direct money from their contributions to the software.
This is how apache httpd began for instance. I think some of the employers of contributors were non-profit as well.
I think that's actually the only sustainable model for open source. A single company paying people to develop open source software and hoping to make money from that -- was probably never actually sustainable.
If the current economic conditions don't support people working on the clock to contribute to open source software that their employers use -- because software has gotten too complex, or because companies have gotten much more stingy or unwilling to pay for such things -- then indeed we won't have much open source anymore, we'll have proprietary source-available licenses like this.
