Temporal is an OSS platform designed to help developers build reliable and scalable applications by ensuring that their code can handle failures seamlessly. It provides a framework for creating durable workflows, which makes it possible for application logic to recover from crashes, retries, or interruptions without losing progress.

Temporal was created by Maxim Fateev and Samar Abbas as a fork of Cadence, which Fateev and Abbas had developed as engineers at Uber. Their motivation for creating Cadence was to address new challenges around availability and disaster recovery that developers were beginning to face with the rise of microservices and distributed systems.

They decided to build a company around their technology when they realized that the problem they were solving was bigger than any single company and that they were the ones who were most well-positioned to help other enterprises in solving it:

I think one thing worth mentioning is that we never were people thinking about starting a company. We actually didn’t discuss starting the company until we got the first VCs talking to us. We were just working on the project. We were trying to solve real problems. We were doing it as an open-source project. There was kind of an assumption that maybe it would become successful one day and something would come out of that. But the reality is that it was never like, “Okay, we need to build the company, let’s build something…” It was just solving real problems and trying to make the project successful. At some point, it became successful, and we started getting interest. Then we started to discuss that. And then initially we actually were hesitant because we had good jobs and both of us never managed a single person before starting the company. So we were just ICs, just engineers, and we had a good life at Uber building our project, but we just realized that the idea we had and the product we had was much larger than the company. So the full potential couldn’t be realized within any company just because obviously priorities are different. And then we decided that taking money was the option. And yes, I don’t think we had any doubts that the two of us should do it together. Let’s say even the open-source project wouldn’t be successful, I think, if both of us weren’t there.

They also saw the potential of open source in facilitating adoption of their solution and driving conversions to their revenue-generating cloud offering:

Our business model is that we have fully featured open source under a very permissive MIT license, and we don’t do open core. So, it means that there is no crippled open-source version and then an enterprise version. Our open source is fully featured. And the only way we monetize it is by hosting the backend component of that on the cloud. And we also promise our users that it’s fully compatible. So, if you are running our SDKs against the open-source version, you can switch a connection string, and within a few minutes, you can run it against our cloud. But we also promise if you run against our cloud, you can switch connection string and connect to the open source without changing a line of your code. So I think that keeps us honest because it means we cannot have features that will break compatibility. It’s pretty straightforward. We are innovating on scale. We are innovating on control plane. We are innovating on cloud features. But the core abstractions and how code runs and SDKs, they’re open source, and they’re compatible.

They hit a major milestone in the validation of their thesis when they recently closed a $146 million series C round at a $1.72 billion valuation.