The Future of InfluxDB OSS: More Open, Permissive with Complementary Closed Source

By Paul Dix / Product, Use Cases, Developer
Feb 26, 2021

I was recently on the Changelog Podcast talking about Elastic’s recent change away from open source licensing. I’m at 1:02:45 to 1:24:03, but the whole thing is pretty interesting if you have time to listen. I talked about what we’re doing at InfluxDB and what our future plans for open source are. Yesterday, part of my interview was excerpted, which I retweeted and said:

The future I’m talking about is InfluxDB IOx, which is the new core of InfluxDB: a columnar database written in Rust using Apache Arrow and with object storage for persistence. I wrote about InfluxDB IOx here and also talked about our preference for permissive licensing (IOx is dual licensed under MIT & Apache2).

A few people misunderstood what I wrote in that tweet, assuming that the future we envision for InfluxDB is one where we only build software for the cloud and we abandon open source. Nothing could be further from the truth. With InfluxDB IOx, we’re doubling down on our commitment to open source and we’re putting more into what’s freely available. It will form the basis of the backend for an upcoming point release of InfluxDB 2.x OSS and our storage architecture within our cloud product. We’ll also have a commercial offering for users of InfluxDB and InfluxDB IOx that complements the open source bits they’re running.

The last part about being complementary is what I think is the most important and interesting part of our open source strategy. When developing a plan for the future for InfluxDB open source and commercial efforts we wanted two properties:

1. The InfluxDB Cloud offering runs the open source bits as is (as they're built for the community).
2. Our on-premise customers should continue to run the open source bits as is.

Said another way: The commercial offering should be separate software that is complementary to the open source software.

There are big development, testing, robustness, and software maturity wins to be gained from this model. Our testing surface area is the open source builds and we run those in production in a continuously delivered cloud product. This means we’re likely to find bugs before anyone else. Any bugs found in a customer environment will be fixed in the open source repo and immediately tested in the real world. Another benefit that we’re hoping to get is that it’ll give our community the chance to participate in the open source development and roadmap more than in previous versions of InfluxDB.

To accomplish both of these goals means that we need to have a commercial software offering that isn’t a fork of the open source. It’s another piece of software that uses the open source to build some larger system. In our case this larger system is really all about an operational cloud platform. InfluxDB IOx will feature replication, subscriptions, scale out and scale down all out in the open and under a permissive license allowing users both cooperative and competitive. These features have never been available in a production ready version of InfluxDB open source, but soon, because of our new strategy, they will be.

This is in harmony with our philosophy that the open source things should be truly free and open and permissive, while the commercial things should be obviously closed source and commercial. We don’t want potential users of InfluxDB to be confused about how we intend to make money and whether they’ll need to pay us for anything.

With InfluxDB versions 1.x, our commercial offering is a fork of the open source builds. That is, it’s a replacement. If you’re an open source user and you want to buy the InfluxDB 1.x offering, you either move over to our cloud, or you  buy our InfluxDB Enterprise software, which will have to replace your running open source InfluxDB instances.

This is firmly in the camp of what I’d call Open Core software: a core part is open source and there’s a proprietary fork that adds functionality to that open source thing. Many databases are or were structured like this. However, many of them are moving to a model where they ditch the open source license and instead opt for some source available license with usage restrictions. Their obvious goal is to create a monopoly on having a hosted product while still, hopefully, gaining the free marketing, buzz, and traction that being open source frequently provides.

I think that both the open core and source available strategies are less than ideal. I want open source projects where everyone is free to do what they’d like with the software, including competing commercially with whoever developed it. I also want projects that have clearly defined goals and responsibilities that can take contributions under that umbrella while pushing other concerns to other software. The complementary model I’m espousing puts your closed source efforts into the other software category.

Now you might say, wait a minute, you’re just weasel wording. You’ll just choose to put something in the closed product rather than put it in the open source. I’ll tell you now, that isn’t my intention, but the best part about this strategy is that you don’t need to trust me. Because the closed source code is complementary to the open source, nothing stops other open source developers or other companies from developing their own versions of our commercial code. And they’ll be able to do so because all the APIs are out there in the open source bits.

And this competition is protected by the fact that the InfluxDB IOx code (and all the other open source we do) are licensed under permissive non-restrictive licenses. You don’t trust for that, you can verify. It’s already out on the internet and free for the taking. This is why AWS and others were able to fork Elastic and carry the torch forward on open source efforts. So the name might change… who cares? What matters is that the users had the freedom to take things into their own hands when circumstances demanded it.

This protection against potential future bad actors, even if those actors are us, is why we’re so big on permissive licenses and complementary commercial software. The license today isn’t a promise we make to the community. It’s a deliverable that you’ve already signed for and are in possession of. Obviously, with InfluxDB IOx, it’s not ready for use so at this point you’d need to believe that we’ll follow through with this. But since there’s nothing to yet to use (or lose), you can just sit back, eat popcorn and watch the show.