Merging efforts with Redict

[ddevault]

Hi, I'm one of the people working on the Redict fork, and we would like to merge efforts if possible. Bringing the discussion here from #8 (and various private conversations) where there is some additional context.

The only thing we're really committed to is the name and the use of the LGPL license. If the folks working on this fork can get on board with that, then it does not make sense to split the community in two, but we are committed to the copyleft approach so we will need to get consensus on this to merge forks. The rationale behind LGPL has been explained in a few different places, but I've summarized it here.

As far as practical matters are concerned, there is the matter of infrastructure and communication. We're using Codeberg rather than GitHub right now, which should be very familiar to GitHub users and has the advantage of being free software, which we are strongly in support of using. I hope you're willing to give it a shot, but I don't think it's a hill worth dying on. Discord on the other hand, I can't speak for everyone involved in Redict but I think it's a very hard sell. We're using IRC right now, but we could be convinced to use Matrix, which is a bit more user friendly.

[likecrazy1]

I don't see why we should go with copyleft for Placeholderkv. BSD is perfectly fine.

You have to meet the community at the other end of the stick, after all :)

[LeoniePhiline]

I don't see why we should go with copyleft for Placeholderkv.

To prevent another rug pull.

[Conan-Kudo]

I do think it's worth considering whether the future should involve a copyleft license. Ultimately the reason we're in this situation today is because it was permissively licensed and Redis Inc was allowed to do this through the terms of that license. Using the LGPL and distributing the copyright grant (ie not using a CLA to centralize the sublicense permission) effectively prevents that scenario from happening again.

Redis' unusual extension mechanisms should largely be unaffected by this with the choice of the LGPL, as only the codebase itself is copyleft, while extensions and scripts can be whatever they want.

As an aside for communications, I personally would prefer Matrix over Discord (and other non-free and more importantly closed platforms). GitHub vs Codeberg/Forgejo, however, is something that I think contributors are going to care much more for. I suspect that for various reasons, many of the contributors are going to prefer it being on GitHub.

[likecrazy1]

The key difference here is there is no "Redis Inc" to change the license. This is a community run project, similar to other community projects that have maintained permissive languages the entire time

[mattsta]

Ultimately the reason we're in this situation today is because it was permissively licensed and Redis Inc was allowed to do this through the terms of that license.

Nothing in the BSD license says "BSD or just whatever yolo!!!" — you can't just change a license because you own a company that stole an open source project more and more from a global community over the years. They clearly made an illegal license change to try and get more revenue out of their failing company.

The only thing we're really committed to is the name and the use of the LGPL license.

I think anything non-AGPL is basically equivalent since the use case is almost always "hosted server platforms" — the GPL and LGPL restrictions only trigger if you send customers binary-only artifacts.

Also, as above, nothing lets people change the license from BSD to just "whatever else you want because people feel like it." Source code licensing is weird because technically each person's copyright is to their contributed lines and not technically the entire file, so if you add a new license for new changes, the new license only applies to the new changes, etc. It's a huge mess unless you gather signatures from every contributor who ever had a PR merged since the beginning of time.

Legally, it must stay BSD forever. Practically, you can rip out license headers and do whatever you want until somebody sues you (or unless you are an evil foreign corporation who thinks they don't have to respect copyright law).

[joshmanders]

Drew your fork was the first I saw when the news started breaking and my biggest concern from the outside was that it was on codeberg. I understand your principals and admire them, but I think the biggest thing that would harm your fork becoming what everyone congregates to is that Redis is here on GitHub. All the contributors are here, the users are here, everything is here... Asking probably 99.998% of all users in the community to pick up and move to a different site, no matter how noble the reason, probably would be the biggest killer and people may settle on congregating around an inferior fork because they don't have to up and move somewhere else.

The shakeup of Redis being forked I think is big enough friction to fight against, let alone adding "all communication and efforts have completely left where you knew them to always be.".

Just my prospective as an outside user of Redis.

[LeoniePhiline]

On the other hand, it might be time for an exodus from GitHub and re-decentralization.

Today, Microsoft owns GitHub, NPM, systemd (disputed), TypeScript, VSCode, ... Open Source got centralized and what is happening to Redis is just another symptom of the general direction.

Heck, some people today even believe GitHub == Open Source:

I'm a bit skeptical since it's not hosted on GitHub. as is the standard for open-source projects, so I'm wondering why this fork wasn't hosted here instead of some other site I'm not familiar with.
It makes me question the legitimacy of it.

redis/redis#13157 (comment)

I have never been a codeberg user, but Redict made me open an account there. I looked around and liked it - I might want to host own FOSS projects there.

Drew's decision of hosting on codeberg could just be a step into the direction of fixing our broken, centralized FOSS ecosystem.

[mattsta]

some people today even believe GitHub == Open Source

The only constant I've seen in computing over the past 30 years is "mass market" developers will continue to get simpler and less informed over time. Centralized platforms will continue centralizing more things until every computer only has two buttons: "fun" and "work".

You basically can't make money as a software company anymore unless everything you create is on some cloud "one click to deploy" console. click and launch and bill by the second. forever. never have control over your platform hierarchy ever again.

The perhaps unexpected consequence of everything becoming so opaque and "simple" is we used to learn a lot by continuous troubleshooting. We had to understand our entire systems from CPUs and RAM to networking and storage types and failover and redundancy at five different levels, but these days you can have developers in their career for 10 years and never touch any of those things. Just "click to deploy" behind 37 layers of closed off abstractions you never have to bother learning, so you never know how anything actually works. We've lost all our technical learning by osmosis, so only advanced people seeking out advanced tools actually learn the state of the art anymore.

Is the GitHub developer centralized control good? Probably not, but "everybody knowing GitHub" removes weeks of learning when joining a new company vs everybody using different random platforms. I'm not sure companies realize how many months of onboarding they just get to skip these days since everybody uses the same 3 hosted platforms and employee knowledge about them is perfectly transferable for an entire career without losing capability.

[likecrazy1]

We must be careful not to let external goals, no matter how good intentioned they are, interfere with our goals: to create the best possible fork of Redis. Centralization of Git repo hosting sites may be a problem, but it is not one we should be aiming to solve with this fork, especially since things are already confusing as they are.

[mattsta]

One interesting point I think people should fight over: what do people want redis to be?

Redis has grown too bloated just because the company kept trying to "more feature more profit" maximize everything.

It doesn't actually need all these features. It would be much easier to make it a perfect 100% solution to 80% of uses where it almost needs no development for those specific features going forward. Currently it has so many sprawling edge cases you could spend years running in circles fixing and building things almost nobody is using and almost nobody cares about even though stuff is technically weird/broken/wrong for some extreme use cases.

Many features of redis were made as "just because they were fun" but it doesn't mean every feature needs to exist forever.

Another approach: invert the system and make everything an external module so you could have a group of feature-complete core modules, a sprawling "use at your own risk" feature set (you break it you fix it), then an alpha/experimental feature set.

[madolson]

I'm sorry I didn't respond directly to you Drew, yet, there is been a lot going on.

Fundamentally, I don't care too much about the license or the name, but what I want out of this Redis fork diverges too much from what I think you want it to be. I really don't care about FOSS ideologically, I personally enjoy contributing to it but don't want to make decisions for the sake of keeping software open. I care more deeply about the end users of Redis and making sure they're getting a highly performant engine. I don't want to compromise on using tools people are more familiar in order to meet an end. I also don't want to compromise on working with corporations to get them to contribute, which is something I think I've been rather successful at within Amazon.

The core of Redis is too bloated, and the things that need to be optimized aren't getting optimized. My major frustration with how the previous core team was running is we spent a lot of time on things that weren't important. We added random metrics for fields nobody asked us for "consistency". Redis needs to get better. We need to figure our multi-threading performance, it's sharding and replication system need to get dramatically more resilient, and I want it to be easier to add extended functionality with modules. In the spirit of what Matt said, "invert the system and make everything an external module so you could have a group of feature-complete core modules, a sprawling "use at your own risk" feature set (you break it you fix it), then an alpha/experimental feature set.", is the architecture I want to trend towards. All of this is stuff I want to focus on.

I'm concerned about a rug pull again too though. I'm working to build a diverse maintainer group and am hoping to approach foundations to get the project into a stable governance. That's what I would rather do instead of trying to switch the license.

[likecrazy1]

Drew is a part of a small but vocal minority of FOSS opinionated diehards, which I respect. With that being said, please keep in mind that most developers and end users share a similar mindset of madolson - they use and/or participate in FOSS but don't have deep opinions on it. A vast amount of developers (including FOSS) use Macbooks, iPhones, have Github accounts, use Discord, use proprietary social media apps to talk with friends and family outside of FOSS work, and so on. Trying to convince them to switch platforms just because it is "more FOSS" is a non starter, because they already aren't FOSS absolutists and they won't be just because of a Redis fork. Acknowledging Github centralization is not enough to convince people to move off Github, because it is simply a non issue for them.

It is a very hectic time right now - trying to use a different code forge and forms of communication (which, to be frank, most developers don't use) will only add confusion. Many of these alternate platforms may have quirks that FOSS diehards can put up with, but the average developer will find discomforting.

• IRC requires you to pay for the ability to see messages when you are away, while Discord does that for free. Matrix could be better, but it comes with its own problems: https://telegra.ph/why-not-matrix-08-07
• Codeberg doesn't have as many features as Github, and it is still very much still in development. As an specific example, the CI/CD is still a work in progress as shown via their webpage: https://docs.codeberg.org/ci/ . It clearly states CI might "break at any time and for an undefined period of time"

This is not the time for experimentation - we need something ASAP and Github is the best place to coordinate it.

I don't think the BSD license is a big deal if the software is controlled by a community (as this fork is), not directly by a company driven by profit. Many BSD licensed programs that are community run have been doing just fine for decades. I firmly believe this project is in good hands. While the license could be up for further discussion, the project's best chance for success is unquestionably on Github.

[Conan-Kudo]

Drew is a part of a small but vocal minority of FOSS opinionated diehards, which I respect. With that being said, please keep in mind that most developers and end users share a similar mindset of madolson - they use and/or participate in FOSS but don't have deep opinions on it.

This is a very unfair and negative characterization of the issue. While it is true that folks like Drew and myself are a minority these days (both of us are community-centric open source developers who grew up alongside Linux and are heavily influenced by our experiences in that realm), that does not mean our analyses and concerns are not valid.

I don't think the BSD license is a big deal if the software is controlled by a community (as this fork is), not directly by a company driven by profit.

A community is made up of the people, and depending on who engages and why defines the culture and nature of a project. There is no governance in the world that can protect you from a company just hiring and closing the codebase. That is the story of Redis: a project that was created by an individual, a company sprung up around extending it, they hired the creator and consolidated developer resources, and finally closed it up.

This is not an uncommon story with permissively licensed projects. Sometimes it results in a transition to copyleft (as what happened to Element and what Drew has done with Redict) and sometimes it results in a transition to non-FOSS (as what happened with Redis, MongoDB, et al).

Copyleft/Reciprocal/Share-alike open source licenses exist to close this hole. And provided no CLA with a sublicense grant is ever offered, it's effectively permanent without going through a super-arduous relicensing effort (which guarantees that the community ultimately agrees to a license change).

This is why you see the GNU AGPL being commonly used with Fediverse projects. Many of the folks who create those projects have been involved in other projects where stuff like what happened to Redis has happened, and they seek to avoid it for things that are intended to benefit the wider world.

While the license could be up for further discussion, the project's best chance for success is unquestionably on Github.

I could debate this too, but I think this is also a point we can probably compromise on. The legacy of Redis is on GitHub, and that has value too, even if I personally don't like GitHub much either.

[likecrazy1]

that does not mean our analyses and concerns are not valid.

No one claimed such. There is plenty of valid criticism to be had of Github, for example. The concerns regarding the fly-by-night Github clones are just as valid. The question is finding a solution that works for most of the people using and contributing to the project. No solution is going to be 100% perfect. However, most people from Redis team were on github - and we are using Github to host this discussion right now. It is the home of the original redis, and it has everything we need to get going quickly.

This is not an uncommon story with permissively licensed projects ... Redis, MongoDB

All those projects were managed by companies, not communities as I had previously stated. Clang and FreeBSD have been permissively licensed and is still permissive. Rust, Nim, Zig, pytorch, postgresql, tensorflow, and nodejs are other permissive software that have maintained their license, some of which even had large corporate involvement. It seems the "rugpull" you are describing is the rare exception, not the common occurrence. Regardless, in the exceedingly rare case a "rugpull" happens again, we fork it again and continue on.

To be clear, we're still not 100% if this BSD to (L)GPL change is even legal. We would like to see proof that what Redict is doing with the license is perfectly legal. Mere speculation is not enough for legal matters - has Redict checked with their attorneys? Even if it is legal (which i highly doubt) it seems like a disrespectful spit in the face to the Redis contributors that contributed under a permissive license.

I could debate this too, but I think this is also a point we can probably compromise on.

Studies have been done that show adding one extra "step" in an process significantly reduces the amount of people that finish it. We need the workflow to be as easy and friction less as possible. Drew himself recognizes this to some extent, which is one of the reasons he hosted it on Codeberg instead of Sourcehut. Choosing Codeberg is a implicit admission that meeting the people where they are is necessary for the success of the fork. Ultimately, the people are on Github and so Github is the place to be.

[ddevault]

Good morning, everyone.

Fundamentally, I don't care too much about the license or the name, but what I want out of this Redis fork diverges too much from what I think you want it to be. I really don't care about FOSS ideologically, I personally enjoy contributing to it but don't want to make decisions for the sake of keeping software open. I care more deeply about the end users of Redis and making sure they're getting a highly performant engine. I don't want to compromise on using tools people are more familiar in order to meet an end. I also don't want to compromise on working with corporations to get them to contribute, which is something I think I've been rather successful at within Amazon.

Hi Madelyn.

I have to admit that I'm honestly somewhat insulted that you would characterize the ideology of our fork as such. I tried to explain a few times, but we are not compromising on commercial user's needs, such as the needs of AWS, nor are we compromising on tools. The LGPL is well-suited to AWS's needs -- even if your employer would have a marginal preference for BSD, LGPL will not impose any additional compliance issues for the way that Amazon makes use of Redis, and was carefully selected over more strict copyleft licenses like AGPL or EUPL for this very reason. The concerns of commercial users have been instrumental in the choice of license, not a compromise we're "willing to make".

As for tooling, Codeberg is simply where our work is being organized. We need somewhere to do the practical work of building a fork. You're welcome to participate in the consensus process for moving somewhere else, like GitHub, but -- come talk to us about it. Make your arguments and we'll listen to them. I guess we can discuss it in this thread, but I feel that we have to overcome some kind of block which prevents us from working together at all, first.

The core of Redis is too bloated, and the things that need to be optimized aren't getting optimized. My major frustration with how the previous core team was running is we spent a lot of time on things that weren't important. We added random metrics for fields nobody asked us for "consistency". Redis needs to get better. We need to figure our multi-threading performance, it's sharding and replication system need to get dramatically more resilient, and I want it to be easier to add extended functionality with modules. In the spirit of what Matt said, "invert the system and make everything an external module so you could have a group of feature-complete core modules, a sprawling "use at your own risk" feature set (you break it you fix it), then an alpha/experimental feature set.", is the architecture I want to trend towards. All of this is stuff I want to focus on.

I don't think this is on-topic for this thread, but, for what it's worth, I'm in agreement.

---

I'll look into setting up a Matrix channel -- I could use some help with that, since I'm not very familiar with Matrix.

As for GitHub, I don't think it's necessary to decide right now, and I don't think there is a consensus on the matter. But if we agree that having Redict and placeholderkv work together is best for the ecosystem -- and I think it is -- we can start looking for those consensuses instead of just trudging on in our respective silos.

You're invited to our silo -- are we invited to yours? Do we need a silo? Let's look for agreement on the license and then we can stop all of this fuss and sort out the rest together.