It's Time for the Open Source Community to Get Real

By Paul Dix / Company, Developer
Aug 22, 2018

Like many open source developers, I’ve been reading the commentary around Redis Common Clause Licensing with great interest (HN thread). The gist of it is that work on certain enterprise modules for Redis that are developed by RedisLabs will be licensed under the Apache 2.0 + Common Clause license (basically a new license), which will prohibit them from being used freely by hosting and cloud providers and other software makers that profit directly from them. Redis will continue to be developed primarily under the sponsorship of RedisLabs under the liberal BSD-3-Clause license. There seemed to be some initial confusion that Redis itself was getting relicensed, which Salvatore (antirez) has been trying to clear up.

Despite that confusion, I don’t think the community’s outrage is driven largely by that. RedisLabs’ post wasn’t ambiguous about the licensing of Redis itself. I think most of the community outrage will continue even with that clarification. I think most of the people that actually read the RedisLabs post understood what was going on. They’re just not being honest with themselves about the realities of developing and driving the success of open source software. In short, it takes continued investment, and that must be subsidized somehow.

I spoke last year about the difficulties of building a business on open source software and the fact that OSS is always subsidized either through people’s free time or some other successful business. Building a business in the open source infrastructure space has become much harder over the last few years because of the cloud providers’ continued march across the entire infrastructure software market. This is exactly what’s driving RedisLabs’ decision on this licensing move. Their move makes sense for the business and, more importantly, for the longevity of the open source Redis project. Why do I say it makes sense for Redis’ longevity? Because longevity means continued investment, and that money and time has to come from somewhere. Let’s quickly review the different ways to subsidize an open source project.

Developers’ free time is where it often starts. This means individuals writing code and documentation in their evenings and weekends. This is usually in addition to a full-time software development job, which is ultimately what pays their bills. This model doesn’t scale and I would argue isn’t a valid option even at the small scale of libraries. If you have a library of any amount of complexity, it will take continued effort to fix bugs and evolve it. Otherwise you end up locking it down and sealing it off as “done”. If you have a larger project, the realities of it being driven by free time contributions are even worse.

The more successful approach is to have open source be the exhaust of some other successful business. Facebook and Google produce significant open source projects mostly subsidized by successful advertising businesses. However, there are frequently hidden motives for these projects. For example, Google puts significant investment into Kubernetes, but it’s also in their financial best interest to do so. It commodotizes the software of the cloud platform, which gives them the perfect wedge to get into the market currently dominated by AWS. Understanding the motives of the organizations that are driving the open source projects you love is important because if the financial realities change, their support for that project could dry up. And an OSS project without any support is one that is sure to die over some period of time.

Then we have open core. A company produces an open source project (the core) and then creates proprietary software in or around that project which they license or provide as a service. This is obviously the model that RedisLabs is pursuing. It’s also our model here at InfluxData and the model of many other open source companies. The revenue derived from the closed source software drives continued improvement on the open source front.

Lastly, we have consulting and support, which I think is a dead end. It certainly works on a smaller scale with individual developers, but it falls apart when trying to build a company. Most of the time you’d be better served by picking some other open source project that is successful and building a consulting practice around that. Then you have your developers billing hours to clients rather than writing code that results in zero financial activity for their employer.

Matt Klein, creator of Envoy, was arguing on Twitter for the foundation approach. Basically, put the open source under the stewardship of a foundation and have the development funded by grants from that foundation. However, I don’t think that’s scalable and it has the same problem of determining where the subsidy comes from. Look at the paying members of the CNCF or the sponsors at CloudNativeCon (run by the CNCF). They certainly bring in money from all that, but that is driven either by VC money from startups trying to build businesses around CNCF projects, or from large successful companies trying to hire developers or pursue their own financial interests around those projects. Also, this assumes a certain level of scale for the project in question, which typically requires years of investment to even get to.

I don’t want to pick too much on Matt, because I’m a big fan of his work and of him as a person. But what happens if the gravy train dries up at Lyft (his current sponsor for all his work on Envoy)? He’ll have to look for a new sponsor, which he’ll almost certainly find, but it’ll also be tricky because he’ll have to make sure their motives align with his own for the Envoy project (which are as pure and laudable as I’ve seen in the OSS community). Envoy will continue to live and die by the largesse afforded by successful technology companies that sponsor its development through full- time developer salaries.

That brings me to another unspoken truth about open source software, which is that the organization that “owns” a project is generally the one that employs the most developers that contribute to it. RedHat knows this, which is why they frequently do acquihires of popular OSS projects. Venture capitalists also know this, which is why they conduct an oil rush style land grab to either fund, or get their portfolio companies to acquihire the primary contributors of any hot new open source project.

Open core is a fairly honest way to go about developing open source software. As long as you’re clear about what is open and what is closed. Within InfluxDB, our dividing line is that anything related to high availability or scale out clustering is kept as a closed source commercial product while anything in the single server realm is open source (but we’ve been moving some network code into our open source recently, which I’ll talk about in a little bit).

The accusation that RedisLabs did a bait and switch is entirely unfair. They’ve been funding open source Redis development for years and that work is now and will be in the future under the liberal BSD license. It’s not like they tricked a bunch of people into using Redis and pulled the rug out from under them. I’m sure that more than 99.99% of the Redis users are completely unaffected by this. And for those others, it’s not like the code that’s already out there is unusable. To my knowledge they can’t retroactively apply the license. So we’re really only talking about forward development to specific modules (not Redis core).

Redis is a fantastic piece of software. I’ve used it at multiple jobs, I’ve given talks at conferences about it, and I’ve recommended it to people. This announcement changes nothing about that. The only thing it does is show me that RedisLabs is aggressive about ensuring the company’s longevity and, with it, Redis itself. As long as RedisLabs is around and profitable, they’ll be able to subsidize and sponsor open source Redis development. Don’t like their direction? You can fork and you can even do it with whatever’s current when you make that move. Before you start freaking out, let the continued development in pure open source BSD licensed Redis inform your opinion, not a bunch of fear-mongering.

In software development, we appreciate that most things in software are all about tradeoffs. Developing a distributed system? Gotta pick AP or CP and decide which tradeoff is for you. Trying to ship a release? Gotta pick the features that really matter or the timeline that’s more important, more tradeoffs. I argue that the same is true of open source licensing and open source funding models.

In open source licensing, the tradeoffs are about what people can do with your software. If you’re going with a license like MIT or Apache2, you have to be prepared for anyone to take your software and do whatever they want with it, including making more money off derivative works of it than you do. However, it’s easier to build a bigger community and get more people contributing because they can do anything they want with it. If you care about making sure that anyone that takes your code contributes it back to the community, you pick GPL2 or AGPL. The tradeoff there is that you limit the commercial options for developers that might want to build a business with your code.

The licenses and tradeoffs there generally feed into the funding model. Open source must be funded somehow. I don’t think there’s a one-size-fits-all or silver bullet to this. Open core, big business exhaust, foundations, and dual licensing all lead to models that fund development.

It’s these sets of tradeoffs that InfluxData thinks about when we open source software. For example, we’ve chosen to license Flux, our new language, under the very permissive MIT license. Flux also has code to query open source InfluxDB servers over the network, which goes beyond where we normally partition open source versus closed. However, our goal is to get it as wide adoption and contribution as possible, which means that we want developers to use it for fun projects, commercial projects, building companies and everything in between. What this means is that we’re prepared for others to profit from the existence of Flux.

I measure our success with getting Flux into the world with a series of milestones. First would be getting InfluxDB users using the language. Second would be to get users of Flux outside the context of InfluxDB itself. Third is if and when we see other open source projects adopting Flux as a language. Finally is if and when we see companies (and competitors) adopting Flux as a language and deriving revenue from it. We’re prepared for all of those because that’s what success looks like for this piece of open source we’re working on. However, that doesn’t preclude us from continuing to develop closed source software in the commercial version of InfluxDB that we drive revenue from to subsidize this open source development.

Ultimately, I think the open source community needs to take a deep breath and think about the realities of OSS development. This work isn’t free and it costs people’s time, effort, and passion. The last is one I connect with on a personal level because I appreciate how taxing it can be over years of continued effort. These things don’t come free and if a company like RedisLabs happens to be commercializing some part of Redis while still contributing a significant amount to freely available permissive BSD Redis, they should be commended, not attacked.