Generally my stance with these forks born from community drama is "wait and see." Sometimes the fork will gain traction and become the de facto "true" version (see Hudson -> Jenkins). Sometimes the fork will flop and people will largely stick to the original despite whatever caused the schism (see Terraform -> OpenTofu).
Many of these recent forks are being done because people won't want AWS/GCP/Azure to slap a UI on top of their free open-source product and resell it, making tens of millions of dollars per day in the process. I can't really blame them.
I agree. It has only been a few months since the split. I have noticed more and more uptake of OpenTofu amongst colleagues, and I've personally switched. The thing that makes the difference is what is running on people's laptops, because that's what people will eventually put into prod.
The point is that once they are no longer compatible, people would standardize on the one that they're familiar with which is most likely the one that's running on their machine.
But currently, people are equally comfortable with both; the CLI commands are exactly identical between the two, save for the name of the binary itself. In any org where both are in use, if people are forced to choose at some point, they will have to balance many other factors besides familiarity, such as features and confidence in the platform.
> The thing that makes the difference is what is running on people's laptops, because that's what people will eventually put into prod.
I disagree—I think support of deployment tooling (like Atlantis) is the bigger proof. If you are running terraform on your local machine it is likely a very small company.
Just to clarify, provider-defined functions are coming in OpenTofu 1.7, along with e2e state encryption. Generally, I recommend not comparing version numbers of Terraform and OpenTofu post-1.6.
Implementing the e2e state encryption was non-trivial, and we wanted to make sure we get it right, so that's why the release took us a while. We also got a slight additional delay due to needing to handle the C&D letter OpenTofu got from HashiCorp[0], but that's all sorted now.
The beta for 1.7 however is coming out this week, with the stable release planned in the next ~3 weeks.
In the very early days of Terraform, when it was 2 months or so old I helped a little. How many people did (so much more than me) with all these projects to be later betrayed by relicensing.
> git log --pretty=format:"%h %an %ad %s" --date=short | grep "Luke Chadwick"
dcd6449245 Luke Chadwick 2014-07-30 Add documentation for elb health_check
0eed0908df Luke Chadwick 2014-07-30 Add health_check to aws_elb resource
96c05c881a Luke Chadwick 2014-07-30 Update documentation to include the new user_data attribute on aws_launch_configuration
15bdf8b5f9 Luke Chadwick 2014-07-30 Add user_data to aws_launch_configuration
8d2e232602 Luke Chadwick 2014-07-29 Update documentation to reflect the addition of associate_public_ip_address to the aws_instance resource
974074fee9 Luke Chadwick 2014-07-29 Add associate_public_ip_address as an attribute of the aws_instance resource
> How many people did (so much more than me) with all these projects to be later betrayed by relicensing.
Were you betrayed? They did a thing you licensed them to do. That’s the whole point of non-copyleft free software licenses, after all! It’s kind of odd to specifically choose a license which allows others to use one’s code in proprietary software, then be upset when others use one’s code in proprietary software.
If one wishes one’s software and its users to remain free, the answer is to use a copyleft license.
They can and did use it in commercial software before relicensing. I don't have a problem with that. It's a betrayal to get a huge community together under one expectation and then decide you don't like that expectation any more. Had they used, even something like AGPL from the start it would not have been successful in the same way, would not have gotten the same levels of outside contributions, so yes it's a betrayal.
It's a limited betrayal, because that license also allows for OpenTofu to exist and fork, but the need to do that is just annoying.
> Many of these recent forks are being done because people won't want AWS/GCP/Azure to slap a UI on top of their free open-source product and resell it, making tens of millions of dollars per day in the process. I can't really blame them.
I won't blame them for regretting their past actions, but I hope the lesson would be learned: if you want to put limitation on the use of your software, you shouldn't have licensed it in a way that doesn't allow such. You can't recall a gift because you don't like how the recipient is using it. Though you are more then welcome not to gift them ever again.
> Though you are more then welcome not to gift them ever again
That's actually an accurate description of what's happening with these re-licensing dramas. Redis versions from before the split are still BSD-licensed. They can't recall those gifts. The re-licensing only applies to newer versions.
Of course, it wasn't just people employed by Redis, Inc. who were providing the gifts. My (vague) understanding is that a lot of contributions came from people at AWS, etc. Technically, AWS was providing those "gift" contributions to Redis -- because Redis, Inc. maintains the copyright for community contributions -- and Redis was then re-gifting those contributions to the world, via the BSD license. That's all fine and dandy until the big contributors realized they're actually fiercely competing with each other for cloud customers, and it's not realistic for Redis, Inc. to compete with the largest cloud provider on Earth without any technical moat whatsoever. Hence the re-licensing.
I think the breakdown in trust for Redis, Inc. is overblown. By far the biggest contributor to valkey (madolson) is employed by AWS. Does the OSS community really think that's a better organization to back in the long term?
First of all, you can "recall a gift", if it is legal. I don't think I've seen people arguing that these re-licensing actions are not legal.
But if you mean that you can't recall a gift without making people mad, then yep, that's true! But keeping people from being mad is not the only thing that matters.
But the real problem I have with, "I hope the lesson will be learned" is that the lesson people are learning is "don't try to build ambitious software requiring a lot of work from a dedicated core team using an open source license; you're going to find yourself damned if you do and damned if you don't".
And I think that really sucks! And sadly the ship has already sailed here. I'm certain we're going to see way fewer products with open source licenses because of all of this. And I think it's unlikely we'll even see as many products with "source available" licenses because, how is it worth the hassle to release source when the community has shown more good will to projects that are entirely proprietary?
I really think I'm going to look back at the last 15 years or so in awe at how often I had the luxury of digging into the behavior of software I rely on, by reading the code.
We're living in a society, with certain systems baked into it.
Fighting to change those systems and norms is a Good Thing™, but I'm too pessimistic to act today as if the change is coming tomorrow. I'll both work to change those systems, AND act as if they're here to stay.
I'm not sure if this was a purposeful allusion or not, but I entirely agree that you "can't recall a gift" in exactly the same sense that you can't keep talking on a payphone for a long time when someone is clearly waiting; because, you know, we're living in a society!!
Unlike the payphone analogy, where there is metering rules, and as long as you abide by them, you can keep talking, even if it's impolite, there is a legal definition for gifts (it is, after all, a transfer of ownership, and such things are regulated), which, as far as I know, matches the social norm of not being able to claw those back.
Ha, except, to go full circle, then if you're using that legal definition of a "gift" requiring a transfer of ownership, it's clear that open source software is not actually a gift, because there is no transfer of ownership.
You can't have it both ways! If it's a "gift" in the colloquial sense of something freely given, then it breaks social convention to claw it back, but it is not illegal. If you want to use the legal definition of a "gift" - ie. for tax purposes, implying a transfer of ownership - then contributions to open source software are not at all a "gift" in that sense.
> And I think it's unlikely we'll even see as many products with "source available" licenses because, how is it worth the hassle to release source when the community has shown more good will to projects that are entirely proprietary?
This, thousand times. Looks like FOSS advocates feel so threatened by "source available" licenses that they will do everything possible to keep them from gaining momentum (see Commons Clause).
It's a shame really. It would be nice to have a standard and well known license that would both allow users to use software freely (for using and adapting) and still protect makers from their competitors (AWS comes to mind) undercutting them with their own product. Oh well.
EDIT: ...and here comes the first (anonymous) downvote. Proves my point about FOSS sentiment, I guess? Come on, it's a discussion, you can do better than that.
FOSS originalists insist on no limitations on use of the software.
The FSF prohibits such in what they call freedom 0:
> The freedom to run the program as you wish, for any purpose (freedom 0).
And OSI explicitly forbids it in their open source definition:
> 6. No Discrimination Against Fields of Endeavor
>
> The license must not restrict anyone from making use of the program in a
> specific field of endeavor. For example, it may not restrict the program from
> being used in a business, or from being used for genetic research.
This rules out no-CSP licenses from those definition, as well as the original JSON license, as it used to read something like "this software shouldn't be used for evil". Those rules would also block banning software from being used for war crimes, human rights abuse, etc. And while I can understand the legal minefield with prohibiting some use, I'd really wish we had a good license that would indeed try to also curb using software for committing real atrocities (and not just possibly reducing shareholder value). But I digress.
Sure, I know, but I mean that's just their subjective line in the sand. (Their maximal-freedom in this kind of infinite dimensional space.)
After all wouldn't a user be more free if they were able to just do whatever they want with it, not just run it? Ie. free to copy/modify/sublicense it in any way? Why is program execution more important than other use of the intellectual property?
If they want to maximize freedom for all potential users, then they ought to think about sustainability of the software. (As in economic incentives and market share and whatnot.) To me it seems they have a static worldview, the only thing they care about is that current set-in-stone version of the work, but that's basically putting their head into the cool refreshing sand of ignorance.
(That said, I'm nowhere near FSF/OSI circles (duh! :P), so I have no idea what's their current thinking of this. Maybe they are fully aware of this, but ... based on HN chatter it seems that they realized it's a hard problem and picked an oversimplified worldview as workaround, and now it's institutionalized denial.)
> And while I can understand the legal minefield with prohibiting some use, I'd really wish we had a good license that would indeed try to also curb using software for committing real atrocities.
I'm very skeptical of the practicality of it (after all if there's one thing states in general are good at, it is waging large scale wars and appropriating everything required for it), but if adding naive sounding clauses to FOSS-ish projects can prevent at least a few drone attacks it will have worth it.
Also, if people want to somehow put these use-restrictions into "the right context at the right time" then they can add a clause for that.
Ie. add a clause listing categories of uses and/or users (military, law enforcement, surveillance, and any state, state-owned, significantly state-sponsored entity) that require express written authorization from a named organization/institution, and folks could simply pick this when they start a project. (From Apache2-NATO to AGPL-ChaosComputerClub and so on.)
> But the real problem I have with, "I hope the lesson will be learned" is that the lesson people are learning is "don't try to build ambitious software requiring a lot of work from a dedicated core team using an open source license; you're going to find yourself damned if you do and damned if you don't".
Yeah, for things running server-side that could be used by Amazon and Microsoft, they should use SSPL from the start. In this case everything is clear and everybody knows what to expect. For regular users, there is absolutely zero difference between SSPL and OSI-certified licenses.
Yes, they definitely should use something like that from the start, in my view. But I think they won't, because there is now a lot of evidence that this will result in a bunch of bad press, whereas just making it proprietary will go without comment.
the best strategy is still to start out with something that's press-positive (Apache2) and switch to BSL/SSPL after funding is secured. bad press will happen, but at least later, after the good press phase.
With the noise people make when you don't use an OSI open-source license, little wonder. But when Redis started I think we didn't yet boardly understand the limitations of OSI licenses in the era of big tech cloud computing.
To people starting projects today, you have no excuse, we know better. Don't use OSI open-source unless it's entirely a labor of love that you're giving away free.
OSI Open-source business models are dead. Don't make that mistake.
> That is, if I was still in charge, would I change license? But that's an impossible game to play, I'm away from the company for four years and I'm not facing the current issues with AWS impossible-to-compete-with scenario.
Not saying he would have decided any differently, just that cloud computing has changed open source situation for the worse.
It looks to me like people start with open source licenses because that's helpful to get them market-share (and in some cases community contributors and maintainers), and then they switch to a non-open-source license reserving certain rights to profit to them hoping to maintain the users that they wouldn't have gotten if they started with that license.
I am curious for examples of any projects now *starting( with one of these non-open-source rights-to-profit-reserved licenses, now that is clearly "understood". Are there any examples? Are they successfully attracting users? Contributors?
Wikipedia suggests it was initially apache, changed to BSL in 2019. https://en.wikipedia.org/wiki/CockroachDB. But still perhaps an example of fairly quick switch to BSL before it had gotten wide market/mind share? I don't know the history.
"We’re adopting an extremely permissive version of the Business Source License (BSL). CockroachDB users can scale CockroachDB to any number of nodes. They can use CockroachDB or embed it in their applications (whether they ship those applications to customers or run them as a service). They can even run it as a service internally. The one and only thing that you cannot do is offer a commercial version of CockroachDB as a service without buying a license."
> Don't use OSI open-source unless it's entirely a labor of love that you're giving away free.
Well, know what your secret sauce is. I think performance is really the best differentiator. Make a fully behaviourally compatible (maybe not bug for bug) version available and then sell a proprietary faster version.
Think an compiler that doesn't due any optimisation and outputs naive code. You know have a useful OSI project, and a clear value add, and a clear boundary between the two.
This is really applicable for databases, and it still leaves you with something useful for learning small projects, and for developers to run locally on their own machines.
>I think performance is really the best differentiator.
I don't understand this at all. Most open source projects start out equally as a means to give back to and collaborate with the community as well as showcase one's skills. You're asking me to purposefully publish badly optimized software? I don't have it in me. That offends my sensibilities of craftsmanship. A 'slow' open source project will never get traction. Even if it did, I also don't know how an open source project wouldn't immediately have it's obvious performance bottlenecks fixed.
Far better to go the VSCode route. Release a useful project, then release paid extensions for it.
this is the open core model, it works well for things like GitLab (as far as I know)
and in effect GitLab is doing a BSL-like thing by after a few years they release features to the free tier
but it rarely works if you need to decline contribution from people who would eat into your profit margins. I think ElasticSearch had this problem (and the community basically ended up with a few forks, because people sent the patches for security features that were in the enterprise version, and to no one's surprise they did not get merged ...)
so, I guess it works if there's a huuuge scope with plenty of things to contribute, to shoot for the moon together, without hurting the business side too much.
You can probably set up a decent privately-funded venture to deal in OSI software. The problem comes (as it always does) when the founders think they're the reincarnation of Steve Jobs and deserve a nine-or-ten-figure net worth for making a few nice, but ultimately not earth-shattering, software tools. Then they have to enshittify to get ready for the IPO.
The hyperscalers weren't selling Terraform though, Hashicorp was losing to Terragrunt, Spacelift et al, who had decent to good offerings.
I'd say Elasticsearch is still the comparison to make here for a product that clouds just resold, then again, Redis the company didn't build Redis the software and their latest marketing smells more of VC hawkery than any reasonable pitch
> Hashicorp was losing to Terragrunt, Spacelift et al, who had decent to good offerings.
Would love some data in support of this statement. Not saying you're wrong necessarily, just it feels like a perception vs. reality comment potentially.
Don't have any data I must say, just a series of discussions here and elsewhere over the years, voicing either appreciation for the platforms above or displeasure with the logistics/price of TFcloud, e.g. with one I remember
The vast majority of projects that I've come across at work just had the tf CLI wrapped in a CI/CD pipeline + some bucket, but the managed competitors seemed to come up more often (compared to other tools/platforms) when people wanted to use/were using something as a service.
Perhaps it's really just a perception thing, I never checked their financials
edit: I think I went off-track from the point. The point was that the ones selling managed versions were not the hyperscalers, but people building wrappers and similar around it. The other commenter with the list of fork-backers illustrates that nicely.
> people won't want AWS/GCP/Azure to slap a UI on top of their free open-source product and resell it
If it wasn't open-source it won't be as popular as it is in the first place, Redis is also using ton of open source software or libraries for free.
Not defending AWS/GCP/Azure, I actually got my software used when i was young by a large company for free (not even a mention- Still using it i think, 5M+ Play Store Downloads), but that is the spirit of open source
Open Source is, by and large, intended by the creator to donate their ideas to benefit humanity as a whole; many people feel that using their thing to help strengthen an (ethically questionable) monopoly is acting against that core goal.
I think it's less about strengthening a monopoly and more about zero sum business models.
If AWS/Azure/GCP/et al. ran a cloud version of X and the main company supporting the open source project was a going concern, I doubt many would have a problem with the entire scheme.
However, in reality, every enterprise support dollar that goes through a third party cloud-managed offering is one that doesn't go to the first party.
In which case, what dollars are left to pay the independent company that creates and supports the software?
Granted, there are a lot of nuances to the above, but I think it's generally fair to say that third-party cloud companies are making more off managed open source offerings than they're paying to contribute to them.
This is why the most viral AGPL license you can find is the only right license for Open Source. There is no downside: for honest, upstanding developers who want to use your code, there's no problem, because their code was going to be Open Source, too. For the soulless corporations, they'll either not use your code, or contribute back their modifications, a win-win for everyone.
The only losers are people who are engaging with the Open Source community in bad faith, viewing it as something to steal from, rather than participate in.
is there a stronger version of AGPL where if you run it as a SaaS you need to publish the source for the infra/management/self-service/payments machinery too?
When I fix a bug in OpenSSL, it benefits humanity regardless of who deploys it. Maybe slightly less beneficial if it fixes an evil service, but still... Better to have a successful TLS handshake and get on with the evil.
I don't think anything else open source I've done has been widely deployed, but if I save a bit of someone's time because they can use something I did, or save some users' cpu and bandwidth, it doesn't matter to me if that's a user of a free service or a propriatary one, I still helped their user.
Redis actually has very few external dependencies compared to most modern FOSS:
IIRC, it only need libc and OpenSSL (the latter only if you build TLS) on your system, and provide their forked copies of Jemalloc, LUA, fpconv, HiRedis, Linenoise and Hdr_Histogram.
I work for a large enterprise and we use terraform open source atm, but I can pretty much guarantee we move to OpenTofu once the dust settles a little more.
I remember when we had the libav fork. Turns out 10 bickering idiots pronouncing the freedom revolution were ultimately not half as productive as one Michael Niedermayer.
tbf, ffmpeg‘s api and thus libav is so obscure that it would be impossible to fork it and create a nice looking api, without bothering people.
I vaguely remember the news about the Microsoft guy that was called out on twitter and I’ve read the issue and looked at some cli/api parameters and was stunned. So much possible flags. I hope that I will never need to deal with it.
But still kudos for all the maintainers. It works and has probably support for all codes and all options of these codes.
> people won't want AWS/GCP/Azure to slap a UI on top of their free open-source product and resell it, making tens of millions of dollars per day in the process
Then build that UI yourself and sell it and make millions of dollars per day yourself, noone is stopping them.
Ah but you see there are 2 problems: 1/ "UIs" are harder than people think, especially by those that use that term derisively like you did. There are PLENTY of popular products that are basically just UI on existing data.
2/ AWS/GCP/Azure aren't slapping UIs. They're offering "managed operations" for these products. What is it? And sure, Hackernews is likely to scoff at that - we know how this site feels about dropbox -> https://news.ycombinator.com/item?id=9224
But if it didn't offer value, people wouldn't pay for it. Redis engineers are good at building a key value storage. AWS/GCP/Azure engineers are good at building managed operations. Combine them together and you've got the best of both worlds.
AWS/GCP/Azure aren't making money off Redis, they're making money off their experience in operating cloud infrastructure. And the free market wants to pay them to do so.
>Generally my stance with these forks born from community drama is "wait and see."
They are generally a
good thing, save for the poor souls that will end up maintaining a project that was started with them while they were still active. The success of the fork doesn't matter so much as the direction it inevitably pulls the original project.
The io.js drama gave us a huge step forward with NPM once their hand was forced. Hopefully some good ideas come of this too.
I'm actually surprised by how well received Valkey is right now, given that they forked not too long ago. Below are GitHub engagement insights for the two projects:
Part of the bet is probably that since Terraform is almost necessarily going to run on a cloud service that is already being paid for, the user might not care that a bit gets added to the bill.
Redis? I'm not sure. Like you say, they don't want Big Tech to slap a UI on it and profit. And, really, once they start competing on price (which they might sooner rather than later to keep people from going back to on-prem) you can guess they might use something that's free so they don't have to pay the license on a per-server instance.
Important to note that the "people" in this case is the company that bought the rights to the Redis trademark from the original creator and then took on $350M in VC funding. The community that created and supported Redis since its inception was not involved in the decision, and isn't getting any of the benefit.
I'm using Gitea locally. I haven't come across forgejo before. It seems to be forked on the basis of providing a fully open source solution (it states that some Gitea enterprise features are not present).
Do you know what the main differences are and whether it is worth switching?
1. Gitea, Inc replaced the prior community leadership structure with one controlled by Gitea, Inc and have pivoted into being primarily about a hosted code SaaS they launched this year that didn't exist for the first 7 years of the project. They could do it because they had 2 of the 3 seats on the community stewardship organisation at the time to vote for it, but that wasn't always true. For a lot of people, Gitea's primary motivation was for the self-hosted and fully open use case, but now it's not clear that that will remain any more of a priority for Gitea Inc as it is for e.g. Gitlab
2. There were also some contributors who were interested for the sake of decentralising code forges (and not just git), and so were big into the forgefed project which was an activitypub based federation protocol. Gitea Inc were officially on board with that, but the contributors felt they weren't helpful enough to actually implementing that with missteps like letting grant funding from NLNet expire.
The contributors from groups 1 and 2, and Codeberg banded together to make Forgejo after the Gitea change.
Until the latest release (just last month) Forgejo was one way pulling all changes from Gitea, but they've diverged enough that they're now hard forks. Both have active development, but Forgejo's main unique focus is the federation stuff, while Gitea's was enhancing their CI offering. But while Gitea may have more development effort, being funded by a commercial organisation rather than volunteers and a non-profit, I think they have a long way to catch up to Gitlab in that front, so it feels like they've dropped their unique factor to try chase Gitlab.
At the moment forgejo does not have features I'm interested in as I'm not making my internal gitea instance public. However, I'd be interested in it if it provides support for things like hierarchical project grouping and organiation/group-wide project and issue tracking. So I'm going to keep an eye on the project to see how it evolves.
One thing that concerns me is Forgejo's statement that they will diverge further from Gitea without migration commitments. This would make it harder for me -- and others -- to switch after upgrading to Gitea 1.22 and later. A similar concern is the other way around: if I switch to Forgejo and want to move back to Gitea, I won't be able to if the projects have sufficiently changed (e.g. if they implement project grouping differently).
I think Hudson -> Jenkins is not really a fitting example here, because it was more of a rename caused by Oracle owning the Hudson trademark. While Oracle halfheartedly indicated to continue Hudson on its own, from what I remember it was pretty clear from the start that Jenkins was the new Hudson.
>> Generally my stance with these forks born from community drama is "wait and see."
Whats funny about this one is as follows:
1. The license: BSD? LGPL? Do both... nothing says that you cant make the product available under both licenses. You prevent another rug pull...
2. The platform: Do both, Run the thing on GitHub like it always has been and back it up to the other platform. If MS makes GitHub into the next source forge... then you're already half way out.
3. The name: Not a hill any one should die on. Pick three, ask amazon legal to clear them or FSF legal to clear them and vote. Redict and valkey are both fucking stupid names... Yea you might have to live with storage mcstoreface but that would be better than either of the current options.
As for FOSS drama... Lacking any clear leadership, peoples ability to self organize is limited. These sorts of things happen all the time (systemd, x vs waylaid, how many unix forks?) The winning side is almost always the one with clear leadership.
What AWS/GCP/Azure provide with managed Redis is much much more than just a UI. There are a lot of technical issues that come with running Redis reliably in the cloud. I’d say UI work is probably 5% of that at most.
Many of these recent forks are being done because people won't want AWS/GCP/Azure to slap a UI on top of their free open-source product and resell it, making tens of millions of dollars per day in the process. I can't really blame them.
I can.
Free software is, at its core, wage theft. It is truly unfortunate that so many people don't understand "big picture" economics, not the $2 for a loaf of bread economics, but the creation of value, it's consumption, and allocating resources to maximize creating the "right kind" of value. Most programmers "get" that writing code has value, hell tech companies will pay $5,000/week in total compensation just to do that, of course "coding for money" isn't the same as "coding on something you love", or are invested in, or does something you want. But here is the detail that so many miss, it is still $5,000/week "worth" of value. Whether or not someone is paying you to do it, there is still value there. And when you think about it is it all that surprising that putting that value into a thing doesn't make it something others might value too? Others who don't have the chops or the time to make it themselves? THAT is economics. And there are so many people who can see that value just sitting there and say, "Hmm, I bet I know someone who would value that, and I could get them to pay me some of that value in cash money in exchange for hooking them up." And it's game on buddy. And what is that game? Stealing the 'value' that would have been returned as a wages to a coder if they had been hired and keeping it for themselves.
You might as well decorate your front lawn with $100 bills and put up a sign that says, "These bills are decoration I forbid you from using them to go buy things for yourself." Sure some folks would respect that sign but a whole lot more would say, "Uh, good luck with that, and thanks for the cash."
If you write code for "free", no matter what license you try to put it under that "prevents" people from profiting off of it, they are gonna profit. You can either make it possible for them to profit and cut you in on some of that, or you can decide for yourself that you're okay with all of that value you created funding someone else's lifestyle.
Can someone ELI5 why I should feel bad about Redis charging massive companies like AWS and Google to use/sell/profit from their software? Am I really supposed to feel like Amazon is the good guy in this situation? As far as I can tell this change doesn't affect 99.999% of Redis users, but I understand I could be missing something?
For a lot of people, myself included, it’s ideological. It’s not about “feeling bad” for gigantic corporations, it’s about what FLOSS stands for. Something either is or isn’t free software, and for a lot of people that doesn’t matter, but it matters to me.
It affects users who were using hosted redis - there is no longer any competition. If you liked to use redis hosted by someone else (for example for lower price, or better integration, or something like this), it is no longer possible. It's Redis Lab way or highway, and they can jack up prices as high as they want.
> If you liked to use redis hosted by someone else [...] it is no longer possible
That's not true though. Cloud vendors can choose to pay Redis Ltd to continue to offer "official" Redis as a managed product. Azure is doing this. AWS and GCP just chose not to.
Can't imagine Redis Ltd will be allowing cloud vendors to undercut their offering long-term.
Even if Azure Redis is cheap now, just wait until the next low-performing quarter at Redis Ltd, and they'll raise Azure's fees to make their offering more attractive.
They are the monopolist now, no one can force them to have fair prices.
I completely disagree with that prediction. When comparing the operating costs of a first-party vs third-party managed Redis service, cloud vendors have substantially lower operating costs for their underlying infrastructure (servers / data centers) than Redis Ltd. This means the cloud vendors can still offer a competitively-priced product, despite having to pay Redis Ltd for licensing fees.
Cloud vendors can also offer better inter-op between their managed Redis product and their other managed services, availability of managed Redis in every single region the cloud vendor offers, lower latency, etc. The managed offering directly from Redis Ltd can't compete on those qualities.
Additionally, Redis Ltd is motivated to not massively jack up fees on Azure, because in that situation Azure could switch to ValKey (or any other fork, or an in-house compatible re-write -- which they already have one of) and tell Redis Ltd to pound sand, like what AWS and GCP did.
Market forces are what makes Redis Ltd have fair prices, and this inherently means there's no monopoly.
Why, unlike Redis and Elasticsearch and Terraform, was there no big community fork of MongoDB when it was relicensed?
Cockroach, Materialize, and MariaDB were all also relicensed without massive backlash, I think. But I think that's because they had fewer users at the time.
But Mongo's was the one relicense event that didn't produce so much shock that a new fork came out of it. And Mongo's stock is doing great, if that's a good proxy for their overall success.
Definitely an interesting question. Some things that may explain why --
Mongo was always AGPL and relicensed to SSPL. This had the following consequences:
* Very few companies and zero large cloud companies ever attempted to run the MongoDB codebase in production as a managed service, other than MongoDB the company.
* Mostly because of the above, MongoDB did not receive many code contributions that did not originate from within the company. There were some, but not nearly to the extent of the others you listed
* The difference between AGPL and SSPL is not nearly as large as the difference between BSD and SSPL or Apache and SSPL.
The license matters less than copyright ownership. Prior to the license change, MongoDB insisted on copyright transfers. Every line of code was owned by them. That's why they were able to re-license it. Elastic, which used to use the Apache 2.0 license, did the same thing: they insisted on copyright transfers as well.
Other people that didn't own the copyright to any mongodb source code of course had the right to take the source code and fork it under the AGPL. But there would have been no choice about the license under which to distribute that fork because of how strict AGPL is. By insisting on copyright transfers, Mongodb was able to dodge that and re-license the entire code base without having to require permission from anyone because they owned all of it.
For the same reason, there never was much of a community of contributors outside of Mongo. Most large companies would have steered clear of that legal mess and declined to contribute or fork. The flip side of course is that this strong ownership marginalized mongodb as a community even before the license change. It simply didn't matter much to most large companies as they would have steered clear of it anyway.
With Redis, this is not the case. Redis the company was an active contributor to the code base but most of the contributions actually came from the outside and they never owned the copyright to those contributions. The BSD license allows anyone (including Redis Inc.) to redistribute the code under whatever license. Which is why Redis can do this. But for the same reason everybody else can continue as is using Valkey without having to worry much about Redis the company having retired from what otherwise is a thriving OSS community.
Most people I know (including me) that used MongoDB in their companies for sometime, already carried a lot of regrets after 6 months. I think the community were not so excited about forking or doing anything with it, when there are better battle-tested solutions
I believe it takes an organization a huge inertia to be stuck with it, possibly if you managed to grow your company really quickly. But most projects I've seen that used mongoDB ended up being rewritten/thrown away
I find it astonishing when I see how much mongoDB has managed to grow its revenues, now its like $2B trailing when literally nobody needs it
RDBMS's can be scaled to "planetary" scale and once you throw in a few other noSQL DBs to fill in other gaps (like Redis), you literally will never need to pay a license
MongoDB's success is probably a similar case to Oracle, there are many OSS alternatives but some old businesses have the foundation of its business on that db and moving out would have a huge cost, so they accept shredding millions to software that OSS have even better alternatives
Anecdotal but the perception in my corner around the time of the license switch was that Postgres was good enough now with bjson columns, and we could just use that for new projects. Projects that needed to scale beyond what is easy with Postgres are fairly rare and usually mean you’re doing well enough to throw money at citus or whoever to prevent everything from melting.
My impression, as somebody who's had to choose this layer of infrastructure a few times.
Many people who "start" with those database choices either (1) "end up" elsewhere or (2) are perfectly content with treating their database as a SaaS business expense.
Their communities have self-selected into a [profitable] niche that excludes the kinds of people (like the author of this blog post) who are both capable and motivated to maintain a fork.
The author of TFA would probably categorize MongoDB as "software I hate" (a category he touches on in the article), to put it in perspective.
There were copious reference links in the article but the one that stood out to me and that I spent some time reading was this GitHub issues discussion on license [1] (but really on the differing opinions of two of the larger forks communities and values).
I am pleased that Valkey has made the decision to remain independent from the competing Redict fork project. The dogmatism on display in that thread is frustrating. It is one thing to stand by your own principles and opinions, it is entirely another thing to aggressively push your opinions onto others. With the two projects remaining independent, we will get to see which kind of community stewardship results in project success and longevity. The alternative, I fear, might have been technically minded people being railroaded by ideologically driven zealots.
Dogmatism and zealotry are words we probably mostly associate with religion, but I think they apply exactly to the kind of people I would proactively exclude from any public community I was trying to build.
If AWS and other cloud providers gave if only 0.1% of the profit they generate out of these open source projects back to the developers we probably wouldn't have this problem. Unfortunately they don't and it's only fair that eventually those developers take it in their own hands. It's not a great situation but it's certainly understandable.
> Unfortunately they don't and it's only fair that eventually those developers take it in their own hands.
"Fair" is somewhat loaded. The developers certainly have a right to change their product and charge for it, but it's not nearly as cut and dry in my opinion. How many contributions were made because of the completely open nature of the product? Is it "fair" to those people that the controllers of the project want to change how it's offered at a later date? Some people are happy to feel like something they have contributed is in use by a lot of people regardless of whether someone else is making money from it.
There are often lots of entangled assumptions in open projects like these. Ultimately, people have a right to offer their work as they want, so I see no problem with projects trying to request additional restrictions on how their work is used, but I also don't see a problem with companies using open projects as offerings. It was offered for free, and it's not like the cost of the offering isn't usually just the cost of the underlying resources plus some additional amount for ease of management.
Disregarding the question of if the CSP compete fairly with providers of open source SaaS, your math is broken:
AWS revenue is about $90.76B, though most of it isn't from Redis, I'd assume. But let's be generous, and assume 10% of that is. So about $10mm. For the recent version, Redis-the-company contributions to Redis-the-software were less than third of the code base, so let's say they get $4mm. That's very little revenue for a company that has a valuation of over $2B.
Revenue is irrelevant, profit is what matters. The vast majority of the cost of any redis service offered is going to be the cost of the underlying compute and disk resources used. In some cases the margins could be close to nonexistent after paying for the resources utilized and the people to manage it, and it's used as a table stakes service that needs to exist for people to want to use your platform.
The vast majority of these projects didn't seem to have a problem with large companies like Netflix using their software, even if it was put on a cloud server, as long as it was managed by Netflix. Now that the management portion is moved to the cloud provider, along with some amount of possible profit, it's a large problem? Was it not a large problem when the companies were using these projects directly? Was there not some assumption and hope these companies would use these projects by the people contributing to them?
You must mean something other than 10%, that would be $9 billion by your numbers. 0.1% would be about $9 million so would be closer to your envelope math.
OP suggested the CSP should give 0.1% of their revenue to open source software they make their revenue from. As Redis isn't the only SaaS AWS offers, I was gracious and allocated 10% of those 0.1% to it.
Got it. It would actually be less than that since the number you selected was for revenue, not profit which is what OP asked for. Looking at some prior years it looks like AWS profit is close to 1/4 their revenue, so $90 billion would leave them with (generously) $25 billion profit. 0.1% of that would be $25 million and 10% of that (your estimate of Redis's share) would be $2.5 million.
The post is a little conflicted? It starts by saying he likes redis becasue it was a great fit for his personal vector db he wrote on top of it but then goes on to say he's worried about the future of the company for focusing on ai support, which is what he was already doing with it? I'm not sure I really get the concern about trying to support ai needs though. Atleast it's relevant compared to making changes to a stable kv store for the sake of change.
Are these redis forks just vocal terminally online internet people fighting, like most people don't resell redis and don't care, don't comment or get involved?
I really don’t get why Redis didn’t keep the same license but with an addendum that companies (where this applies to the ultimate parent company) that have more than some huge amount of revenue (say, $5 billion), can’t resell it. Similar to the license provision for the Llama2 model. That wouldn’t upset people nearly as much, since it would only apply to a handful of hyper scalers, and then Redis the company could cut deals with all of them to make a bit of money. Now they will end up with much less because of these fully open source competitors that were only created because of their foolish license change.
I agree. The dual licenses don't really slice reality the way they want them to - that large companies should pay, and everyone else should use for free. So just say that. Pick a revenue number, and say that anyone above that number should contact for an alternate license.
To answer sibling comment by theamk: I think such projects should just disclose their rates up front.
This would mean every startup that hopes to be acquired will avoid it. ("resell" is legally complex, and lawyers during acquisitions are very cautious)
I don't have many points to consider, that's the root of my comment. The only point I can think of is that a project is a result of its people. And Redis people are now Valkey. Thus, for me, the word Redis is a deprecated word that in past meant what is now named Valkey.
As I understand it, linux has dependencies on Redis. Since redis licence change, that can't work so linux needs an alternative.
Linux foundation made a fork of redis named valkey, which was instantly backed by most of the Core maintainers, and many large companies (AWS, GCP, Oracle, Snap).
So it seems obvious that this fork which will be part of linux dependencies, has backing of big corps and core maintainers isn't going anywhere and is likely the 'new redis'.
I thought the author was bringing in genAI for little reason...then I clicked through. For some reason storing vectors and chats is core to Redis' vision of its future. (https://redis.io/blog/the-future-of-redis/)
I'm, generally, a mobile dev so I'm not familiar with redis. My handwave-y understanding is its a in-memory key/value DB.
I don't understand how that brings anything to the table for genAI. Couldn't the pitch read the same if you were mongoDB, postgres, whoever?
Also, my goodness, my eternal enemy, the idea a vector DB is something different than keeping a store of file -> pair<string, list<double>>.
The odds you need a vector DB unless you're doing insanely high scale stuff with AI are very low. If you're doing consumer stuff, please use ONNX and keep the pair, and thus the file, local and private.
Redis will be used for genAI as it's always used: answer queries faster. Users are not interesting in waiting, answers need to be immediate. Plus reducing load on whatever you got behind Redis is a nice bonus.
I did evaluate a few vector databases for our RAG PoCs with quite a significant amount of metadata for permission handling on both the vector and the query, and execution time was in the area of milliseconds as far as I remember. The RAG performance hit pales in comparison to what computing time larger LLMs need, so I am not sure you are on the right track here.
Naively, I don't understand how Redis would be involved at all. Ex. in simplest system set up, we're running O(seconds) network request that relays output from a GPU to a client. Again, I'm a naive mostly mobile dev, but I'd presume the same machine running inference would stream the response JSON.
A vector DB is the complete opposite of what you describe, it maps list<double> to pair<file, string>.
The queries it's good at are not "what vectors map to this filename", but "what pieces of text are closest to this vector, and what metadata do we have about them?" This is a non-trivial problem to solve if you don't want your queries to be O(n) where n is the dataset size.
This is useful because AI models can transform any kind of content (usually text or images) into vectors, in a way that content similar in meaning is transformed to vectors that are close to each other. This can be used e.g. find all documents related to your search query, even if your search keywords are never directly mentioned, to find articles similar to the one you're currently reading, to search images by their descriptions, or even to see how closely a user submission matches "undesirable" content, like spam or porn.
I agree that specialized vector databases are a little silly though, considering that Postgres and others have vector extensions now.
The specialized vector database performs well when processing pure vector tasks but performs badly when it comes to SQL compatibility and integration with the existing system; And the traditional database with vector algorithm or vector plug-in like ES, PG, and Redis, achieves the vector function, the advantage is that it is very easy to create tasks in a production environment, but when the data scale is relatively large, they will quickly encounter performance bottlenecks.
There is a new type of vector database that combines the best of both worlds, which is MyScale, the SQL vector database. You can refer to the following blogs to see the comparison. our comprehensive benchmark evaluation reveals that MyScale exceeds other products in terms of filtered vector search accuracy, performance, cost-efficiency, and index build time by a long way. Importantly, MyScale is the only product tested that delivers healthy search accuracy and QPS across various filter ratios.
I know vector DBs x embeddings, so I'm afraid I'm just awful at communicating: to wit, and much to my consternation, I have to write and maintain code for both image and text embeddings, on 6 platforms.
I think we're getting to the heart of my confusion, and I only assume it's because of different use cases/expectations on privacy.
Lets say I'm CEO of Mousetrap Inc., and I got this .txt file, our top secret plan for a better mousetrap.
I want genAI to pick out the parts about the new metal alloy.
I upload the file to B2BAI LLC, who turns it into List<String>, then we give it to the model and get back List<List<Float>>.
Vector DBs store the List<String> and the List<List<Float>> for retrieval.
I, the top secret mouse-trap inventor, do not want my plan stored on any 3rd party computer.
But, this app I use puts it in an a16z approved Vector DB™.
The vector DB provider now has the embeddings (List<List<Float>>) and the chunks (List<String>), which violate my desire to not have my top secret mousetrap plan stored at rest anywhere .
Big companies who are extremely protective of their secrets use the cloud. Even the US government isn't afraid to store classified information in AWS, and they're not joking around with secrecy.
Unless you're acting specifically against American interests, I can't imagine a situation in which a cloud company would actually steal your secrets.
If anything, I'd be afraid of a vector DB vendor getting hacked, but I don't think that most non-tech companies who want to use vector embeddings for their documents can provide better security themselves.
Presumably the output of an ML model, the titular vector, and the chunk of text that created that vector are stored in a vector DB?
(that probably read aggressive, ignore my tone. At length:
I run the model locally and store the vector locally, but I'm doing consumer use cases so I have different tradeoffs, so I'm glad to have someone who uses them interlocuting.)
at work we're still at the pre-fork drama version of elasticsearch, it works and leaves us open to pick whichever direction we want to go at a later date when we need it. The same will be for redis, it works, no need to stay up to date.
My prediction is that Valkey will be the dominant "fork" moving forward. I don't believe the Redict team's prioritization on their niche values is going to resonate well with businesses that are going to end up both using and contributing to development in this space..
However I think the RESP is going to become even more of a standard protocol that many viable implementations support moving forward. Microsoft is working on Garnet, and I can imagine other major cloud providers having their own implementations or forks at least.
It seems to me that dual-licensing AGPL + commercial and no CLAs is the best way to go.
AGPL ensures no one will serve your software via network without also showing their code (which they can avoid by buying commercial licenses and thus funding the project) and no CLAs ensures that the project can not be relicensed without every contributor agreeing. (after all, if really every person can agree it is a good idea there might be some merit to it).
No CLA for commercial license would mean that any contributor retains copyright to their work. So, you mean they get proportional dividend from commercial contracts? Is there a precedent? I'm honestly curious.
No, because the license. If you release code as FooOSS please will remain as FooOSS. With a CLA the company that owns it can also offer it as a different license. If you don’t sign the CLA, you can offer it as a different license…
But regardless I sell your code under FooOSS until the cows come home without paying anymore else a dime. If I couldn’t, then it wouldn’t be OSS. Now, depending on the FooOSS I might have to share any changes I make… but you cannot revoke my license to your’s.
I really like Redis, used it a lot in the past, but I just don't see a place for it in a modern, cloud-hosted architecture. A central cache just doesn't make sense in any scenario I can imaginewhen considering the cost/performance curve (my imagination might be limited though).
Microsoft Garnet is the only redis fork that actually improves upon it, improving performance by an order of magnitude. Maybe the others will catch up, but it's very "Hacker News-esque" to fail to mention something the largest company in the world is working on.
The point is to benefit humanity, not make money. With that said, sure this ideology seems impossible to realize change in the current money-obsessed world, but the thing is that these ideologies are simply incompatible. Yes, I'd say that you are also unfortunately money-obsessed, your whole post is centered on it; I don't blame you though, I also have to focus a majority of my life on money to raise my children, but it doesn't have to be like that.
We won't make change until enough people are willing to sacrifice to make it, and most people just aren't willing to bear that load when going with the existing system, while broken, alleviates that pain while unfortunately also acting as a network multiplier to not just perpetuate, but also strengthen, the status quo.
Make no mistake, the existing system is built with features made explicitly to limit your freedom. You simply can't live without selling your labor. If you look at a lot of people trying to start their own businesses (FLOSS or not), they're trying to use the system to earn their freedom in a system where true self-determination and financial independence are synonymous.
That's all the FLOSS ideology is, buying our common self determination through leveraging the power of computing. And looking at how much money it's generated, you can't say that was an impossible dream, but we're losing the war.
Cool, I’ll send you my land lords banking info so you can pay my rent, the info for my kids childcare, and where to contribute to my retirement account.
Also, for what it’s worth, I’ve forgone millions of dollars in compensation over the years to work on socially beneficial projects, and literally just left $250k on the table last year alone. But yeah, wanting to support my family makes me greedy.
I said money-obsessed, not greedy, not really the same thing, but it is something that's becoming more and more pervasive. Case in point, your whole response was focused purely on money.
I actually find it pretty interesting that there's so much hostility towards my posts when I attempt to start a discussion on alternatives to our present and decaying society. Like, it is a lack of imagination? A resignation to reality? Belief that this is the best we can do?
Personally, I /can/ envision a future without landlords, banking info, and retirement accounts, where we direct the immense productivity of our people away from one that necessitates a focus on money. I guess I'll just need to work on my pitch.
I’ve been working in digital rights and advocacy for years. High rhetoric isn’t how you change things, it’s long-term commitment to meaningful action that must be sustained or it will falter.
My annoyance is that I’ve had this discussion a hundred times and unless you are in the trenches trying to make change while supporting your family I’m not really interested in musings on what a better world looks like, I’m busy trying to support myself doing the work to make it happen.
And per my comment above, I’ve given up a TON of money, but I still deserve to have money in my pocket.
Now that's something I can work with. I don't intentionally spout high rhetoric as a way to chastise or belittle, though I admit I do let frustration leak into my words. I honestly am looking for how I and more people can be a part of a change, I do _want_ productive discussions.
This week has been an interesting one for me, my perspective has shifted quite drastically. Honestly I was bitter, I found that I was unintentionally on a mission to inflate perceived injustices to create bad people in my mind, ostensibly for the purpose of making myself look "good" in comparison. I let that need leak into my interpersonal interactions in an attempt to push that juxtaposition into other people's minds.
I'm not in the trenches like you because I spent a decade focusing on bootstrapping a company because I wanted money, and I selfishly wanted to just ignore everything that bothered me and focus on what I loved doing. In the end it ruined most of what I actually value, and that changed me in ways I hadn't realized; in the end I burned myself and bridges as those things began to crumble.
I will say that I've thought a lot about our conversation this week as I've been trying to find a path to somewhere better, as I do struggle a lot with what you're saying as I have kids of my own, some adult, who are seriously struggling because of the screwed up money obsessed world we find ourselves in.
A pretty big part of the torment I was laying on myself was because I didn't feel like I deserved the monetary success I had worked so hard to find, I felt like liquidating my value as my co-founder had was tantamount to becoming one of those people I so fervently despised. I've instead been trying to prove to myself that I could do it again on my own, with the expected result.
I decided to call our investor this week and negotiated a buyout of my equity. Now I guess I just need to figure out how I can turn that into some good in the world. I'm incredibly grateful at this point actually, I've experienced having nothing, I've experience true hopelessness, and I've experienced how much even a small gesture by someone who cares can drastically change one's circumstances and frame of mind.
If there's anything you could share with me about your experience in advocacy, I would be humbly thankful.
Yep, free software originated among academics employed by institutions who paid them for things things other than their creation of software. And good on them!
But there just aren't enough professors, grad students, or young people with plenty of extra time on their hands, to build all this stuff for free.
Do you share a part of you charge with the people that contributed? If not, what you're doing is the same as what others did when they took your work and profited from it.
You've all agreed what can and can't be done with your code based on the license you used.
If you want to make money with software, it's proprietary or dual-licensed (A)GPL with CLA. Anything else you'll bait and switch on people.
Well, apparently it stopped people who made profit specifically by using their project without giving back and that might have alleviated the OPs frustration, which is fair enough.
Because I’m in the same market now and they are my competitors so I can’t monetize my work at cost if somebody else is taking my labor for free and undercutting me on price.
Changing from an open source license is a kind of tech product spin on enshitification.
Even if the product continues to get features and active development, like Oracle poured into MySQL after its acquisition, a database or framework going less open source is still a death knell.
The mainstream programmers will move on and use something else. Anything else. Who who has heard that the license can change would now pick it for a new project?
I'm confused. Does SSPL not require more sharing of source code than GPL and the like?
I've always thought the "we're just hosting a server with our modified version of this OSS code, so we don't have to share the source" argument was trash.
It's not even being compared to GPL. The original licence was BSD. You're right, these licences are meant to make things more free. It's incredible to me that even software engineers can't see beyond local optima and convenience to the bigger picture. BSD is like saying "you're free to do anything including throwing shit over your neighbour's fence". Individual freedom is basically irrelevant. It's community freedom that matters.
Nobody owes you free labor, but it's a world of uncertainty. People don't like uncertainty. Will this labor be priced reasonably, at around the same level that I value it, or will they pull a vmware and ask for my first born?
Many of these recent forks are being done because people won't want AWS/GCP/Azure to slap a UI on top of their free open-source product and resell it, making tens of millions of dollars per day in the process. I can't really blame them.