Ajay Kulkarni, CEO, and Michael Freedman, CTO, are the co-founders of Timescale, a time-series SQL database optimized for fast analytics and complex queries. Timescale is deployed for mission-critical applications for organization’s in manufacturing, space, oil & gas, logistics, mining, finance, telecom and more. In this episode, Ajay and Michael discuss Timescale’s licensing and the evolution of open source.

Transcript

Intro

Michael Schwartz: Welcome back, Underdogs. This is Mike Schwartz, your pilot for episode 17. Your destination is an interview with the Founders of Timescale, a popular time-series database with a handy SQL interface.

In just 22 months, the database has over one million downloads, and the company has raised $27.4 million.

To keep things interesting, we’re having a little change in format. This week, we have two guests, Co-Founder Ajay Kulkarni, and Mike Friedman.

They might be a little hard to tell apart at first, Ajay is the CEO, and he does most of the talking initially, Mike is the CTO, a professor at Princeton, and his contribution is slightly more tacky.

Timescale has written a fantastic blog about building a self-sustaining business model in the year of cloud computing. I created a short link to it http://gluu.co/timescale.

But before you read that, let’s get to the podcast. So, without further ado, here we go.

What Is A Time-Series DB

Michael Schwartz: Ajay and Mike, welcome to the podcast.

Ajay Kulkarni: Thank you for having us.

Mike Friedman: Thanks for having us.

Michael Schwartz: Although this is a business podcast, in layman’s term, what is a time-series database, and what kind of applications is that good for?

Ajay Kulkarni: It’s a great question, and maybe, I’ll start by describing what is time-series data.

I think it’s technically defined as time-series data is a dataset where you are essentially measuring something over time, so, you know, every data point has a timestamp and a new measurement. Put another way, time-series data measures how things change over time.

Typical sources of time-series data, I think, historically, have been things like financial industry, where you have tech data with stocks and other commodities. And I think, more recently, you’ve seen time-series data converge from the DevOps market, where you have people measuring all types of systems, and workloads, and services, but I think one thing we found today is that time-series data has been emerging in more and more and places.

A lot of this is the rise of machine did an IoT. Broadly speaking, we now see time-series data measuring wheel and gas sensors, you see it in manufacturing, you see it in power plants, the logistics market is measuring time series over space and time.

Even in a consumer world, Uber or Lyft is collecting data points over time and space, that’s time-series data.

So, a long story short, time-series data is a niche workload that has, in the past few years, kind of exploded and become ubiquitous. Because of that change, you’ve seen the rise of time-series databases, which I think is your original question.

What we found with time-series databases is that, number one, time-series data, because you are collecting measurements over time, as you can imagine, the data piles up very quickly. And so, fairly soon, you get databases that are in the hundreds of millions or billions of rows, which leaves us to a certain scalability and performance challenge.

What time-series databases do, in general, is that they essentially optimize for this workload in a way that allowed you to get increased performance with much fewer resources. So, maybe your less disc, less RAM, smaller box, will get you further because they are optimized for this work.

Because of the growth of time-series data and the rise of time-series databases, time-series databases, in general, now have been the fastest-growing category of databases over the past 24 months.

A couple other things is that it’s not just performance, but time-series database has also introduced additional usability aspects that are useful for this workload. For example, special analytical queries and time-series data, and other things that traditional databases just weren’t designed to do.

Origin Of Timescale Company

Michael Schwartz: At what point did Timescale, the company, get started? Was it before, or after, or at the same time, as a community coalesced around the software?

Ajay Kulkarni: We have a funny story, which I actually think is not that uncommon.

Timescale, the company’s started in 2015, but, actually, under a different name and a different premise.

We started off building an IoT platform, and long story short, we were collecting a lot of time-series data from over a hundred thousand devices, and we needed time-series databases to store this data.

We used a few off the shelf items, and they didn’t really satisfy our needs, so the first version of time-series was actually something we built internally for our own needs. And, very quickly, the people who were using the platform, the people who we were describing the platform to, who were more interested in the database.

While it’s not the classic Kafka, Hadoop, Spark community model, there were quite a few people who were using and were interested in Timescale, the database, before the company officially became Timescale.

Mike Friedman: I think the interesting thing is, even some of those companies that Ajay mentioned, like Kafka and Confluent, it’s not unusual for these open source technologies to start inside a place, in that case it was a much larger LinkedIn, while for us, it was our own startup, but they were created because they were designed to scratch our own itch.

And the interesting thing about that, which I think we’re flexible on also how different, as technology from a lot of the other time-series databases, which came by, initially, narrowly focusing on something like DevOps, is that we were looking at this IoT setting, where you often had complex data, you wanted to make complex queries, you wanted to join the date, enriched the data with other business or metadata you had.

So, that let us down a path to build something for own needs, then, of course, it turns out that those needs are widely shared across many industries.

Ajay Kulkarni: What ended up happening, we ended repositioning the company and re-launching the Timescale early 2017. And, in the beginning, our only thinking was, ”Hey, this would be a great database for IoT,” because that’s where we came from.

And as soon as we launched, this funny moment, where a few weeks after we launched, we had more press on Timescale than we did in the last probably year of our IoT platform. And with this funny moment, we were like, “wow, this thing is actually way bigger than we thought, and it is even larger than IoT.”

That’s when we realized that there were few trends that were broader trends coalescing. One was the rise of time-series data, the other was the resurgence of SQL, as a query language.

When we launched it, and even today, we are the only time-series database that supports SQL. Number three was the resurgence of Postgres. And, in fact, Postgres, has been the fastest growing database over the past two years. And number two is Mongo, just to show you how fast Postgres is growing.

And the way Timescale is packaged is that we are actually engineered on top of Postgres, so we look and feel just like Postgres outside the world.

This intersection of time-series SQL Postgres and scalability, and we’re right at that intersection, and I think as a result, as soon as we launched, the response in the community was way larger than we had expected.

Community Contribution

Michael Schwartz: So, the community seems to really want to use Timescale, but how’s the community been in terms of contributions and feedback, and what value has the community added to the development process?

Mike Friedman: I think the community has been very valuable in a couple different ways.

One is, we actually post large slack community with around 2,000 people, and these are a lot of our most active users, who ask questions, help each other, help direct what future features are in one. So, community contributes in a couple different ways.

One is, as you point out, traditionally. Sometimes, that means development.

But, I think in many open source projects too, there’s a long process of getting community people doing a lot of core development, where, particularly towards the beginning, it’s more things, like, smaller features, bug fixes, whatever, but I think the value of a community is much more than that. It’s also people building you into reference architecture that others could use, people help developing and showing best practices, or deployments, and different scenarios.

Also, learning from what community needs to really help design a product and engineering a roadmap that fits the lens.

Ajay Kulkarni: We have essentially a public Slack channel, which is where I could check how our community lives. Right now, I think it’s the thousands of people, which is where we get product feedback, any bugs that they find, but also where the community helps each other in terms of onboarding and use cases, where they just want to say, “hey, who’s using Timescale for, let’s say netflow?” Someone else would jump and say, “oh, this is how we are using it.”

We think that’s great, it’s really showing, like, a collaborative community that kind of drives growth, in a way that we don’t need to be very forceful about it.

Mike Friedman: One more comment on that, you know, the interesting thing about Timescale as the technology is that it’s a very flexible, given the fact that partly related to what we really focus on providing what looks like full SQL length, and kind of full schemas, or even JSON, whatever, we could be used in a lot of different ways, as opposed to a lot of things that were nearly built for DevOps, or whatever, that we’re really super candid about how you should store your data.

And what that means for us then is that there’s many different settings in IoT, for example. The way you actually want to store your data or have a data model is different. For example, if you have 10,000 sensors of the same type, or you might have 50 different types of sensors, all collecting at the same time, or you have different locations, and you don’t want to actually connect the data. Or, you have lots of different things, which could be giving you different types of data in arbitrary fashion.

So, Timescale supports all of them, but you actually want to use a slightly different data model, depending upon huge heterogeneity, which could use it.

And that’s also where you find the community helping to develop best practices and help each other out as part of their journey.

License Design

Michael Schwartz: So, switching topics a little bit, Timescale has a really interesting licensing model, you have a core Apache 2 version of Timescale, you have your own Timescale license, which you call TSL. And within TSL, you have both free and commercial features. Can you explain a little bit about the rationale behind this license design?

Ajay Kulkarni: For sure, and just to be clear, it’s essentially one-code base, and in that code base, we have probably, at this point, 99% of the code is Apache 2. We’re just starting to add some TSL features, and nothing has been relicensed essentially. Originally, Apache 2 code is still Apache 2.

I think what’s interesting is that, when you’re developing a business project, you have to balance different needs. One thing is to balance the needs of people who are somewhat passionate, I would say, about open source licensing, and they really want an OSI-approved license.

But, also, there are folks, for example, in large enterprises, who don’t care as much about whether it’s OSI-approved, but they really just want to see the source code, and see what they’re running.

And as well as this whole user experience problem, which is, like, people want to be able to move from different versions, without downtime or migrating data. This is essentially what we are trying to balance with this new model, which we didn’t invent. It is similar to what, for example, Elastic has been doing. This code base has Apache 2. In fact, vast majorities are Apache 2, but there are also some TSL features, and some of the TSL features are free and some are commercial.

Essentially, we give people the choice, so we can say, “if you really want Apache 2 version, you can build that from source, or here’s a set of Apache 2 binaries that you can install.” And it’s great. Other folks can say, “hey, if what you really care about is free, but you’re not as, you know, maybe religious about open source, here is a free binary with Apache 2 and TSL features that could run, and then, you can even compile from that source.” And that’s great.

And then, the third folks are like, hey, if you are, say, a larger company and you have some really critical needs, for you, because of your type of business, you are not opposed to paying to open source, and in fact, maybe you like things from open source that gives you a general set of accountability that you wouldn’t have otherwise. It may be demagnification, and another features, here’s a commercial binary that you can pay for it.

I think what we should try to do with this licensing model is provide that flexibility, but have it all in the same repo so it’s all transparent. In other words, the same workflows you could use to see what open source features are down the pipeline, you can still use these features to see what enterprise you should have down the pipeline.

And this is our way to be more transparent and to engage the community more. And then, what we see now is people finally Github issues on proprietary features.

It’s kind of the behavior that we are trying to facilitate.

Enterprise Value Prop

Michael Schwartz: So, what’s the core value proposition for the enterprise part of the software?

Ajay Kulkarni: What we found is that some features that are useful to the broader community, from startups to large enterprises, a lot of those features include usability, ease of use, and performance. And those are either an open source or the free community tier.

But, there are some features that really become relevant when you’re deploying Timescale production, and those are the ones that are in the commercial offering.

A few examples of that are around data lifecycle management. If you are running a time-series workload at scale, overtime, you’ll have issues around maybe data retention, performance around trying to optimize resource utilization.

And, for these features, what we’ve done is, we’ve said, look, if all you want to do is use the database, it’s free. But if you want to be highly tuned and optimized in an automated fashion, well, you don’t have to be involved.

What’s typically that you will see is a large-scale production workload – that’s in the commercial version. The initial, commercial offering essentially boxes all that into automated data lifecycle management – that’s an enterprise tier.

Competitive Differentiation

Michael Schwartz: There must be other Timescale databases out there. How do you differentiate yourself from those offerings?

Ajay Kulkarni: Well, number one, there’s only one Timescale database, but there are multiple time-series databases out there.

The whole reason that Timescale exists is that when we were rebuilding our previous company, we tried to apply half a dozen of the existing time-series database there were already there, and it didn’t work. The main reason why it didn’t work for us was because we just wanted something that supported SQL in the relational data model.

And so, we built that, and when we built it, people thought we were crazy, it was kind of heretical to try to build a time-series database on a relational database and support full SQL, but we felt that that was important because SQL was easy to use, and we already knew it.

We found no reason to try to teach ourselves and our users a brand new language.

Number two, it was not only SQL well-known, but it’s the third most well-known language after JavaScript and HTML CSS, so there’s 14 millions developers today who know SQL.

Number three, we like SQL because it allowed us to use all the broad set of tools in the rich SQL ecosystem, from Tableau, and Power BI, Visualization, to Kafka and Spark for data pipelines.

When we launched it, and even today, we are the only time-series database that scales and supports SQL.

In fact, because we are built on top of Postgres, that means that, even though we launched only maybe 20-21 months ago, when we launched, we had the broadest and the largest ecosystem of any time-series database. And we are built on this rock solid Postgres engine, which has decades of liability working to it. The thing that users also found is that we were the most reliable time-series database as well.

DB As A Service?

Michael Schwartz: Do you offer hosted database-as-a-service version, or is that something you plan to offer in the future?

Ajay Kulkarni: We have something internally right now that’s in private beta, and we’ll have more news on a hosted version later this year. But, we’d fully recognize that a managed version of Timescale is one of the more requested features, if you will, or capabilities that people that are in communities were asking for, and that is one of our major focuses at the moment.

Michael Schwartz: Is anyone else hosting a TimescaleDB service right now?

Ajay Kulkarni: I think there may be a few folks in the PostgreSQL system that do that, but right now there’s no official Timescale sanctioned, managed cloud, but that will change in the next few months.

Saasquatting

Michael Schwartz: There’s this big conversation in the industry about what I call “saasquatter”, and you called open source strip mining, that is basically cloud providers who have economies of scale in hosting and operations, offering open source as a service – very well! And sometimes undermining the business models of the open source companies themselves and potentially reducing innovation.

How do you feel about that? Do you think that is positive or negative?

Ajay Kulkarni: I really like the way that Jay Kreps from Confluent framed it, which was, “cloud providers are acting in this way, and we actually don’t fault them for it.”

I think open source licenses today have been incredibly permissive and allowed for the behavior that they’re doing, and the behavior is, you’re taking, essentially, the R&D work by an external community and using that to fuel proprietary projects. I’m not casting a judgment on what they are doing, but that’s essentially what they are doing.

That said, I think this behavior is actually really dangerous for the future of open source in general, because what you essentially have is a bifurcation between the communities that are actually really innovating and driving the state-of-the-art, being separated from the companies who were able to gain from that innovation.

And, over a long-term, that’s not sustainable, because there’s communities and organizations that are actually developing open source software. If they can’t find sustainable business models, then, I think this whole thing falls apart.

What we’re trying to do is to say, “Look, we are not casting judgment on the cloud providers, we’re not even trying to redefine open source. What we are trying to say is, look, as an open source business, we’re trying to strike this balance between, yes, we really love the principles of open source, and we’re trying to preserve it, and we’re building a community, but we’re trying to do it in a way that allows us to build a sustainable business. Because, otherwise, Timescale will not be around in 5 years.

I think a community, the folks are really benefiting from TimescaleDB today, they really want Timescale to be around because it’s something that keeps rolling. In that way, I think we’re totally aligned, but I think this does require, I think, a shift in how we think about open source software. And I think some people are fine with it, and I think some people will need to adjust.

I think what we’re going through now is a transition in open source. That is not the first transition we’ve gone through.

I think in the mid-to-late ‘90s, when you had the rise of the OSI, a lot of the early open source folks at that point, with a free software foundation, called this OSI license is not open source because they weren’t free like the GPL.

So, there was a backlash then.

I think a similar backlash, maybe a decade ago, when open source companies started building out the open-core model, and they started having two rebuilds, one open source, and one closed. And even then people thought, “oh, if you are an open source business, you need to be doing 100% open source.”

And there was a backlash.

I think where we are today is that people accept that open source licenses don’t need to be as onerous as GPL. And people that accepted that were, “Hey, the open-core model is a totally acceptable open source business model. I think where we are today is another adjustment period, and I fully expect in 5 years people will say, “oh, yeah, here’s an open source company, they struck this balance, and we think that’s completely fine.

Mike Friedman: Just to clarify one thing that Ajay said. I think it’s important for us to recognize that we are keeping the vast majority of our code, licensed under Apache 2. What this differentiation, with certain capabilities that are then licensed into the Timescale license, or paid, is then saying, ultimately, if you want to find the best version of Timescale in the cloud, that will be provided by Timescale, the company.

Why Same Repo

Michael Schwartz: I like the way that you’ve done it too, because you don’t have two repositories. You actually have one repository, with a folder that has the TSL license code in it -can you talk a little bit about why you made the decision to structure it that way?

Mike Friedman: I think there is both, internal and external, reasons for doing that. What Ajay already described is, a lot of value that people get from, certainly value people attribute to open source due to its completely unrestricted for use and modification, but there’s also value that they actually see the code.

Famous quote that “many eyes make all bugs shallow.” And the idea of this is that when this code is all available, even if some of it is not under an OSI-approved license, that means developers could always see the code that they’re actually running themselves, could become confident of it.

And if they happen to ever run into performance issues, or perhaps bugs, but of course, that never happened, is that they can actually see the code and try to deal with themselves, and ultimately, make contributions, carry on their typical developer flows with GitHub and GitHub issues, and tracking as they normally would.

We think there’s a lot of value from an external perspective, but what it also allows us to do is kind of create this continuum of how people could consume the software in their own production. So, for example, typically, if you’d, let’s say upgrade, from an open source or community to a paid version, you’d have to download a new piece of software, reinstall it, migrate your data, and so forth.

And the way we developed it, effectively, if you have the community installed, for example, you just need to basically enter license key that nearly unlocks all of the paid features. And, similarly, actually, deep down internally, there’s actually a slightly different binary between the pure open source and the community, and this allows you to upgrade or downgrade, without any concern for your production workloads.

But, internally, this actually also then ensures that because everything’s one repo, don’t ultimately have this divergence between what is the open source version of it and the closed force.

For many companies, when you actually have your open core, the additional thing is closed source, you have to spend all this effort of moving various patches back and forth between the two versions.

And overtime, you find that the features and capabilities, between the open source version and the closed-source version, start to diverge.
And this kind of avoids that issue, and it also leads to a lot more transparent software engineering, for both reasons that are, external to community contributors, as well as internal to our own software developers.

Mixed Bits

Michael Schwartz: Have you gotten any pushback from customers? At Gluu, we once had a customer who didn’t want any AGPL code on their system at all, and we ended up repackaging one of the AGPL components from Gluu as a post-insulation download.

Mike Friedman: People often ask us, “well, if you want to go this approach, or, you know, if you’re worried about, let’s say, the cloud providers – why not just make it GPL?”

And the answer is GPL is restrictive in other ways.

We thought it was important for many large corporations, many of which, big enterprises sometimes are resistant to GPL, to allow it to be really frictionless in their adoption of the open source, the Apache 2 version of Timescale.

Now, regarding this question of the kind of type of license key, can you accidentally use things, I just want to be clear in two ways, just to avoid maybe if there’s any confusion.

First of all is, that the way we’ve designed it, and we thought about this carefully, we really want to make it so that people couldn’t accidentally be violating a license. And this is why we actually have a license key in the first place.

We could have, for example, just said that the certain features are commercially available, but there’s no actually technical restrictions to them. And then what happens is larger organizations could download it, people across organizations could start using it, and then, they run the risk of that they, accidentally, because not everybody understood the terms, started violating the license.

So, we really wanted to keep that line between, you can never run the risk of violating it through accident, not understanding the terms of it, and so there has to be an explicit action in order to
unlock these additional features.

Now, with the use of the community, it really turns out that the main things that community restricts are really just a narrow scenario, which basically says, “if you are a cloud provider, where the only thing you’re doing is offering a hosted database-as-a-service.” Or, if you are OEM, and you’re kind of shipping to the edge, and the only thing you’re doing is offering the databases that you’re providing the other value. That’s the only thing that really the Timescale license restricts from.

For many companies, even SaaS companies, and in that sense, we’re, actually, I think more restrictive than some of the other recent licenses that also come out.

For many SaaS companies, this is not an issue. If you’re on-premise, this is not an issue, if you on the edge, it’s not an issue.

You’re really just an issue if you’re looking to deploy Timescale hosted as a service, for the community edition. And there’s often a very little confusion with companies, you know, are they a hosted database provider.

Transition To License

Michael Schwartz: Switching the tracks a little bit, currently, the both of your revenues are generated from support, and it sounds like you’re trying to move to sale of license. Has that process started yet, and how’s it going?

Ajay Kulkarni: It has started, and I would say it’s going pretty smoothly. I think what’s interesting is that, maybe some companies who restrict open source policy, and they only want to use the Apache 2 binary, I think for folks like that, we have a support and services package in place that makes complete sense.

And there are others who are completely comfortable with the idea of a commercial license, of the transition from open source commercial license. That’s where we can bundle in some of these enterprise features, as well as instill support and services.

I think what we essentially offer to people is a choice on what they want.

I think the key thing is that businesses see value from Timescale, they want to make sure that, number one, that they have an insurance policy in place for the production workloads, but some of them also want to make sure that they have all the bells and whistles and the best possible version of Timescale in place. And that’s worth the commercial licensing.

Partners

Michael Schwartz: I know it’s a relatively new company, have you developed partner channels? And if not, have you thought about what type of partner relationships will be important to you in the future?

Ajay Kulkarni: Number one, despite being a young company, I think we emerged with already a pretty large community ecosystem, thanks to Postgres, and we were able to have partnerships conversations a lot earlier than what we would expect.

For example, late last year, we announced collaboration with the Grafana, the Visualization, where we authored the SQL/ Postgres connected to Grafana. And, even last week, Zabbix, which is a kind of a monitoring tool announced support for Timescale.

One thing that we are finding is, with the rise of time-series data and the ubiquity of Postgres, there’s already this latent demand for folks who want to partner, to provide the best time-series SQL experience to their users.

That said, there’s a lot things that we could be doing, there will be more that we’ll be announcing this year, but, in general, if you’re someone in the ecosystem, or if you’re like an SI, or a consulting firm, and you see the value of time-series in SQL, then, I think we’re trying to be the best partner that you can work with.

Mike Friedman: And I think along the lines, the point of PostgreSQL system is that there’s already a huge installed base, but also a huge ecosystem around Postgres, both in terms of size, and consultants, and service providers, and whatnot.

So, what we find is that many of them have customers and clients that have time-series needs, and as Ajay pointed out, more and more people are figuring out that many forms of data, and we’d like to say, all data is time-series, they want to start using understanding it better. The fact that Timescale is so well integrated and compatible with Postgres, means that there’s a natural way that they could take some of their own existing data infrastructure that they know and love, and now get all these new capabilities for time-series data with it.

Thoughts About RedHat

Michael Schwartz: So, this question is sort of from Leftfield, IBM just announced recently an acquisition of Red Hat. What do you think that means for the industry?

Ajay Kulkarni: I think Red Hat’s acquisition by IBM is incredibly validating for open source, and it’s not the first validation. In fact, another major validation was last year, when Microsoft acquired GitHub. And I found that, probably even more remarkable, given all the history Microsoft being combative to open source.

But I think now what you find with that acquisition, and now with Red Hat by IBM, is that open source is really validated as a viable software development distribution and business model.

In the past, I think people had thought, “oh, open source, it’s just free, it’s the cheap product.” And maybe that’s where things started, but what we found now is that the value of the open source is more than free. In fact, it’s often the leading technologies, the best technologies are open source, so it’s a real shift.

I think what we’ll see over the next few years is that we’ll find even more open source success stories, for example, in the form of multibillion-dollar sustainable businesses.

Mike Friedman: I also think it shows one more thing in that, sometimes people refer to the open source business model, but I think it’s important to distinguish that there are, in fact, multiple different open source business models. And this often leads to the nature of the different type of open source companies.

Red Hat, part of what they were doing from the beginning was putting together and packaging and incredibly complex ecosystem that was your operating system distribution, then ultimately, building services on top of that.

If you have other types of open source businesses like Cloudera and Hortonworks, who
are bringing together many different types of open source tools, and types of infrastructure, then delivering them as part of a broader solution.

On the flip side, you also have type of open source companies, like, Mongo, and Elastic, and Confluent, and us, who are the major contributors behind each of their technologies, but are bringing a more purpose-built type of software infrastructure from the market, as opposed to accumulating.
So, all these are actually different forms of businesses, but they all have something similar. I think they’re going to take slightly different paths and see different reactions from the market.

When Software Should Be Open Source?

Michael Schwartz: Is there a certain type of software that you think lends itself to open source?

Mike Friedman: One thing that has happened is people move from thinking that only proprietary and closed-source software was sufficiently enterprise-ready, to thinking that if you’re running low-level software infrastructure, it almost de facto has to be open source.

And part of that transition is related to the notion of ultimately want to see and trust the code that you’re running. Open source gives people confidence of that.

You want to have a viable path to self-run it, if, for whatever reason, you don’t want to allow other companies to really control your destiny. So, the fact is that open source gives you confidence in that.

And I think there’s an increasing belief that the community contributes and, again, this notion of “many eyes makes bugs shallows”, that in the end, we could deliver high-quality code that fits a lot of different use cases by being open source.

Advice For Entrepreneurs?

Michael Schwartz: The last question: Any advice for new entrepreneurs, who want to start a business that is developing open source software?

Ajay Kulkarni: My number one piece of advice would be to scratch your own itch.

One thing I’ve learned through this experience and through past companies as well, is that building a company is really hard, and I think it’s harder than, say, the tech media, and Twitter and Linkedin make it seem, because it’s obvious there’s a lot of selection bias in the press. And it’s hard, not just because you need product-market fit, but you also need the market fit.

You essentially need all the stars to align that the world needs something, and that you’re the right people to build it.

I think it’s really hard to artificially create that, and so, I think the best way is, just scratch your own itch. If there’s something that’s missing in the market, and that you have a really strong burning need to build, and you feel confident that you could be the best person to build this, then build it. And then, get more people involved, and get feedback, and let it snowball from there.

That’s probably step one of a very long journey, and then we’re still, I would say, really early in that journey. But I think, for people starting off, I think that’s a piece of advice I would give.

Mike Friedman: Yes, I think a lot of what Ajay said was correct, and something that we think about a lot and have talked about in the past that, ultimately, I think why this interesting move, as we talked about was, we initially were building Opti Platform.

One of that, as we saw, and we are familiar with this feature, with lots of devices sending data, and, in fact, some of our background – I probably know, I’m also a professor of Computer Science at Princeton – and a lot of our other early engineering team were former Ph.D. and postdocs. We have a lot of experience, a lot of this very high-skill distributed data, but that gave us kind of unique experiences about – especially when we were operating on this platform – about what you need, and how you want to use it.

For example, some of the pains we felt was that, when we’re initially using some of these NoSQL time-series database, we couldn’t do the type of queries you want to answer questions for customers. What we realized was that if we wanted to ask something new, we had to do this application space, and you are like, well, I need to get this engineering sprint, I can’t deploy. If someone wants to ask a simple query, it’s going to be a month before I could deploy new capabilities.

And so, when you start feeling that pain yourself, it really helps to wreck you on a certain roadmap that allows you to ultimately build a highly useful product. I think that sometimes people go after markets because they say, “okay, I’m going to do this very hands-off calculations about market opportunities, and business forecasting, and go into intellectually drive, where there’s value.

Maybe, one could be successful that way, but I think you need to deeply understand your user, and how your user will be consuming your technology. And often, that’s because, in the past, you’ve had to be that user yourself.

Michael Schwartz: Congratulations on the success of the company. Thank you for all your hard work, and thank you for being on the podcast.

Ajay Kulkarni: Thank you so much for having us.

Mike Friedman: Thanks for your time.

Credits

Michael Schwartz: And thank you to the Timescale team for arranging this interview.

Transcription and episode audio can be found on opensourceunderdogs.com.

Music from Broke For Free by Chris Zabriskie and Lee Rosevere.

Production assistance and transcription by Natalie Lowe.

Operational support from William Lowe.

Follow us on Twitter, our handle is @fosspodcast.

Next week, we’re interviewing a legend of open source Martin do Giannis, Founder and CEO of Moodle, the world’s leading open source learning management.

Until then, thanks for listening, and have a pleasant journey.