How we are building a self-sustaining open-source business in the cloud era (version 2)

Ajay Kulkarni -

Today, we are announcing an update to the Timescale License, which governs many of the advanced features of TimescaleDB, including native compression, multi-node, continuous aggregations, and more. This update loosens restrictions and provides expanded rights to users, reinforcing our commitment to our community.

Notably, this update adds the “right-to-repair”, the “right-to-improve”, and eliminates the paid enterprise tier and usage limits altogether (thus establishing that all of our software will be available for free). These changes will apply with TimescaleDB 2.0, which supports distributed hypertables for multi-node scale-out, slated for release next month.

Two years ago, we first announced how we were building a self-sustaining open-source business in the cloud era, and that we had started developing features under a new, source-available license called the Timescale License (TSL).

At the time, the TSL was a radical idea: a source-available license that was open-source in spirit, but that contained a main restriction: preventing companies from offering software licensed under the TSL via a hosted database-as-a-service. We added this restriction, which only applies to <0.0001% of all possible TimescaleDB users, to enable us to build a self-sustaining business in a world that was rapidly moving to the cloud. (And importantly, we did not and have never re-licensed any of our open-source software, which continues to be licensed under the Apache 2 license.)

The TSL, like the Elastic License before it, and like the Confluent Community License (coincidentally launched around the same time), are examples of what we call “Cloud Protection Licenses.” These licenses attempt to maintain an open-source spirit, but recognize that the cloud has increasingly become the dominant form of open-source commercialization. So these licenses protect the right of offering the software in the cloud for the main creator/maintainer of the project (who often contributes 99% of the R&D effort). This “cloud protection” is what enables open-source businesses like ours to become self-sustaining in the cloud era.

However, since these licenses are not officially sanctioned by the Open Source Initiative (OSI), whom many view as the arbiters as to what is and isn’t officially “Open-source”, these licenses are generally not considered “Open-source” (capital O) (although this sentiment may be shifting). At the same time, many developers still call these licenses “open-source” (lower-case o) because they embody the same open, transparent, collaborative spirit.

Two years later, this experiment has proved successful, exceeding our expectations. The Timescale community has continued to grow to over 500,000 active databases today. The TSL governs many of our new advanced features, including native compression, multi-node, and continuous aggregations, and adoption of these features has continued without friction. The public cloud providers have been deterred from offering these TSL features for free (and are now reaching out to discuss revenue sharing agreements). And other OSS entrepreneurs have reached out for advice on how to create similar licenses.

In fact, this experiment has gone so well that today, we are announcing an update to the TSL that reinforces our commitment to our community. This update loosens restrictions and provides expanded rights to users, including:

  • New: Right-to-repair
  • New: Right-to-improve
  • All enterprise features are now free
  • No more usage limits
  • Simplified legalese

These changes will go into place with TimescaleDB 2.0, slated for release next month.

In the rest of this post, we explain why we are making these changes, what this means for users, and why we think this is necessary for the open-source industry as a whole.

What is TimescaleDB?

TimescaleDB is the leading relational database for time-series data, engineered on top of PostgreSQL, offered via free software or as a fully-managed service on AWS, Azure, and GCP.

TimescaleDB offers massive scale (100s billions of rows and millions of inserts per second on a single server), 94%+ native compression, 10-100x faster queries than PostgreSQL, InfluxDB, Cassandra, and MongoDB – all while maintaining all of the reliability, ease-of-use, SQL interface, and overall goodness provided by PostgreSQL.

Initially launched in April 2017, TimescaleDB has come a long way in just 3.5 years, with tens of millions of downloads and over 500,000 active databases today. The TimescaleDB developer community today includes organizations like AppDynamics, Bosch, Cisco, Comcast, DigitalOcean, Fujitsu, IBM, Rackspace, Schneider Electric, Samsung, Siemens, Uber, Walmart, Warner Music, and thousands of others.

The growth of the Timescale Community is a clear sign that software developers need a new database to rely on for their time-series data, and that increasingly more and more are turning to TimescaleDB. But even with all this adoption, how does one build a sustainable business, particularly given the predatory actions of some public cloud providers?

Enter “Cloud Protection Licenses,” like the Timescale License.

What are “Cloud Protection Licenses”, and why are they necessary?

Not that long ago, the open-source business model was straightforward: companies run your software, and when they need help or advanced capabilities, they pay you for commercial support or enterprise features. This is the world in which today’s Open-source licenses were written.

But the world has changed. Today companies would rather pay someone to run your software, thus obviating the need for paid support (and making selling enterprise capabilities much harder). The standard Open-source licenses allow anyone to completely commercialize your software without contributing any software development.

In other words, the rise of the Cloud has cut off the primary business model for open-source software.

Enter new licenses like the Timescale License, Elastic License, Confluent Community License, and others. These licenses, which we call “Cloud Protection Licenses”, attempt to maintain an open-source spirit, but protect the right of offering the software in the cloud for the main creator and maintainer of the project.

This “cloud protection” is what enables open-source businesses like ours to become self-sustaining in the cloud era.

Some may ask, “Why create a new license - why not just compete with public clouds by just providing the best product experience on a level playing field?”

The problem is that the playing field is far from level. Today, the public cloud vendors (Amazon, Microsoft, Google) are trillion dollar corporations – the largest companies in the world – and have a myriad of advantages that arise from that size, including market position, pricing power, deep balance sheets, and (what many have even called) unfair business practices (source: Wall Street Journal articles from April 2020, September 2020). They lock large customers into prepaid, discounted, multi-year enterprise-wide agreements, and give startups $100,000s of free credits.

Yet even with hundreds of thousands of employees and tens of billions of dollars in cash, the public clouds did not develop TimescaleDB, the Elastic Stack, the Confluent Platform, and countless other open-source projects. These were built by independent teams dedicated to advancing state-of-the-art technology and serving developers worldwide.

This is David vs. Goliath. The Rebel Alliance vs. the Empire. Entrepreneurial teams taking on the largest corporations in the world with new, innovative technology. Cloud Protection Licenses foster more innovation, and enable the open-source underdogs to compete against the public cloud giants.

What did developers like and not like about the initial Timescale License?

Ever since we launched the TSL, the response from the community has been overwhelmingly positive. But over the years, the community has also provided really helpful feedback - via GitHub, Slack, Twitter, Hacker News, Reddit, email, etc. - which we have incorporated into this latest update.

Overall, an overwhelming majority has been supportive of the general direction of the TSL, understanding that offering a managed service is increasingly the primary commercialization approach for database and other infrastructure software providers:

“I think we're too hung up on OSI open source licenses. The additional restriction in the timescaledb license that you can't run a paid database as a service offering affects hardly anyone negatively (AWS). It affects us all positively by providing a sustainable business model to support additional development and support of an open-source product we use. Win-win if ever there was one. I'd like to see more open-source and closed-source companies consider this model.” (Source)

But we also heard some requests for liberalizing some of the terms of the Timescale License:

“One of the important reasons I personally use and support open-source is the freedom to not only inspect (which the TSL provides) but to also not have to ask someone else and wait on them to make any changes I need to the software I use. Any chance the TSL can be modified to include this freedom too?” (Source)

“I don't care if I can see the source code if I can't actually _do_ anything with it. If I can't run my modifications in production, it doesn't guard me against vendor lock-in and it doesn't give me the right-to-repair.” (Source)

We’ve listened to that feedback, and looked at where we are going as a company and how our direction lines up with our licensing. And, so we are pleased to announce changes that remove some restrictions of the TSL (and simplifies it in the process).

Giving more rights to users: right-to-repair and right-to-improve

Listening to our users and the general developer community, we are pleased to announce some changes to the Timescale License that loosen restrictions and provide expanded rights to users, reinforcing our commitment to our community.

To be perfectly clear: These changes solely give users additional rights in how they can use and distribute TimescaleDB in more scenarios; these changes do not further restrict any rights.

The two biggest rights we are adding are the “right-to-repair” and the “right-to-improve.”

First, users now have what some call the “right-to-repair” with TimescaleDB. If they encounter any issue or bug that they want fixed immediately, they can find, fix, and deploy a fix locally before it might be released upstream.

Second, users can now add additional features to TimescaleDB that might fit their own needs, and use their modified version for internal use, to build a SaaS service, or even when shipping code to users. Some call this the “right-to-improve.” Previously, they would need to upstream this change back to TimescaleDB before deploying into production. That also meant (as Hacker News readers pointed out) that proposed enhancements couldn’t be run and hardened in production before being submitted upstream.

Previously, we had included these restrictions with good intentions: we wanted to incentivize developers to contribute bug fixes and enhancements upstream, so that the software would be improved for everyone.

We also were concerned about the issues, uncertainty, and support burden that can arise from users running modified versions; we spend a significant amount of time helping answer questions for free in our large and active Slack community, which now numbers almost 5,000 members.

However, after hearing from the community, we’ve come to appreciate that the benefits of these rights outweigh their downsides.

👋 Goodbye to the enterprise tier (and going all-in on cloud)

There’s another big change we are making in the TSL: eliminating the enterprise tier altogether. This means that we are now making all of our software, everything licensed under Apache-2 and the TSL, available for free.

In the past, open-source businesses generally relied on commercial support and an enterprise tier (known as “open-core”) for commercialization. Timescale was no different.

But this year, we have increasingly focused on our managed cloud service as our primary commercialization strategy, and selling an enterprise edition of TimescaleDB for on-premise deployments (either on customers' own physical hardware or on their own cloud VMs) as our secondary commercialization strategy.

That fully-managed cloud service is now the industry-leading service for time-series data, running on all three major clouds and available in more than 75 regions. The growth of our cloud business has enabled us to make it the centerpiece of our business.

This has simplified a key question that every open-source company has historically wrestled with: which of our features should we “hold back” from our free version and keep in the paid enterprise tier?

Before, we would have difficult internal debates about new features: Release something to support our community and drive adoption? Or limit it to the enterprise tier to drive revenue?

Today we are going all-in on cloud, and removing any notion of paid enterprise capabilities from the Timescale License.

By going “all-in” on cloud, our choice becomes simpler: make all features available for free, so that we can invest in our community. Users can then either self-manage for free (including use our open-source k8s helm charts), or use our managed cloud.

But this easy choice – and our ability to “support our community” while preserving Timescale’s long-term viability –  exists precisely because we have the Timescale License, which restricts cloud vendors’ ability to offer TSL software unless they first establish a business relationship with us.

So with this thinking, earlier this summer, we moved most of our existing enterprise features into TimescaleDB’s free community tier. And with our upcoming TimescaleDB 2.0 release, we are moving the last enterprise features to the free community tier.

Our original Timescale License also allowed us to set potential “usage limits” on community features. The thinking was that, hypothetically, we might at some future time want to allow users to use multi-node TimescaleDB up to, say, 4 servers for free, but thereafter need an enterprise license.

This is similar to how many SaaS services “tier” consumption under different levels of plans. But these usage limits were always hypothetical: we never released a TimescaleDB feature with usage limits. And internally, we never really liked the idea that users’ internal consumption could “expand” to a level where they would no longer be able to use TimescaleDB for free (even though sized-based pricing is fairly common to databases in the enterprise).

So today, we are also removing any notion of community “usage limits” from the Timescale License.

The main restriction we have preserved: no TimescaleDB-as-a-service

What we have preserved, however, is the main restriction preventing other companies from offering TimescaleDB-as-a-Service in the cloud.

Along a similar vein, we also don’t allow parties to “fork and modify” the database and redistribute this forked version to others, which could serve as a way to try to circumvent licensing restrictions.

This concern isn’t hypothetical: Amazon, for example, has attempted to fork both the code and community of Elastic by releasing its own questionably-named “Open Distro for Elasticsearch” that re-implements some of Elastic’s key community features and licenses them instead as Apache-2 (while heavily monetizing these features as part of its managed Amazon Elasticsearch Service).

As we shared earlier, this restriction is the heart of Cloud Protection Licenses like the TSL, and is what enables further innovation.

Summary: What’s changing and isn’t changing

Let’s review the rights previously granted by the Timescale License, newly granted, expanded rights, and those that are still disallowed:

Note: To understand these changes, it’s important to understand the concept of “Value Added Service or Product”, which is a key part of the Timescale License (and can similarly be found in the Elastic License and Confluent Community License).  

The notion of a Value Added Service or Product is that you are building something of value on top of TimescaleDB and not just “reselling” it as part of a “database” or “database-as-a-service”.  (The formal legal definition can be found here.)

This Value Added Product or Service can certainly be commercial or proprietary; the TSL is in no way a “non-commercial” license. Many companies provide SaaS services using TimescaleDB as part of their service offering, or distribute commercial products embedding TimescaleDB. They just can’t purely offer “TimescaleDB-as-a-Service,” which is why cloud vendors like Amazon or Microsoft can’t and don’t offer the TSL parts of TimescaleDB as part of AWS RDS or Azure Postgres.

Definitions:

  • “utilize”: Offering code/product via a software-as-a-service
  • “distribute”: Shipping code/product via software
  • “Value Added Service or Product”: Something of value on top of TimescaleDB and not just “reselling” TimescaleDB as part of a “database” or “database-as-a-service”

Rights previously granted (and still allowed) under Timescale License

  • Right to run unmodified TimescaleDB for internal use
  • Right to utilize unmodified TimescaleDB to offer a Value Added Service
  • Right to distribute unmodified Source and Binaries as part of Value Added Product
  • Right to modify TimescaleDB for internal development and testing, and subsequently upstream modifications to Timescale

Rights newly granted (formerly disallowed) under Timescale License

  • Right to run modified TimescaleDB for internal use
  • Right to utilize modified TimescaleDB to offer a Value Added Service
  • Right to distribute modified Binaries as part of a Value Added Product
  • Right to distribute unmodified Source and Binaries, even if not as part of Value Added Product

Rights still disallowed under Timescale License

  • No right to utilize TimescaleDB for external use, unless as part of a Value Added Service
  • No right to distribute modified Source
  • No right to distribute modified Binaries, unless as part of a Value Added Product

What does this mean for me?

If you are a current or future user of TimescaleDB, these changes mean that you have more rights. But if you are looking to provide TimescaleDB-as-a-service, you are still restricted to only offering the Apache-2 edition.

In general, by refreshing the Timescale License and focusing on our cloud service, we can continue to invest in our community by releasing our best features to be completely free to use.

And now these features include distributed hypertables in TimescaleDB 2.0 for even greater scale. Beta users have already been running multi-node TimescaleDB in continuous daily use for many months, including a 22-server cluster by a Fortune 50 company ingesting more than a billion rows per day. We’ll be writing more about TimescaleDB 2.0 when it launches (soon!).

Today, you can deploy TimescaleDB on-premise or in your own cloud account, running the software on bare VMs or using our open-source k8s helm charts which automate high-availability/failover and continuous PITR backups. Totally free to use, and now free to even modify for your own use or for services or products you build on TimescaleDB.

Or, if you prefer, you can let us run TimescaleDB for you, fully managed on AWS, Azure, or GCP in 75+ regions and with access to a top-rated support team.

And, join our 5,000+ member Slack community for any questions, to learn more, and to meet like-minded developers – we’re active in all channels and here to help.