How we are building a self-sustaining open-source business in the cloud era

Today, we are announcing that we have started developing new open-code (or source-available) features that will be made available under the (also new) Timescale License (TSL). You will be able to follow the development of these features on our GitHub.

Some of these new features (“community features”) will be free (i.e., available at no charge) for all users except for the <0.0001% who just offer a hosted “database-as-a-service” version of TimescaleDB. Other features will require a commercial relationship with TimescaleDB to unlock and use for everyone (“enterprise features”). And to be clear, we will also continue to invest in the core of TimescaleDB, which will remain open-source under the Apache 2 license.

Going forward, all new features will be categorized into one of the three following buckets: open-source, community, and enterprise.

Software licenses like the TSL are the new reality for open-source businesses like Timescale. This is because the migration of software workloads to the cloud has changed the open-source software industry. Public clouds currently dominate the space, enabling some of them to treat open-source communities and businesses as free R&D for their own proprietary services.

While this behavior (also known as “strip mining”) is legally permissible within the boundaries of classic open-source licenses, we believe it is not good for the open-source community because it is not sustainable. It makes it impossible to build the independent businesses required to support large-scale open-source projects (without being tied to the whims of a large corporate sponsor with varied interests). We ultimately believe that a self-sustaining business builds better open-source software.

(The new Confluent Community License is another example of an open-source business enacting a new license to counteract strip mining by some of the public clouds.)

In this post we explain what we are doing to address this challenge. We also explain what this might mean for you, an existing or potential TimescaleDB user.

[More detailed questions can also be found in the FAQ below.]

What is TimescaleDB?

TimescaleDB is an open-source time-series database that scales and supports full SQL.

Two years ago, we started working on TimescaleDB to scratch our own itch. We were building another business (an IoT data platform) and were unhappy with many of the existing open-source options: We wanted a time-series database that scaled, yet also supported SQL and the relational data model. We also needed something more reliable than any of the existing time-series databases.

Turns out we weren’t the only ones with this itch. In the 20 months since we launched, the response to TimescaleDB has far surpassed what we expected, with over 1 million downloads, 6,000+ GitHub stars, and mission-critical deployments worldwide. In an industry crowded with database options, TimescaleDB remains unique in offering both SQL and scale for time-series data. In fact, AWS has told us that TimescaleDB is the most requested extension on Amazon RDS. And it’s public knowledge that TimescaleDB is the most requested feature on Azure PostgreSQL.

But today, we face a new challenge: how do we translate all this open-source adoption into a commercially sustainable business?

Can open source be sustainable?

We’d like to be clear: we are strong advocates of open-source software. Open-source software is transparent, flexible, and produces higher-quality code. At its core, TimescaleDB relies fundamentally on open-source PostgreSQL.

Open-source software also builds communities. So many of the building blocks of computing, from programming languages to the Internet, developed because of collaborative communities sharing knowledge across the industry. Collaborative communities build better things.

But open source also introduces its own challenges for long-term sustainability. Many OSS projects start from within and are nurtured by much larger corporations, or develop as community projects relying on external sponsors or foundations for financial support. These backers can be fickle. And building complex software infrastructure requires top-notch engineers, sustained effort, and significant investment.

So to develop a large-scale, technically-complex project and ensure long-term sustainability, Timescale is not only an open-source database project, but also a company.

What options do open-source companies have to make money?

Open-source companies typically sustain themselves financially in three main ways: support, hosting, and open-core licensing. (We’ve written a deeper analysis of these models here.)

We don’t love the support model long-term, even though it accounts for nearly all of our revenue today. Only selling support creates perverse incentives for an open-source company, where making the product easier to use cannibalizes support revenue. Further, the need for support significantly diminishes as workloads migrate to hosted services, including those offered by third-party cloud providers.

We like the hosting model, which also provides a great user experience. But hosting alone has two limitations. First, with a large number of TimescaleDB deployments on premise and at the edge (including deployments ranging from $35 Raspberry Pi’s to monitoring $10 million Cray Supercomputers), hosting can only be part of our answer. Second, the major cloud providers threaten to capture most of the hosted workloads, potentially leaving little for open-source companies.

We also like open-core licensing, but not how it’s often implemented: part open-source, part proprietary closed source. As OSS users ourselves, we don’t like using black-box infrastructure software that we can’t peer into. And as OSS developers, we find that the process of managing two different parallel code repositories is slow, frustrating, and brittle.

TimescaleDB’s approach to long-term sustainability

We’re placing a new emphasis on the long-term sustainability of TimescaleDB, while still addressing the needs and wants of our community. We’ve consulted with our free users, paid customers, advisors, and other industry experts on our approach in order to develop what we believe to be the best path forward for us.

Our existing code will continue to be licensed under the open-source Apache 2 license, and many more OSS-licensed capabilities are in development. But, we also will soon be releasing new “proprietary” features under an open-core model.

Many of these new so-called “proprietary” capabilities can be used for free, with only some more enterprise-relevant capabilities requiring a paid license key to unlock and use. So for that vast 99.9999% of users — just not those cloud providers — a significant portion of the “proprietary” features in TimescaleDB will be both open code and free-to-use at no charge. We view our free “community” features as our way of giving back to the community while protecting against cloud providers.

In the spirit of openness and to solve the “black box code” problem, we are building both our open-source and “proprietary” software in the same repository, and then making the source code for the entire repo available. That is, the entire repository will be “open code” (or “source available”), just not all licensed under an OSI-approved open-source license. This allows TimescaleDB users to inspect, comment, file issues, and contribute on open-code features using the same GitHub workflows they’d normally use for our open-source features. Because we’ll maintain a clean directory structure and build processes between open-source and open-code bits, users can choose to build and use either licensed version.

What is the Timescale License (TSL)?

Up until now, everything released in our GitHub has been licensed under the Apache 2 open-source license. Today we are announcing that some upcoming features will be licensed under the new Timescale License (TSL).

Going forward, our GitHub repo will have both Apache 2 source code and TSL source code (but the latter isolated in a separate subdirectory). An open-source binary only includes Apache 2 code and is covered by the Apache 2 license, while a TSL binary includes both TSL and Apache 2 code and is covered by the Timescale License. All source code is open and public, and anybody can contribute. (But the TSL is not an open-source license, as per the definition by the OSI.)

This structure allows us to define three tiers of software features:

1. Open-source features (free): Will continue to be licensed under the Apache 2 License. Going forward, we will continue investing in our open source core to add features and improve performance and usability.
2. Community features (free): Will be licensed under the TSL, but will be made available at no charge. There are two exceptions that are prohibited from using these features (without a commercial agreement): (1) cloud and SaaS providers who just offer a hosted “database-as-a-service” version of TimescaleDB, and (2) OEMs that don’t provide any other value on top of the database. This tier enables us to continue to provide free features to and invest in our community, while protecting from open-source strip mining.
3. Enterprise features (paid): Will require a paid relationship to use these features. In particular, a license key will be required to unlock these capabilities, even though no software upgrade or even restart will be required to upgrade from the Community tier. This tier enables us to generate revenue and become more self-sustaining.

For those interested in the nitty gritty of software licensing, you can find the new Timescale License in our GitHub repository.

Stay tuned for an upcoming release of our first community and enterprise features, which will include better data lifecycle management and automation through our new background scheduler framework. You can see their development all in the open, right in our public GitHub.

Explaining the nuances of the TSL

For those who’d like to learn more, we thought we’d spend a few more words explaining our motivations behind the nuances of the TSL.

In general, in our license we have attempted to clearly define the rights that are granted, and to protect users from accidentally violating the license. We’re not looking to be in the business of auditing companies for license compliance.

For example:

• By requiring a valid license key for using enterprise features, we explicitly protect users from accidentally using those features (and thus accidentally violating the license). Our users at larger companies, where it can be harder to monitor all TimescaleDB usage, have in particular asked for this kind of protection. Instead of providing accidental access to enterprise features, our license key checks will either raise warnings or refuse access, as appropriate.
• The TSL allows (and encourages) Value Added Products and Services, which we explicitly define by the interfaces to the database offered to end users. In other words, OEMs or SaaS providers can certainly allow their end users to query or write to the database (commonly known as DML operations), but the TSL prohibits them from allowing their end users to redefine or modify the underlying database structure or schema (e.g., through a DDL interface). Put another way, if someone were to offer both DML and DDL interfaces, they would effectively be providing a TimescaleDB database-as-a-service. We encourage you to reach out about your specific use case if you have questions.

Questions or feedback?

As mentioned above, we’ve made this decision carefully, soliciting feedback from our free users, paid customers, advisors, and other industry experts.

If anyone has any questions, we’re available. Please feel free to email us at licensing@timescale.com, or join the #timescale-license channel on our community Slack.

FAQ

Are you re-licensing your existing code base under the TSL?

No. Our existing code base will remain open-source under the Apache 2 license.

This model feels new to me. How should I be thinking about it?

We are following an open-core model, which is an existing practice within open-source. The core of TimescaleDB (our existing code base as well as any new open-source features we develop) will remain licensed under Apache 2. The change is that there is now a new folder (/tsl) that will soon have new code licensed under TSL. You can choose to exclude that folder if you’d like (it’s an easy flag in our build process). Put another way: instead of placing our non-open-source bits under a closed proprietary license, we’re placing them under a source-available license (TSL), so you can see the code.

Is the TSL an open-source license?

No, the TSL is not an open-source license, as per the definition by the OSI.

Why not just use a proprietary closed-source license?

We believe that a source-available license has significant benefits to both users and developers. It allows TimescaleDB users to inspect, comment, file issues, and contribute on open-code features using the same Github workflows they’d normally use for open-source features. It also allows TimescaleDB developers to be able to maintain all code in a single repo, instead of needing to maintain two different parallel repositories (which slows down development time and leads to a more brittle code base).

I’m looking to use TimescaleDB inside my company. How do I know if I’m in compliance with the TSL?

Unless you buy a license key, you are only using the Community Features, which are free to use for all internal use cases.

I’m looking to build a service or product around TimescaleDB for my customers. How do I know if I’m in compliance with the TSL?

Unless you buy a license key, you are only using Community Features, which are free to use unless you’re doing something like just offering TimescaleDB-as-a-Service.

Are there any other open-source businesses following a similar model?

Yes. You can see a very similar three-tier hybrid structure in the Elastic License, as well as a hybrid OSS/commercial structure in the CockroachDB License.