Redis is not “open core”
antirez.com
antirez.com
http://firstmonday.org/ojs/index.php/fm/article/view/1470/13...
Frankly, I think it is great that RedisLabs is using proprietary [1] software in order to sustain and fund improvements for real, honest to goodness free & open source software. Thank you.
[1] "Commons Clause" is proprietary and non-free for many reasons, the asymmetric permissions are the tell.
For Redis to be "open core", Redis Labs would have to be the owner and copyright-holder of the Redis codebase (like, say, NGINX Inc. is the owner and copyright holder of the Nginx codebase, and therefore are able to split Nginx arbitrarily into the Nginx "core" vs. Nginx Plus.)
But Redis Labs don't own Redis. Redis Labs—despite employing antirez—are just 1. a sponsor of the open-source development of Redis, and 2. a participant in the ecosystem of ancillary Redis products.
A closer analogy than "open core" is the thing RedHat, IBM, Dell, etc. do with OpenStack. They all make their own "distributions" of it, which combine the core FOSS OpenStack project with their own proprietary add-ons. OpenStack itself is a FOSS project, and is not "open core."
Similarly, Ubuntu and RHEL are corporately-developed Linux distributions. Is the Linux kernel, therefore, "open core"? No. Those distributions don't own Linux. They just bundle it together with their own stuff, and sell the bundle.
This model works very well for us, but I appreciate that it can be hard to replicate.
In fact Red Hat deploys specific obsfucation techniques to make it harder for competitors to redistribute RHEL, while technically respecting the OSI definition of “open-source” [1]. I understand the business motivation for playing these sorts of games... but it kind of deflates the notion that Red Hat’s model is anything special or worth emulating.
Assuming Redis Labs will accept pull requests and generally follow the process of collaboration casually known as “open source” for their proprietary modules, even if it doesn’t meet the OSI’s technical definition of open source... Then as far as I’m concerned the Redis Labs model is more open, in practice, than RHEL’s.
I'm very familiar[1] with the "obfuscation" you linked to, and I think you are missing context. Red Hat used to ship their Linux kernel source RPMs as vanilla Linux kernels plus a series of patches. They switched to releasing the source RPMs as a fully patched kernel tree. They did this because Oracle started providing commercial support for RHEL (not just Oracle Linux), which is how Red Hat makes money. This had no impact on open source redistributions of RHEL, like CentOS, because they just compile the kernel source without modifying it. AFAIK the kernel is the only package they do that with.
[1] There was a kernel bug between RHEL 6 RC and GA, the RCs had individual patches, the GA kernel source RPM was pre-patched. Lack of patches made it harder to track down, but it was still possible by applying the patches to the RC kernel, then diffing the patched RC source against the GA source.
IMO distributing only the pre-patched source of the kernel is the same kind of violation. The preferred form for making modifications is the original source plus separate patches, that's what the people who are working on that code use.
Patches are useful, of course. They are useful to understand the evolution of the software, to support it, etc. But they are not necessary in order to make modifications to the software. Ten-fifteen years ago it was actually the norm that open source software had private source control repositories and only made periodic releases as tarballs.
If you have the Perl script that generates C code, you get a benefit from being able to modify the Perl script rather than the C code. So the Perl script is the preferred form for making modifications.
If you have the history, you don't get any benefit from modifying the history. In this sense, having the history is not relevant to making modifications, only to studying the code (for example to make the same modifications on another branch/fork of the code, like I do with upstream patches, or like Oracle could do if they had the Red Hat patches).
Your could say that this phrasing is shortsighted, but note that neither Red Hat not Debian or anyone else has ever given the complete history to Linux or any other piece of software they distribute, but they had to give the complete base source tarball as distributed by the upstream project.
Studying the code is the first step in making modifications. I would always want to have a working "git blame" before trying to modify a codebase, so that I could understand lines in the context of the changes they were part of before I modified those lines. I consider it considerably harder to modify a codebase when I don't have proper version control history available.
So maybe their lawyers disagree with us? Or maybe they're institutionally allergic to being a GPL enforcement plaintiff, even in their own strategic interest.
This is actually an interesting argument but I'm not sure this statement is necessarily or obviously true. What has been put forth in this blog posting is that Redis Labs has created proprietary modules for features that antirez has no intention of accepting into Redis core (like JSON and a full-text search engine). So why does it matter whether or not Redis labs owns the code? NGINX Inc. sells modules for features they aren't putting into the core product as well.
It doesn't appear like owning the full copyright to the core makes any difference.
Citus makes proprietary modules for it, and likely employs some postgres devs. I wouldn't consider postgres "open core" by any means. I would consider Citus "a proprietary extension".
In this case, it seems like that is the monetization model for Redis (and plenty of other open source projects). It's not the case, as far as I know, for Postgres.
Its not entirely bizarre to say that, though it's farther from undisputable open core than Redis is, as there isn't a single proprietary vendor with as significant a relationship to the open source project as is the case with RedisLabs.
> Citus makes proprietary modules for it, and likely employs some postgres devs.
And EntrepriseDB. And a number of other proprietary downstream vendors that sponsor significant Postgres development. If PG is open core, it's radically decentralized open core.
Anyone can split the Nginx core codebase arbitrarily into A and A Plus.
"Nginx" is trademarked, just as "Redis" trademarked, but I don't think we're talking about trademarks. I think we're talking about code, and the BSD open source code bases can -- in theory -- be changed and evolved by literally anyone.
---
> Those distributions don't own Linux.
With such permissive OSS licenses, there is little of the traditional concept to the word "own".
> Similarly, Ubuntu and RHEL are corporately-developed Linux distributions.
Hypothetically, suppose Ubuntu was responsible for over 90% of Linux development, and Ubuntu maintained extensive non-OSS additions to Linux.
Or suppose CloudBees was responsible for over 90% of Jenkins development, and CloudBees maintained extensive non-OSS additions to Jenkins.
Then yes, in both cases I would absolutely call it open-core.
I don't think that's a dirty word; it simple describes the realities of the situation.
You seem to be making a distinction with a difference.
Cloudera (Hadoop), MapR (Hadoop), Elastic (Lucene), LucidWorks (Lucene/Solr), DataStax (Cassandra), and DataBricks (Spark) are all companies with an "open core" business model around Open Source projects hosted at the Apache Software Foundation. (Those are just off the top of my head -- there are plenty more.) All ASF projects have many copyright holders.
antirez as the creator of redis is stating that redis is not open core. antirez as an employee of Redis Labs is working for a company that has adopted an open core strategy, and which is using redis as their core, which doesn't make redis the API open core.
Taking an Open Source product and having paid proprietary addons for additional functionality people are willing to pay for is the definition of the "open core" model. I'd have a lot more respect for what Redis and Neo4j are doing here if they weren't creating a cloud of associated FUD and confusion.
But the Redis Labs blog post was incredibly confusing when it could have just straight-up said "We're making some plugins proprietary," and this post is awfully embarrassed of the term "open core" when there's nothing to be embarrassed about. Debian, the group that is so doctrinaire about free software that it literally doesn't ship gcc's manpage by default on the grounds that it's nonfree, is happily running the open-core edition of GitLab. You're not doing something bad by saying you need money from paying customers to support the folks working on FOSS. There are lessons to be learned from previous open core efforts, and they won't apply 100%, but no lesson on successful companies applies 100% to a different situation. And they certainly apply more than 0%.
I'm not sure I would describe it that way. Certainly some part of the community is happy about it, other parts are certainly not.
I swear, this entire fiasco is utter stupidity and has caused countless worthless debates. This is no big deal. Anyone who thinks this is a big deal doesn't have a clue and should just stop now.
For what it's worth, having closed sourced extensions for an open source licensed core product (in this case Redis) is the canonical definition of "open core", and this post does not really prove otherwise. Sure, there could be some minor variation here (with Redis Labs not owning Redis directly), but largely it's the same model for all practical purposes.
I'm fully willing to accept at face value his reasoning but we wouldn't even be discussing this again if there wasn't yet another blog post telling us how we all have it wrong.
My advice to Antirez is to just leave this alone for a month and I doubt anyone will still care in a week.
To you Redis is an independent open-source project, to which Redis Labs generously donates your salary so that it you can work on it full time.
But to most people online, that is not immediately obvious: because of the company name, you working at Redis Labs, and them being the main sponsor, Redis is seen as the "open-source core product" of Redis Labs. https://redislabs.com/community/oss-projects/ also strongly leaves that impression - it even says that to contribute to Redis you have to sign the contributor agreement with Redis Labs.
Once you have that impression, it's natural to assume that Redis + Redis Labs modules are part of one product family, and that the roadmap for both is being planned based on the business goals of Redis Labs.
There's nothing new about this. Postgres has apis for writing foreign data wrappers, MySQL has pluggable storage engines, etc etc.
Is antireZ worried about redis' reputation after the hn license drama? Is he just waxing philosophical? I kept waiting for the post to go somewhere.
Redis is awesome. antireZ is doing great work. Its a bummer he felt compelled in some way to write this.
But then what’s wrong with open core? It’s a reasonable business model, so why the denial?
Whether you believe him or not is your call, but it's not simply a semantic argument.
> that is able to provide strong guarantees is non free. In an open core business model around an open source system it is fundamental that you take something useful out of the free software part.
Isn't that an exact description of the difference between redis clustering and RLEC ? I would say that easy setup and automated (ie, no downtime) recovery are "strong guarantees" and are the "clustering ... mechanism implemented in a different non-free layer" .
I support there being a real business model to maintain the FOSS redis. Just wanted to point out that it sounds like you're arguing against yourself about the true nature of Redis / Open Core
> Redis Labs customers often asked directly for such things. And actually, such features could be cool, but it’s not Redis, I’m not interested, and the open source side of Redis does not have the development force to keep all this things going btw. And this is a major advantage both for Redis and for Redis Labs: it is relatively cheap to pay just me and a few more OSS development time internally, while allocating the rest of the resources to development of things that are useful for the Redis Labs business. There is anyway a great deal of contributions arriving from the community. And I also keep saying “no” to all this fancy ideas… which is also a problem.
At first the author says that there is not enough manpower to develop new large-scale Redis features, but then he says that contributions are being turned away.
Then the core group is left with the maintenance headache for years to come, and more features makes any changes antirez wants to make more difficult.
I admire antirez very much for making it a priority to keep the core small.
* support or training. RedHat seems to have cracked this, other large companies struggle to make it work.
* building an SaaS around it. That seems to work only if no other large player attempts the same
* proprietary extensions (whether you call it "open core" or not).
* getting sponsored for adding features (doesn't seem to scale all that well)
I have no moral objections to any of those.
And then there are things like OTRS AG delaying the release of their own source code, to make the SaaS offering more attractive compared to self-hosting, which kinda annoys me (mostly because it means they can't really accept user-contributed features in a meaningful way).
And that's a problem.
Here's the problem and why what he's saying is a distinction without a difference. This rule is arbitrary, I had never seen it before and it's needed for redis not to be open core.
It very much is.
> I want Redis to be Redis, that is, this general tool that the developer can use in different ways to solve certain problems.
It's telling that the best that can be said is this ambiguous language. Nothing prevents these "different ways" and "certain problems" to change at any given moment.
This post is very confusing as open-core is not directly relevant to Redis the database, and it seems to be defending something that nobody is accusing it of in the first place.