Michael Schwartz

Episode 22: Puppet – DevOps, Security, and Cloud Automation with Luke Kanies

Luke Kanies is the Founder of Puppet, an open source tool for software configuration management. In this episode, Luke discusses the fundamental challenges of starting, building and running an open source software business.


Michael Schwartz: Welcome back to Open Source Underdogs, the podcast where we interview the founders of pure play open source software companies, and hopefully illuminate the business models that power their success.

If you’re not familiar with the Puppet platform, it helped define the market for configuration management as code. They’re also one of the pioneers of the second generation of open source companies, i.e., the company was founded after Red Hat.

Luke Kanies is the founder of Puppet. After serving as CEO for many years, he was elected to lead the board of directors as chairman. He’s working on a new startup, which he talks about in this podcast, and he’s helping entrepreneurs in an advisory capacity.

It was a great honor to interview, Luke. So without further ado, let’s cut to the tape.

Luke, thank you so much for joining us today.

Luke Kanies: Thank you for having me, Mike.


Michael Schwartz: Can you tell us a little bit about how Puppet got started?

Luke Kanies: Yeah. I think there is only the long version of the story.

I started Puppet around 2005, but I had begun doing the arguing, and research, and community discussions as early as 2002/3. But it was by 2005 that I kind of run out of other options.

I spent some time doing consulting and working at another company, trying to convince other people who had already had the technology that they should build a company. And by 2005, I both had run out of other options for myself to do as a means of making money, and it also concluded that none of the other more obvious people to start a business in the space we were going to.

So, the person who was running the CFEngine was going to start a company, and the person running the config wasn’t going to start the company. So, I basically said “well, if no one else is going to do it.”

There’s this old saying about “if you look around a poker table and you don’t know who the sucker is – it’s you.”

One time I was at the event, I looked around the table, and I couldn’t figure out who the entrepreneur was, so I said “well, I guess it’s me.”

So, I just quit a job making six figures, and didn’t know what else I was going to do. I sat down and I took the prototype that I built last summer, and started building a product around it.

Within about ten months, I had our first paying customer, and bootstrap for four and a half years, so we are run and profitable from about year on, and went from there.


Michael Schwartz: How many initial partners were there in Puppet Inc.?

Luke Kanies: Just me.

There are two other people who I gave the title of Co-Founder when they joined the company three and a half years later. But by then, we already had a complete product, we had a customer base, we were making multiple hundreds of thousands of large revenue.

I was able to pay them their previous salary when they joined the company, whereas I went without salary for ten months, and I went for two more years, paying myself less than half of what I had been paid previously.

By the time they joined the company, I was desperate, I was expecting twins any day now, so I was in a really, really tough shape. I think they both did good work for the company, but I would say that they were much more employees number 1 and 2, and I just called them founders because I was not making high-quality decisions about titles and things at the time.

Existing Community

Michael Schwartz: The point you started Puppet, there was actually no existing community around Puppet, you started it from scratch.

Luke Kanies: Yeah, that’s one of those rare cases where I started the company and the product about at the same time.

And I, from day one with Puppet, knew that I wanted a company around it.

At the time, we had this community at LISA. So, LISA is this system administration conference, it’s been there for a long time, and there was this smaller config management community within LISA. And I remember at the conference, we did these all-day workshops, and they’ve got maybe about 20 people.

I did a poll, “how many people here have written their own product, their own piece of technology, their own config management tool?” And nearly everyone in the room raised their hands. And then I said, “of all those tools, keep your hand up – is anybody outside of your organization still using it?” And Mark Burgess, who started CFEngine, he was the only one who kept to stand up.

There were already a bunch of other projects out there that existed, were in use, but really weren’t in use by anybody else.

And so, the challenge wasn’t can I build a piece of technology? The challenge was – can I build a piece of technology, specifically with the goal for other people to use it?

And from my perspective, the only way to do that was to say “my ability to eat is depending on your liking my product.” And if I can’t sell something to you, if I can’t build a business around this, then the product is not good enough.

That’s essentially what I focused on, and that’s why it slides in my presentation from 2006. I said, look, if it’s not good enough, I don’t deserve to eat. And that kept me focused on building something people would love, not just building something that I liked.

Initial Revenue Streams

Michael Schwartz: How did you initially monetize? Because that’s a lot of pressure to put on yourself, especially with an open source product. What was the initial monetization strategy?

Luke Kanies: Services. And, thankfully, in a lot of ways it was straightforward, because I had spent almost two years as a consultant before I started Puppet. Well, six months I spent in BladeLogin in-between. I spent almost two years as a consultant, and I mostly focused on doing CFEngine work.

I did two kinds of work with CFEngine. One was, I did training.

So, I would design a CFEngine training class, and had 20 people meet me somewhere – I don’t remember where it was – oh, I know. I flew out to Los Alamos National Labs and taught a class there. I remember I got paid $19,000 in a week for that. Of course, I did a ton of work in prep for that, so it wasn’t a week of work but it was a week on site.

I’ve also done a couple of essentially implementation projects, where I go in, and it’s about 50/50. At the end of the week, you’re going to have a running functional implementation and also at least one person who is highly trained in implementation.

When I started Puppet, I took that same basic model. We’re going to do training classes that cost about $2,000 per person, and we’re going to do like group trainings, and then we’re going to do on-site trainings, where you can pay for the entire company. You can pay for some people, it’s a fixed price for that group. And then, we are going to do implementations. The business model was already in place, built around the project.

When I started Puppet, I basically said, “I don’t know how this works.” I didn’t know how to negotiate pricing, I didn’t know how to think about value. I would just roll those same basic concepts, and do what we do at Puppet.

Ironically, if you look at our average sale price, ten years after I started those services, our average sale price for a downloadable installable software was within a couple of grand of my week-long services engagement that I started in 2005-2006.

So, I did a pretty good job of landing on a reasonable price point and getting to the point where I knew what I was doing, and how I was doing it, why I was doing it, and how much I could charge for it.

And then just for the next ten years, figuring out what else do I need to add to make it work, and how can I provide a better product, and then overtime, how to go from the first installation as $20,000, to a million-dollar installation, and then a ten-million dollar installation.

Initial Bootstrap Phase

Michael Schwartz: We’ll drill down a little bit more on the revenue stream business model stuff later, but I’m still interested in the startup phase. So, did you say it was four years until you actually raised the first round of money for Puppet?

Luke Kanies: Yeah, we were running profitable from 2006 to 2009.

I brought Andrew Shaffer in, Teo in 2008. We got offered a round of funding that year, but it was contingent on me stepping down as CEO, and there were some other things that we didn’t love about the round, so we turned down that term sheet.

I pitched to a few other investors before, not officially pitched but had conversations with. I had found investors who I would have taken money from, and I found investors who probably would have given me money, but I never found investors who were both of those things, who wanted to give me money and whom I would have taken it from.

In 2009, Puneet Agarwal from True Ventures tracked me down at an event, he said, “hey, we’ve been following you, we would like to give you money.” And I said, “well, that doesn’t sound right.”

Most investors, when they say, “we are interested in you,” say, “we should talk again.” And Puneet said – “we should talk again… On Monday.”

On one hand, I was interested in the things that come with raising money, but I’d been at a startup that had gone bankrupt because it raised too much money, and the investors brought in the wrong managers and all kinds of stuff – that was a more complicated picture because of market timing and stuff.

I had seen plenty of the bad examples, and so I was very skeptical. True Ventures was able to convince me that they were going to be a really good partner, and that they weren’t going to make a lot of the short-sighted anti-founder decisions that investors were famous for.

Overall, they’ve been a great partner. We got our first round in 2009, almost four years after Puppet started.

Startup Leadership Challenges

Michael Schwartz: Can you talk about some of the leadership challenges during those initial four years?

Luke Kanies: I mean, there weren’t any because I was the only employer, so essentially, I was the one out there doing all the work.

I was the only person there. I was trying to build a community, I was trying to build a product, and I was trying to build a business – all at the same time.

It’s worth noting, like, I wasn’t the developer when I started Puppet. I had written some small scripts before that, probably 2000-line Perl script before Puppet.

I have never written a line of Ruby until I wrote the prototype for Puppet. And I had never shipped software that anybody else has ever used, when I started Puppet.

So, in addition to trying to figure out how to be an entrepreneur, how to deliver services, and how to sell, I was also trying to figure out how to become a programmer, and how to ship software that doesn’t break, and stuff like that. So that was pretty much just me the whole time.

I did bring in Teo and Andy towards the end of that bootstrapping period, but in the end, by then, most of the questions you needed to ask in business, to figure out that we have a real business here, those questions were already answered.

And the rest of the questions to figure out, essentially, “how do we take what we have and scale it up, how to get the most out of it? How do we turn this from a one-person operation into a functional organization?”

Those kind of traditional scaling questions that I think are super, super important but are really, really different from “what problem are we trying to solve, how do we solve it, how we deliver it.”

Those questions were pretty much solved before I had my first employee.

When to Use Open Source?

Michael Schwartz: When do you think it’s appropriate to use open source as a development methodology, and when do you think you should patent and license your software?

Luke Kanies: That’s an impossible question to answer in the abstract.

It’s worth saying something. It’s not that I don’t believe in patents. For me, I would say patenting and licensing are orthogonal. I could totally see you licensing software that you don’t patent.

I will personally probably never bother to patent software – I’m not saying I absolutely won’t – but in software, I think patenting is primarily an anti-competitive mechanism for suing smaller players into oblivion, rather than the actual mechanism for publishing innovations.

I think it’s mostly the fault of the courts, that have just allowed pretty bad patent behaviors. Maybe someday software patents will be useful, I just don’t see that right now.

In terms of licensing versus open source, I don’t think you can answer that in the abstract. I think that you need to have a very good reason to go open source.

I think that you can name some companies today that have built really good solid businesses on open source software. But for every single one of those you can name, I can name a hundred companies that have built really solid businesses on commercial software.

And it doesn’t mean you should never do open source, but it does mean that the barrier for it being the right answer is much higher than it is for commercial software.

And there’s a trend right now where people say, “oh, well, in this industry, in this part of industry, infrastructure, you have to be open source.”

I would say to every one of those circumstances like, that’s just not the case – Amazon is not open source, AWS is not open source. The vast majority of what we use in our infrastructure is not open source. Cisco is not open source. Right.

There’s a story that you have to be open source, but the reality when we look at the stacks that we have to rely on, there is a lot of open source – but there is a lot of proprietary software. I think you just start with getting rid of the excuses for, “oh, I have to be open source.”

And then, you need to say, “Well, what are some really good reasons to be open source?”

To me, this is the interesting part of the conversation. The first thing is to answer the question “what are great reasons to open source my software?” And then, the next question you have to ask almost immediately is, “can I sustain a business in that case?”

I know there is a ton of really great open source software that has no business around it. And I think a lot of that is really important.

For me, personally, I’m primarily interested in open source entrepreneurship.

So, my fundamental interest is about the business side of any of this stuff. I’m much more of an entrepreneur than I am an open source person. If you had to get rid of one of those, I’d far rather never do open source again than never do entrepreneurship again, if that makes sense.

I do think you have to protect space to build your business as you think about what you are going to open source.

And I know this is going to sound cynical to some people, but I think of open source as primarily a marketing strategy: This is a mechanism for people to become committed to your product, without having to make buying decisions.

Sometimes, that commitment is a technical commitment. I’ve built this piece of your technology into my infrastructure, into my development workflow, into some portion of my life, and I love it so much that I want these other things that go with it.

Sometimes, it’s honestly just – I’ve got brand awareness because everyone knows about Docker, and so I’m going to go figure out whether I can get from Docker some money or not.

But I think that’s the right way to think about, not all, but most open source is, top-of-funnel, getting broad usage everywhere.

It is a fantastic freemium model with the one caveat – that the thing that makes people love your product is the thing that’s also available for free. Which means that building a business on it isn’t impossible, but, in most cases – you look at Splunk.

Splunk has an amazing, fantastic freemium business. But at a certain point, Splunk says, “you’ve got to pay me or you can’t use my software anymore.” And no one goes to Splunk and says, “how dare you ask me to start paying after 500MB?”

But if you had open sourced that, and said the same thing – “by the way, you have 500MB you should pay me.” Then, all the people would say “how dare you ask me to start paying after a certain point?” So, there is this challenge of messaging that a lot of people hear this as a permanent promise that everything will always be free.

That dynamic, and I wrote this article a couple of years ago, about the fundamental challenge of open source is that thing you offer for free has to be sufficiently great that people can succeed with it, but has to leave room for there to be some other thing you charge for.

In many cases, you rely on lightning to strike twice. The thing that’s free is great, AND the thing that’s paid for it is also great. And, as we know, lightning doesn’t usually strike twice.

So, it’s a kind of a pretty challenging conundrum, in my opinion.

Puppet Sans Foss?

Michael Schwartz: Do you think Puppet would have been successful if it wasn’t open source?

Luke Kanies: I think it’s a fantastic question, and it’s one I thoroughly enjoy speculating on.

I think – obviously this is a pure speculation – I’ve no idea. I would guess, that would be far less used, and it would have made far more money. That’s my guess. So, when you say successful, it depends on what you mean, right?

Downsides of Open Source

Michael Schwartz: What are some of the other downsides to open sourcing your software?

Luke Kanies: Honestly, I think one of the hardest ones is the messaging side. Because I recommend founders think about open source as a liability, in a financial sense.

What you’re saying your community is, I’m making the brand promise to you that this software will always be free and always be high-quality.

And that brand promise is expensive.

So, when you open source your software, you’re not just thinking about what can’t I do in the future, and things like that. Google shuts off products all the time. Google has a thousand products, and the average users do not care when Google kills Google Reader or kills Google Glasses.

But if your core product is something, and you go in and say, ahh, you know what – turns out we aren’t able to pay our developers with the business that we built. And so we’re going to have to fundamentally change our developer, or shut our whole project down. Because 99% of developers in this project are paid by my company. So we’re either we’re going to completely reframe our business and start charging basically everybody, or shut the whole thing down.

You’re breaking your brand promise.

And the brand promise was, “we won’t do this.” The brand promise was, “it always will be great and it will always be free.”

At least, it leaves not a lot of wiggle room to help people see, well, “*free” with an asterisk, and “yes, except…” And that conversation is really complicated.

So I think we got lost in the weeds of that conversation all the time. One of the things that happens is, there’s one person in the room that’s screaming all the time about licensing or something.

There’s some part of the open source ecosystem that demands a certain kind of fidelity, or a certain kind of allegiance, or a certain kind of zealotry. And if you refuse to commit to that kind of allegiance, then that person’s going to scream as loudly as they can all the time. And it’s really easy to confuse yourself into thinking, “that person represents the wider community.”

And sometimes they absolutely do. But in a lot of cases, they absolutely don’t.

So, you have to figure out how to have that conversation with your community. By that I mean, people who use your project, the people who contribute to it – and by contribute, I mean people who are on your IRC channels, or helping to ask and answer user questions, or responding to email questions – these are all super important contributions.

You have to be able to have a conversation with those people about, ok, where is this balance between survivability of the company that funds the vast majority of development on this project, and what the community needs to be happy, and things like that.

I think it’s a little bit like the relationship between unions and big companies. If you look at the relationship in Germany. Germany’s had unions for long-time, but Germany unions recognize that if they get too powerful, they can destroy the business. And the business has recognized that if they get too powerful then workers began suffering, and they recognized like this is the dynamic that we have to play with here.

It seems like, at some point in the 20th century in the US, the unions kind of stopped caring about whether the business they were working for was viable, and the dynamic got off. And the businesses stop caring whether the employees that they hired, what situation they were in.

And so, that dynamic is critical to the success of an ecosystem.

And if you were starting an open source business, or even just a project, you’ve got to be willing to sign up to manage that dynamic for the lifetime of your project, because it’s a really, really important part of people being happy.

And so much of it is: Are we meeting your expectations, what did you expect, and are we succeeding in those expectations? It’s not really about what you did, it’s about what you did relative to what they expect.

I think you have to think about that upfront. And you have to be willing to sign up for that work.


Michael Schwartz: You answered one of my questions that I had written. I remember Puppet doing a lot of trainings, and I was going to ask you why, but I think you kind of just explained it.

Luke Kanies: Well, I think training is great for two reasons.

One is, it’s a fantastic revenue source. If there’s a demand for it, it’s an amazing revenue source.

And the second is, people are paying you to become experts in your product.

In my opinion, you should sell as much training as the market can possibly support, because it’s super high profit from a service’s perspective, it’s amazing business! And, again, everyone is now skilled in your product.

To me, there’s no downside and a lot of upside.

Michael Schwartz: Yeah, it’s challenging to build a good training program. We’ve been trying it with Gluu for a long time. And we want to, but it’s actually pretty hard to do it.

Luke Kanies: And especially – it’s one thing to have the intro training class, it’s another thing to have three tiers, and your product for this specific vertical, or for this specific type of user, so yeah, I totally agree.

Scaling Revenues

Michael Schwartz: So, training – it is a great business and it helped you get started. But you alluded to this earlier, to really scaled the business, you needed, maybe, some other way to generate revenue streams. How did you make that transition?

Luke Kanies: In 2010, we launched our first, what I would call commercial product, which was our first attempt at building a licensed product, rather than everything being free, and the only thing we offered were services.

I think as of maybe two years ago, or three years ago, we finally have some idea of how that might work in practice.

So, six years of trying from first released to, “oh, I think I know how to make this work in the long term.”

We were super early when we started, but then I thought “you know, I don’t know exactly how to make money, but I’ll copy one of those great open source businesses that are out there.” Or, at some point, after a few years, I looked up and went, “let’s count the open source businesses.”

And it was like, well, there’s Red Hat. Red Hat went public as a T-shirt and mug company – that’s never going to happen again.” Okay, well, that’s not a good example.

What about MySQL? Well, MySQL is now owned by Oracle. Now, therefore, no one else can ever build that same GPL-based relicensing business again. So that one’s out.

Well, who else was left? There weren’t that many other businesses left that I could use as an example. And so we were breaking far more new ground than I would have liked.

I always recommend founders do as little innovation as possible.

There’s like, part of your business that’s really innovative and risky? Well, don’t, like, invent other risks to other parts to your business.

Like, if you know your software is super risky, don’t be risky in how you think about your hiring practices. Don’t be risky in how you think about whether you are going to have managers or not. There’s just no reason to add more risk to your business.

We didn’t have a business model that we could copy very effectively. And you would probably recall we tried open core, but we tried a ton of different iterations of like, we’re going to have this complete feature be commercial, or we’re going to have the infrastructure components be open source, and the graphical components be commercial.

We were trying a bunch of those different things, and it all kind of ran into this cliff of – because the primary reason to do open source in most cases is: “I want you to become addicted to my product. I want to build the thing that you love.” And some portion of you are going to have a set of problems where my commercial product is a better fit, or you are going to decide for some reason, hopefully for a functional reason, but also for other reasons, to upgrade to my commercial product.

And the challenge becomes – you need to build something that is great enough for the free users that they become successful and happy, but that isn’t a complete solution, such that, at some point, they decide, “oh, we need to start paying them because we’ve hit some sort of barrier.”

That balance is basically where we spent 7, 8 years, trying to find that balance.

And we built a great business – so I don’t mean to say that we failed, or that we didn’t get a lot done, and make a lot of happy customers in the meantime – but from the business strategy perspective, this is something that we were kind of always messing with the throttle. Where do we put this line, how do we think about it.

And to be clear, I am on the board of Puppet, and I’m not directly involved in product strategy or building products, so this is all stuff you can learn from reading our website.

So if you look at our website right now, and you look at the open source projects that we are releasing today, you’ll see that they don’t follow quite the same model of – let’s build an open source engine with a commercial graphical interface on top of it, or a commercial packaging for it. And, in a lot of cases, it’s a different story.

And I think right now, the story will vary depending on the project. If you look at Lyra versus Bolt, the commercial strategy for those are different from each other, I’m pretty sure.

I think the whole industry is learning about how to do this right now, and we certainly have been part of that learning this whole time. Some of it has been quite fun, and enjoyable and educational, and some of it has been really uncomfortable, and at times miserable.

How To Get Customers To Pay?

Michael Schwartz: How did you actually make that balance, or more simply, what did you actually end up charging for?

Luke Kanies: I kind of reject the idea that we have a clear answer to that, or that we can have a clear answer.

I really wanted people to be buying software that made a big difference to them. But then, plenty of cases, people buy software because they thought it was the right thing to do, or people buy software because they really wanted a support contract, but we didn’t offer that separately.

It’s surprisingly hard to figure out what a customer’s motivations are, and obviously, you can figure out per customer, but you can’t go across all of your customer base and say, “I know what all of them are thinking, and I know why all of them are buying,” especially, as you get to a thousand, two thousand, three thousand customers. It becomes fantastically hard to figure out exactly why someone did something.

So, we sold a license to downloadable product that the vast majority of the software inside that product was open source software. But there were key portions of it that were commercial, and there were portions of the commercial that changed over the years, depending on what we built and what we found. This makes a big difference, this doesn’t make a big difference, this needs to be open, and this doesn’t need to be open.

We listen really closely to the market year after year, and change our behavior based on what people said.

In essence, we had quite a few separate open source projects, the biggest one, which was Puppet, and then a commercial downloadable product that combine all that together in one download.


Michael Schwartz: So, it wasn’t just Puppet, the license, but some of the tools in adjacent markets, let’s say, that you included in this Enterprise subscription?

Luke Kanies: Exactly.

As one simple example, Puppet has always worked for the small utility called Factor. And you can of course download the RPMs to each of those, but we would say, well, in our commercial product, we are going to have Puppet in Factor, and over time, we had to include our own separate Ruby because we couldn’t rely on system installations to Ruby for lots of reasons.

We found especially the way we use certain things competing with the way Rails uses certain things, and so we would have really significant incompatibilities between our Ruby and system Ruby. So, that was one of the things where we found that it was much better experience, from our customers’ perspective, if we distributed the entire stack that we were reliant on.

Over time, Puppet became much more reliant on the JVM. A lot of our core tech, like PuppetDB, which is this whole separate store engine that we built, that’s already in closure but runs on a JVM. That’s another example of, we’re going to deliver a lot more tech as part of that stack, to make sure that we can ensure that you have a positive experience.

That reduced the operating cost of not having to worry about package installation, of not having to worry about software upgrades or compatibility, or, “hey, does this installation of Puppet kind of compete with my production application?”

Those are examples of things that you get with the commercial products that are not technically commercial software, but they’re part of the operating runtime value of the commercial product.

Customers Who Want Commercial License?

Michael Schwartz: Did you find that some customers just didn’t know how to buy open source license, and that they preferred some of the liability, and protection and indemnification that came with a commercial license?

Luke Kanies: I mean, honestly, whatever you might be looking for, we definitely found people with those things.

We found people who were offended that any of our software wasn’t free. We found people that were still scared of open source. We found people that wanted to buy our product and would prefer we’d just never talked about open source. We found people that would buy our product, but then only use the open source versions, and not actually even use the commercial versions.

We found every kind of iteration. And over the years, those different iterations made support costs much, much higher.

You’d say “I’m going to do it my way instead of your way,” but then you call us for support, and it would take us three days to resolve your problem instead of five minutes.

So that’s one of the things that shifted our practices around what we’re delivering and what we expect over time. Because in order for us to make your experience better, and to reduce your problems, and if you have a problem that we can resolve quickly, we had to get a much narrower set of valid installations out there.

Why Transition out of CEO?

Michael Schwartz: So, initially, you rejected some venture capital offers because they came with strings of you not being CEO. But then after eleven years or so, you decided maybe you didn’t want to be CEO. Can you talk a little bit about why the reasoning behind that transition?

Luke Kanies: Yeah, it’s certainly complicated. As of 2014, by the end of that year, it became clear that I was no longer happy in my job.

And I’d say I was unhappy for a few reasons. And, I don’t think I’ll get it all in here, but I might get a little bit. There’s more I could say, but I will tell the high-level version.

Mostly I was burned out, I had been running in the red forever, I had rebuilt my executive team twice. It was clear at that point that some of my key executives were not going to be in the company much longer, either because I didn’t want them to be there, or they didn’t want to be there. And managing people is incredibly, incredibly hard. And success is critical.

I had put everything I could into helping these people be successful, and I didn’t have anything left. The thought of going out, trying to hire replacements was too steep a hill to climb a third time.

So, I said “look, I’ve done it as long as I can, I don’t have anything left to give.” At the same time, it was very clear. I founded Puppet to prove to the world that you can build a general-purpose automation system, that is of real value both to the companies but especially to the employees, the people doing the work, and actually building one and adopting one.

That you can build one where the mechanism for automation is text. Which means you can version control it, you can share it. Things that came before Puppet – this might not be super obvious, and CFEngine had this problem, but like all the previous like, widespread solutions did – if I had something that was great, I couldn’t email it to you. I couldn’t ever put it on GitHub.

In fact, in a lot of cases, I couldn’t even use it from one version to the next. I’d have to recreate all of my installations because they didn’t have this text-based configuration. And I wanted to prove that we could do that. I wanted to prove that it worked, that it was a good idea, and all these things. And we did.

But, when you look at my strategy for the first ten years of Puppet, it was all about getting a beachhead and organization, it was about getting the first 10% of every company in the world automated.

But I also realized the next challenge, the next ten years, it’s about getting the next 90% automated.

Not just the challenge, like, the technical challenges of that, but like the people challenges, and especially the contract management challenges of that, are really, really different from that first ten years, and those first challenges. And more importantly, they are really, really different from what’s near and dear to my heart.

I really respect the job of Enterprise sales, I respect the work of navigating an organization and figuring out how do I get a deal in place that the entire organization buys into enthusiastically; they don’t just write a check, but they actually use the software.

How do we get team after team after team, and exec after exec after exec to buy into this, in a way that they’re successful. And, you know, the company gets paid, the product gets used, the users are happy, the company is happy – that is incredibly, incredibly hard, and it’s not my skill set.

I am really honestly over-focused on the individual human, on the individual user, and I’m not great at thinking about the teams, and especially thinking about teams of teams – and that’s what the company needed.

The company needed somebody who was excited to have a complex, multi-team, multi-organization conversation about how the entire organization can use this product.

I think Puppet has actually scaled organizationally better than anything out there. If you look at, we’ve had companies where 70% of the company is using Puppet. We have companies where hundreds and hundreds of people are using Puppet. And there are a lot of other ways in which it scales organizationally just really, really well.

But from a deal-mechanics perspective, from what it takes for Puppet the organization to scale, I wasn’t the right person to navigate those. And when you find yourself in meetings where, I’m either having the same conversation I’ve had for a long time, because now we’re selling to more conservative systems instead of leading-edge early adopters. But also, I don’t ever want to sell to CIO. I just don’t ever want to do it.

And it’s not that I don’t respect them, it’s because they don’t use the software directly. I am personally interested in users, not buyers, not project managers. And you’ve got to be great at understanding and working with all of them to be great at Enterprise sales.

And I could tell what Puppet needed in the next 10 years was something else. I couldn’t get motivated to do that.

Now, the actual mechanics of how the transition happened were a little more messy than that, and I like to say it was my plan and the board’s execution of the transition. So, it’s been an interesting time.

But with Yvonne Wassenaar over there now, I’m super excited.

I think she’s perfectly positioned, she’s got a ton of strategy experience that every company needs. She was at New Relic when they went through that transition from entirely inside to this mix inside/outside sales. And that’s the stage that Puppet’s at.

So, having somebody who respects the fast initial adoption sale, but also knows how to build out that big large Enterprise sales – that’s the mix of business that we’re going to have in the long-term. And somebody who is excited about that and experienced about that is the right CEO of the Puppet. And that’s not me.

Luke’s New Business Idea!

Michael Schwartz: Do you think you’re going to start another company?

Luke Kanies: I already have.

Just super fast – I’m starting a new relationship management software company, focused on helping you ensure your most important relationships are healthy.

I think contact management is one of those, it’s like, one of the most important problems with the worst tools available today. So I’m hoping there will be some aspects that we’ll release that will be open source, but the core product, in this case, will be commercial.

Michael Schwartz: Will it be a SaaS product?

Luke Kanies: I don’t think it will. Man, this is so complicated. I’m doing like, six things at once, and the largest envelope with all those things is, my next 10-year mission is trying to convince the market that power tools are important, and that they have been under invested in.

And also trying to teach the market where a power tool is. And I think, I don’t know this, but I think it’s much easier to build a power tool when it’s local operations against local data.

So, you can have SaaS components, you can have backend headless services and things like that. But I think in general, a power tool – it’s hard to believe Photoshop could be as great if it was a SaaS product. It is hard to believe that AutoCAD could be as great as if it was a SaaS product – No.

Is it great if you have SaaS components? – Yes. But is the core experience ever going to be as good as if it’s a fat-client app, operating on a powerful computer in front of you? I don’t think it is.

That’s my operating like thesis right now – that we need to build power tools with local operations against local data, and we’re not trying to build it for everybody. I think too many companies are targeting products to be used by everybody – there’s two billion people online! That these should be used by everybody? I don’t want that.

Those two billion people, they’re not all going to pay for the same software, and I want to build a software that makes people more powerful. That means that I will need to build the software that you will need to pay for.

If you are not willing to pay what it costs for a cup of coffee a week on my contact management software, then we are not building anything for you. And that means that for most people, this is not the right tool for you. It’s only for people whose networks matter so much that they’re willing to invest time.

I’m not saying it should be as hard to use, but if your contact management isn’t at least as powerful as your text editor, like you made a mistake somewhere. Content management matters a lot to some people. Relationships matters a lot to some people. And the tools I have for doing it are nowhere near as complex as my compiler, my text editor, my project management software. All my developer tools are way more powerful than I had as a manager, or that I had as a leader, or hirerer, or as a CEO – all those tools were really simplistic. Why?

I think as a CEO, I deserve as complicated and powerful tools as the developer, or the sys admin, but they are not available. So, I want to try to convince the world that everybody deserves powerful tools. That your hotel cleaner deserves powerful tools, that your construction workers deserve powerful software tools, and it’s not just sys admin developers.

Challenges Of Open Source Business?

Michael Schwartz: Wow! Good luck with that. I think that, just as a data point, you’re recording on Audacity did not crash, and my SaaS recording tool did.

Two last questions. One’s about companies and the second one is about people.

The first question is: What do you think are the biggest challenges facing pure play, open source startups today?

Luke Kanies: It’s super easy. You are giving your product for free, why would anyone pay you?

That seems really obvious. There’s no other business where you give away your product for free, and then try to find some other way to pay it, that I know of. I think it’s super hard.

There are models that work, there are proven models. Red Hot got rid of their source RPMs, they made it harder to build a completely new, from-scratch copy of Red Hat.

There are some of those, but all those starting on a presumption that I’m going to get broad enough adoption that a 2% conversion rate, or a 5% conversion rate allows me to build a viable business. I think it’s conceivable, but it’s super hard.

Michael Schwartz: The last question is do you have any advice for the entrepreneur, the person starting the business – and it could be about not just necessarily the business challenges, but some of the personal challenges of starting a business, around open source software?

Luke Kanies: There’s a ton of advice out there, or really a ton of people who are trying to say “this is what entrepreneurship is,” and almost all that framing is “and if you don’t do this, then you’re doing something wrong.”

You know, there is this thread about the most successful people get up at six in the morning. Okay, well what if you are a night owl? Well, I guess you’ll never be successful. Suck it.

I’ve never gotten up at six in the morning, I can’t really speak coherently until at least 9 AM.

So I’d say, for any entrepreneur, it’s really easy to find advice that you will never be able to follow, and become dispirited, and feel like you’ll never be able to succeed as a result. I would focus much more on finding success cases and ignore the failure cases.

The things that you’ll never be like – if you can’t be like, then just ignore them. There are lots and lots of ways to succeed in general, so focus less on whether somebody else’s successes is replicable by you.

There’s a great thread on Twitter today about all these different amazing people who built great business, and how Jeff Bezos’ parents were able to give him $250,000 to start Amazon.

Ok – on one hand, Bezos is a great entrepreneur, but on the other hand, if he didn’t have rich parents, then we wouldn’t know if he could be a great entrepreneur.

It’s really easy to tell yourself a version of reality that makes it so it seems harder for you, but it might actually be literally harder because you don’t have rich parents, or rich friends, or a rich uncle, or whatever that is. And that is just being an entrepreneur. Full stop.

And for me, I would say, be really, really clear about why you’re doing open source. And then make sure that’s the actual thing you do with it.

If you’re doing it entirely for top-of-funnel for usability, for getting broad usage, and then you want to convert people to paying, then that’s a very different business than this small engine needs to be open source because it needs to be distributed everywhere, but the viable broader product doesn’t. That engine, being open source, may not have much implications in terms of your product. That’s what will be different.

Or, my partners really require this to be open source. Each of these point to a different business model, and a different set of constraints on you. And so just saying it all needs to be open source, or I have to be open source, is not really very instructive.

Be really crisp, and be clear, and put walls around it. Then ask yourself “can I build a viable business outside of those walls? Can I build the business that I want to build?” Because I guarantee, whatever it is – you could build a services business making half a million, a million, maybe five, or even ten million dollars a year – but that might not be the business you want.

And if your goal is to go out and raise ten million dollars in venture capital, or a hundred million dollars in venture capital, I know that that’s not the kind of business they want. So, you’ve got to be clear enough about why, and then what’s left, and then what’s left is enough to build the business that you want to build.

Michael Schwartz: Awesome! Luke, thank you so much for your time today and sharing all that with us.

Luke Kanies: Thank you for having me on the show, Mike.

Michael Schwartz: Transcription and episode audio can be found on opensourceunderdogs.com.

Music from Broke For Free and Chris Zabriskie. Our audio editor is Ines Cetenji.

Production assistance and transcription by Natalie Lowe. Operational support from William Lowe.

Follow us on Twitter, our handle is @fosspodcast.

In the next interview, we have Sam Tuke, the CEO of pHplist, an open source platform for email communication management.

Until then, thanks for listening.

Episode 21: Couchbase – NoSQL Engagement Database with Ravi Mayuram

Ravi Mayuram is the CTO and SVP of Engineering at Couchbase, a NoSQL vendor responsible for the Couchbase Server, an open source, NoSQL, document-oriented database. In this episode, Ravi discusses how an entrepreneur may successfully orient themselves around the problem they’re solving.



Michael Schwartz: Welcome back to Open Source Underdogs, the podcast where we talk to the leaders of successful open source companies about the business model that powers their growth.

This week, we’re excited to have Ravi Mayuram, CTO of Couchbase. In the interest of full disclosure, Couchbase is the latest database supported by the Gluu server.

We’ve been super impressed with the technology, their level of engagement with customers, and their flexibility to find ways to work with us.

Ravi gives a pretty good technical and business overview, so let’s just dive into it.

Ravi, thank you so much for joining us.

Ravi Mayuram: Thank you for inviting me.

Michael Schwartz: So, how’d you get involved with Couchbase?

Ravi Mayuram: That was a good number of years ago.

In the early stages of the Couchbase, there was a lot of exciting stuff going on here. And my own experience with some databases had led me to thinking – with all this innovation that is going on, with the new way of development paradigms and the new way of the data being more flexible, what should be the answer?

Some of us were thinking in terms of how to get going on that, and Couchbase was doing some of the stuff, so I started to talk to some of the people here, and that excited me to sort of jump in and get the journey going to where we are right now.

What Is Couchbase?

Michael Schwartz: This isn’t a tech talk, but maybe just to help our listeners, could you explain a little bit about what makes Couchbase different than other databases?

Ravi Mayuram: The fundamental question we were sort of asking ourselves when we began this journey was – many of the assumptions that we had to make when the relational databases were built are no longer true, memory is a way cheaper, network is a way faster.

And the entire application development paradigm had completely changed. There was no object-oriented programming, back in the day when the relational systems were built.

So, every paradigm around the database has changed. But the databases that we were still using, the relational ones, which were predominantly the ones that used technology that was developed some 40 years ago, in the late ‘70s and early ‘80s, whereas every other piece that we talked about has completely changed since then.

So, in this new landscape – what assumptions would you make, and how would you build a new database? So, that is the fundamental premise.

And what are those pieces that are worth keeping? One of the lessons that we had learned – from the relational work – what would you like to keep, and what would you really like to change or design differently?

If we look at it from that perspective, we would like the databases to be a little bit more memory-friendly, and network-friendly. These were the two assumptions you could make earlier, so it was very disc-oriented.

Also, a single system, if you will, a single-node system is where relational systems work, because you could never rely on the network back then.

So a distributed database, which is memory and network-centric, would be one element of it, from the standpoint of how infrastructure and how the bottom-half of the database need to look at the problem. And on the top-half was all this change to the object-oriented programming paradigm.

So, in this paradigm, there is already this object-relational impedance, as we call it. And how do we basically solve that, how do we make databases that much more natively plug into the application development paradigm now, which is object-oriented, and the World Wide Web is here, JSON has become this lingua franca of the web.

In this circumstance, where any endpoint that you talk to is describing and consuming JSON, in this object-oriented world, what would be the database’s role? How can it become easier and a help to the application developers, as opposed to being the friction point between an application, developer, and finally, when you want to roll something out, to production.

How do we solve these problems?

In a manner, which takes databases forward, it’s not worrying about whether it is SQL or NoSQL, but how do databases need to move forward. And what would be those foundational changes that we have to make, and what are those good lessons that we’ve learned from databases that we must keep.

And so evolved the journey at Couchbase, in building the new data platform, which is based on the NoSQL technologies, and the lessons learned from there as well.

Why Open Source?

Michael Schwartz: So, where does open source fit in the strategy?

Ravi Mayuram: A very good question. One of the lessons in the last 40 years of software has been to move from what we used to call monolithic stacks to open systems, open source.

And that movement has been basically lead because of this reason that, no matter how friendly, or how much APIs that you have there to integrate into systems, you always needed to make that little tweak or a change.

You didn’t want that to be hidden behind some proprietary wall, where you couldn’t see how the software is actually going to run. So, integrating multiple components into one place, that has always been a huge pain, because it’s not, you know, “I can take bridge at A and consume bridge at B.” It’s not that clean. You always have to do some last-mile programming, if you will, before two components will talk to each other.

And you need to understand how these components work. And so, having the facility to observe under the hood, and so the open source movement began. That also gives you the ability to help within a community around how we are building, which is very important for adoption of a technology.

These two elements of sort of having a community as well as an ability for that community to feel that they can own a piece and move that forward, which will both solve their problems as well as move the consumer software forward, is generally the motivations behind the open source.

And a platform, like a database, or a data platform like ours, requires the community to come together and consume this move, this forward, and benefit from that, as well as the company that’s doing this benefit.

The lesson learned is to start with an open source sort of a paradigm and ethos, and cultivate that community. That way you get to be closer to your users, you learn from them, you adapt to changes faster. Instead of doing the classic full-on cycle of focus groups and everything, you can basically go faster by interacting with this community.

It’s a win-win on both sides, and that is always one of the motivations for the open source-based companies like ours, which want the community, as well as monetize on the back side when the deployments are serious enough.

The Couchbase Community

Michael Schwartz: Can you just describe the community?

Ravi Mayuram: The community is a set of developers who are building applications on top of platform like Couchbase.

In this case, our community is those developers who take Couchbase, and build applications, the modern applications which are the ones that require flexible data model, performance, scale, what are all the other requirements that they have, which the older relational databases could not service those needs.

That generally becomes our community, the community of web and mobile developers, and perhaps even beyond, in terms of the types of applications that are getting built on Couchbase.

What Features Are Open Source?

Michael Schwartz: Couchbase has a very nuanced feature matrix, in terms of which features are community and which features are Enterprise. So I guess I’m wondering – is the functionality that’s in their community software enough to actually have a large community who actually uses this for production applications?

Ravi Mayuram: Actually, our general philosophy is to enable the developer and monetize deployments at scale.

So, from a feature functionality perspective, we do not sort anything back. What we basically have in the community edition, developers can go freely develop anything that an Enterprise can, actually.

But where the functional feature differentiation comes in, features like security, scale, performance, because we believe those are functions of large-scale deployments – which only major, successful Enterprises will need. And that’s where we would like to monetize that.

From a sort of API level, there is nothing that you will not be able to build on a community version, which you can only build on the Enterprise.

So, I hope I clarified that nuance. Yes, there are certain pieces which are Enterprise-only, but they fall mainly under the category of security, performance and scale, and manageability – a certain amount of manageability features, because you would need that only in large deployments.

Per Server Pricing

Michael Schwartz: On the licensing side, you license per core. Is that right?

Ravi Mayuram: We license per server, and there are three – small, medium, and large, if you will, in terms of the number of cores per server.

And that’s how we tier this thing. Per core pricing is not where we start. It’s basically built on the small box of 16 cores, from 16 – 64 and above. I think that’s how we tier our pricing model of – it’s per server licensing with a number of cores, as opposed to per core.

Michael Schwartz: Is that because, for most of the Couchbase Enterprise deployments, you’re seeing dedicated servers, for this database, and not containers, or VMs, etc?

Ravi Mayuram: Basically, it becomes easier from the standpoint of people who are procuring. Even about 40% of our customers have their stuff on the cloud, even they are provisioning, based on the quantities that they can buy, which is based on 3X large, or 4X large. So it comes with a certain number of cores per server kind of notion, as opposed to core pricing.

And so that was easy to start there, so it’s easy to describe and sell that, versus how many virtual versus real. We are a little bit more in the earlier stages of the company, so we are a little bit more lax, and we would rather have option than monetize every bit of it.

Challenges Of Containerization

Michael Schwartz: Do you see any challenges though with containers and some of the elasticity as pooling up and down servers and scaling? It’s hard to know, like, how many servers or even how many cores you have, and that’s a moving target overtime? How do you deal with that?

Ravi Mayuram: Yes, I think it is a little bit of the elasticity, the core thing that has really changed, if you will, in terms of consumption models.

So, it has become sort of utility computing, and in some cases you would call it, or shows on demand pricing, and there are more ways to get to the same problem. But cloud is all about elasticity, and capacity on demand is what it comes down to.

So, yes, you will not be able to squeeze the last drop out of it, but for the most part, you can get to it through a different proxy in terms of how much the API calls, how many are actually happening, how much throughput you are getting. So that’s another proxy for exactly how many cores one CPU is using.

But, the back end of the computation is always at the CPU core level, which is another way of sort of, may be more coarse-grain, as opposed to being too fine-grain, in terms of ops per second kind of monitoring. But we can get there as well, and we will get there.

At this point, we were just skeptic, like I said, simple and coarse-grain, so it’s an easier conversation in terms of pricing and adoption, and not worrying, in terms of – it’s a little bit more wholesale than retail, if you will, so that makes it easier.

License Enforcement

Michael Schwartz: License enforcement – are you actually enforcing the license, or is it just on the honor system?

Ravi Mayuram: It’s the honor system at this point. The licensing enforcement is not there, like it is one lesson learned from the ‘90s of not doing license managers. But, there is monitoring capability, so the rest of this commercial discussion happens based on that honor system of the usage. And most enterprises are very amenable to that, and that’s why we don’t see that to be any sort of an issue.

Michael Schwartz: It’s a lesson learned from the ‘90s that the licensing server could cause an outage, and you just don’t want that?

Ravi Mayuram: Exactly.

Michael Schwartz: The last moving parts that you need in a database, from a standpoint of anything is that it can limit your ops per second, I think that is the right way to go, and not impose more software on it.

Customers Of Couchbase

Michael Schwartz: Okay, can you describe who are the customers of Couchbase?

Ravi Mayuram: Our technology, being a horizontal one, is pretty wide.

It goes all the way from financial services to eCommerce, to gaming, to streaming media, the top 10 in any of these segments. I can go on and on, in terms of areas like travel.

Six or seven major segments, in which we have the top 10 using, there are about another six or seven verticals, if you will, where the top five use this. So, you can imagine our spread in the types of use cases, as well as performance, and the scale requirements, because these are the digital leaders in their segments, so they are the ones who are in the forefront of technology.

And their demands are something that has never been met in many cases because they never have the technology to go to this global scale. There are places where there are like 1.5 billion ID’s sitting in Couchbase, servicing any touchpoint. There are places where people are doing 8 and 9 million operations per second for travel reservations and the stuff.

There are places where people are doing customer 360, where they are managing hundreds of millions of documents, which is basically the information that is coming from multitude systems in one place.

Airline reservation systems are running on Couchbase, flights cannot take off unless that transaction in that sense goes through Couchbase.

Logistics companies uses any bit of information that you’ve actually seen in terms of packing their packages runs on Couchbase. So, high volume, high transactional stuff, which is globally scaling with geo-distributed data, and guaranteed performance, whether you’re the first user or the millionth user, you get the same low-latency.

These are some of the use cases where Couchbase shines, and many, many, many mission and business-critical applications are run on Couchbase. That’s what keeps us going here, that’s what gives us all the validation for all the hard work and the deep work we do in the architecture of the product.

Is Couchbase Only An Enterprise Model?

Michael Schwartz: You know, when I hear that requirement, I almost think that it’s only a requirement that large Enterprise has. So, there’s no small businesses that need this like super high throughput and multi-data center, let’s say, redundancy, and fast-response times. So, it’s not necessarily an open source type of problem, though.

Ravi Mayuram: Actually not, I would beg to disagree.

Simply because, what has really happened, if you look, is that, back in the day, most of the systems that were built for Enterprises, small, or medium, or large, is basically for those systems to be targeted to a set of agents – who are the middlemen between the end-user and the service – to which they were the agents: A travel agent, a call center agent, or any of these agents, you can keep looking at all these agents that you’ve had in the past.

The real movement that is happening now, this is the digital transformation, we call it “disintermediation of the intermediary.”

If you look at who is doing the travel reservation, there are no more agents. It’s you and me doing the travel reservation.

So, your world is your community right now, in terms of your user base, if you will. You have a billion users who are all on the internet, on the information highway, if you want to call it. They are the ones you’re servicing. Every small business that they put their first service up, that’s why going to the cloud is important to them, because it’s got the features – it can give you the performance at scale, it can give you the reach across the globe, across different geo-centers.

So, these have become table stakes now. It is not just a requirement, which is only for the 50 companies on the top.

Every gaming company that is coming up and wants to put up its first game, they should have a hundred million users, running on their software. And you need to show the leaderboard of the Five Guys who are actually on the top of that thing – how do you get to those Five Guys a hundred million users playing the game? That is a challenge that a platform like Couchbase solves for them.

And the same thing happens across the globe in any kind of service, if you want, to small, medium, or large. Your problems are the same.

The larger enterprise is, this problem is persistent and continuous throughout the year. And the smaller ones, the span of this, maybe, they use one or two applications, but the intensity remains the same. Does it make sense?

Develop But Scale

Michael Schwartz: Yes, I guess what you’re saying is that if you’re launching a game, you start with Couchbase, and you develop it on Couchbase, and then if you need to scale it to billions, you don’t have to re-architect your application?

Ravi Mayuram: It runs on my laptop, or it runs on three nodes. That is fine as far as a developer is concerned, but seamlessly, you’d be able to scale this to 1500 and more clusters, and across three geo-centers with redundancy, and geo-distribution of data, and manage your GDPR requirements of data privacy – all that stuff with a click of a button.

So, stuff that you can do on the glass, without you ever having to go back to redesign your applications. That’s what we really built here, so that it becomes easy. Our general mantra is “develop with agility, deploy it at any scale,” anywhere, whether it be bare metal, or virtualized, or containerized, or in the cloud – all orchestrated and managed through one common infrastructure.

And I think that is what you need in this stage, because there are a lot of unknowns that are thrown in your way.

Your application can change, your deployment can change, your usage patterns change. Your data needs change, so this is the database that is built for that change, and built for a failure. Because you should be basically taken into account that when you’re running such a large-scale system, it can fail.

Your act can fail, your data-center can fail, your cell tower near you can fail. Yet, your application should be running, and be able to recover, and go back, and get the job done for you.

That is what we have, and all this with as minimal manual intervention as possible. We have automated a lot of that stuff to make the problem appear simple to the end-users, where we do sort of heavy lifting to solve difficult problems underneath the hood.

Can The Community Contribute?

Michael Schwartz: This is probably an understatement, but what you’re doing is actually very difficult. And my question is, the open source development methodology has been good for innovation, but because what you’re doing is so hard – can the open source community actually contribute in a meaningful way?

Ravi Mayuram: It’s a good question. Yes, they can in certain areas. And in certain areas, perhaps best left to the professionals.

What I mean by the code innovation in distributed computing, our code innovation in some deep areas of transaction, or multidimensional scaling that we do, those are not the areas where community can actually get in and develop some new feature.

But there are a lot of consumption-oriented stuff on this platform that needs to be built, because a database doesn’t stand alone by itself. It’s got to be in the ecosystem. There are so many tools and integrations, and all those interactions that actually have to do with the database that needs to be built.

And our client API’s, there’s a lot of stuff to be built out there, because there are so many new frameworks and paradigms coming out there. So, that’s where we find the community involvement. And by doing that, they actually enhance the core of the product, with even some code in some areas, by suggesting, “hey, how about we do this for it to be more secure, or for it to be easier and more flexible?”

So, from that experience, we learn, and the community also contributes. In some code areas, there’s less contribution, but in some of our client, and integration, and tooling areas, there is a lot of excitement from the community.

Evolution Of Monetizing Strategy

Michael Schwartz: I realize you haven’t been there since the beginning, but you’ve been there for some time. I’m wondering if it’s really hard to get the monetization strategy right for open source companies? Has there been any evolution of how to charge, or what to charge for overtime since you’ve been there?

Ravi Mayuram: Yes.The evolution basically has been in terms of bringing more capabilities into the platform and charging from the standpoint of solving tougher issues in the platform.

So, the philosophy is, bring more logic to data as opposed to moving data to logic.

This is the fundamental problem, in one sense, this platform style thinking actually solves. Which is, earlier you would have a database. Then you’ll write a connector to move this data to a search. You’ll write a connector and move this data to a warehouse. You will move this to a faster performing cache.

So you are a sort of duplicating data all over the place. And the problem with the duplication of data of course is more usage of the resources, but the bigger problem is consistency. You don’t know which is the consistent representation of the data is because you have just copied them all across.

So, in this platform, what we’ve really done is bring a key-value, a standard second index with a coding capability, with a full-on coding language. And for this, we very deliberately chose a sequel because that’s the only coding language that has withstood the test of time in the last 40 years.

And then, we added the search, which is the inverted or excel analysis base search, not the classic database type search – this is the information that will be truly sitting next to a database.

And, finally, we added the analytics piece to this one, so you can do an analysis of the data that you have in the same platform. For the first time, you can do these four things in the same platform, and workload not impeding the other – that’s what the magic is.

And, now, by doing this, what we have really done is added different types of workload underneath our platform, and so, the way we monetize this platform is by different types of workload actually running on the same platform. So that has basically been the evolution.

When we started, it was a straight-up key-value store, so you could get set, update and delete. That’s all the workload we are monetizing.

Now, we can monetize beyond that, select start from workload along with all the subqueries and SQL-92 standard queries, so you can write a serious enterprise app on top of this. And then, you can do all your faceted navigation, and search, and textual analysis. That type of application, that workload can run on the same, so you always have had this problem of trying to do, or solving a search problem away from a database problem – you don’t have to do that now.

And, finally, for all this data that are sitting in this platform, you can run your analytical query, which is a pretty heavy workload as you can imagine. And we have a query engine in the back, which is chewing through that.

In the same platform, we have workloads, which are microseconds, which is our key-value get sets, millisecond response time, which is our query. It is the same millisecond response time for our search, and finally, tenths of seconds or even hundredths of seconds, for our analytical queries, all running into the same platform, one not impeding the other.

So, kind of what we call “Hybrid Transactional Analytical System” is what this platform is.

So, how has it evolved? Different workload has been added and serviced under the same server, and so, generally, the monetization workspace on the capabilities that we have added here.


Michael Schwartz: Switching gears just a little bit, I wanted to ask about partnerships. There is technology partnerships with other vendors, but I guess I’m more interested in sort of the channel partnerships.

Has Couchbase been working on developing channel partners? And how has that worked out for you? Has it lived up to your expectations, or just, how’s it going with the partnership side?

Ravi Mayuram: We have started to build those out the last year and a half or so.

We have channel partners, we also have ISVs, and also we have the GSIs, as Global Service Integrators. These are different channels through which we are pursuing the further adoption of this.

You can see some of our partners in our sort of channels and partners website. I wouldn’t want to pick any one of them out to highlight, but we work with technology partners, we work with channel partners, we work with GSI implementers of our technology, and that’s generally our strategy.

As a platform, we need to be where, so to say, where the conversation is, and in many cases, partners are in those conversations, and we work with them to be in those conversations.

Partner Support

Michael Schwartz: Have the partners been able to take over some of the support burden from you?

Ravi Mayuram: Yes, but it’s an evolving thing, where they have been able to take on some.

I would say they have made more progress in taking on the professional services or the servicing element of it now. Eventually, they’re also getting geared up for some of these support needs, which is an automatic organic evolution from there, so those are in the stages of infancy.

History Of Couchbase

Michael Schwartz: One historical question. Couchbase, when I mention it to people, sometimes there’s some confusion around CouchDB. Can you talk a little bit about sort of the evolution of, are those project-related, or how did the name come about? Just help people understand.

Ravi Mayuram: Actually, the genesis of Couchbase is the merger of two companies, a company Membase, which was the company behind the Memcached, the open source project, and CouchOne, which was a company behind the CouchDB project.

The people that were behind the CouchDB project came over to this merged company, and they brought their ideas. So, the CouchDB was what was built earlier, that’s a separate thing. Couchbase, the code base has indigenously evolved here, a combination of what was Memcached, and eventually, what we added to that, in terms of the persistency.

That is the evolution, and at that stage then, it was a merger of two equals, Membase and CouchOne. Obviously, the name had to have both parties represented, so it became Couchbase, and since then, CouchDB vs. Couchbase has been a question in many people’s minds, but we do not share any code between these two projects.

Couchbase, if anything, has the API compatibility with Memcached protocol, and so, it’s more of the Membase interfaces, plus all the stuff that are developed on top of it.

Couchbase As A SaaS Service

Michael Schwartz: Are you thinking about launching a SaaS service, or maybe you already have a SaaS database-as-a-service?

Ravi Mayuram: We have a Couchbase managed service available, which is offered since last June timeframe or so. Database-as-a-service is an area we are really actively thinking, and it will be the right time to talk about what we’re doing there.

Open Source Strip Mining

Michael Schwartz: You surely have been following all of the sort of controversy around open source strip mining and evolution of licenses to prevent large SaaS providers like Amazon, from monetizing your hard work.

Any thoughts about sort of what’s happening there right now? Is this a good thing for open source-first SaaS providers, or is it a natural evolution?

Ravi Mayuram: I think there are few classes of open source software, and so, whatever the behemoths do, it should be consistent and fair from that standpoint.

There are open source projects which are started by communities, so there is no single company behind them that was putting the resource and money behind it to develop that, it just came about because of a set of people who started to develop something.

If they are going to monetize on that, then there should be some way to share some of bounties from there, with that community. How that can actually happen has to evolve, but that’s one set.

A company like ours, or many others out there, I recently saw news about, yet another open source-oriented company, source being formed and offered as a service.

In all these situations, it’s a question of fairness, like you say. And, yes, it’s an open source thing, but it is an open source, you should think of it as, in one sense, as an escrow of the core, with the customers who want to actually buy.

Somebody else profiting from it, without actually contributing to it is where the unfairness of it actually comes about. If that is a really clear way of contributing first before monetizing from there, I think there will be a lot less heartache, in terms of how some of these bigger companies are approaching this problem.

I would rather they all become part of this community and contribute to it, and after that, them offering some of the stuff as a service would seem fair.

Advice For Entrepreneurs

Michael Schwartz: You’ve probably talked to a number of entrepreneurs who are starting companies around open source software. What is the advice, or do you have any advice for those entrepreneurs?

Ravi Mayuram: I think there are a couple of things that any entrepreneur first has to be very focused on.

First is the problem that they’re actually trying to solve.

You have to be very close to the problem first, you have to live it, you have to understand the problem. You really need to have your value proposition in solving the problem.

Whether it is open source, or not, is a decision that you can take eventually. Because the reason why I’m saying that is that, otherwise, you get into this popularity game, and monetizing has got nothing to do with the popularity game. It’s not based on eyeball revenues, those days are over.

You need to be really solving a difficult problem in the domain that you are entering, that there is value in that.

Even if you open source stuff over there, you will not lose value in what you are actually providing. So get close to the problem, talk to the people who are living the problem, and evolve your business plan around that.

If you solve the right problem, will they hire you to solve the problem is the question you need to ask. If I build this, will they come?

If that question is answered, open versus closed, and all these are fait accompli, which will take care of themselves, and even if someone actually profits from your open source, you will profit even more. I think that’s what market’s actually treating in that way.

So, licensing, open sourcing, somebody else running your stuff – these are all the secondary issues eventually, if you solve the real problem correctly.

And of course, you have to have defensible stuff in there, in terms of what is it that you’re going to have, which is your magic sauce versus what is it that is really available. That is what really will take you to your promised land.


Michael Schwartz: Good advice, Ravi. Thank you so much for joining us today.

Ravi Mayuram: Fantastic! Thank you for having me. It was a pleasure talking to you.

Michael Schwartz: Thanks for the Couchbase team for helping to schedule with Ravi.

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

Music from Broke For Free and Chris Zabriskie.

Our audio editor is Ines Cetenji.

Our production assistance and transcription by Natalie Lowe. Operational support from William Lowe.

Follow us on Twitter. Our handle is fosspodcast.

Tune in next week for the conclusion of Season 2.

Until then, thanks for listening.

Episode 20: Redis Labs – Database for the Instant Experience with Ofer Bengal

Ofer Bengal is the Co-founder and CEO of Redis Labs, home of Redis, one the world’s fastest instant experience databases. In this episode, Ofer discusses the evolution of open source software in the cloud-hosted market.

To note: This interview took place a few weeks prior to Redis Labs’ announcement of an updated license for modules created by the company. You can read more about the Redis Source Available License (RSAL). Open source Redis continues to be licensed under BSD.



Michael Schwartz: Welcome back to Open Source Underdogs, the podcast where we cash the collective knowledge of founders, who use open source software as part of their business model.

No company has been more central to the discussion of open source business models than Redis. Just google Redis and Amazon, and you’ll get back pages of results.

When I was in Tel Aviv, it was a great honor to interview Ofer Bengal, CEO of Redis, in their awesome new office.

So, without further ado, let’s cut to the tape.

Thanks so much for joining us today.

Ofer Bengal: Thanks for having me.

Michael Schwartz: I’ve started four companies, which is more than anyone I know, but I think you’ve got me beat. How many companies have you started? And how did you come to get involved with Redis Labs?

Ofer Bengal: My story is a bit unusual because of my background, I’m an Aerospace Engineer. I got to the high-tech business by some sort of coincidence.

For years, I was designing airplane modifications and installations on war airplanes like F-16, F-15, etc. I did it for the Israeli Air Force, and then, I started my own sort of consulting company in the same area, doing work for American companies, Israeli companies, got bored with it, and started to invent toys. Sold some toy concepts to American companies like Coleco, the Time – I don’t know if you remember that company – the Cabbage Patch Kids, Hasbro, etc.

Then I wanted to start my own toy company, which would not just invent toys but also manufacture them. It was 1980 some, I prepared a very nice business plan to raise money for a toy company, can you believe it, so, no one wanted to invest in that company, except for one person that was from the high-tech business in Israel.

They were two brothers, who were the fathers of the pioneers of the high-tech business in Israel, their name is Zisapel. The guy told me, “give me the stuff to show my kids, if the kids like it, I’ll invest.” That’s the due diligence. He came back after the weekend, “the kids liked it, and I’m going to invest.”

A few days later, he said, “You know, I even have a better idea – why don’t we start a data communications company together? I’ll put the money and you will manage the company.” I said, “why are you even suggesting that because my mind is in toys now?” He said, “you look to me like an entrepreneur, pushy, etc, so I would like to bet on you.”

I said, “no, thank you, I’d like to carry on with toys.” But later on, once I couldn’t find more investors, I gave up, and I started a data communications company. That was back in 1991, or so.

And from then on, that company I took public at NASDAQ in ’97, and then later on, I started another company, which I sold, and then another company, so it became back door to the high-tech business.

Michael Schwartz: So, how many companies is that?

Ofer Bengal: Basically, in terms of starting companies, I started four companies in my career, and then managed another two on request of venture capital firms. One for Sequoia, one for Star Ventures. And these companies were a bit in distress, and I was called to try to save them.


Michael Schwartz: In 2015, Redis Labs hired Salvatore Sanfilippo, the original author of Redis, but before that, you were using the Redis name, you’d raised quite a bit of capital from Silicon Valley – did you learn anything from that process? And looking back, would you have done anything differently?

Ofer Bengal: Not really. Like many other companies, where you start is not where you end.

When we started in 2011, the database market was dominated by very large companies, like Oracle, and it didn’t make much sense to start a database company at that time.

We, me and my partner, who started the company, came from the application acceleration space, and we thought that we always knew that whatever you do in the front end of the application, the database is always the bottleneck. We thought that we should do something around it, and we started with cashing systems for accelerating databases.

At the same time, when we just started, we found a relatively new open source by the name of Redis, which was started by an Italian guy, Salvatore Sanfilippo. And we thought, hey, this is cool – let’s take it as the engine under the hood for what we were doing at that time. And so we did.

But after a year, we saw that this open source is becoming extremely popular, and we said, “maybe, we’re in the wrong business, and maybe we should turn the company and make it a Redis company.” So, we did that.

A couple of years later, Salvatore joined the company, and he is now leading all the activities around continued development of the open source.

Now, a word about Salvatore. This guy started Redis, and the first version, I believe, was out in ‘09. He did it initially as a part of the project he was doing for Telecom Italia. He was looking for a very fast database, he couldn’t find one, so he decided to develop one by himself. He didn’t have great expectations from that and just put it out as an open source.

That was ’09. Around 2011, Redis started to pick up and became extremely, extremely popular. Today, it’s one of the most popular databases in the world, and definitely one of the most popular open source projects in the world. So, that’s a little bit of history of Redis.

Customer Segments

Michael Schwartz: Most of our listeners probably know that Redis is used by a myriad of organizations, and Redis Lab has thousands of customers. But, when your potential market is so broad, how do you segment the customers?

Ofer Bengal: Redis is very horizontal in nature, so it covers many, many use cases for modern applications, and that’s why you find Redis today in almost any enterprise in the world, not to mention startup companies, developers, etc, etc.

We basically sell to all industry verticals, so just to give you some names.

In banking we sell to American Express, Wells Fargo, Credit Agricole.

Financial Services: MasterCard, Visa, Intuit, Fiserv.

eCommerce: Walmart, eBay, Starbucks. Social: Twitter, Twitch. Media: MSN, DreamWorks. Advertising: Havas, Rev Mobile, Outbrain. In technology: Apple, Cisco, Dell.

In communication, Comcast, AT&T, Verizon, Vodafone. And so on and so forth, in other industry verticals.

Michael Schwartz: I guess, my question was, because you can sell to anybody, do you break up the customers into different types and segment them in any way, when you look at them from a marketing perspective?

Ofer Bengal: We look at few dimensions.

First of all, we look at what are the capabilities of the database.

We map that into use cases of modern application. And then we map that into industries. We have all these matrices of mapping, and we have white papers and explanations for each of those. The idea is that, today, the world of databases has changed a lot from like 10 years before.

Originally, you had one database type that fits all. So, if, I don’t know, Citibank decided to use Oracle, they’ll adopt Oracle for everything. This has changed a lot because today it became more silo business.

Certain databases are good for certain type of use cases, and these use cases are very typical for certain industries. So, today, you find in a single Enterprise multiple databases not just that, with the single application, even a simple iPhone application, you can find five, six, seven different databases serving it.

Everything is changed, and that’s very good for us, because the market is a way more diverse now, and there is room for new entrance, and so on and so forth.

Value Prop

Michael Schwartz: What’s the value proposition of the Redis Labs’ commercial offering?

Ofer Bengal: What we did with Redis Enterprise is, we took it to the next level in terms of being suitable for Enterprise use.

There is a difference between an open source project, which can be very powerful but misses several elements, which every Enterprise requires.

In terms of scalability, we offer infinite scalability, various degrees of high availability with instant auto failover, better performance, more stable performance, and tons of other things, which make the product more robust and suitable for Enterprise use.

Revenue Streams

Michael Schwartz: What are the revenue streams for Redis Labs?

Ofer Bengal: Monetizing open source has always been a challenge, as you may know.

It all started with Red Hat providing support for the software. We never thought of this as a good business model, so from day one, we decided that we do not want to provide support to the open source. Until this very day, we do not.

Basically, the idea was, “let’s add value to the commercial software and sell it.” And that of course comes with support.

Today, we offer it in various delivery models. The first one is what we call database-as-a-service.

Database-as-a-service means that it’s a fully managed service, fully automated service, whereby the customer signs up in a zero-touch manner, and everything is done automatically by the system without human intervention.

He signs up, they create a subscription, and then they start to use the database with their application, without us being involved in the process. And they pay starting with on-demand, which means, as much space they consume in terms of gigabytes, terabytes, petabytes, etc.

And then we try to convert the large customers, the large on demand customers to annual subscription, where they commit for a year. That’s one part of the business. And then, the other part is the more conventional software selling part, whereby we sell annual subscription to our software.

Again, we quantify by what we call shards. Shard is a process of a database that has certain capabilities in terms of throughputs and amount of data that you can process, etc. But, anyway, all-in-all, we quantify what we sell according to the size of the database in general, and then you can get it, either as a fully managed service, or as a software that you install by yourself and operate by yourself.

Breakdown Of Revenues

Michael Schwartz: Can you share with us any percentages of like what percentage is database-as-a-service or versus software?

Ofer Bengal: When the company started, we only offered database-as-a-service, we didn’t have fans at the beginning to create, build a large field operation. So, we decided to go for the zero-touch model, which is not very costly. We started there.

A few years back, that accounted for like 80% of ourselves. Today, it’s changed. There we have a significant sales force. Today, we have around 60 to 65% of our business is driven by field operations, direct sales, and only the rest is database-as-a-service.

R&D: Open Source V. Commercial

Michael Schwartz: With regard to R&D, how do you prioritize how much you should invest in the open source core part of Redis, and how much to invest in the commercial offering?

Ofer Bengal: With the open source, there is Salvatore, with a group of developers. He still leads the development of the open source. And then, we have a way larger team, working on what we call Redis Enterprise, which is our commercial offering.

The way to decide what to put here and what to put there is kind of very sensitive. Basically, our decision was that this fine line is drawn, so whatever it has to do with new functionalities, in terms of commands, data types of the database – that will go to the open source.

When it has to do with the deployment of the database in a large-scale, and all the ongoing operations of the database – that will go to Redis Enterprise. I think it works well for us because the database is continuing to be very popular, whereas we are doing good with selling the commercial offering.


Michael Schwartz: Redis is the poster child for what some call open source strip mining. Amazon, Google, Microsoft offer hosted Redis platform, and despite huge revenue, they haven’t contributed a fair amount to fund innovation of the platform.

If I understand the situation correctly, Redis changed some previously BSD-licensed software to a non open source approved license to prevent this opportunistic behavior.

My first question is, why not just change to the AGPL?

Ofer Bengal: Although AGPL provides a little better protection than BSD, because you need to contribute back basically any enhancement that you do to the software, we didn’t feel that this is a showstopper for a cloud providers to adopt a successful open source projects, and I’ll explain.

What happened in recent years is, as the cloud business grew, cloud providers such as AWS are adopting any successful open source project, making it a fully managed service and selling it for tens of millions, in the case of Redis, hundreds of millions of dollars per year.

Now, they did not contribute anything to the development of those open source projects, so it becomes some sort of unfair competition because they use their monopoly power, and the fact that people come to those clouds for the infrastructure, and eventually, they see all those data services that AWS offer.

To me, it’s exactly the same situation as the antitrust thing that we had in the past with Windows and Explorer, if you recall that. Microsoft was basically giving you Explorer for free, and by this, trying to capture the browser business. And there’s nothing we can do about that at the moment.

What we thought was that we didn’t want to change the license of open source Redis all together. First of all, you can’t change history, and secondly, we didn’t think it’s good, in terms of adoption perspective, etc.

So, what we decided to do was to leave the core of the open source BSD as it was. But certain new enhancements that we are adding over time, will be under a different type of license, which is still source available.

So anyone can take the source code, change it, do whatever they want with it, except one thing – they cannot sell it as a product. Because we think it’s not fair.

So, this is what we’ve done, the initial concept was called Commons Clause, it was done together with a few other companies. We are now looking at ways to make it even better for various reasons. I will not get into that today, but the concept is the same.

We think that we need to protect our rights as developers of certain software products, and avoid cloud providers for just taking that, without investing anything and monetizing it big time.

Community Reaction To License Change

Michael Schwartz: Redis Labs has Enterprise software that they release, there’s this Enterprise platform, and there’s Redis Core – do you think that the open source community is overreacting here? Isn’t this a common practice?

Ofer Bengal: With all due respect to the open source institute, I think that they are a bit detached from today’s reality, and for them, open source is like a religion.

I think that the environment has changed a lot since the ‘70s, or ‘80s, when open source started, with the emergence of cloud providers and what they do with open source.

I think that the market has its own dynamics, and that’s why you see all these different initiatives, not just by us, but other companies have started similar initiatives of trying to bypass the open source with something which is a little bit better.


Michael Schwartz: In fact, MongoDB, who’s had AGPL in the first place, for some reason, felt that AGPL wasn’t providing enough protection.

Ofer Bengal: As I said before, we always thought that AGPL does not provide protection, because the proof of that, by the way, is that recently AWS announced what they call DocumentDB, which is basically MongoDB product. I guess they took some of what Mongo had under AGPL in the past, before they changed to SPPL.

And, practically, if you read the AGPL license, it does not prevent companies like AWS from taking the product and selling it.

Progress In Harmonization

Michael Schwartz: In the previous Open Source Underdogs podcast, Mark Shuttleworth, Founder of Ubuntu and Canonical, implied that both sides need to work together, that it’s normal for this type of evolution of license and business relationships to evolve.

But do you see any progress that this may actually be happening?

Ofer Bengal: Well, I hope so.

To be honest, I have a company to run, and we need to grow the business, so this is not our main goal in life. We will be happy to participate in any such effort obviously. I’m not sure that we have any interest to lead, any efforts like this, because we have other things in mind, but I definitely think that this is required.

How To Compete With Amazon

Michael Schwartz: Redis Labs has its own cloud-hosted database-as-a-service, and although Redis Labs is pretty sizable, no one has economies of scale like Amazon, Google, and Microsoft. How do you compete in that hosted market?

Ofer Bengal: The only way to compete is with technology, and what we are doing now is taking Redis to the next level.

Redis started as a cashing system. Later on, it became a data structure engine, and later on became a database.

What we’re doing now is taking it to the next level, which means, making Redis what is called a multi-model database, whereby you can model the data in many different ways, starting with key value, data structures, graph, time series, streaming data, search functionalities, AI functionalities, and some more.

The idea is that with that, which is, by the way, the new trend in the database technology, we will be able to cover many more use cases, and by that, capture a larger market share, so that’s our strategy.

All these new enhancements are licensed differently, with this new different license, which prevents the likes of AWS to adopt it.

So, that’s our strategy in terms of competing with these companies, because, obviously, in terms of visibility, etc, you can’t compare.

Sales and Marketing

Michael Schwartz: You mentioned previously that you have built up the sales force overtime. Can you talk a little bit about sales and marketing? I would imagine you originally started with a lot of inbound, but how have sales and marketing sort of evolved since you got started?

Ofer Bengal: As I said, in the first years, everything was inbound.

We started zero-touch, which means, we drive people to our website, where they can sign up, create subscriptions, etc. Those were the first years.

After we completed building the software product, this is very hard to sell online, just by putting it on the website, so we started to build field operations – that was around 2015.

Today, it’s pretty sizable organization, we have people on the ground in all parts of the US. We have a team in India, we have teams across Europe, we have a team in Israel. And when I say a team, they comprise sales rep, they comprise solution architect, so any sale is very technical in our case.

It’s not just a sales person knocking on the door and saying, “hey, I’d like to sell you a refrigerator or something.” You need to work with the tech people of the customer, analyzing their environment, their architecture, etc, and finding the best fit. So, this is done by our solution architects, and they work in teams with the reps.

Then, we have all the marketing organization, which basically drives demand, so they work with all advertising, with a CEO, we do tons of events. This year, we’re going to do 90 different events across the world – all of that drives demand, in terms of leads.

Then, we nurture the leads to become what we call MQLs, Marketing Qualified Leads. And then we have a team of what we call SDR, Sales Development Reps, which basically pick up the phone, call these MQLs, and try to see if there is substance there, if there is a project going on that we can tie in, etc. If so, they convert them to become what we call QSLs, Qualified Sales Lead, and those are handed over to the salespeople, to start doing the actual sales work. That’s the way we work.

We also rely heavily on partnerships, we have a few very strong partners, and those partnerships are very intimate. We really go to market together, both on the marketing side, and also sales teams work together. We work like this with Pivotal, with Red Hat, now with Microsoft, and some others. So, that’s very powerful for us.


Michael Schwartz: Can you just maybe elaborate a little bit more on the partnerships? You have sort of technology partners, like you mentioned Pivotal, Microsoft, etc. What about integration partners, or other types of partners – how do you work with those?

Ofer Bengal: We work with some of the large system integrators in the world.

I can’t say that so far we found the sweet spot of how to do that, in terms of, it seems that when you get to the larger and larger companies, and as I mentioned before, we sold and worked with the largest companies in the world. We have approximately 40% of Fortune 100 companies as customers, you need really to be in direct contact with their technical teams.

So, it’s very hard to do it second-hand, that you educate someone, and they do it. So far, we weren’t too successful with that, although we very much like to leverage that, obviously because that gives you much larger coverage, but so far, our successes in partnerships were more with IT companies, who basically try to sell the entire IT suite to those large Enterprises, companies like Pivotal, Red Hat, etc.

Challenges of Being an Israeli Company

Michael Schwartz: Has being an Israeli company presented any special challenges?

Ofer Bengal: The major challenge is me spending half of my life on planes, that’s the thing. Because I split my time between the Mountain View, where we have our headquarters, and Tel Aviv, which is R&D Center.

The flight time direct between Tel Aviv and SFO is 13 and a half hours, direct. And if it’s not direct, it can easily take like 20 hours or so. Anyway, I spend a lot of my time on planes and fighting jet lag fiercely, but that’s what I have to do.

Michael Schwartz: So, you get time to listen to podcasts.

Ofer Bengal: Exactly.

Redis In 20 Years?

Michael Schwartz: Where do you see Redis Labs in 20 years?

Ofer Bengal: I think that we have a very unique opportunity, which, in my eyes, and I’ve been around, is a once-in-a-lifetime opportunity.

We have a very rare combination of a huge market, which is being disrupted, and open source, which is extremely popular, strong value proposition, with the commercial product on top of the open source. And then, apart from that, Redis is the fastest database in the world. I don’t know if I mentioned that before.

I don’t know if you remember the first time you did a Google search, to me, it was like magic: You clicked and you got it immediately. Now, today, this type of performance is expected from any modern application, especially with Millennials, Generation Z, etc, they don’t have the patience to wait, they would like to click and get it.

Now, when you look at what happens under the hood, when you click, a request goes over the internet to a remote server, a database is involved, it has to get back to you, etc. If all that happens in more than 100 ms, which is 0.1 second, you start to feel uneasy, as if something is not operating properly.

Now, the database was always the bottleneck when it comes to end-to-end application performance. And Redis is the only database that can process tens of millions of transactions per second, and all that, it’s sub-ms latency.

And with that, we see ourselves today as the enablers for modern applications to provide what we call instant experience. By the way, this was always the selling point for Redis, and I’ll claim to fame, and we push very hard on it.

Today, we offer graph functionality, much faster than any other graph database, we offer document functionality way, way faster than any document database, time series, the same, streaming, we do so much faster than Kafka, etc.

So, whatever we do, we do way faster than anyone else, and this is basically our main setting point. So, today, people in the industry know that whenever you need something fast, there is only one solution, and that is Redis.

Going back to your initial question about where do I see Redis Labs in 20 years, I’ll start from the beginning.

I think that we have a very unique opportunity, which in my eyes, and I’ve been around, is a once-in-a-lifetime opportunity, and this is because we have the very rare combination of a very large market.

The database market is going to be $60 billion market this year, which is being disrupted for the first time in its history with the entrance of new type of databases, which some people call NoSQL, etc, and many other changes in this market.

Secondly, we are based on a very, very popular open source project, which is available and being used in almost any organization in the world. That’s very unique.

On top of that, we have a commercial product, which is robust and stable now, which provides many value adds to large Enterprises on top of the open source.

Add to that the growing demand for instant experience, today, people would like everything to be instant, we provide that capability.

And add to that the fact that Redis runs originally on RAM. RAM is relatively more expensive than other media such as SSD, or obviously disk. So, in the early days, it was like a little bit of a hindering factor for wider adoption of Redis because of the costs associated with the underlined resources. But, today, there is another trend, which works for us, and this is the trend of new memory technologies, persistent memory technologies by companies like Intel, Samsung, etc.

If you compile all this together, it seems that we are on the verge of a huge opportunity, and
it’s basically for us to do it, or not to do it. And this is what I always tell the people in the company, “guys, it’s in your hands.

If we don’t make it a very big multibillion-dollar company, this means we did something wrong.” That’s it.

Advice For Startups

Michael Schwartz: The goal of this podcast is to help entrepreneurs who are starting businesses around open source. Do you have any advice for entrepreneurs who are just getting started about how to use open source software as part of the business model?

Ofer Bengal: Do not neglect the business model. Think about your business model from day one. Because when it comes to open source, that’s the most challenging issue. You know, you can build a great product, great technology, which everyone likes, you want to make a penny out of it, so think what is your strategy, in terms of what do I sell, how does this compare with what’s available in the open source for free, and basically how do I make money.


Michael Schwartz: Ofer, thank you so much for sharing your wisdom.

Ofer Bengal: You’re welcome.

Michael Schwartz: Transcription and episode audio can be found on opensourceunderdogs.com.

Music from Broke For Free and Chris Zabriskie. Our audio editor is Ines Cetenji.

Production assistance and transcription by Natalie Lowe. Operational support from William Lowe.

Follow us on Twitter, our handle is @fosspodcast.

Tune in next week for interview with Ravi Mayuram, CTO of Couchbase.

Until then, thanks for listening.

Episode 19: WSO2 – API Management Platform with Tyler Jewell

Tyler Jewell is the CEO of WSO2, maintainers of a popular open source API Management Platform. In this episode, Tyler discusses WSO2’s subscription-based business model and the future of cloud versus on-prem services.



Michael Schwartz: Welcome back to Open Source Underdogs, the podcast where we get you into the middle of open source business models.

Our guest today is Tyler Jewell, CEO of WSO2, and a partner in Toba Capital, a Bay Area VC fund.

Tyler does a pretty good job of explaining what WSO2 is about, so let’s just dive right into it.

Tyler, welcome to the podcast.

Tyler Jewell: Hey, thank you for having me.

Michael Schwartz: I’d love to hear a little bit more about your background. You worked for Oracle, Quest, Veritas, PA – how did you get here? And what did you find so exciting about the opportunity to lead WSO2?

Tyler Jewell: Well, I’ve started off my career with a degree in Computer Science, I had a very short-lived career as an engineer. I wasn’t all that good with that, but I got this amazing exposure to enterprise software, spending six years of BEA in various product-related roles.

And that really led to a career in product management. Got exposure to different companies and different products, usually related to developers, middleware integration, DevOps, and successively worked on projects of different complexity and scale. And that really helped build a global view of markets, products, and how you move those products to those markets.

And, through accident more than anything, while I was at Quest Software, and doing product management, they had a view of markets, which were combination of mergers and acquisitions, investment, and product management in the classic sense. And I got invited to work on a variety of corporate development activities, a few acquisitions, some divestitures, and for a while, leading their investment portfolio.

Once you start wandering in the corporate development, you really develop a broader view of markets, and you start to look at things about, “how do I help develop the market?” And there’s lots of ways to do that besides just building products.

And that just gives you a completely different perspective on the ecosystem, how businesses are built, and that opened up all kinds of other opportunities for me. I started doing board work, I had done angel investments, the corporate investments.

Over the years, I put about a hundred million dollars of venture capital and money to work in various companies, all related to DevOps. That got me opportunities in Oracle, and eventually allowed me to form the hypothesis on why I started coding.

And it was never a goal for me to become a CEO, but just the opportunity was so exciting, and people were asking me to lead it and go forward with it. Next thing you know, you’re the CEO of a company. Codenvy, the investments were just a wonderful experience over 6 years.

And when Codenvy was sold to Red Hat last year, the founders of WSO2 – which I’ve been on the board for almost eight years – were ready to focus on being technical founders, like, the relationship that we had, and asked me to come on board here.

So, it’s just been really one thing after the other, there’s been no particular vision in mind other than good technology, good people, and kind of developing markets.

How Does Open Source Enhance The Business Model?

Michael Schwartz: WSO2 has created a number of successful enterprise integration software platforms. How do you think that making these platforms open source enhances the business?

Tyler Jewell: I feel like that open source is this important trade-off that you make. By opening your source code, you are creating an environment of visibility and transparency that should lead to a community in all sorts of ways that you can’t even anticipate in the beginning.

So, if you can put value on some definition of the community through that transparency, then it’s a good trade-off to make. When you’re dealing with investors, I tell investors, “look, open source really is supposed to bring investors to key attributes.”

The first thing is that if the investors are paying for the intellectual property to be developed, and then the company gives up some of these rights by putting an open source license on it, then in exchange for that, they should get a significantly higher rate of distribution on their software products.

If it’s available, and there’s limited restrictions on access, they better be paired with some sort of mechanism, by which you get a hundred, or a thousand, or ten thousand extra distribution. And that’s meaningful because it should generate a lot more opportunities for you to sell your value than it would have otherwise.

The second thing is that there is this unwritten, implied contract between the open source vendor and its community. And the community, whether they realize it or not, because they have access and rights to the software, they do take on some implied obligation of evaluating the software a little bit more thoroughly, without depending upon the vendors resources.

So, there should be, overall, a much lower cost of sale because more of this evaluation process can be done without the vendor having to commit resources to do it. So, from an investment point of view, those two qualities really should materialize, and obviously that should leave to a good rate of return.

Value Prop

Michael Schwartz: WSO2 has several products, and I guess each product has its own specific value proposition. Do you think that there is an uber value proposition that is common among WSO2 products?

Tyler Jewell: The perception is, as WSO2 does have a number of different products, but we play in a single market, which is the integration market. And the integration market is really defined itself to be API-driven over the past few years.

So, you don’t do integration unless you’re going to package it up into some sort of API. And so, every product that the company has is really tailored around this narrative on what an integration platform needs to take in order to deliver on this API-driven vision.

You start with APIs, you then need API management. In order to build the APIs, you need to have an integration backbone, so that’s an ESB and message broker. And then, you need to secure all that, and that’s how we get to the identity space.

The company, for a long time, was very technically-oriented, it positioned a lot of these things as separate, individual components, but all the components were really designed around this common integration narrative. Over time, I think the company has gotten better about how to communicate that.

What Does Open Source Mean To WSO2

Michael Schwartz: What does open source mean to you? Is it just licensing the code under an open source license, or does it mean something more?

Tyler Jewell: Open source to me is a commitment to openness more than anything.

I think that the phrase “open source,” it too easily implies a licensing model associated with that. But if you’re really going to call yourself an open source business, you need to have a commitment to openness. And when you commit to openness, this creates a level of transparency that allows you to get a level of trust with your potential customers, and when you have a higher degree of trust, your interest becomes more aligned along the way.

I think that most companies start off by just looking at this as a licensing mechanism, they can put it out there, and you get this kind of distribution exchange. If you start to see that the whole business process and the workflow around the intellectual property can be equally opened up, it just really changes the dynamic of how your prospects, and your partners, and your employees engage with each other, and with the rest of the world.

That creates these aligned interests, which, then, fuel growth in profits, which are the things that businesses look for.

What Types Of Software Should Be Open?

Michael Schwartz: Not all software necessarily should be open source. What types of software do you think lend themselves to being open source?

Tyler Jewell: I’ve certainly seen it, the case where it’s an enterprise software, where if, there is a wide spectrum of opinions on the direction that the software can go, opening that up to community is a very effective way to try to rationalize and deal with all those different perspectives.

If there are lots of concerns about the configurability, or the security of the software, having it be open and transparent gives almost kind of outside credibility, and mitigates the risks that could come from very complicated software.

So, we’ve seen time and time again that that tends to work very well, when you have a consolidation of the commons of reconciliation of wide-viewpoints – open source attempts to do very well there.

I’m not all that well-informed about the consumer market or the pre-packaged software market, but it strikes me that we’ve seen less success, at least commercially, with technologies that take highly shrink-wrapped products, and then open source them, where consumers just expect them to work. It either works or it doesn’t, it’s a very binary sort of thing, and there’s not a lot of engagement.

I think we’ve seen from overtime that when products fall into that very tight sort of packaging, the community doesn’t give as much respect for the nature of the open source, and I don’t think there’s a fair equilibrium that shows up on that, so that my sense is that they’ve done less success in that regard.

Community Projects

Michael Schwartz: You announced that WSO2 will be launching more community-driven, open source initiatives in 2019 – how are these different from WSO2-driven initiatives?

Tyler Jewell: Yeah. What’s interesting is, WSO2 is 14 years old now, and when the company started a long time ago, their vision was certainly working in the integration demand, but they were building out kind of this big platform, singular platform that was an alternative to websphere and weblogic at the time.

It was really the WSO2 product, and obviously, they called it a lot of things, but the platform essentially was the product, and it was this big thing how to solve big problems.

Since then, all the products that we ship are based upon this Core Kernel that we’ve got, and it’s all WSO2 branded products that’s there. And there’s no concept of an upstream with us.

The WSO2 repository builds the WSO2 product, there’s no forking, there’s no branching, it’s a very tight linear relationship that’s there.

People who tend to adopt our open source, first have to become familiar with our brand, build some reference ability, and see that we’re a quality brand, and then they’re willing to adopt the WSO2 product line in whatever configuration they think is fit there. So, it’s a kind of a very direct, linear relationship.

What we’ve seen as very successful over the past seven years is that the nature of marketing and how products are evaluated have shifted, and that you can take any number of critical and essential components to enterprise architecture, put them out as open source technologies and build community and transparency around those, and under a different brand.

It doesn’t have to be your corporate brand, it can be under some project brand, or whatever it may be, but the important impetus there is used by your peer group.

Can you get other developers and technologists to adopt it, can you collaborate together on those things, and through that, you gain adoption and interest. For us, we’re going to be committing to more of those types of projects, and then using those components along with components from other third-party, open source providers, rolled into our products, if you will, the WSO2-branded products that we can provide support and commercial capabilities around.

I think that good companies today have a blend of these products and projects. And WSO2 has predominantly been almost only products, we’ve had some projects along the way, like, Ballerina and City, but we’re moving towards having bigger commitment to these projects along the way, whether there are projects or third-party ones.

Revenue Streams

Michael Schwartz: You don’t charge for the right to use this software, and I guess you probably get this question a lot… So how does WSO2 make money?

Tyler Jewell: We don’t charge for the right to use the software, we sell subscriptions. Subscriptions are the mechanism by how we deliver most of our value to our customers.

And subscriptions come with a couple of things. One, it gives you the right to ask us questions in development or production, it gives you an SLA , and when you’re dealing with very complicated software that’s powering trillions of transactions, now you need a response SLA on this particular issue.

It also includes updates. The updates are really what make us unique.

I think that we have an approach here that is unlike any other open source software company.

With the updates, the updates are where you expect patches, fixes, security issues, things that were unexpected when we had released software. But what makes this particularly unique is that when we need to do a patch or a bug fix, we still release that as open source, it is still Apache licensed.

And we put that into master, and it’s in the unreleased version of the repository, and it’s available for anyone to get.

So, someone can compile that, and they can put that into their environment. But the service that we provide to our customers, who are on a subscription, is, we take that patch, we backport it specifically to your version, we convert it into a binary so that you can install it, just that binary and nothing else. Then, we also test that binary pretty exhaustively, so that we have the highest confidence level that what we’re giving to you is going into that environment.

What we do for the customer is, we take the patch, we backport it to the specific version for that customer, we convert it into a binary, we test that binary on environments that largely mimic that customers environment, and so we have every level of confidence and risk mitigation that the patch that we give to the customer is going to be meeting the needs and expectations they got, without disruption to them.

And those binaries that we ship, those binaries are only available for those people on subscription.

And that’s how a big way of how we communicate that value, we get to hold to our premise, our open source principles because everything is still technically open source in the code basis, but the value that we provide is in the work that we do with the binaries and patches and the risk mitigation of that. And our customers look at that and say, “Oh, you know, well, that seems like an equitable exchange of value here. We’re happy to pay the subscription.”

Customer Retention

Michael Schwartz: I was reading in your annual report that you have an excellent track record with customer retention, so that subscription and providing the binary updates provides an incentive for customers to renew. Any challenges around getting renewals?

Tyler Jewell: If you look at our dollar-based retention rate, it’s equal to Mulesoft, which is a mostly proprietary platform on that, so we’re doing well in our particular peer group.

When customers turn on us – we do have some customers who just downgrade to a peer open source, for whatever reason, maybe they had budget cuts or whatnot – but we look at those not as negatives.

I mean, I think that on a dollar basis, you can look at it and look at it as a kind of a loss, but when we go into those counts, we say, “look, you know, if you’re going to do this, you still want to be active in the community, you can still act as a reference to us, you’re still happy with the technology, you can still give us feedback.”

So, they’re still strong contributors to the community overall, and there’s an immense value that comes with that, even if they’re choosing not to get the updates in the SLA associated with it.

And when we look at all of our turn, and every company has it, about two-thirds of our churn are companies who are sticking with us, and so it’s hard for us to look at those as losses.


Michael Schwartz: So, one question I have is about – and I don’t want to get too deep into licensing because it’s a really deep topic – but sometimes customers, I get the comment that customers know how to purchase a commercial license because it comes with reps and warranties and acceptance of liability.

But the open source licenses normally try to minimize liability and minimize reps and warranties – does a subscription address some of those issues too?

Tyler Jewell: Yeah, we, with our subscriptions, can offer different types of identities and warranties for customers. We do it both, for the patches in the binary form that we issue and for the open source code.

We have a little bit of an advantage there, we hold copyright to everything that we write ourselves on that. Even in the situation where we get outside contributions, we take copyright. And when we hold clear fork so that we can maintain that, and do all of our legal checked.

That sounds like a control provision, and it’s not so much of control provision, it’s more of you want to have complete and total visibility to the entire code stack so that you can patch any portion of it all the way down, even if necessary you need to get into the JVM, or to the OS as well.

Once you can demonstrate that, on the legal basis and the business basis, you can start getting more flexible with the legal terms that you negotiate, and on top of that, you can make higher commitments on the SLA basis. And we’ve even offered truly abnormal response time SLAs, for customers who feel that they need that.


Michael Schwartz: One of the WSO2’s priorities that you documented was to build a culture of transparency. I have to say you’re living up to that. WSO2 is really transparent. I think we’re private business – why do you think transparency is important?

Tyler Jewell: Transparency is really essential to our business, we practice it in number ways. I think it’s fundamental.

I think transparency is the most effective way to get diverse groups of people with different points of view to be aligned. And it does that because when you’re transparent, there is independently verifiable information.

And when outsiders start to absorb that information and can verify that, it allows them to build trust much more quickly. And when two different parties have trust with one another, they are able to align their interests much more quickly, and then collaborate.

This works well, not just with meritocracy, with the Apache way in software products, but we found that it works well with our internal culture – with how we prepare our marketing and sales,
how we treat our financials, we are actually pretty transparent about our financials outside and online, our hiring practices, our partnering practices.

I’ve just found that as the larger that you get, growth really comes from the momentum that you can establish. And when you’re dealing with large populations of people, and product, and partners, and customers, you can build a lot more momentum by getting everybody’s interest aligned and transparency is the fastest way to do that.


Michael Schwartz: WSO2 is hiring a lot of people. The goal said 175 people in 2019. That’s almost one person per business day. What are some of the challenges that come along with this velocity of growth?

Tyler Jewell: Well, the biggest challenge is, you need to have a source of talent that you can work with. And we found that there are really two great ways that you can find the source of talent.

First our largest office is located in Asia, and it’s in a region that has very high-quality graduates in computer science, and computer engineering and business. It’s very important for us to be able to be credible and well-respected, so that we can work within that community and do a big portion of our talent through that.

The second is that you have to really look to everybody, all your employees.

Your employees become your recruiters because it’s an environment that has a certain set of ideals and principles, and they’re working out in other communities that have people who reflect similar sorts of ideals, and so it becomes really essential that everybody is recruiting other people that they really respect along way. The source of talent is one really important thing.

The second that’s really challenging is culture and onboarding. In an open source company, so many of the people are mission-oriented. They work for the company because they have a high degree of aspiration to the outcome. They work on it for the love of the technology, they work on it for the brotherhood with the people that they get to work with. There’s a lot of that that goes on, and less so on a compensation or a financial incentive basis. I think we all work for money, but this mission orientation, this mission theme is a big part of that.

When you hire larger and larger groups of people, it becomes more challenging to get everybody aligned on that mission, and for everybody that you have an equal share of the commitment to the principles, and so you really have to start investing almost exponential higher rates, in terms of culture, as you get bigger.

Otherwise, you’re really going to start to fray at the edges, and the talent that you get isn’t going to stick around, you can have a high degree of attrition, and long-term people are going to start to lose sense of the mission as well. So, these are the two big things we face.

How To Build Culture

Michael Schwartz: When do you say invest in the culture – how do you invest in a culture exactly?

Tyler Jewell: First, you need a really clear and concise definition of your principles and ideals, and it can’t be marketing fluff. It’s got to source itself from the founder’s beliefs and the founder’s behavior.

Then, you need to have a commitment that everybody’s going to live up to those principles and ideals. You have to be willing to tell people that it’s okay if they don’t believe in this particular approach, or it’s not comfortable for them, that that’s okay, that this is maybe not the environment for them.

So, how do you go about doing that? Well, you got to have a lot of materials to explain it, there’s a lot of collaboration that you need to do with your tech leaders and your middle management across the company, so that they can embody this and practice it. We actually incorporate our principles and philosophies into our performance review system, and that’s all part of everything that we do day-to-day.

And since we’re so community-driven, and it needs to be focused on the mission and the theme, you have to invest a significant amount in people and things that allow people to participate in that community, whether it’s games, company all hands sessions, big office spaces that allow people the flexibility of their work schedule, whatever that is, everybody participates in the community in their own way, and you have to not make that equippable budget item.

That has to be kind of first on the budget. You have to put all those things in place, so that those people, who want to be a big part of our community, whether it’s our internal/external community, have every tool and resources available to them to do that, and they can’t point anything that’s holding them back on that.

That’s a big part of it as well, as steering increasingly larger numbers of resources, and time, and focus, into those activities.


Michael Schwartz: Switching gears just a little bit, WSO2 recently announced some new cloud offering. I’m wondering if you think cloud will come to contribute more revenue than software subscription in the future.

Tyler Jewell: You know, I think that Cloud is a delivery mechanism for sure. Is it going to overtake on prem versus not on prem, I’m not sure that I’ve got a particular bias on that.

What I do see happening is that Cloud is definitely changing the velocity at which new services can be brought online. I see the services cropping up on prem in the cloud hybrid everywhere, and so I think we’re looking at a truly hybrid world.

And that services are going to be able to reside anywhere, they’re going to be able to live anywhere. From our point of view, we think that that creates a wonderful integration opportunity, a lot more things that need to be brought together into a common view.

Which one of those things wins it’s hard for us to say because each and every environment has such unique and different needs. But it’s hard not to ignore the pure scale and size of Azure, and AWS, and Google – pretty impressive revenues across the board.

Experience From Cloud

Michael Schwartz: Has moving to cloud services created a friction in the type of business that you were? Because it seems, like, in the cloud business it’s about operations, whereas in the software vendor business, it’s more about customer relationships and product innovation. Has there been any growing pains of moving into this cloud business?

Tyler Jewell: We definitely had a lot of growing pains there.

Right now, our public cloud is really just a public cloud variation of our on prem products. So, it’s not much of a hybrid situation, the value propositions are largely the same in that regard.

I think that what we’ve really figured out is that in order to run a public cloud, we had to operate our products in ways that we never operated them before. And that, in turn, caused this to redesign a lot of basic primitives in our products, related to update, configuration management, operations, and whatnot.

And that, in turn, is actually one of the big reasons why we’ve had the kind of growth over the past couple years, because 35% of our customers are running our products. Even though it’s an on prem version of our product, they’re running it in a cloud style.

So, we basically ate our own dog food, and going through that process actually caused us to rethink all sorts of things at the end of the day. That was probably the biggest benefit we got.

Sales Cycle

Michael Schwartz: What’s the typical sale cycle? Do people find the open source, and then call you? Or is WSO2 more active in generating business?

Tyler Jewell: We are more of an inbound business, believe it or not, because we put our technology out there, we evangelize it pretty aggressively. So, customers tend to approach us, and they’ve already got a project in mind for that.

They approach us in one or two ways. About a third of our customers approach us through a partner, so, a system integrator or reseller that they’re already working with, and a lot of those partners are equally committed to open source, and we are their open source vendor of choice in that regard.

Then, other customers have architects and VPs of engineering, who have been designing systems, and they see that we could fill portion of their architecture, and they contact us.
It’s almost always the case when, by the time they contact us, there’s done a lot more evaluation than you might be surprised.

And they’re contacting us because they’re looking for advanced system design, to hear the total story maybe they’re ready to engage on a subscription. It can go any number of different ways, and that process takes about 3 to 9 months. With most customers, sometimes it’s up to 2 years, sometimes it shorter than that.

Customers come with us, they come to kind of really two starting points.

One starting point, which is obvious, we have a lot of different components, is they’ve already got an architecture, the architect is very confident that they’ve got the right design, and they’re just shopping for certain components. “I just need an API Gateway.”, or, “oh, you know, I really need a message broker.” and they’re not shopping for anything else.

And so, their comparison-shopping, us against the other open source components that they’ve come across, and it’s kind of a best-of-breed sale, and that sort of sales process and a sale cycle is very well-structured. The requests are pretty standard, and we have lots of ways to service that with our sales, and our solution architects, and our partners.

The other type of customers that come to us are customers that have broad business problems.

They know that they want to build all kinds of services in the future, they know they need a broad integration backbone, they don’t necessarily know what the best architecture is yet. And they’re looking for us on a consultative basis.

In that situation, we spend a lot of time, with either our partners, or that account, doing solution design, putting hypotheses together, and it’s almost like an advertising agency, where you have to say, “Here are five or six different ways you could approach these broad class of problems, and here’s all the different configuration of, either our technologies, or other technologies out there that would let you deliver on that.

In that situation, it’s a longer-term sale, it’s highly consultative. And if you do a good job on the consultative side, then they’re usually more willing to pick our technology stack, get into a subscription with us, and sometimes even turns into a strategic relationship.


Michael Schwartz: It seems, like, for anybody in the enterprise integration business that channel partners are going to be important, but I’m wondering, are there other types of partnerships that have also been important for WSO2 to grow the business?

Tyler Jewell: There are really essential partnerships that happen in the open source realm in the ecosystem itself. Everybody’s competitive to each other, and everybody is complementary to each other now, and so it’s really important to build key technology relationships with other vendors, as a way to demonstrate confidence in the software that you’re building there.

I think that WSO2, historically, had kind of a very vertical stack technology that it has built from the ground up. It hadn’t done as much of that as some other companies had, but over the past couple years, we’ve been shifting towards more of that. And there are important relationships that we’ve got budding with vendors like Red Hat and Pivotal, which are, on one hand, both complementary to us, and competitive at the same time.

Those are pretty essential when we call those technology partnerships to go along side of the channel partnerships that we got.

WSO2 In The Next 20 Years?

Michael Schwartz:You have a 10-year product patch lifecycle, which is really long. How far ahead do you look? Do you look 20 years ahead in the future? Or, another way I could ask a question is, where do you see WSO2 in the next 20 years?

Tyler Jewell: Oh, well, you know, what I will say to that is, the company’s raised $45 million over these years, and for the first 12 years of its life, it was not profitable and cash flow positive.

So, I think that when a company is going through that sort of phase, it’s searching out for product-market fit, and when you’re looking for product market fit, and you’ve got a cash runway, you’re kind of forced into a horizon, which is somewhat tailored to your cash position along the way, although really good founders will look way beyond that.

With the company now cash flow positive and profitable, it completely changes our horizon, and I think we really think of things, and probably we like to think of them as 10-year horizons, although the pace of technology is moving so fast that 10 years just really, you know, kind of shock the hell out of me.

But we certainly are making bets that I’d be surprised if we don’t see any revenue. It could take us three to five years before we see revenue on some of those bets.

And it’s really refreshing to be in a position, where you can take those sorts of risks on as a company, while still supporting your existing customers. And for us, I think the biggest shift is, all of integration over the past 14 years has been essentially done, center of excellence, a big, ION middleware. And that’s even our classic stack, but that’s shifting towards a completely distributed, decentralized mode, driven by containers and kubernetes.

So, we’re just kind of over the moon tickled because we get to take all this domain expertise that we’ve got, but we’re basically throwing a lot of stuff out the door, and say, “If we had to re-envision all this stuff from a developer first code, first decentralized, first point of view, how would you make it all work?” and you just approach things very differently.

We’ve got about a hundred employees, working on things that I would say related to this sort of thing, and I really don’t anticipate seeing revenues from any of those things before ‘20/21. It’s that sort of rising that you got to be playing with.

Final Advice

Michael Schwartz: My last question is, any advice for new entrepreneurs about launching a business around open source software?

Tyler Jewell: Well, if you’ve already made the decision to go open source, and now you’re creating a business around that, be reflective of what are the principles and values for why you did open source the first place.

You need to hold to that and find a business model that allows you to not compromise on those elements – I think that’s really important here.

The other thing is to recognize that, take it one step at a time. Businesses are not built overnight, they’re built over a very long horizon, and you just need to have a mindset of just keep taking one step forward. And as long as you keep doing that, things will work out.


Michael Schwartz: Tyler, thank you so much for sharing your thoughts and experiences today.

Tyler Jewell: This was a real pleasure for me, Mike, thank you for having me.

Michael Schwartz: Transcription and episode audio can be found on opensourceunderdogs.com

Music from Broke For Free and Chris Zabriskie.

Audio editing by Ines.

Production assistance and transcription by Natalie Lowe. Operational Support from William Lowe.

Follow us on Twitter, our handle is @fosspodcast.

Tune in next week for an interview with Ofer Bengal, CEO of Redis.

Until then, thanks for listening.

Episode 18: Moodle – Open Source Learning Platform with Martin Dougiamas

Martin Dougiamas is the Founder and CEO of Moodle, the leading open source learning platform. Moodle empowers educators to manage coursework, track class analytics, and communicate easily with students. In this episode, Martin discusses how Moodle leverages partners and revenue sharing to grow the business.



Michael Schwartz: Welcome back to Open Source Underdogs, the podcast where we strive to teach the next generation of software entrepreneurs how to use open source software as part of their business model. Our guest today is Martin Dougiamas, Founder and CEO of Moodle.

If you aren’t familiar with the learning management system Moodle, here are some stats: There are around 100,000 Moodle sites out there, with around 150 million learners in 230 countries, who are taking 18 million classes.

Martin is one of open source software’s most passionate advocates.

After all the requisite trials and tribulations, he’s built a super successful global business that’s had an epic social impact.

Martin, thank you for joining us today.

Martin Dougiamas: Hey, Michael, it’s a real pleasure, thank you.

Michael Schwartz: So, how did Moodle get started?

Martin Dougiamas: My background is that I come from Central Australia, I grew up in the deserts out there, and my school necessarily was the school of the air, so over the radio.

There was no internet back then, shortwave radio bouncing off the atmosphere, and I was used to studying remotely and doing things that way.

When I got to the city at about age 12-13, I was a year ahead of other students. And fast forward back to university, I was helping the staff of the university I was working at, to engage with a new internet technologies, and I knew it could be a lot more interactive than it was.

As soon as the webcam came in, internet Skype came in, it became a very one-way transmission media. I was like, “no, no, it’s got to be more.” So, I started developing my own software for interactive learning and collaborative learning particularly. Then, I was doing a PhD in education on top of my background and computer science, and Moodle is right there in the middle of all that – it’s between the technology and education.


Michael Schwartz: So, what’s the difference between a learning management system and a content management system – couldn’t one use a CMS for teaching?

Martin Dougiamas: Really, you could use email for teaching, if you’re good enough at teaching, you can use anything, you just use a whiteboard or a telephone.

What an LMS gives you is the affordances around the teaching processes and all the workflows.

The grading, we have tools in Moodle, for example, for peer assessment, so if you’re managing a thousand students, and you want them all grading each other, there’s a lot of management of that needs to happen, and that’s the kind of thing that Moodle’s good at.

Why Free

Michael Schwartz: The goal of the business is inherently to make money and return money to investors, and so, how do you align the social goal of doing this good to get the software into educator’s hands, the benefit of students, and making a return on equity?

Martin Dougiamas: I would disagree that that is the goal of a business. That is a model of business, a particular capitalistic model that has grown popular from the US.

Business is literally being busy. It’s an activity, so there are many ways to define business. The social good, and the social mission of a business defines the business. We aim to break even, we aim to pay for our activity, to pay all the people who are involved, that, essentially, are operating as a non-profit.

If there are excess funds at the end of the day, it goes back into the business for the next year.

It’s always operated like that ever since I bootstrapped Moodle, without any investors, 17, 19 years ago.

Investor Objectives

Michael Schwartz: You mentioned that, I think it was last year or the year before, that you managed to find investors who are aligned with this vision, but how do they feel about that? Because, at some point, they need to make a return on their investment.

Martin Dougiamas: The way that works is, as I said, we bootstrapped it for many years, so I was 100% owner of Moodle up until last year. What I found was that the motto we were operating under was growing, very consistently and very evenly, at a kind of a flat rate, not an exponential curve.

And it was starting to become urgent that we step up against some very large well-funded competitors in our industry, including Google’s, and Microsoft’s, and things like that.

So, to get that rapid acceleration, I did look for a financial partner who could help us out. I rejected 50 VCs. Really, around 50 that I talked to, because the conversations were always about, “How much profit will I make in so many years?” and they wanted all that kind of stuff.

I eventually met a family – actually that was in Tel Aviv, a conference I was at – a French family, who really understood the mission that we were aiming at, and supported what we were doing, and wanted to help.

From their point of view, it’s not about profits every year, if they want to return their investment, which they expect to be in decades rather than a couple of years. If it’s a growing business, and I own a percentage of it, in the future that percentage will be worth a lot more, and they can sell out and step off the elevator, if you like at that point, without any harm to the business because somebody else was stepping into the elevator at that point.

It really doesn’t have to be about profits to be a growing functional business that an investor can do.

Evolution Of Business

Michael Schwartz: Can you talk about how you generated revenues over the years, how did you generate revenues initially, and how that changed over time?

Martin Dougiamas: I had a computer science background first, I had the educator background, for the design and the content of the project second. And then, I was living on a scholarship actually, almost nothing, you know, a shoestring budget.

And then, I had to learn how to do business, so it was like this, the first stage was, people started asking me for help with the software, and I’d go, “Yeah, sure.” I was helping them for free as you do with a small project.

Eventually, I’d just start saying, “Look, I’d have to charge for this, you know.” And within a very small time, I had something like 70 clients, who were universities and businesses around the world. Silicon Valley Bank was one of them in the early days, in the early 2000.

And I was charging for services, and I got to the point with that 70 clients that I realized I was spending all of my time servicing them and not on the software, and I had to make a decision which way I was going to go. It was like, was I going to be the CEO of a big service company that made the software, or was I going to focus on the development, and I chose the second part.

What enabled me to do that was that some other people in the community were saying, “we’ve been doing this for a long time around education, technology, we’d love to do with Moodle – why don’t we become partners, and we’ll pay you a royalty?”

And with one or two of them, I developed a contract, which is a royalty contract, and they pay roughly 10% of the gross revenue on any Moodle-related services.

In return, they get to use the trademark that gets to be promoted around the community, they get to use the trademarks that we have all over the world, so that was such a real win-win situation, and that’s been the primary business model from, let’s say, 2004 until today.

We now have 80 Moodle partners around the world, but they range in size from very small companies with just a couple of people, up to large companies with thousands of people.

Royalty Collection

Michael Schwartz: And it’s basically on the owner system?

Martin Dougiamas: Yes, and that’s something that has been a slight problem enforcing the royalties. In the early days, it was much easier, the trust factor was very high, there were no problems. As we got more partners and things got larger, we started to feel the need to check up on these things, so just relying on royalties is not the only revenue stream in the future. We want to have a little bit more different control as we go forward.

Other Licensed Tool

Michael Schwartz: Are there any license components that you’ve developed, or are thinking about developing in the future?

Martin Dougiamas: There’s been none up till now, but there is something we have developed, which I can’t even tell you about, because it’s going to be launched next week in London. I’m going to be there.

Michael Schwartz: On February 27th, Moodle launched Moodle Workplace, a solution only available to a select group of premium Moodle partners.

Martin Dougiamas: But it’s a set of components that sits on top of Moodle for a very specific market, and markets include higher education, and K-12, and the workplace market. Workplace Learning is, in fact, where we get most of their revenue from.

So, it’s the workplace market where we were addressing with these extra products. And we feel okay about keeping those within our partner network, to give our partner added value. And it’s type of market that doesn’t mind paying for services like that.

Customer Segments

Michael Schwartz: You actually anticipated my next question, which was, how do you segment your customers?

Martin Dougiamas: I mean, it’s a lifelong learning, right from kindergarten right up through the workplace.

Moodle’s used in a lot of very interesting and diverse places. I was at the World Bank a couple of months ago, the World Bank was using Moodle in their development projects for 10 years. Every one of their development projects has an education component, and they usually use Moodle for that.

In the development space, in general, globally, there is a lot of use of Moodle. It’s also used by fire stations, in hospitals, everywhere you find learning and training, you find Moodle’s being used. We just focus on those three big sectors the most: K-12, higher education, and workplace, with the development side of things becoming rapidly rising one.

Moodle SaaS

Michael Schwartz: One of the previous podcast with MongoDB’s founder, Eliot Horowitz, he stressed how important it was for open source companies to launch cloud services.

I was reading a little bit about Moodle.net, which I guess is still in the development phase, but do you have any expectations around Moodle.net contribution to revenues in the future?

Martin Dougiamas: We already have a SaaS offering and have had for a couple of years, it’s called Moodle Cloud. And that’s, just press and go get a Moodle site very subscription-based, the traditional model of SaaS, which is very well understood, and that’s been growing continuously since we started, and we have something like 30,000 Moodle sites on that platform. It’s definitely the part of us going forward.

Moodle.net is actually the third step, it’s something I’ve been trying to build for many years. This is going to be the most successful because I’ve actually put a lot of resources fund at this time. And if you’d say it’s marketplace for content – pretty much – and a place for professional development of educators.

They are smart people, but any software that you put in the hands of people, it’s not going to be used until you are trained in it, and you have some support. So, just putting Moodle with all its many, many, many features in the hands of educators isn’t enough. We are really focused now on the professional development side.

Moodle.net is a social network that enables our community to help each other, in a very specific, direct way, so that, for example, a teacher who’s teaching Portuguese to German speakers can find another teacher, teaching Portuguese to German speakers, and then they can work together, share content, and share things they find on the internet with each other, as well as thinks they’ve developed with each other.

Now, in there, we have a whole plan to have a backup place of more advanced services, so that will bring revenue in the future. But for now, we’re just really focused on making it a really powerful, social network.

Moodle App

Michael Schwartz: You mentioned that most of the largest contributor to revenues was the service partner network is cloud number 2 – and is there a number 3?

Martin Dougiamas: The third one would be, we have branded apps, so we have a free app that students use to connect to the Moodle side. If they want, they can also use the web, but the app has added the advantage of working offline, and, of course, it’s better on touch screen. Students can do there courses on their mobile devices.

We sell a branded app, and that enables the institution to make their app with their name and their logo in the app stores, and it’s something that we create and maintain for them. So, that’s another upcoming revenue source that’s growing too.


Michael Schwartz: Switching modes a little bit, can you describe your approach to building the team – how does location get its way into the higher equation, and what else goes into you figuring out, like, who do you want to bring onto the Moodle team?

Martin Dougiamas: I started in Perth, Western Australia, we never made a big deal out of that, so I know a lot of people don’t know it, but the bulk of the team is here in Perth.

Over the years, people have been coming through the community activities, and got really interested in being part of it, and seeing more of a way. It’s a lot of the people we hire we already know they have some experience that prove themselves, by taking part in various things around the projects.

It’s not just development, we also have a lot of conferences, we do about 20 conferences a year around the world. There is a lot of training, and all the partners, and all that is activity support stuff.

People come from my network. Perth is not a good place to run a business from, it’s really the end of the internet. So, you go right to the end, and you turn left, and that’s Perth.

I’m traveling a lot up in the north hemisphere to be closer to where all the people are, up in Asia, and Europe, and North America, and South America, for that matter. And more, more Africa.

Second headquarters is now in Barcelona, and we have 20 people there already, and that’s growing rapidly. That’s a lot closer to where the action is. It helps if people are near one of the big offices, but probably, I think a quarter of the company work from home remotely.

Moodle In 20 Years

Michael Schwartz: Where do you see Moodle in the next 20 years?

Martin Dougiamas: For me, it’s nothing less than building the infrastructure of the future. I mean, what do we want our infrastructures to look like? It’s basic as road, water, and electricity.

Education is so important for us as a species that it underlies everything. You look at people voting at elections, it’s all based on education and information that they have, and giving people context.

I’m a strong believer that the more wisdom you can accumulate, the more compassion you have, the better human you’re going to be.

So, for us, empowering educators is really about improving the world and to making open source a really good, high-quality, free software be a part of the infrastructure, as easy as finding a power point in the wall and sticking your device in it, and it just works, and everything charges up.

Moodle is already the mainstream product being used in education everywhere in the world, and it’s a step from there. When I go to countries now, I find them able to open doors, talk to very high-level people about their infrastructure that’s underneath all of their schools and universities, and talk to them about how can we move forward together to build that infrastructure to a higher, more efficient level, so that they are not wasting money, purchasing licenses from some software that they’ll never own – but that they own and control their own infrastructure, and contribute to the development of that infrastructure. So that it’s simply the best choice.

That’s basically what most of my work is now, and there’s so many opportunities in that area that I feel very confident that open source really is the future, and it’s not just my industry, it’s all the industries.

Look at Linux, how, of course, based on previous flavors of Unix, and so on, but if you look at all of these .coms, and all the infrastructure that’s driving all the websites and, you know, this tool we are using now to record this, underneath it all is Linux, just silently sitting there, quietly doing its work and making stuff happen, and that’s terrific.

You know, no one really thinks about it, talks about it very much anymore, but that’s how the world should be.

Open Source V. Cloud

Michael Schwartz: Do you think that we’re fighting an uphill battle against the cloud though, where there’s sort of this move to centralization and not operating your own infrastructure?

Martin Dougiamas: I think actually that is a phase, and that the idea of distributed and federated systems was kind of ahead of its time at various points in the last decade or two.

But I really think it’s making a comeback. Things like the GDPR, and it’s public starting to realize the control that very large profit-focused companies can wield over us.

If it was easy to be part of an alternative, I think people would more and more. And so, as the technology improves, and as we improve, I think – I don’t want to sound like a zealous idealist because I really don’t think I am, I’m quite a practical person – I think as technology gets easier, and you can make a decision based on knowledge and wisdom then, why wouldn’t you?

For example, if you could be a vegetarian, and eat food that tasted like meat and had all the advantages of meat, but you were a vegetarian, I think a lot of people would switch because there would be no downside. So that’s what we have to get to.


Michael Schwartz: You’ve probably been following some of the discussion in the community about licensing, and the move away from the GPL, and also the introduction by certain open source companies of new licenses, to prevent large SaaS providers from using their software, without contributing back in any way. Do you have any thoughts on that trend?

Martin Dougiamas: I’m mixed, because I’m still a bit old school, where open means open, and freedom means freedom, and you’ve got to give people a freedom.

But I’ve also experienced the case, where a lot of people take advantage of us, without giving back, I can put the gilts on them that goes only so far.

Really, it’s going to be about them finding the right leverage for people to be part of your project, and to bring them in somehow. And, again, you’ve got to make it so that it’s just as easy to do so. You’ve got to make it in their interest to do so.
And it’s not easy, but I think there is always a way if you’re creative and you look at it. And we have a lot of companies who didn’t have to be Moodle partners, but have become Moodle partners because their benefit’s there for them.

And we don’t have to go around strong-arming everybody for that to happen. We hopefully use more carrot and less stick. It will depend on every project, of course.

Moodle Users Group/Foundation

Michael Schwartz: Moodle did a great job partnering with external organizations, not just your system integrators, but, for example, there’s a Moodle Users Association. Did the foundation ever get started? And could you also talk about the Users Association?

Martin Dougiamas: Sure. The Users Association was actually launched by myself, I started it, and we handed it over, so we have no control anymore. We just created it as a structure and let it go. And it’s going well!

That’s an organization of users who pay membership to be part of a decision-making process that decides how to spend all that money from the membership. They are restricted to only paying for core improvements of Moodle.

We regularly get hired by the association to develop things. That’s what the users want. So, this is working out really well.

It also gave a lot of people a way to contribute to Moodle that was compatible with their organizations. Universities don’t just sign checks and give them away, they have to subscribe to things, they have to have types of structures to be part of.

The Moodle Foundation is for a different purpose, it’s for being part of certain research-based proposals and projects that happened, primarily in the EU, but also elsewhere.

In Europe, there’s millions and millions of Euros being applied to educational-related projects. And very often, people use Moodle to satisfy those projects. So, they’re like, “free is like funding.” They use Moodle, they build something. After 3 years, nobody cares. It just kind of has no major plan, and their project dies. It’s a complete waste of public money.

The Moodle Foundation is designed to be an actor in those situations, where it can bring in the value proposition that we will make sure that the money goes into this project, if there’s any development that occurs, that it gets done well, that we make sure it gets into the main code base, that it is supported by the main Moodle enterprise, for years and years to come.

That helps those projects be more successful, get starting in the first place. And it also means that public money goes toward open source software that everybody benefits. And sometimes a nonprofit organization needs to be doing this thing – it can’t be a company. So, that’s why the Moodle Foundation is a non-profit, and it’s based in Brussels.

Protecting IP/Brand

Michael Schwartz: Sometimes, the foundation is used to hold the trademark – have you ever thought about safeguarding the code base in any way, for using a foundation for that purpose?

Martin Dougiamas: I have, and I know that’s a bit more common to do it around that way, but there’s no downside with the way we’re running now.

The code base is actually under my own name at the moment. The Moodle Company is involved there, although we are the stewards of it.

I think if the Moodle Company disappeared, it wouldn’t have particular control over the software that the people couldn’t get around. So, yeah, we thought about it, it’s probably too much trouble to go to changing at all like that without any real benefits, so it’s probably not going to happen.

Closing Advice

Michael Schwartz: My last question is, do you have any advice for entrepreneurs who are starting a business around open source?

Martin Dougiamas: Yes. I would say, get a vision and mission, strike early, like, take some weeks when you’re doing nothing else and really, really, really think about what you’re trying to do if you want to have a very clear, social mission, in my opinion.

We are literally all living on a little pinprick of dust floating in space. So, keep that context in mind.

If you are creating your project, what are you trying to do with it? What problem is it really solving? How is it helping the planet? How is it helping the rest of us? And make it really meaningful for yourself, because if you don’t have some meaning like that driving you, you might not have the energy to keep going for years, years, and years when things seem grim, when things seem difficult. You’re going to need that clarity of vision.

I’ve refined our mission and vision a couple times over the years. The one we have now I feel very happy with, I’m happy to stand behind it, communicate it to anybody. We have very strong values as well, we have five values of education, innovation, respect, integrity, and of course, openness.

And having those in your mind, in your pocket, it helps you structure your organization, helps you plan your activities, helps you choose what to work on and what not to work on. I’d say that that would be the most important advice I would have given myself at the beginning. It is I knew the stuff intuitively, but I couldn’t express it all, I couldn’t lay it out, it wasn’t on that website. And it would have helped.

The second thing I would think of, I wouldn’t worry too much about monetization at an early stage. I would make something that people really want because if it’s wanted, if it’s needed, opportunities will come up. You would work it out later on. And you just have to find some way to stay alive. That may involve doing another job for a while, just, I don’t know, moving out into the countryside or something for a bit.

If you got a strong mission behind you, it’s not going to be a problem. The money will sort itself out once you have something that’s of value. So, it’s probably the two main things I think I’d suggest.

Michael Schwartz: That’s great. Martin, thank you so much for your time today.

Martin Dougiamas: Absolute pleasure, Mike. Thanks for the chat and the opportunity, and I’ll see you around the world somewhere, I hope.

Michael Schwartz: Okay, and best of luck with Moodle.

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

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

Introducing our new editor, Ines.

Production assistance and transcription by Natalie Lowe. Operational support from William Lowe.

Follow us on Twitter. Our handle is @fosspodcast.

Tune in next week for one of the biggest open source companies you might not have heard of WSO2. The CEO, Tyler Jewell, has a ton of interesting observations about the industry and entrepreneurship.

Until then, thanks for listening.

Episode 17: Timescale – Time-Series SQL Database with Ajay Kulkarni and Michael Freedman

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.



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.


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.


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.


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.

Episode 16: Liferay – Digital Experience Software with Bryan Cheung

Bryan Cheung is the Co-founder and CEO of Liferay, a leading provider of open source software. Liferay’s digital experience platform is used by companies like Airbus, HPE, and NASA. In this episode, Bryan discusses how Liferay was founded to achieve both business and social goals — and how they stayed true to their mission over nearly two decades in business.



Michael Schwartz: Welcome to episode 16 of Open Source Underdogs, the podcast where the founders of open source software companies help you transform your business model into a successful venture.

Bryan Cheung is a Co-Founder and CEO of Liferay, an open source content management platform that grew from a church basement to a hundred million in annual revenues without ever taking outside capital.

I read an interview with Bryan in 2018, and it was one of the inspirations for this podcast.

I created a short link to the article. You can read it by pulling up the URL: gluu.co/Liferay.

If you’ve been listening to the podcast in order, there are only three companies that we’ve interviewed that haven’t taken venture capital. They are:

1. Canonical
2. NextCloud
3. Liferay

What I really liked about the Liferay story is that it provides an example of a well-executed business that stays in control of their destiny.

I don’t want to give up too much here. Apologies in advance if the audio quality is not 100%, the interview was recorded on speakerphone. But without further ado, let’s cut to the proverbial tape.

Bryan, thanks a lot for joining us today.

Why Bryan Joined Liferay

Michael Schwartz: You mentioned in one of your previous interviews that you were a reluctant CEO – how did you happen to be one of the founders of Liferay?

Bryan Cheung: I call myself a proto millennial, I’m a little bit older than the generation we typically associate with that moniker, but closely enough maybe where it was important for me to live my life meaningfully, and in early 2000s, right before I started Liferay, I was traveling a lot overseas, I was involved in volunteering with the youth group.

I was just thinking about how I wanted to spend the rest of my life and doing it for, you know, some kind of capitalistic enterprise probably wasn’t top-of-mind for me. But when I met my co-founders and was presented with the opportunity at Liferay, it sounded compelling enough that I thought it was worth giving it a try.


Michael Schwartz: So how did Liferay actually get started?

Bryan Cheung: Brian Chan, who is the Chief Software Architect, started the project at the open source project in 2001. He had been working on the software for about three years, and one of his motivations was, he saw a lot of large enterprises having access to quality software that just wasn’t affordable for nonprofits, and so he started to see the open source movement.

And seeing open source software, being available essentially for free, as long as you are willing to put the sweat and work into making it work, he wanted to make enterprise portal software available to nonprofits as well.

So he was doing that for a few years. One of our first users was a corporate in Los Angeles, he was doing some consulting for them, and at some point the project barged enough that we needed more consultants to join. And it was right around that time that he thought maybe this could turn into something bigger, so he approached me and a couple of the other co-founders about basically starting a company at that point.

So in the middle of 2004, we each left our respective jobs and started Liferay. I have been working as a consultant with the Universal Music, one of our other co-founders had been with Accenture, and another one had been I believe a government contractor of some kind. We kind of had these stable things going on, but we decided to take a risk and start the company in 2004.

Michael Schwartz: Originally, you did professional services, and then at some point you pivoted the business into product?

Bryan Cheung: That’s right. So for the first five years or so, it started with the four of us, and then we started hiring friends of friends as co-workers, and we grew the services practice. Because the software was open source, it was freely available to anyone who wanted to download it. It did take some work to get it implemented, and really the nature of the platform was, it was intended to build custom solutions, while also reducing the time and effort for that, by providing a lot of functionality out of the box.

It was nice because we could propose Liferay as a way for a large Enterprise to get, let’s say a customer portal or an intranet that fit really well with their requirements, whether it was the systems that got tied into it or the user experience on the front end, but it would cost a lot less than they would expect because there were no license fees, and also a lot of the functionality that they would need was out of the box, and we just needed to tweak it a little bit.

In the beginning, and even until now, we haven’t had external funding, and so services was a nice way for us to build up the company and fund a business while we figured out our business model.

Then in 2009, we saw a lot of the other open source leaders like JBoss and MySQL, doing sort of a Enterprise Edition approach, where they would have a stable version of the software that had a full enterprise end-of-service life policy, professional support, maintenance, bug fixes, as well as some legal insurances.

And we saw that model working pretty well for some of the other players in the space and we tried it out, and that really was successful for us. We went from being 90% services-driven up until 2008, to be 90% subscription-driven within a couple of years.


Michael Schwartz: You mentioned stability, and that was one of the things that interested me about the previous interview – how do you think the stability of the platform relates to the ability to commercialize it and to scale?

Bryan Cheung: So in your interview with Mike Olson of Cloudera, he mentioned that he had targeted market of large enterprises, financial services, companies, hospitals, insurance companies, and we experienced something similar.

When you think about the nature of enterprise portal, customer portals – that tends to be something that larger enterprises typically want, a lot of those have a longer relationship with the customer. If you’re an insurance company, they have policies that you want to renew every year, and in the stressful event of a claim, you probably want the customer to be able to transact that as quickly as possible.

So with these kinds of large enterprises that used the functionality of Liferay, they really needed that stability, they needed that assurance that the software wasn’t going to change over a long period of time. That whatever they purchased a specific version for, those were the features that we’re going to work, and that we were going to introduce new things that might be innovative or fun, but might disrupt the experience for the customer.

That really was the core value proposition of our subscription, and it’s what’s really allowed us to monetize.

I think, again, Mike Olson was sharing similar lead that they were able to key in on specific enterprise needs, like compliance or large-scale operations that were specific to the needs of large enterprises.

Now, in terms of innovation and new features, we were also able to do two things. One is, because the open source branch continues to be developed after the release of the stable enterprise branch, we are able to continue to release those new features there. But we also introduced the marketplace, so that some of the additional functionality can be delivered via plugins that customers who want to use these features, can do so by installing it.

Maintenance Period

Michael Schwartz: Red Hat gives a really long, 5-year lifetime product, but we found it’s really hard to maintain those old versions – how long is it stable?

Bryan Cheung: Typically, for each major version that gets released as part of the subscription, we have at least four years of maintenance and updates. Again, these are just bug fixes, and stability, and security updates. And we will continue to support the product even after that 4-year period.

I believe the total support period is about 5 to 7 years or so, to the point where it does go into limited support, where it’s really just more our team advising the customer about known issues and how to work around them, but it is a pretty long life cycle.

Portal V.CMS V. DXP V

Michael Schwartz: We’re getting back to the business, it originally started as part of a portal CMS platform, but the offering has become more expensive so now you describe it as a digital experience platform. Can you talk about how and why that change came about?

Bryan Cheung: You know, one of the challenges we’ve always had with Liferay was, we came from the portal space, we were also known for our CMS capabilities. But those two monikers were a little bit limiting.

When you think of CMS, you think, “Oh, you guys are just like WordPress, Drupal.” And then when you say the word “portal”, people think, “Oh, isn’t that from like 1995?”

And Liferay, a lot of our customers would say things like, “Oh, well, you guys are definitely more than just a portal or CMS.” Or they’d say, “Well, we use Liferay when we need a portal, but we don’t want to use a traditional portal.”

And so, what do I mean by all that? Well, when you think back to how I was describing Liferay earlier, there are sort of three things that people need to Liferay for. One was, they had a lot of very specific business needs. Whether that was systems to integrate with, or customer requirements that needed to have some extra development. But they also needed to quickly build a solution that often used standard functionality and features that would be things like content management, document management, collaboration features, workflow, and forms.

And then they needed to wrap that all up in a really great user experience on the front end. Of course, that started with just web, but extended later to mobile and different connected devices.

So when you call Liferay a portal or CMS, you don’t really fully capture that full range of capabilities, which is, you know, you can get this solution built really quickly, but it’s flexible, customizable, especially for large enterprises, especially for B2B and B2C industries that have that long customer relationship.

We landed on the term “digital experience platform” to try to capture all of those nuances.

I’ll probably be the first one to admit that it’s kind of an industry insider term, no one’s really looking for a DXP, they’re not probably going to google for it unless they heard it from us, or from a competitor of ours, or from one of the analysts.

It’s not the greatest theme I would say, but we wanted to at least try to get out of some of the preconceptions people had about terms like Portal and CMS, and it seems to be doing the job for now.

Value Prop

Michael Schwartz: What would you say is the core value proposition of the Liferay platform today?

Bryan Cheung: It really is connecting companies to their customers through a great user experience, being flexible enough to address those custom business requirements for a large enterprise, while all being easy to maintain, and to have a low cost to market, and flexibility, and innovation for future dates.

Enterprise-Only Features

Michael Schwartz: Are there different features for the enterprise and open source platforms, or is it just a different licensing sort of packaging different?

Bryan Cheung: So we do have some additional features around the enterprise subscription.

One of those is our integration with Elasticsearch. Elasticsearch obviously is something that larger enterprises tend to need, and so we do have an option for customers to purchase that. And then, of course, it is the maintenance and support services provided by our support organization.

One of the things that we hear over and over again from our customers is that we have a world-class support group. Tthey really go above and beyond to resolve issues for them. And more and more we’re also moving toward figuring out how to make our customers successful.

I think in the early days of open source, it really was about, “Hey, here’s this thing that I used to have to pay for that I get for free.”, and that’s really cool. Now, I think a lot of people realize that technology is complex, and having access to the software is just really step one.

How do you actually make the most of it, how do you implement it correctly so that you get the most from it, how do you avoid making some of the mistakes that others have made before.

And maybe most importantly beyond just the software. If I’m trying to engage customers through my site, or if I’m trying to more efficiently manage my business operations through digital means, or if I’m trying to aggregate all the knowledge I have in a company and find it quickly, there are probably some things I need to do, organizationally. Cultural changes, business processes I have to implement alongside the solution in order for it to really deliver the value that I’m looking for. And how can I partner with an organization like Liferay, to understand what those things are, so that I don’t waste my time figuring it out myself.

We really want to build that part of our organization out as well to complement sort of the break-fix support that we already have, and some of the enterprise-only features.


Michael Schwartz: You didn’t talk a lot about license, so you mentioned some extra features that are in, let’s say, the Enterprise distribution, but is there a license difference between the Enterprise and Open Source releases?

Bryan Cheung: Our open source release is licensed with the LGPL, fairly common open source license. I think the conversation around licensing is probably not as heated or ideological as it was maybe about 10 years ago.

When we started we were with the MIT license, which was very similar to BSD. It was a very permissive license, and then we moved to LGPL at some point. One of the things that’s been part of our journey has been figuring out our open source business model.

I think as you know we are self-funded, and so one of the ways that we tried to balance the needs of the community and our commercialization was to move from MIT to LGPL.

At the end of the day, I don’t know if that matters all that much, I think especially with the plethora of open source software out there right now, the most important thing probably is adoption and winning the hearts and minds of developers.

On the Enterprise subscription, we do offer a commercial license, what we found is that large Enterprises that tend to subscribe to our offering understand commercial licensing better, their procurement departments are more comfortable working with that. And we can provide some assurances around that license that might be harder to do with the open source side.


Michael Schwartz: What did LGPL offer that MIT license didn’t?

Bryan Cheung: At the time we made that decision, there were a couple of large companies that were using Liferay as a platform to build different offerings.

One was a collaboration solution, and the other I believe sort of a verticalized customer portal solution for the automotive industry.

We had a feeling at the time that maybe it wasn’t “fair” for these larger companies to take our software and monetize it, without any relationship back to our ecosystem. So we felt that the LGPL might give us some protection from that in the future.

I think in the hindsight, it was probably difficult for those organizations to make those efforts successful without our involvement. I do think ultimately what they tried to do didn’t quite take off.

It’s kind of one of the pros and cons of open source, you get access to all of this powerful software, really without any restrictions but how do you make the most of it? How do you navigate it, how do you develop and customize it in a way that doesn’t get you down a rabbit hole later, where it’s hard to upgrade, or it’s hard for you to take advantage of the innovations and additional features from the mainland community.

I think now that we as an industry overall have a lot more experience with open source. I don’t think some of those challenges we faced back then would be as much of an issue today.


Michael Schwartz: One of the challenges I think for every organization is sales and bringing new customers. What are the primary sales channels for Liferay? Do people just find you on the web, or would you say the partner channel or direct sales?

Bryan Cheung: I would say, in the first 6-7 years, open source really helped us go to market.

One of our penetrations into a large Enterprise was developer-led. You had Java developers at these large banks and insurance companies, who were maybe tired of using some of our competitors who are maybe too complex, and projects built on them might take far too long to get to production.

Liferay was using pretty standard Enterprise architectural practices or the time we were using EJBs at some point and moved to Spring and Hibernate, which were widely accepted, we were compatible with Tomcat, MySQL, JBoss, which were popular at the time.

And so that really got us into a lot of our initial customers as well as in our expansion period that they continued to help us.

With that groundswell of support from developers that got us into a large enterprise, we then started to get recognition, both in the industries that we served, but also with some of the analyst firms like Gartner and Forrester. And then that sort of event gave us the peer recognition and the analyst recognition that gave confidence to some of the mainstream companies to adopt Liferay, because we had to track record.

What then happened, I would say, is that there were two kinds of system integrators. One was smaller maybe boutique integrators that’s had a track record of taking open source software, understanding it, and then implementing it.

Again, MySQL, certainly JBoss and Tomcat, later Liferay, Pentaho, maybe even MuleSoft, and the smaller integrators found that they could provide more competitive bids for building solutions by having open source foundation. And then the larger integrators, companies like Accenture, Wipro, Cognizant – these came later and saw really the strategic value of open source. That the flexibility, the security may be the way that you could better build best-of-breed solutions for complex, digital transformation problems, was an advantage for their customers. And so they started to engage with Liferay and others for some of their strategic customers.

And so that kind of was a very organic process for us, it wasn’t a strategy that we had thought up beforehand, but it’s worked out really well for us.

Startup Marketing Advice

Michael Schwartz: I’m curious if you had any insights to what are some of the more tactical marketing investment you can make as a startup.

Bryan Cheung: Thinking back on our history, so again, following that arc of that early grass roots adoption by developers – a lot of our early investments were in events like JavaOne.

I remember our first JavaOne, one of the things we did was we bought baseball jerseys that had sort of Liferay scripted on the back. And then instead of the player names, we had things like Ajax and JSR.68, which were kind of the things that developers cared about back in the day. I’m probably dating myself a little bit with some of these terms, but we had an ideological discussion about this like, “Hey, no one’s going to take us seriously if we’re wearing these baseball jerseys. “

If we mean to be competing with IBM and Oracle, these are the people that companies take seriously. And then the ones I think that really understood developer’s hearts and minds were like, “No, this is our way of saying we are not like Oracle and IBM.” And we needed to apply our strengths.

We invested in the booth at JavaOne, but instead of having expensive giveaways and kind of large gimmicks, we did the baseball jersey thing. And people noticed, and then they would start a conversation with us, and once they started talking to us about the technology, that’s what got them really excited. And I think we were able to get people to be invested in the community and just start evangelizing Liferay back into our organization.

In a way, we played up our outsider or maverick position, especially for the developers who didn’t want to go with the status quo. And what we found is that those tend to be the most passionate people, the ones who were really going to go above and beyond to sell your brand and your company to their stakeholders. So that really worked for us, certainly in the beginning.

Now in 2018-2019, I think JavaOne maybe is part of the establishment, so I don’t know if that specifically would work but I think the principles would still apply.

DXP Cloud

Michael Schwartz: Is there a cloud-hosted version of Liferay?

Bryan Cheung: Yes, we introduced Liferay DXP cloud earlier this year, and it’s exactly that.

It’s a cloud-hosted version of Liferay, but it’s actually more than just a place to put your Liferay-based solution. DXP Cloud actually provides a full Enterprise pass for managing the life cycle of your software project, from build to deploy to managing our production.

It has a full set of tools and frameworks to do everything, from continuous deployment integration to testing to auto-scaling, to an auto backup service.

It is built to work on top of AWS, and will be supporting other cloud infrastructure in the future, but it’s got another layer on there so you are not just doing AWS but you have all of that functionality there.

It’s really nice, so our team what we found is, when we were starting to deploy complex projects based on Liferay to production, there were all these things we had to figure out. How do you configure Jenkins, how do you deal with Kubernetes. How do you deploy Liferay to Docker and manage those containers, get them all talking to each other, how do you deal with elastic scaling when demand goes up.

So instead of having our customers figure out all those things on their own, we decided to figure those things out for them, and really save them time, effort and money doing that.

We really think DXP cloud is going to be a time saver, and again, on this theme of how do you deliver value to large enterprises. Large enterprises, they don’t want to have to deal with the DevOps aspects of their solution, they just want to get to market quickly so that they can engage customers faster, learn what the customers want, and then evolve quickly to meet those needs.

Michael Schwartz: I realize it’s early, but how is it going in terms of uptake from customers on the cloud offering?

Bryan Cheung: I was actually really surprised because we introduced three or four different products this year, and DXP Cloud, I would say, had really strong interest, maybe the most of all of those products. We actually already have a pretty significant pipeline of opportunities for people who want to use DXP Cloud, so it’s definitely been really successful.

Advice For Bootstrappers

Michael Schwartz: Do you have any advice for entrepreneurs, specifically who want to grow the business organically?

Bryan Cheung: Don’t do it. I’m just kidding. Definitely do it, but it’s a lot of work, and it takes a lot of sacrifice. But I do think the rewards make it very, very worthwhile.

I think one thing is that you have to be very clear with yourself and with your team on what the goals of the business are.

I think for us, I shared a little bit about my background, I never had ambitions to have a position at a company, or to make a lot of money, but I did want to live life meaningfully, and to use it in a way that would benefit others.

And I think that sort of motivation really is shared by a lot of people at Liferay, and we are able to do that through Liferay I think because we have control over how we grow the business, how quickly we grow, and how we balance the needs of the financial success of the company, and the non-financial success factors.

And because we have that strong vision and purpose, I think it makes the sacrifices required of being self-funded worthwhile and meaningful. And what I found is that the people who work at Liferay, who believe in what we’re doing, they are able to get behind that, and they’re willing to make those sacrifices as well.

We have some brilliant people at Liferay, a lot of them work really, really hard, they’re super talented, they can probably be much more financially successful in many other places. You know, maybe you would argue that that would be true of the founders as well, but there is a sense that we’re all in this for something greater than ourselves. And that’s what really holds it together.

So I think, you know, if we were to change that, or if we were to engage with an outside investment firm of some kind, I think we would lose a huge part of who we are and the value we have as a company.

Liferay Non-Profit

Michael Schwartz: I read in one of the interviews that there was a nonprofit associated with Liferay. Can you maybe just come in a little bit about how and when you were able to do that, and what’s been the experience in balancing, I guess, the goals of the nonprofit and the goals of the business?

Bryan Cheung: We are a for-profit company. From our inception, we have used some of our earnings to support nonprofits of various kinds. A lot of it is around problems that we believe can’t be solved in for-profit ways, things like disaster relief or fighting against human trafficking.

I personally think that a lot of people actually don’t want a handout. When I talk to, let’s say, young folks who have been incarcerated and come out of prison, or when I talk to people who live in developing areas of the world that are maybe economically depressed… What they don’t want is some Western entity, whether it’s for-profit or nonprofit, to come in and just build them a school or build them a well, or give them food and clothing. They actually want to find a job, and they want to earn their own money, they want to develop their skills, and help themselves.

One of the things that made it possible for me to get behind Liferay emotionally was this realization that for-profit companies can actually do a lot of good.

It’s good for people to work hard and to feel that sense of accomplishment from building something meaningful – that’s why we believe in so much of what we do as a for-profit business. But, again, you have to complement that sometimes with non-profit means because some of the very big problems are just really hard to solve, let alone do it in some kind of economically self-sustaining way.

Our vision is that the two sides of Liferay can complement each other. I would love to see that play out in a local community. So are there ways where the places where we have offices and do business are complemented by non-profit activities that also served that local community. I don’t think we’ve gotten the formula right yet, but we have some inklings of it.

One of the things we’ve done, for example down in Brazil, we have a very successful for-profit business. They’re members of our open source community decided to join Liferay and start Liferay Latin America, but one of our most talented developers down there came out of the public school system, and in Brazil, the public school system is not as well funded, and even a lot of the middle-class, they’re going to private schools.

Unlike in USA, here I think you can’t find public schools that are very good, and most people do still go to public schools. In Brazil though, being from public school means that maybe you didn’t have as many opportunities as some of your peers. So this developer, he was telling the story that one of his mentors, when he was growing up, was a developer and show them how to write code, in the sense of empowerment and possibility that he experienced when he wrote his first software program was really life-changing.

And so even though he came from sort of this more challenging background, he was able to follow this session around software development and build a career. He has since gone back to the public school where he grow up, and he has organized funding for a library. But he’s also been able to get some of his co-workers from the Liferay office, who were also developers, to go back to that school and teach these kids and expose them to coding and software development.

It really changes the trajectory of their lives, so boys and girls who maybe otherwise wouldn’t see those role models and maybe who had seen just soccer players and kind of dreamt about doing that, now they’re kind of seeing this new world of possibilities.

And, first of all, that is not really a for-profit activity, but I think even on the nonprofit side, I wouldn’t say that it’s required a lot of investment, but really is just people taking their time out and building relationships with that school.

So that’s the kind of impact we want to make, we want to be a for-profit company that engages the community, maybe identify some of the ways that money can help kick-start or catalyze some kind of change in that community, and then hopefully there are ways for those efforts to sustain themselves in the future.


Michael Schwartz: Awesome. Bryan, congratulations on all the success at Liferay, and all the commitment over the years. Thank you for your hard work, and thank you for being a guest on the show.

Bryan Cheung: Thanks very much.

Michael Schwartz: Special thanks to Yotam from Liferay, for coordinating the 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, stay tuned for the founders of TimescaleDB.

Episode 15: Camunda – Workflow and Decision Automation with Jakob Freund

Jakob Freund is the Co-founder and CEO of Camunda, an open source platform for Business Process Management. Camunda’s customers include AT&T, Wüstenrot building society, Lufthansa Technik and Zalando. In this episode, Jakob discusses Camunda’s unique journey from consulting to a product-based company.



Michael Schwartz: Welcome to episode 15 of Open Source Underdogs, the podcast where the founders of open source software companies explain the process of defining a successful business model.

Jakob Freund is a Co-Founder and CEO of Camunda, a Berlin-based company that is reinventing workflow automation.

I recorded this interview back in November but I’ve been a little backlogged. In December Camunda announced the completion of a € 25 million series A.

Although Jakob told me it was in the works, I didn’t ask him about it in this interview because it wasn’t finalized. But Jakob has a great story to tell, and Camunda is a business that we can all learn from.

So without further ado, let’s cut to the chase.

Jakob, thank you for joining us today.

Jakob Freund: Yeah, sure, I’m happy to.

Michael Schwartz: So, tell me a little bit about yourself, what did you do before Camunda?

Jakob Freund: Before I started Camunda, I used to work with another software vendor, in the same industry, Business Process Management.

And that was just about a year or so, and before that I actually went to university. So I did start Camunda pretty soon after I finished my studies basically.

Origin Story

Michael Schwartz: Tell me a little bit about how Camunda got started? What’s the origin story?

Jakob Freund: As I just have mentioned, I was already in this industry called Business Process Management, which I always found very interesting. I did work in that industry as a consultant, and I figured that I could actually do that as a freelancer.

And then I met my Co-Founder Bernd. He was already freelancing in the same industry as basically a Java developer, doing workflow automation with open source BPM technology back then.

So the two of us met up, and we had this idea about starting a consulting business around BPM – that was back in 2008. And that’s how Camunda basically came about.

Customer Segments

Michael Schwartz: Who are the customers of Camunda? Do you segment in any way?

Jakob Freund: Yes, maybe just to complete that story, so Bernd and I started Camunda as a consulting business for BPM, and we did that for about five years, on 2012-13, more or less.

And as consultants, we understood that market quite well. We saw all the technologies out there, and we saw that there were BPM process automation products delivered by the big players, like the IBM, Oracle, Software AG.

And it looked like a good number of the relationship consulting struggled with actually applying those products.

So they had software developers themselves, they wanted their software developers to do process automation projects, and those developers struggled to use the IBM’s Oracle’s, and other products because they were so heavy-weight, and not really open, in a sense of an architecture, not easy to embed, and things like that.

We decided then, in 2013, that the time was right to deliver a BPM technology that would be appreciated by developers, and we started that as an open source project.

This is basically how Camunda transitioned from a consulting business to a software business.

So, to answer your question now, this kind of open- source process automation technology applies to basically any organization that wants to automate their business on one hand, and at the same time, see IT as their core business infrastructure, therefore, also entertain their own software development teams.

And you will find that kind of organization in different industries. So, for example, insurances in the German-speaking area, but also banks of course, in a broader sense, in national services, telecom companies, media companies, eCommerce – in that says, it’s a real horizontal technology applied in different verticals.

Why Open Source

Michael Schwartz: Why do you think it was important to make the product open source?

Jakob Freund: For two reasons really.

We have already engaged with another open source project, so the initial version of our project was basically a fork of that project because we didn’t see it really evolving and moving.

So there was some history behind it on one hand, but then again, also, we figured that since this is a product that is built with developers top-of-mind, it’s meant to be used by developers.

It’s kind of a natural thing to say, okay, let’s make this available open source, so that developers can adopt it very easily, without signing up for anything. That developers can also contribute to it, if they’re missing features, some of their spot box, not so much in order to get that work force for free, but in order to actually do not get them engaged and excited about the technology, and also to understand where we should be headed in terms of the next features and the roadmap.

So it’s kind of a product management treat that you will get when you deliver such a technology open source.

Revenue Streams

Michael Schwartz: So how do you monetize what things do you sell at the company?

Jakob Freund: I guess it’s a pretty common approach really.

You could say it’s an open core based business model, so we have to workflow the engine, you know, the actual thing under the hood in the headless fashion that executes those business user-friendly flowchart diagrams in order to orchestrate services.

For example like microservices, but also in order to orchestrate human work, and things like that.

This is headless so developers can embed it in their own architecture, and that’s all open source.

Then it comes to putting your processes into production, then running them, and you can still deliver the open source version, that’s fine, it’s stable and everything.

However, you might want to also have additional features around operations, for example.

So there is a tool that we deliver, which is called Cockpit, which comes with pretty powerful features for operating complex ecosystems of automated workflows.

And that tool was partially open source as well, but the majority of features is available to Enterprise customers.

Another tool for example is called Optimize, which is more about business users.

So business users get the ability to look into the running process right away, in real time, they get nice reports, and for example, heat maps on flowchart diagrams. So I, as business user, have this direct access to the technically running business processes.

In terms of adoption, it means that developers adopt technology right away, it’s open software, they can use it, they propose to put this to production towards their management.

At some point, the management might wonder about, “yes, of course, support and maintenance.” But also about, “okay is there any additional tooling available for operating this, and is there any additional tooling for making our business sponsors happy?” And that is available with Enterprise.

Breakdown Of Revenues

Michael Schwartz: In terms of revenues, is the greatest percentage of your revenues from license or from support?

Jakob Freund: So the support is part of the license subscription, so we don’t unbundle that, to sign up for the Enterprise version of the product, to get all the additional tools, and features, and the support.

So since it’s not unbundled, I could not say that the revenue can be split between those two elements.

But when we look at consulting, which is about best practices and more consulting coming on site, and reviewing your architecture, and stuff like that, that consulting comes on top of that.

When we look at our revenue, we could say that about 90% is coming from the Enterprise subscription, which is a license business, including the support service. And 10% is around consulting services.


Michael Schwartz: Are other companies or software vendors taking your open source and building it into their product?

Jakob Freund: Yes, absolutely.

We have customers for example as Gainsight, a customer success management firm, which embeds Camunda in their product, there’s Autodesk, for example, and many others.

It’s pretty straightforward for software vendor to embed Camunda in their product, in the headless fashion, so their end-users wouldn’t be aware of Camunda, but they get those workflow management features.

If I was, for example, a vendor that had a product that it’s about email automation in whatever way, like for marketing or others, and there’s those drip campaigns, where I send out an email, and depending on the reaction of the recipient, I might send out a follow-up email – that’s a workflow.

And you can design that workflow in a graphic away in Camunda, and then let Camunda run that workflow, and all within your product, without exposing Camunda to your uses.

Have Productizers Been Beneficial?

Michael Schwartz: How are those relationships going? Do you see contributions back from those partners? And I’m just wondering, has it been really beneficial, or sort of neutral, or how’s it gone with those types of deals?

Jakob Freund: Well, I would say it’s extremely beneficial for us, but not so much in the sense that they would contribute large amounts of code, in that sense, that they were actually, like rebuilding the code features that we then simply merge, get app, and then we’re done.

So that’s not what you should expect when you bargain on open source, or when you pattern open source as a vendor yourself, but you will be getting a lot of very, very helpful feedback from the people actually using your technology. That can be just individuals, open source users, they can also be organizations, like those software vendors.

By looking at what they are asking for on the forum, by looking at their pool requests, or things that they are building on top of all product and then contributing that as what we call “community extension,” which we also feature then into our ecosystem.

We understand pretty well what now should be the next steps in terms of making the product more powerful.

One example, I just mentioned this heat map feature that shows which part of our process is executed most often – that was an initial version, not developed by ourselves but by a partner of ours, as a plugin.

And then we looked at that, and we actually redeveloped that from scratch.

We didn’t actually merge a single line of code, but we got a pretty good understanding of how the feature could look like.

Soon our developers ended with stuff like, having a Spring Boot integration, for example, that can also be related to more business-user related features, like the heat map that I just mentioned, and many more aspects.

Productizer Revenues

Michael Schwartz: Do these customers, who are productizers, do they buy a subscription?

Jakob Freund: There are both.

There are software vendors that sign up – for example, we have Aion fashion with us, and then we even get Royalties, based on their own success with the product that’s out there, but of course there’s also other companies that use the open source version and don’t pay us.

And I’m quite sure there’s many more of that category. We can’t really track that since we don’t ask people to leave their email address in order to download Camunda.

It’s not that we have a direct tracking of who’s using the open source version, they are not paying us, but, of course on an anecdotal level, when you look at our meetups and other community events, we actually do encourage and invite those companies to present there just as well.

It’s not important for us in that sense that they’re paying customers in order to get presents in our community.


Michael Schwartz:How do you look at sales and marketing – is it mostly in-bound, or how are you sort of approaching it?

Jakob Freund: Well, as of today, it’s 100% inbound, in fact. So we don’t do any cold calling or, otherwise, outbound prospecting.

So, what happens is that we basically have the website of course, and the website is about the open source community, and it’s also about the Enterprise offering, so people approach us asking for quote, for example, also putting that pricing request form, things like that.

And, of course, there’s also some classical general marketing activity, it’s like content that we provide, and they would sign up for that content, becoming a lead, and things like that.

But there’s no open activities, as of today at least.


Michael Schwartz: So, in terms of partner development, is a partner important to you as a channel?

Jakob Freund: I would say it’s very important to us, in a sense of having resources available, people available, who can help our customers to implement their workflows with Camunda.

We have a lot of system integration partners that you can find on the website that have to go through a certain program of getting educated and certified eventually, etc.

So we have those partners in basically any region of the world.

And they are helping us a lot because our clients when talking to us often asked about, “okay, are there any local resources available that can come on site and help us implement Camunda in our organization?”

This is where our partners are extremely valuable.

I wouldn’t say that as of today that they are super important channel partner, so of course we have a few, especially, the bigger ones, who are also proposing Camunda to their customers, and bring new business to us. But I wouldn’t say that we have come to this point, as of today, thanks to that channel.

Open Source V. Enterprise Priority

Michael Schwartz: Where do you draw the line with open source? You mentioned that you are Open Core. How do you prioritize which features are contributed to open core or the core product, and which features are going to be Enterprise?

Jakob Freund: First of all, I know that there are some companies who would just use open source in order to piggyback on this tournament, and deliver what you could call a triple software, which is not really production ready, or not really usable. That’s not how we see it.

We really committed to that ideal, and that’s why we want to deliver a great technology and open source, that developers can adopt and use right away, and build great stuff with that, and then also putting that into production.

In that sense, when we look at new features, if we should make them available open source or not, we have that in mind.

It means that when things about a core engine that especially apply to developers – you know, we have really called it the “rainy Saturday.”

If you imagine a developer, sitting at home on a rainy Saturday, that’s just browsing around the internet, and checking out technology. And perhaps they have some project in mind that they are looking at work right now.

For example, we want those developers to be excited and be empowered to solve their problem or build exciting stuff with Camunda right away.

When it’s about feature stat that would support that idea and would support the developer’s life basically, then this feature is a natural form made available open source.

It applies to the core engine, the headless engine, but it also applies to a tool that we deliver, which is called the Modeler, which is a nice application to create those BPM flow chart diagrams.

That tool is available open source as well, and it’s a whole ecosystem of plug-ins contributed by other developers that enhance that tool. So it’s not just about the core engine stuff that is open source.

Then we have other features, which are more about also other personas within the organization.

For example, when I look at, let’s say, CIO or executive manager in the IT department, they might worry about certain stuff that really kicks in when you go alive with a large set of mission-critical business processes.

Like high availability and data replication across data centers, or update mechanisms, if you want to have like an update of Camunda and your cluster with zero downtime, and stuff like that.

Again, the majority of things that we deliver here is open source still, but here is also the possibility to provide features that you can rightfully say – “okay, do you launch organization, do you want to use this technology on a large scale for your mission-critical business?”

It’s fine and fair for us to ask you to sign up for an Enterprise subscription in order to get nice features that you would need to build yourself, but you couldn’t, if you wanted to use it that way, and everyone’s fine with that approach.

How Much PS To Take On

Michael Schwartz: You mentioned before that you were still providing some professional services within the organization. How do you draw the line with when to refer to partners in a certain region, or when to maybe take on those professional services yourself?

Jakob Freund: Well, our PS team is steady, specialized obviously in technology and surrounding best practices.

Like for example, how to involve business stakeholders and capture the ideas about to be processed, and to put that into a BPMN flowchart diagram that can be executed.

That’s not so much even about coding or architecture, it’s about simple best practices to talk to business’s user.

That kind of skill set you will find with our consulting team, and it’s a small team really. They’re not supposed to implement, or do the heavy lifting of the project implementation work.

So, when you are in organization and say, “I want to start my Camunda adoption journey, and I need some guidance on how to do that.” then our consulting team is happy to help, let it be on site or remotely.

But, when you say, “I need someone who will actually be with me, let’s say, a team even of developers or consultants on site for the next six months, supporting us, implementing this, etc, then we would actually refuse that request, we wouldn’t deliver that.

That’s the situation where it’s pretty clear that our system integration partners are actually to go-to people.

Range Of Customer Relationships

Michael Schwartz: No one has enough people to serve all of the customers out there. When customers buy a subscription, do you provide different levels of service, based upon different categories of customers?

Jakob Freund: When someone buys a subscription, they are just a customer, and we value each customer very high obviously, so we do not distinguish in that sense.

What we do have sometimes customers are in specific situations.

For example, if someone says, Okay, I have the situation, I want to go live next month, I’m having issues about performance. Or I don’t know, I need some guidance regarding tuning of the engine, or you know, with optimize or using Elasticsearch, its repository.

So, if they’re struggling with that for whatever reason, then of course we will prioritize, and we will help. But it doesn’t really matter if it’s a mom-and-pop shop, so to speak, or if it’s like Fortune 500 or Blue Chip company.

Value Proposition

Michael Schwartz: There’s other BPM tools out there, you mentioned some of the larger companies like Oracles and IBM, etc, so what’s the value proposition actually of Camunda versus some of the other offerings out there?

Jakob Freund: If you compared it to the ones that you just named, the IBM, the Oracle, we believe that Camunda is much more developer-friendly in the first place.

If you look at other open source technologies nowadays, like Elasticsearch and Apache Kafka, etc, it’s pretty clear that they are geared toward developers.

But, if you look at classical so-called BPM’s products, not so much. That other value When you look at classical so-called BPM S products, not so much so that other value propositions in mind like, hey, we are empowering your business users to drag and drop and point and click, and do everything in a model- driven way, and it’s pretty much of a closed proprietary suite basically.

We actually distinguished it coming on from day one and said, no, we’re actually blending the mindset and attitude of the Apache Kafka and Elasticsearch projects with the use-case of business process automation.

This means that we see Camunda as the most developer-oriented and most lightweight, and therefore for developers, easy to use technology on one hand, and two, allow developers to meet the business needs around business process automation on the other hand.

This, we believe, is our sweet spot. It’s kind of right between super low-level developer-oriented technology and relatively high-level, business-oriented products.

Camunda Pivots

Michael Schwartz: One of the challenges of starting a business is figuring out how to create the right offering, that includes both pricing and what’s included in the offering. Camunda’s been around for 10 years or so, has the offering changed a lot? Have you ever had to sort of tweak the offering or pivot a little bit, just wondering like what the process was like for you?

Jakob Freund: First of all, as I explained, Camunda has been around as a company for 10 years, but the product only for five years. However, we didn’t have to pivot the co-product so far. And I believe that’s because of the first five years of consulting.

For those first five years of consulting helped us to understand very well how a product should look like to have a great product market fit. And which is certainly our biggest asset right now, the product market fit.

Regarding the Camunda BPM product in its essence, we didn’t have to pivot at all actually.

Where we did pivot, however, on a smaller scale was when we added new features on new components to the product stack.

Just to give you one example, Camunda supports BPMN, which is a standard for workflow automation, and at some point we also wanted to support a standard for case management. And we added that to the stack – didn’t really take off, to be honest.

I wouldn’t say yet that it doesn’t make any sense at all, but we had to realize at some point, okay, this case management thing. I mean, yes, of course, there’s a market for that, and it’s important. But, to be honest, I mean, the actual thing that is going on in business IT is automation.

So it’s not so much about supporting knowledge workers, but if you want to be extreme, actually you could play some other tools you want to automate. Therefore, we decided to double down on this aspect of business process automation, these little iterations, like a year or so, of trying something out and then tuning that, letting go of something, maybe doubling-down on other stuff – that’s what we have suddenly seen.

Open Core V. Tools

Michael Schwartz: Would you say that your open core strategy is more about adding features, let’s say, extra features like you mentioned, better DevOps, deployment, scaling options for large Enterprise? Would you say it’s more about adding different features into the core products or a JSON tools to the core product?

Jakob Freund: It’s both really.

No matter if it comes to the community-driven innovation in the product, I would say it’s, to a large extent, adding features to the core.

I just mentioned Spring Boot, for example, that’s a great example, that’s really something that the community asked for at some point and even did a bit by themselves, the plugins, etc. And we were really amazed by their activity and engagement.

So, at some point, the community asked, “Okay, guys, could we make this part of the co-product so that it’s supported and included in the next release, etc.” So, that’s the kind of innovation that happens in the core that’s very much driven by the people using the product are also paying us for using the product for Enterprise version – that’s one end.

Then we have that other end, where, I would say, it’s a bit more proactive, where we collect all those impressions from different sources, and figure that, hey, there’s actually some problems around, for example, business visibility and the business really being involved in processes at one time.

And then there’s some vision coming about, okay, what if the business could look at what’s going on any time, in real time, and even get machine-learning back to advise about how to improve their processes. And this is more of a proactive creation of a tool as you just said, and its particular example is optimize.

It’s really both happening, you could say.

5-10 Year Vision

Michael Schwartz: When you look at long-term planning, do you have a vision for where Camunda will be in 5 years, or 10 years?

Jakob Freund: You know, on a fundamental level, we would love workflow automation as a technology and as an instrument to achieve this automated Enterprise.

If this would be recognized by the developer community, on the scale of the most popular open source projects that are around as of today.

Because if we’re honest, if you look at Camunda and Google trends, you’ll see a pretty nice trend. But when you compare it to the Elasticsearch and Apache Kafka project, and absolute numbers, of course it’s not as widespread. So there’s not so many developers coming as of today.

And we would love to change that, we really believe that it’s great fun to use Camunda, that it solves serious problems in developers’ lives, so this is one part of the vision that I would see for the next 5 years that we have this visibility into awareness of the top 10 open source projects. Of course as well as there are certain things around the products stack.

For example, right now, Camunda has delivered on premise, so you can download it yourself and upload it on premise.

We are also looking into offering it as a managed service, and things like that, so there’s a certain vision-based road map for the next years.

But at the end of the day, it’s really about creating this awareness among developers, try the technology that is compared to classical open source text, relatively business-oriented.

So, this is what we are pioneering in fact. BPM is a business thing really, but doing it in a developer array, I believe can propel any organization forward, that sees themselves as a technology company, like any bank, or insurance, is actually a software company of a certain flavor, and this is actually where we kick in.

Biggest Challenge For Open Source Startups

Michael Schwartz: What do you think are the biggest challenges facing open source companies today?

Jakob Freund: You asked that and I already drew the line between open source and Enterprise features. I think that’s a classic one. I think the pattern that I explained, it’s the “rainy Saturday” pattern, I think that works pretty well, at least for software products that I geared towards developers.

But as of today, I wouldn’t start a company that has a product that is meant to be used by businesses users and business users only, and make that available open source.

I don’t really believe in that approach, but if you have a product that is meant to be used by developers, or like in our case, developers plus business users, then open source may sort of make a sense.

The challenge is still to, of course, balance the open source adoption on the one hand with your investments, and the conversion into paying customers on the other hand. Once you figured that out, you can simply hit invest in your pattern, and it works pretty well.

So, the challenge, of course, can be that there’s other vendors, piggybacking on the success of your open source project and competing with your Enterprise offering.

The most prominent example right now is Amazon web services, giving MongoDB and Elasticsearch, a headache because they are offering that open source stuff, with not connecting back to the community or signing up with a REM license, or whatever, with the vendor.

So they are actually competing with the software companies on the open source community. And I know that there’s some companies now, wondering about whether they should change the license, for example, make it more difficult, etc.

I don’t really think that makes sense, so I think having a clear idea about the buying center and then deliver, and then respect the features for each persona in that buying center, either open source if it’s more developers, or Enterprise if it’s more business users.

I think if you do that, then you have a clear conversion channel, or clear conversion track, and you also have a more defensible position when it comes to those cloud vendors, hijacking, so to speak, your open source projects.

Because they can only offer the open source project, they cannot offer those Enterprise features – that’s the challenge that I would say I’m away off right now, but that’s also what I believe will be the right approach to take a look.

I mean, look at, for example, Elastic – that’s how they do it right now, in a sense.

Current License

Michael Schwartz: Which open source licenses are you publishing Camunda under right now?

Jakob Freund: If you like at it, like on the top level, you will read the Apache license, which is just the vast majority of source code you will find on github and our repository is license on Apache, that’s also some MIT licenses.

But in a nutshell, those licenses would permit you to use it, in more or less, whatever way you like. It’s not stuff like GPL or things like that.

Personal Advice

Michael Schwartz: Do you have any personal advice for entrepreneurs who are getting started and want to use open source as part of their business model?

Jakob Freund: I mean, my experience is limited, I have only built this one company, I’m not an entrepreneur. I have this one experience, and as I mentioned before, we started as a consulting business, and this worked extremely well for us.

So, being consultants first, building expertise and reputation and a strong home market, like the German-speaking areas, where there’s not a lot of competition that you could find in the US, which is also kind of helpful, of course, to get going.

And then using that expertise, reputation and profits to start a software business – that works super well fast, and I believe it can work for most people. You would just need to be aware that big investments take time.

It took us 5 years before we started the software business. The question is if you have that time, of course.

Besides that, the thing that we’ve just discussed around, how to define the business model and how to find what’s open source and whatnot – that’s certainly crucial. We didn’t talk so much about talent and the people that you hire and that you work with – that’s of course a very crucial element.

As you can imagine, open source helps attracting great engineers. So there’s engineers who really identify themselves for open source – that has an impact on that they want to work with us.

Here, however, you need to be honest and authentic. Are you doing this only because you’re, for example, idealistic about open source, and it is like, your personal crusade against the evil capitalistic vendors? Or do you actually have a business you’re passionate about?

And it can be both. I guess in our case a bit of the first but probably more of the latter, and that’s fine. But then you should be honest about that also towards your team, and they will appreciate that.

And those that are really like zealots about open source, they might leave at some point, because, you know, “we should make everything available open source. No features Enterprise,” and that kind of stuff. And then, it’s better to part than to not be honest about that.

That’s another advice that I would give about that.

Michael Schwartz: Jakob, thank you so much for your time.

Jakob Freund: Yeah, happy to. Thanks.


Michael Schwartz: Special thanks to the Camunda team for hosting the interview.

Transcription and episode audio can be found on opensourceunderdog.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’ll have a remote interview with Liferay Founder, Bryan Cheung.

One of his interviews inspired this podcast – don’t miss it. He has a lot of brilliant and inspiring insights into life and business.

Until then, thanks for listening.

Episode 14: Canonical – The Company Behind Ubuntu with Mark Shuttleworth

Mark Shuttleworth is the Founder and CEO of Canonical, the creator and maintainer of Ubuntu Linux. One of the most popular platforms for cloud servers, desktops, and IoT devices, Ubuntu is the operating system of choice for new development. In this episode, Mark discusses the business model of Canonical and trends in the open source ecosystem, like the acquisition of Red Hat by IBM and the challenges of open source licensing.



Michael Schwartz: Welcome to episode 14 of Open Source Underdogs, the podcast where the Founders of open source software companies tell us how they achieved escape velocity.

As the Gluu World Tour extended to month four, we visited Cape Town, South Africa, and we’re honored to get a chance to interview Mark Shuttleworth, Founder and CEO of Canonical.

In the ‘90s, Mark founded Thawte, a certification authority, subsequently acquired by VeriSign for around half a billion dollars.

Not content to sit on a beach, Mark then pursued one of his lifelong dreams – space.

After training for a year, he became the world’s second self-funded space tourist and the first South African in space, blasting off on the Russian Soyuz TM-34 space mission.

But perhaps his most enduring contribution was still yet to come.
Mark embarked on a mission to bring Ubuntu Linux to the world. Canonical is the business behind Ubuntu.

Canonical is a fascinating business. It’s forged a powerful business model. For a large business, it’s surprisingly exploitation free.

Without outside investors pushing him for short-term gains, Mark has a freedom to pursue a truly long-term strategy.

Although how Canonical got started probably can’t be replicated, Mark has some deep insights into the open source ecosystem. And just like any business advice, take it with a grain of salt, but some of it you can hopefully repurpose for your challenges.

So enough of my blabbering, let’s cut to the tape.

How Was Space Like Entrepreneurship?

Michael Schwartz: Mark, thank you so much for joining me today.

Mark Shuttleworth: It’s a pleasure.

Michael Schwartz: My first question is a space question. Did your experience preparing for an undertaking a space mission change your approach on entrepreneurship?

Mark Shuttleworth: I guess I’d put it the other way around. I think my experience with entrepreneurship before going to space shaped the way I put together a space mission.

There were a lot of entrepreneurial elements to the way we put that project together, and being younger than the typical astronaut, cosmonaut, coming from a commercial background, having had to sort of drive a small business.

It was a lot of those skills mapped into negotiating with the various agencies and groups that were responsible for Russian space flight, telling the story of what we were trying to do, building a community around the mission, and then sort of making all of the pieces work out, managing operating controlling – all of that.

So I guess, it really was a personal project that benefited from an entrepreneurial perspective effectively, in an industry which is sort of the exact opposite of entrepreneurship.

Why Start Canonical

Michael Schwartz: We could probably spend the next half an hour just asking you questions about space, but this is a podcast about business.

Mark Shuttleworth: I’m pretty sure, I’m pretty sure many of us will get there.

We are at the dawn of much more transparent access to space. Pretty certain that the experiences that I had in some senses, hundreds of thousands people have similar experiences, or the opportunity to participate in some way with our next big steps as a species.

Michael Schwartz: That’d be amazing, I hope you’re right. But switching tracks to business and Canonical – why did you start Canonical?

Mark Shuttleworth: Before I went to space, I built a business in the field of security and cryptography and online commerce.

I had a great benefit of being able to pull together open source components to support and underpin that operation. And it struck me that this is a great way to accelerate innovation that the generosity of others was enabling me to go faster as an innovator and as an entrepreneur.

So I was in the fortunate position I could sit back and think about what kind of impact I wanted to have in the world. And it struck me that that would be a great way to return the favor, to simplify and reduce the cost of integrating open source would allow lots of other people, who were willing to take risks and had ideas, to move the ball forward faster than it would if it was just in the hands of a few large organizations, as technology.

The pendulum always swings, and back in the ‘90s, technology was very much in the hands of a few large organizations. I wanted to be part of breaking that open and enabling open source to be part of breaking that open.

There’s lots of different ways to do that, you can go chase a particular idea as open source, or you can look at the open source experience from end-to-end, and think about how to make that better for the people who are innovating and the people who are consuming and building on it, to structure the relationship between them so that it’s healthy and easier.

Challenges Of a Second StartUp

Michael Schwartz: Canonical is your second business, and one of the challenges around starting your second business is figuring out which lessons from the first business you don’t apply to the second business?

Mark Shuttleworth: It’s so extremely different that I really didn’t think that just because I’d been fortunate in one case that I could count on the same good fortune in other cases, or that certain instincts, which worked in the one case would necessarily apply in the other case.

When you do something completely different, foresight or folly to think that it’s something intrinsic, and that you have to study the problem.

And the sort of open source platform challenge is just completely different to many of the other sorts of opportunities in business, or even in open source.

So I still spend a lot of time thinking about the deep zen of what’s going on, which often isn’t the stuff that’s stressing people out, or the stuff that’s in the headlines – those sort of contextual reactions to something that someone did.

Most people tend to interpret what they see through the lens of the past.

I try to think about what it might be like if we weren’t concerned with the past. And so that’s the approach that I brought to the platform to Ubuntu and Canonical.

Who Is CEO of Canonical

Michael Schwartz: So you’re Executive Chairman of Canonical, not CEO – what does that mean exactly?

Mark Shuttleworth: What it means is that I’m really crap at updating my title on LinkedIn.

I am CEO of Canonical, and I’ve been for a while. I spent some time as Executive Chairman, and I just haven’t updated the bio.

Michael Schwartz: I did see your press release about some news about how your — I think the Wikipedia still says that you’re not.

Mark Shuttleworth: Well, equally, I was not interested in updating my own Wikipedia.

Michael Schwartz: If Wikipedia said it, then it must be right.

Mark Shuttleworth: It must be, yeah.

At one stage, I thought that the business needed a different focus from the CEO.

I was lucky enough to have Jane Silber in the business, and she took on that responsibility for a good stretch, 7 years, which allowed me to focus more on things that where interesting to me and kind of foundational for what we are doing now.

Today I’m sort of more in position of putting all those threads together as CEO. I guess I’ve enjoyed that return.

Thoughts On Red Hat/IBM

Michael Schwartz: Everyone in the open source community is trying to make sense of the IBM acquisition of Red Hat. Canonical has had a great relationship with IBM.

Were you surprised by the acquisition announcement, and what do you think it means for the community?

Mark Shuttleworth: I thought it was pretty clear for a long time that Red Hat wanted to find a buyer. So were the signals of that sort of preferred outcome.

I wasn’t surprised that in the end there was a transaction.

I was very surprised that one division in IBM was able to engineer such a large amount of debt for the whole business to take Red Hat on.

In a sense, it’s a great deal for Red Hat shoulders, investors, owners. It’s a great deal for the bankers, if it works out.

And it remains to be seen if it’s a great deal for IBM, but I buy the thesis that in a cloud world the ability to work well, on the public cloud and on your private infrastructure, is important.

And Raleigh is an important part of most enterprises private infrastructure, so the thesis of combining IBM’s public infrastructure with the Raleigh approach to private infrastructure, I think is a reasonable thesis. We’ll have to see what the execution around that looks like.

And the end of the day, because of the economics of the deal, there is an enormous amount of money that has to be brought in by IBM, through the deal, to justify the purchase price. And I’m pretty sure customers are going to end up being faced with that price.

That creates an opportunity for us. I’m thinking again right from the beginning with Ubuntu with Canonical was that I wanted to be sure that I drove the friction and the cost of building an open source, consuming open source down, even in the late ‘90s, early 2000, I felt that it was really important for the true benefits of open source to come to the widest possible audience.

There were people in the ecosystem, working on driving that cost down, rather than essentially working on their short-term monopolies, or other sort of positions of power that might bubble up in open source in order to behave like, you know, the old school power players of the tech ‘90s.

So we are very committed to driving down the cost of infrastructure that’s open source, driving down the cost of operating that infrastructure.

That I think puts us in stock contrast with where Red Hat was, and increasingly where I think IBM would have to take Red Hat because they’re going to have to earn the money back to pay for the premium that they’ve put on top of Red Hat already high evaluation.

I think that bodes well, we’ve already seen some indication of that.

Customer Segments

Michael Schwartz: An operating system is a core infrastructure, everyone could be your customer. How do you segment the market from a commercial perspective?

Mark Shuttleworth: Internally, within the organization, we think about places where people are working in aggregate, supplied type infrastructure, where you are really blurring the lines between a single host, or single piece of infrastructure, and the whole.

And places are at the edge, where essentially everything is a single point of failure.

The operating regimes of those are quite different, the kinds of things that people are trying to do in those places is a quite different echo of each other, but they are quite different, and economics of those places are quite different.

If there is a primary segmentation, it’s along those lines.

The economics of cloud need to be shaped in a way that makes sense for cloud, the economics of appliances and devices need to be shaped in a way that makes sense for appliances and devices. If you zoom out, you can see a lot of common themes.

In both of those places, we’re thinking about how to help people put the right software in the right place, with the right version, at the right time, but the mechanisms and the economics are completely different, and reality has to line up with them.

Who Does Canonical Sell To

Michael Schwartz: So when your market is everybody, who do you sell to? Like, how do you actually figure out where is the next fuel is going to come from?

Mark Shuttleworth: Well, open source serves well to build a base of people who understand what they’re going to get when they work with you.

In our case, that’s sometimes a little less obvious because people’s relationship with the operating system is a little indirect.

They focused on an application, they focused on a project, they focused on the workload. It really only comes clear when they had been working with infrastructure or operating systems for a very, very long time, because then with a benefit of scale and time, you find yourself dealing with institutional type problems, with all the different versions of Ubuntu out there: How do I understand whether or not they’re compliant, whether or not they are secure, how do I manage them at scale, or how do I keep them compliant.

Those are not the sorts of questions that people are asking on day one.

There is sort of questions that individual teams will ask, that sort of question gets only asked once you’ve been consumed at some scale, across an entire organization.

But Ubuntu is very much in that position today, and so we’re usually able to find in almost any large organization that there is a substantial amount of usage of Ubuntu, and then show the organization how their relationship with that platform gets better in working with Canonical.

Breakdown of Revenues

Michael Schwartz: And that leads into my next question, which is DMB was showing around 130 million in revenue for, I think it was a year 2017. I’m sure you’re doing more now.

Can you shed some light on the breakdown of revenue? Is it mostly licensed, is it subscription? And does Canonical have a whole range of services and products, like is there an 80/20 rule, where 80% of the revenue is coming from 20% of the products?

Mark Shuttleworth: We do a mix of things, and that’s deliberate, you know.

We’re quite willing to do non-recurring engagements because, in many cases, we can help people with, for example, their startups or entrepreneurs, making an IoT device, or businesses building clouds, and so on.

We can accelerate their faster productivity because we have a whole pile of knowledge that we can call on, that they don’t have.

It would be much more expensive and take a lot longer, and be a lot less predictable if every one of those businesses needed to kind of do that pitch-scraping work for themselves.

So we’re quite happy to dig in and do work that people would think of as kind of consulting type engagements.

I know that that’s not considered sexy in Silicon Valley, but it’s an enormous benefit to customers, who otherwise effectively have to figure out how to staff something that they don’t understand.

The way we frame that is that our job is to get a business into a position where it’s very clear how they continue to operate efficiently in many cases that means doing a bunch of sort of heavy lift upfront with that business, which is not a subscription, not a service, not licensing, you know, none of the typical things that Silicon Valley likes.

However, if I come back to the original point, our core goal is to drive down the cost of consuming open source.

In any way we can do that is if we share that cost across many, many players. So subscription and licensing type products really achieve that. In the end we, make a much more cost-effective platform by sharing the cost of all the things that people end up caring about.

They may not really understand that when they start, but they end up caring a lot about those big-picture things over time.

And by licensing the product, licensing and running services that are recurring revenue services, we are really essentially reducing the cost to everybody of those critical functions.

Values Proposition

Michael Schwartz: What would you say is the core value proposition of Ubuntu, or of Canonical’s commercial offering?

Mark Shuttleworth: Managing open source, engaging with open source at scale.

If you look at the generations of open source, in the first generation you had open source components. You had a great compiler that a small community was building on that was interesting. You had tools, a fork there, a spoon there, a knife there – you didn’t really have a whole.

So companies like Cygnus, that were closely involved in those individual tools, those were a sort of poster children, or the figureheads for open source.

Then with the emergence of Linux, it’s sort of moved up a layer, and the idea of ours was a sort of a base-operating system, people thought of a company like Red Hat is providing an alternative to something like Windows.

Today I think we’re in a very different world.

Today, if I look at GitHub, you can’t really explain GitHub, and what’s available to a business on GitHub, through the lens of anything that you’ve ever seen, from the Oracle’s and IBM’s of the world – you just can’t. There’s no analog.

There is an analog for Raleigh, it’s Windows or Solaris. But there’s no analog for the real benefits of embracing open source as sort of an open source first type policy.

And if I look at our customers, they tend to be companies that have moved fastest to say, “I want the real open source. I want the real benefits of open source in my business. I want those everywhere in my business.”

The first waves, they needed to be closely associated with a business, people wanted to look at open source, and make it feel like it came into a shrink-wrap box from a company that they could relate to in the way they’re related to Microsoft, to Sun, or to Oracle.

They wanted obviously a stronger sense of control in a relationship, and they wanted better economics, but fundamentally they still wanted that idea of a product from a company.

You don’t get that if you say, “I’m opening my business up to GitHub.” You have to be willing to figure out how to be productive, and willing to say, “I’m opening my business up to GitHub” – that’s the kind of relationship we end up having with organizations.

Working with us, they are able to say, yes, we’re not consuming Linux at a bigger scale more cost-effectively than we were when we were working with Red Hat.

But more importantly, we are now actually accelerating our entire development applications operation because we’re opening ourselves up to GitHub.

And the way Canonical works with us that is attainable, that we understand how we can make that work.

That’s why I’m excited to do it.

It means that people who do put time and effort into things on GitHub can find a way, either to get more uses of that, or to get a better return on that, depending on their particular interest.

Sales and Marketing

Michael Schwartz: Open source companies have a strange relationship with sales and marketing. Customers normally start using the software, and then they contact the vendor as you mentioned when they get to a certain scale, but can you talk about Canonical’s approach to sales and marketing and how it evolved over the years?

Mark Shuttleworth: The key thing for me is view enterprises customers, not as single things – because they are not.

An organization is a complex thing made up of lots of different functions and opinions and teams, and so on. To move stuff forward, there needs to be some sort of consensus, especially at a platform type top-level.

There needs to be some sort of consensus across that diversity that you are moving in the right direction. So, to my mind, it’s important to be having simultaneously multiple different relationships and conversations with people in an organization that is a prospect or a customer.

There are some of those relationships that are best done, completely transparently as engineer to engineer, open source code first contribution matters type engagements.

And we are quite unusual in encouraging our core engineers to speak with customers, and encouraging our customers to speak with core engineers, because it strengthens that kind of communication.

But it’s also important to be able to sit down with other people in that organization and have conversations that make sense to them about things that they care about. I think the challenge comes if you cross those wires, if you think that you’re going to run a marketing campaign to target developers, then you may be running the risk of using the wrong language, prioritizing the wrong things, emphasizing the wrong stuff.

To my mind, developers love Canonical and Ubuntu because we’re pretty focused on finding ways to help developers be more productive, go faster, experience less frustration and friction when they’re dealing with that vast, open-ended fire hose of open source.

There are a different set of concerns that we have to deal with when we engage with the rest of the business, and so to the extent that we invest in sales and marketing, we certainly do, it’s to make that more rounded communication possible.

I think it is important for every open source entrepreneur to understand that they need to be able to speak multiple languages. It’s the same message, but it’s essentially framed in different languages, to different parts of an enterprise.

Who To Partner With?

Michael Schwartz: Canonical has a deep technology partner network. It seems like everyone wants to partner with the makers of Ubuntu. How do you prioritize in which partnerships to invest?

Mark Shuttleworth: I think this is actually one of the areas where I made a lot of mistakes early on, because as you say, there is an enormous number of companies that intersect with Ubuntu in one way or the other.

And they do often want to engage and talk about a partnership of one form or another.

And I found that we were wasting a lot of resources in trying to conduct too many of those conversations at the same time, when, in fact, the best thing we could do for many of those businesses was to enable them to go faster with Ubuntu, and they didn’t need to be talking to us to do that.

So the easiest way to kind of resolve that is to set a threshold of value, mutual value, on a potential relationship.

We’ve done that essentially. If there is no clear path to a certain threshold of revenue to Canonical from a partnership, then there isn’t the basis for investing in the conversation.

There’s almost certainly appetite for that conversation because they’re using Ubuntu, but when you sort of really dig into it, if neither side can see a clear path to a certain threshold of business they’re going to do together, then you better off, leaving your engineers correspond through the bug tracker.

So today I think we have a much clearer view on the relationships that we are interested in. Because we’re a platform and we are used in so many different places and so many ways, I can’t say that there is a particular game plan or strategy to that, it’s simply the idea that very early in the conversation, we’ll say, “Well, what’s a path to doing a certain amount of business together?”

And if there is no clear answer to that, then the way forward is pretty clear – it’s open source, you know how to use it, you’re here because that’s true, but if neither of us can see a clear way to grow faster together, than “let’s leave it as it is.”

What Defines The Best Partnerships?

Michael Schwartz: What have been some of the most successful partnerships so far?

Mark Shuttleworth: The best partnerships come where people need a platform because they’re doing something other than a platform.

So, an example of that would be somebody who’s shipping appliances, they are selling something that does some very specific, people are looking for that function.

They need an operating system, and we are the preferred operating system. If their engineers have a say, and increasingly engineers do have a say, then businessmen know that to succeed, they need to go faster and faster, and they need their engineers to be happy and productive.

So since we focused a lot on keeping the engineers happy and productive, we’re typically the preferred platform for people in that sort of space.

And again, we’re pretty focused on driving down the cost of the platform, making it cost-effective for people to build services on top of Ubuntu, ship them, be able to answer all the tech platform questions that people have: Is it certified on this hardware, where can I get support, how long till I get support, is it certified, for these purposes is it certified in these countries, who’s going to handle this kind of call, who’s going to handle that kind of call, what do we do in the circumstances.

So more complexities than most businesses want to deal with internally when it isn’t their business effectively.

Our best partnerships come where people are very clear in their minds that they need a platform. Also clear in their minds that that’s not their primary business.

A secondary kind of layer would be places where people understand that Ubuntu is effectively the reference way to do something.

In a field of AI, for example, now it’s very clear most people doing that are doing it on Ubuntu, and they all go faster as a result. There is just much less friction, and we accelerate that, we facilitate that, we make specific types of investments that essentially you get rid of friction between the various groups that are competing and cooperating in AI.

The same is true in robotics, the same is true in all kinds of fields that are important to people. None of those in fact are competing around the platform that they’re using. So they don’t really mind if they end up sharing a platform.

If anything, it is reassuring to their customers, they do not want to be wired in that regard. So I guess the heart of that is, there’s a clear distinction between what people are selling and what we’re selling. That makes for a much more natural partnership.

When folks on the other side of the table are conflicted about what they want to sell, then usually the conversation gets complicated.

Our part in that I think also is just unconflicted. The temptation is to sort of get into everybody else’s business, and we don’t. I like partnering with smaller companies who are good at something, in finding ways that the relationship between us effectively is healthy for them.

I think it’s really important when you are in a position to be an aggregator that you don’t forget what it took to create the things that you are aggregating.

So I think we’re unusually respectful of what it takes to be an innovator or an entrepreneur in open source, and that makes it certainly easier to partner.

View On Licenses To Prevent Saasquatters

Michael Schwartz: Just switching gears a little bit to more ecosystem stuff.

There’s a lot of discussion in the community about how to define new open source licenses that prevent SaaSquatting, or a large SaaS company uses open source technology, and either doesn’t contribute or even undermines the company that’s developing that software.

When I interviewed Jay Kreps from Confluent, he mentioned that open source licenses were created at a time before large SaaS companies were using open source to sort of move into this infrastructure layer. Do you think the community needs to develop new open source licenses to mitigate this type of exploitation?

Mark Shuttleworth: Well, you know, when it comes to the rules and regulations and terms of engagement, and so on, I think there’s one kind of perpetual rule, which is the old “treat others the way you’d like to be treated”, especially if the roles were reversed. I think that’s a universal story, and that’s been the case for a long time.

Beyond that, I’m not that much into sort of commandments written in stone, they don’t tend to last, the world changes, the dynamics change.

And exploring, innovating, testing, finding new ways to organize – those are all normal.

We have social norms and conventions, ways to run society, ways to run businesses, regulatory, and frameworks, and so on. Today they reflect our best understanding of what works. In that light, people exploring different approaches for licensing open source is normal.

Remember, we focused on the whole spectrum of what’s on GitHub. Our engagement with a bank, for example, is about helping them consume more of that diversity. So no one license is going to end up being the answer to all of the questions.

Again, it’s not like any of our users can be in a position where they say, “Look, we’re only going to deal with stuff on the GPLv2 or Apache” – this just doesn’t work that way.

The question really is, how can we get the benefit of all of the open source out there, so we have to work well with all the people who are innovating, both in code but also in licenses.

So it doesn’t work for me to be super ideological about the one license that’s best for everybody.

As I look at the current angst, written debate around open source licensing, I think there’s three groups. There’s the people producing open source, typically smaller, typically innovative, typically focused on creating something new. There are aggregators, we call them the SaaSquatters, and then there are also the buyers, they are also the enterprises.

Then, stepping back, I’d say, we are only at the beginning of that debate, so as a consequence, what you’re seeing is 1.0 type thinking from all of those players.

This shallow thinking and the arguments that I’ve seen from all sides, the cloud company’s arguments are little bit like Mary Antoinette, you know, “Oh, let them eat cake.”

This should be fine, they’ve set the business model problems, you know. That belies the fact that they really do depend on innovators to innovate, and it isn’t them. They do a lot of innovation, but it’s not this kind of innovation.

Conversely, there’s also folks, super upset at the idea that other people making money off their stuff are missing some obvious points that they benefit from consumption, then from engagement, that lose that if they weren’t willing to make a trade of some form.

And then you have the buyers, the people who ultimately pay the bills. Who also I think they’re a little behind the curve in terms of whether value is really coming from, and how to engage with both those aggregated type players and the underlying innovators.

I’m not particularly fast about where we are at right now. I think it’s normal for pendulums to swing, the pendulum is swinging in one direction now – that’s exercising people’s minds, it’s driving debate. I’m pretty sure it’ll all work itself out.

Challenges For Open Source Startups

Michael Schwartz: Besides licensing, what are the biggest challenges facing companies that want to make an open source software distribution core to their business?

Mark Shuttleworth: I think it’s clear that open source on its own isn’t enough.

And I think that’s because the sorts of things that people are trying to achieve with open source, or the sorts of problems, where people want to see open source play a role, have mushroomed into the full spectrum of problems and opportunities that are out there.

There was a time when interesting software could be written by one person or two people – that is still true.

I mean, it’s still kind of amazing how somebody will think of something and produce it – I love that, that sort of learn, think or invent, I love that. But that approach is completely not relevant when you’re looking at producing something like Kubernetes.

It’s completely not relevant. There is no informal couple of people or one person that can do that.

And I think a lot of the stress in the conversation comes from people who have had one experience of open source, and therefore assumed that they understand how it works or how it should work, and then they’re applying that to circumstances, where those ideas or approaches just flat-out would not work.

Compound that with the fact of course people have interests.

They’re both, either deliberately, or somewhat naively blind to the things they might think that are really convenient truth. Convenient because of their interest.

There isn’t going to be one approach that essentially enables open source to be relevant across the full spectrum of technology, because the full spectrum of technology is a very broad spectrum.

And so people yelling at each other and saying, “You don’t understand.” is probably mostly a symptom of the fact that people are coming from lots of different backgrounds, and making naive assumptions about what it’s like in the other person’s shoes.

How To Balance Corporate And Open Source Interests

Michael Schwartz: The raison d’être of a for-profit company is to make money, and to make a return for investors, but pure-play open source software vendors also have a contract with the community. Is there a right way to balance these objectives?

Mark Shuttleworth: I think it’s important for people to understand what makes someone else tick.

As soon as you start telling other people how they should behave, and specifically telling other people that they should behave the way that suits you, or the way that you behave, you’re probably missing the opportunity to get the benefit of having diverse perspectives.

And I think it’s really important for people participating in a community to have some empathy for the people for whom the project is their lifeblood. That’s super important.

And often in the Ubuntu community, it’s being valuable to remind people of the fact that we are a community because we have different interests and different needs, and figuring out how to make those things work is important, tend to push back quite hard on the idea that the company must serve the community.

I think it’s important for both groups to understand mutual interests. I love that we make opportunity in Ubuntu for people who have completely different interests to Canonical’s.

It’s an enormous amount of stuff that we do that they can free ride on effectively, which lets them explore interesting things that are important to them for whatever reason. It could be commercial, it could be personal, it could be scientific.
And I’m happy to make that space. I push back pretty hard on anybody who says they shouldn’t be spaced for Canonical.

And I generally try to remind different groups inside the Ubuntu community of the fact that they can’t expect everybody to act exactly the same way. Most often I see that sort of argument from people who have entirely external ways to support themselves.

So very large companies that control access to enterprise accounts can make money using open source in those accounts effectively, but they certainly don’t want anybody else coming into those accounts because their margins come from account control effectively.

So a lot of the foundations, where we see large companies essentially standing up foundations is really predicated on the fact that while they want to benefit from true community participation, and that they want to benefit from innovators, they don’t want to see either of those groups in their accounts.

And they’d like to sort of create a fig leaf that is strictly non-commercial, that those accounts can’t go and ask for certain things from – all of that’s normal, where in an evolving marketplace, I find just as a leader, it helps to remind people of the fact that the diversity of interests is what makes an interesting community.

Canonical 20 Years From Now?

Michael Schwartz: Where do you see Canonical in 20 years?

Mark Shuttleworth: 20 years? That’s super interesting.

If I look back 15, it’s been 15 years, in a sense, just an extraordinary amount has changed.

I wouldn’t have predicted 15 years ago that we’d be a key platform on the Mainframe, and on the Raspberry Pi. I wouldn’t have predicted the Raspberry Pi. And I think that’s part of what I love about open source, it’s that people end up doing things with it, that the creators of the open source didn’t imagine.

It is really hard to do that with proprietary software, because sooner or later you’ll run into something that it’s just a small little impediment but you can’t do anything about it.

But something’s really haven’t changed – it is about enabling people to go faster with open source, to drive down the cost of open source, drive down the friction of open source.

I don’t see any other way of organizing software that seems poised to beat open source.

I don’t see anything on the horizon that looks like a discontinuity in that flow, pretty certain that Canonical offers a better way to engage with the entirety of open source for business.

If you are a bank, and you want to engage with open source, with a next generation, with a next wave, and we’re already well-up on the adoption curve. Early adopters are very comfortable with Ubuntu and Canonical, and it’s now on the sort of a faster rising part of the curve.

Maybe there’ll be some other organization that figures out a better way to do that, and that would be exciting, that would be interesting.

But at the moment I think we are well-positioned to be the company that enables people to consume, and integrate, and operate open source across the full spectrum, across all the clouds, and architectures, and devices, and things like that, better and more cost-effectively.

It’s hard for me to predict what will happen at the application lab because I’m not an inventor of applications, I’m not competing with people who make databases, or AI, computer vision recognition systems, or anything like that.

There’s an enormous amount of innovation that happens around us, which is kind of a privilege to watch that I don’t have to worry about guessing too much, you know, who’s going to invent what, because as long as they need a platform, and as long as they want that platform on sort of a reasonable and efficient commercial terms, with a long-term commitment, there’s a role for us to play.

Advice For New Open Source Entrepreneurs

Michael Schwartz: Last question, any advice for new entrepreneurs who are launching a business around open source software?

Mark Shuttleworth: There’s a real sort of double challenge in starting a tech operation that is open source.

Starting a tech operation’s always hard because you want to do something new, and that’s surprisingly difficult.

Like, you genuinely have to do something different if you want to be successful, from a technology point of view, and most of the people who would have that kind of open source view, there’s a technology angle to it, that’s something new that they want to do. And it’s hard enough getting that right.

With open source, you need to think about the fact that you’re enabling your own competition, as the blunt truth of it. You’re enabling people to compete with you, but the benefit of all the things that you’ve done, and that can be both financially and emotionally very daunting.

But at the end of the day, I don’t see any other model for software, which is spreading as fast across the world of the kind of categories of software out there today.

If you’re not going to be open source, you’re almost certainly going to be niche.

That may be satisfying for you, but I doubt it.

For most people, I think they want to find a category, and it really is going to be open source that will define a category. I’m not too worried about the non open source work, or the sort of wrapped around open source work that we see in large aggregators. Because, in a sense, by definition, they’re niche, they can only ever engage with people in their pond, maybe a big pond, but the trick is where the boundaries are.

For people who essentially want to have the whole world as an audience or a market, I think open source is an important component. It’s very, very hard, but I do think it’s the only way.

Michael Schwartz: Mark Shuttleworth, cosmonaut, CEO, Founder, Capetonian – thank you so much for joining us today.

Mark Shuttleworth: It’s been a pleasure.

Michael Schwartz: Special thanks to Claire from Canonical for helping us get us Mark’s calendar.

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 heading back to Berlin, Germany, to talk in person with Jakob Freund, Founder and CEO of Camunda.

Until then, thanks for listening.

Episode 13: Confluent – Apache Kafka Streaming Platform with Jay Kreps

Jay Kreps is the Co-founder and CEO of Confluent, an open source real-time data streaming platform powered by Apache Kafka. Jay is the author of numerous open source projects, including Apache Kafka and Apache Samza. In this episode, Jay discusses creating a hybrid open source offering and usage-based subscription models.



Michael Schwartz: Welcome to episode 13 of Open Source Underdogs, the podcast where we help open source software entrepreneurs metamorphize their business models.

Jay Kreps is a Co-Founder and CEO of Confluent, the company behind Apache Kafka, a real-time stream processing platform, currently used by 35% of the Fortune 500.

This episode is being recorded remotely because Jay is based in Silicon Valley. Jay, thank you so much for joining us today.

Jay Kreps: Thanks for having me.

Michael Schwartz: So it’s not every day that the company you’re working for agrees to let you start a company to work full-time on a project you started while working for them – how’d this come about?

Origins Of Confluent

Jay Kreps: Yeah, that’s a great question. There was actually a whole kind of evolution of the infrastructure stack at LinkedIn, where I had worked.

We rebuilt a lot of the database layers that served the kind of live site, and we had built custom stores, searching for people, searching for the infrastructure, and for social graph that shows how you’re connected to people.

It was kind of time in the world where all the infrastructure was moving from single-server databases and systems to these distributed systems that could scale horizontally, and that was incredibly important for a social network like LinkedIn, because it had to scale, and sometimes faster even than the number of users.

In some ways, it scaled almost with the square of the users because you have all their connections, interactions between them, and that kind of grows faster than just the people joining.

We were really trying to figure out how can you scale the social network, and how can you do it in a way that’s cost-efficient, and how can you not just make it able to handle the data size but actually make it something where you can have hundreds or thousands entrepreneurs that kind of work against these platforms productively, how can it all kind of interrelate.

And so a genesis of Kafka was really that environment, we had all these different stores, we had all these big aspirations for how we wanted to use what was happening kind of in real time and feeding back into the user experience, how we wanted to connect all these different systems, in some sense how it all played together.

And there was really no solution to that problem that we felt was in a well-thought-out, or could scale in that way.

So we really started to think about like, “hey, what was missing in this stack?” And we came to some interesting observations, like a lot of the traditional data processing technology is something that almost comes out of the mainframe.

Kind of at the end of the day, you load everything up into some big data warehouse, or your cluster, and then you run these big processing jobs that come and spit out results hours later, and we thought, you know, it doesn’t really make sense.

Like for a big, global digital business, all your data is continuous, and when you say, “oh, we run all our processing at the end of the day.” It’s not even clear like, at the end of what day?

So we kind of thought, “hey, there could be a model for this,” where instead of taking all this data and bring it all together once 24 hours later, you’d just do it all the time. Kind of model everything that was kind of happening as a kind of a continuous stream of data, and allow a real-time application that we continually process that as it occurs.

And if you did that, you could really feed that back, so that you can have news feeds that updates right away. The interaction could be much richer and more real-time. And this could be kind of the basis for connecting all these different systems, for connecting all these different applications that we would connect around these streams of data.

So we looked at the academic literature, and there’s been some stuff in this area, but it kind of fizzled out, and then we looked at kind of the commercial space, and there really hadn’t been much, and it was a kind of the old messaging systems and other layers, but nothing really good in the area and the way the databases had been developed a lot of theory and thought into them.

That was the origin of it. We started building, we spent about 5 years building Kafka, and scaling it, so it would really handle at LinkedIn: All the activity, okay, what are the actions people are doing, what’s happening right now, all the changes coming into databases – it could really be that kind of central nervous system that connects everything.

We open sourced it at that time, and it ended up getting really popular in Silicon Valley.

A lot of the big tech companies: The Pinterests, and Ubers, and Netflix’s, really took this and built around it, as really a core part of their platform.

As that happened, we really started to come into contact with a broader world. I mean, I have only really worked in Silicon Valley tech companies, so I didn’t really know a lot about how a bank is built and operates, or a big retailer’s built and operates.

But as we started to talk to these companies, we got a sense that the applications for this could be much bigger. Even than what’s happening so far. That this could be the central thing that they kind of all built around.

When we realized that, we kind of thought, hey, what do you need to do to make that happen. Because a lot of these companies just couldn’t adopt what we had as kind of, “hey, download this from Github and go put it into practice.”

They needed a lot more.

So we realized, look, there would have to be some company that we could go fund development on this, turning it into a product, turning it into a service, and take it out into the world.

When we realized that, we put some thought into how we do it. We told LinkedIn that we would be leaving, it was actually a really nice thing. Rather than being unhappy about it, they actually offered to kind of invest and help us on our way.

So, in addition to kind of raising majority of our funding is from traditional venture capitals, we took a little bit of investment from LinkedIn, which kind of helped us get started.

Michael Schwartz: It’s amazing. You don’t hear it very often that company is so supportive, but I guess they knew firsthand how powerful it was.

Jay Kreps: Yeah, it was actually an interesting part of their culture. That they believed in kind of entrepreneurship, and they believed that in the modern world – you don’t come and work someplace forever. I’d been there for seven years. I was there really from when it was pretty small to when it was quite large.

And then they believed in kind of helping people, you know, as time comes to go do the next thing. That was kind of the cultural values that I thought was pretty cool, that they actually acted on that, that they were willing to kind of back it up when push comes to shove.

Project To Company

Michael Schwartz: It’s one thing to have an open source project with lots of adoption and excitement, and another thing to start a business that generates millions in revenues.

So the company started in 2014, and I read a press release, it said that the first commercial product was launched in May of 2016 – can you talk a little bit about the experience of going from an open source project to a commercial offering?

Jay Kreps: It’s actually an interesting thing, there was actually two main ways of commercializing open source. I think for most open source projects, they don’t really need a company, and they actually won’t really support a company in an easy way.

If you go to GitHub, there’s probably some millions of repositories there, I think most of those would not succeed as a stand-alone company. You kind of need something, where it’s popular enough, and there’s enough depth to the problem that people kind of want ongoing work and effort and support and services.

It’s worked pretty well for these core data systems and platforms, it is not the case that it actually works for every kind of little library.

We felt strongly that there was an opportunity in the area we were in, even though there wasn’t really an existing example of any kind of open source company in that space. Because what we were doing is data system that’s not a traditional database.

The first debate was really whether we wanted to start with a posted service in the public cloud, or whether we wanted to start with a software offering that people could run in their own data centers, but that they would have to run. So would we do something that was fully managed, or would we do something that was more of a software product.

We actually thought a lot about this, we came out of the world of really running the software at LinkedIn. Like, we built it and we also operated it. It was pretty attractive to build an as-a-service offering.

Eventually, when thinking about this, we realized you have to do both. And it’s just a question of how you sequence.

We ended up starting with the software offering because we realized for a lot of companies, that’s kind of where they were, and that they were kind of already adopting the open source – that was a nice transition to be able to use the commercial features, if that was useful.

So we did that, and about a year ago, we released our as-a-service offering that’s in the public cloud. For the software offering, we kind of targeted a kind of an open core model, where there are set better price features beyond the open source, and you get also support across all of it.

For the cloud offering, it’s pretty much the same thing, you actually get it run for you, so you don’t have to develop the expertise and stuff to do that.

Open Core V. Tools

Michael Schwartz: When I was looking at some of the diagrams of the Confluent platform, I was wondering if it was more of a tools business model similar to Cloudy, or if it was open core. Is it sort of the same thing to you, or do you differentiate a little bit between those?

Jay Kreps: I think one question that, at least in my mind, has been answered is – you’re building a business around open source, do you need to have any kind of the commercial IPS as part of the offer.

Do you have any software that’s not open source, or is it better to do a pure open source offering?

I think defining it as it has been is definitely better, to have some kind of commercial offering that isn’t purely open source, and you want to find a way to do that doesn’t kill all the attractiveness of an open source platform.

The whole reason people want these open platforms, is there’s such an amazing ecosystem around them, there’s no lock-in; those are the huge advantages.

So you don’t want to ruin that as you think about how to commercialize it, and you don’t want to poison the community. You really want to support, enrich the open source community, rather than stifle it.

To me, that’s the finding that I don’t differentiate much between kind of open core or proprietary tools around the side of this – that’s all. You’re looking for a commercial offering that kind of supports the open source.


Michael Schwartz: Kafka is Apache License because it’s Apache project, but how did you license the other pieces of the Confluent platform?

Jay Kreps: Yes, we do both. We have an open source part of the offering, for example, KSQL is a layer where you can take the streams of data coming into Kafka, and you can do SQL queries on top of them. And that’s open source, so you can download it and use it.

For a lot of the management, or monitoring, or operational features, that can allow you to connect up between data centers or run the stuff at scale. We built those as commercial software, which has a proprietary license that’s part of our offering.

And the way that’s sold is you buy their service. You’re basically paying for your use of the service, and we kind of muter that use by the data that flows through it or that’s stored.

And if you buy the software, we do that as a subscription that is priced by the number of nodes that the software is on.

Both of those are roughly usage-based models that are subscriptions. And I think that’s actually a great model for companies like us, like it means our incentive is to make sure you’re getting value out of the software that you’re using it, and that you’re getting value out of us. And that you are able to use it more than it grows as a platform within the company, more applications are able to come on and take advantage of it.


Michael Schwartz: Were there any challenges around figuring out what item you’re going to actually get on, what was the right pricing model for that? Did you get it right initially, or did you have to adjust it a couple times?

Jay Kreps: Some of the things we got right and some we didn’t.

It’s interesting that you said that, so yes, for these hybrid offerings, where it’s open source but there’s also commercial features, I think they have an element of a kind of a freemium offering. That’s actually really common outside of open source, even.

I come from LinkedIn previously, and parts of LinkedIn’s business had that model, where they had basically a free offering which is probably most people’s experience of linkedin.com, and then you can get a professional account.

And then they have really a full enterprise software product for sales and recruiting that’s totally different from the main site and experiences geared towards users and those demands. It’s very much kind of a freemium model, where you can come and get a fair amount of value, even if you don’t pay.

For many of the people who are, they can get even more value if they can upgrade to one of those tiers and they can target different users.

So, yeah, you have tension in any of those models, because if you gave everything away for free, your users would be the happiest, but you also would have no business.

If you kind of kept everything back, you would have more to sell, but actually that whole basis of users, and that whole set of people who are getting this and building around it, and kind of growing it into something where they would get value from the commercial features, wouldn’t exist.

I think it’s actually a bit tricky to draw that line, but it’s actually very powerful for companies that can because they are able to basically create a lot of value in the world. And even if they’re not capturing all of it, they can capture quite a lot.

In open source, some of these infrastructure layers are so powerful that even if you’re only capturing 10 or 20% of the value you’re creating, that is still quite substantial.

I think that’s actually in many ways the hallmark of a lot of these software-driven businesses, it is very much like that.

If you look at Facebook, or any of these kind of internet services, they have similar dynamic where, in some sense if you think about the raw time people spend on them, they don’t make that much money in comparison, but the scale is so vast that they are still making a lot of money in absolute terms.

Range Of Customers

Michael Schwartz: What are the ranges of customers who convert into Confluent platform customers?

Jay Kreps: Yeah, we’ve got companies of all kinds.

Huge car companies that are doing these amazing connected car projects, where they are connecting all the cars that they sell to the internet, and they are adding all these software features around that, and internet services, they kind of have power stuff in the cars.

Big banks that are kind of rebuilding all their core infrastructure, and trading platforms, and risk systems, and security, and fraud analytics, big retailers that are doing kind of real-time inventory management, so really across the board. And we’ve seen that with kind of small companies to some of the largest companies in the world.

Definitely, it’s kind of time to talk about a commercial offering is when people are getting real value. I think one of the things that was wrong with a lot of the commercial infrastructure platforms is that when a new platform comes around and you evaluate it, you end up quite tied to the platform overtime.

So for something that’s new and kind of unproven and proprietary, you can be hugely tied to it, and it’s not really taking off in the world yet. So you saw so many of those platforms going to fail to ever achieve escape velocity.

And I think open source really solves that for these new platforms. People can do development against that, they can download it, do development against it, you really understand how it works, put it into place for less important applications – all without really spending any money, so the risk is pretty low.

And then, as it becomes something that’s generating a lot of value for them, there can be offerings that would make a lot of sense where they’re interested in paying more to get more.

A lot of this kind of failure to thrive that you saw in so many commercial infrastructure platforms, because this wasn’t just to work the lock-ins and embeddings, so they’ve got a small vendor, it’s really overcome by open source, and I think that’s why you see so many of the popular infrastructure of all types are open in that way.

Customer Segments

Michael Schwartz: So in your customer base, do you segment at all?

Jay Kreps: There are two dimensions that matter, small companies to large companies, and less technically sophisticated to more technically sophisticated.

Of course, there are companies in all of those segments that use the product in different ways, and their kind of needs and preferences are different.

If you think about the small, technically sophisticated companies, I would say that’s the Silicon Valley, but also New York, and parts of Europe, a tech startup scene.

What they want is a hosted service, you know, they don’t want to buy a software, they don’t want to run stuff, they just want to be able to use these services dynamically, pay for what they use and go.

Large technically sophisticated companies, they have substantial on-premise blueprints, they need something that spans both environments.

They need to be able to run the software and their data centers, but also in the cloud, and connect all that up and stream data back and forth, and kind of get something that works across all the environments there.

Let’s say, small non-technical companies, we don’t end up working with them that much just because they don’t really need what we are doing.

How To Prevent Saasquatters

Michael Schwartz: Amazon has a service choosing Kafka, you’ve probably seen MongoDB and Redis have adjusted their license to prevent large cloud providers from competing with them, in a way that doesn’t support the community.

Have you thought about perhaps forking Kafka and providing it under a different license to enable you to capture more value from some of the large cloud providers who might be deploying it and benefiting from it without really contributing back a fair amount?

Jay Kreps: Yeah, it’s definitely been an issue, where the public cloud is so new.

The kind of the dynamics of how you manage an offering, there are still merging, a lot of the assumptions that went into how open source is licensed. They really predict that, they come from a world where the way software was delivered was, it was shipped to you.

Obviously, that’s been untrue for the kind of cloud applications, where it’s like a UI, Apex, Salesforce for a while, but the new thing is that this kind of infrastructure-as-a-service ability to get a database to build these kinds of back-end infrastructure pieces, which is typically the domain of open source, to be able to get that as a service.

Open source licenses haven’t come to maturity in that time, so I think for a lot of these companies, they are kind of going through a struggle, trying to figure out what’s the right balance. How much should be made freely available to anyone who wants it, even if they want to create a competing service and not contribute, and how much should we not do that.

I think the balance people mostly want is actually fair for your customers, to kind of take the software and not pay. That’s kind of the deal that I think you want with open source. You want people to be free from lock-in to the vendor, and that’s a big part of the value.

It’s unclear that, you know, you want to basically fund a ton of R&D for Amazon, who should be able to afford to contribute as well if they want to have an offering like this.

I think people are trying to figure out the right way to adapt to that and do it in a way that’s community-friendly, and that accomplishes the goals of a company and actually just allows the communities to thrive. And I don’t think there’s any kind of final answer to how to do it, not the one that we know yet, but it’ll be interesting to see how it evolves.

Value Prop

Michael Schwartz: What’s the value proposition for Confluent customers? Why do they use the Confluent platform versus a platform of one of your competitors, or just the open source, I guess?

Jay Kreps: There’s a couple things that they’re looking for.

I mean, a big part of that is, how do you take one of these big, scalable distributed platforms and really make it production-ready, and really be able to operate it at scale, and be able to develop on top of that.

Both for our cloud offering and our software offering, that’s a lot of what we’re helping people do is really make it real. So when we work with companies, everything we do with them is really structured around that, we have commercial features, we have open source features, we have support, we have consulting, just to advise people on how to do stuff and to help them get set up, we have training to help them learn how to do that.

All those that’s really just aimed at this – “hey, how can we take a company that doesn’t have this technology, how can we get them started on it, and then how can we make their initial applications successful?”

And then how can we turn it into really a platform that more and more applications can be built on site becomes this kind of fundamental, central nervous system that connects all their stuff. So all of our offerings are actually in that value proposition.

So very much, how can we get from point A, where we don’t have this capability, to point B, to point C, to point D, where it’s this amazing capacity that we build around?

That is what we really help companies do at a really high level. And the way we do that is obviously through all these mechanisms.

So if you’re getting it as a service, then you have to kind of build all the expertise in-house. If you are getting the software, then it makes the people who are standing this up, they are operating it a lot more efficient. There’s a lot less that they would have to build in-house to do that.

Sales and Marketing

Michael Schwartz: What’s the primary channel for getting new customers? Do they find the open source and then they call you, or what’s a typical sales cycle look like?

Jay Kreps: Yeah, that’s exactly right.

The problem that open source solves from a marketing point of view, for infrastructure platforms is basically that if you think about these kind of big complex, distributed layers in a company, you don’t put them in or take them out very often.

You really want it to be the case that people are aware of what you do, they’re aware of the value, in a sense you are a kind of a default choice and solution. And that they kind of call you when they’re thinking about doing some change there.

So you want and kind of get a market speak would be called an “inbound sales” mode, and you want that to be as much of your funnel as possible.

If you try to do it the other way, where you kind of go door-to-door, looking for people who might want to make this change in educating them about what you do, it’s actually pretty expensive, because you’ll find that even if you find a lot of people who are interested, it’s just not the right time, and the right time may not be for some years.

So you end up with these enormous cell cycles and a really high sales cost actually, get the initial deal done, and then they still have to grow the platform to scale internally.

By working in an open source model, you can come to turn that around, where they kind of compete, they can take the open source, they can use it, as they’re getting value out of it and thinking about, “hey, we are taking some production application to you.’

That’s when they may be interested in talking to you and understanding the value proposition you have. That’s the advantage, as from a commercial point of view, to have an open source offering.

Michael Schwartz: I saw a press release from 2016 that you brought on director of marketing and a director of sales. What’s been the impact of formalizing the sales and marketing functions?

Jay Kreps: To scale, go-to-market activities, you obviously knew that. So we have a full management team that covers everything you’d expect from Chief Revenue Officer, Chief Marketing Officer.

You kind of need the full set of disciplines that you would expect to be able to actually scale the good market activity, and that’s been super important for us.


Michael Schwartz: Have you been working with channel partners, and what role have a channel or distribution partners played for developing the sales channels?

Jay Kreps: If you think about we do, what we’re all about taking these streams of data in a company in and being able to connect everything up, and so there’s a bunch of ways that we work with partner companies.

One is that with technology, we can just plug in, so that they can get these streams of data, analytics layers, security layers, and databases, all the different types of things that might either be a source or a sink for these streams of data.

The other way that we work with partners is SIS, so people would come and help companies do development. They often specialize in industry verticals and they really know the big projects in a company.

And so they can kind of help take a new, exciting technology, like our platform, and they help to apply it in these companies, to the problems that are kind of top-of-mind in that industry, which may be very, very industry-specific.

There’s a ton of value in that, and it helps to get leverage and scale. Then we partner also with cloud providers in different ways in selling our cloud offer, so all of those are important ways that the partnership can help drive the business.

Building The Team

Michael Schwartz: What’s your philosophy about building the team – do you try and keep everyone geographically close, and how do you find people and what are you looking for?

Jay Kreps: That’s a great question. I think ultimately for a company like this, company IS the team. There’s no other big asset that the company has.

There’s no factories and machines that you bought – it’s really just a group of people who are really passionate about making something happen in the world.

So all the energy has to go into making that set of people, the right people, and make sure that they’re motivated, and that teams can all work together.

In the terms of geographic separation or consolidation, in a kind of distributed model we have offices in Palo Alto, in London, in Munich, in Paris, in other parts of the US, but we actually take them on remote places as well.

On the engineering side and the sale side, we often go into territories with sales people who are in their territory. We found that works really well. You have to build the company to support it and to work that way, but it allows you access to the best people in the world.

And one of the advantages we have is people all over the world, who are really passionate about what we’re doing, you know, want to be part of it, but they don’t want to move to the Bay Area for lots of reasons.

So, fundamentally, the choice you’re making if you’re building a company is, either I want the best people in the world, or I want the best people that are within an hour drive of my office. And there is a difference between those two things.

There’s a lot of value in having people kind of all in the same building, but there’s a lot of value in having the best people in the world too, and so we chose the latter, and I don’t think we looked back on it.

Open V. Commercial Features

Michael Schwartz: So, there’s a million features you probably want to build for both open source and the commercial. How do you prioritize the work in terms of what goes into open source and what goes into commercial? And how much effort do you spend on each?

Jay Kreps: I mean, we have kind of a vision in the space, so I guess a lot of what we do is oriented around that.

Our vision is really that you could have something very much like what databases have been for static tables of data, you can have that for these continuous streams, so you could really build the company around this stream of events of what’s happening.

All of our efforts are kind of oriented around making it happen, so we are, either building up the stack and trying to add these sequel layers and interfaces, to make it really easy to work with the streams, or we are building core infrastructures that allow us to scale better across data centers and provide more fault tolerance, scalability and redundancy.

We’re building a kind of cloud and operational tool sets that make it easy to get the stuff, or run it in your own data centers. All those are really just organized around that same mission.

In terms of what’s commercial and what’s not, we targeted an operational value proposition, like I said. So the feature is going to fall in that bucket. We usually say – “hey, is this something that would make a compelling commercial feature?” – and if not, we make it open source.

Michael Schwartz: Maybe just to push you on that a little bit, there’s probably a hundred in both categories. How do you decide how much to invest in open source vs. commercial?

Jay Kreps: We don’t actually target our percent. I would say our percent of open source development is still quite high.

It’s not because we’ve managed to a particular percent. What we look at is like, “hey, for these commercial features, what do we need to do to make them really compelling?”

And then in terms of our overall opportunity, what do we have to do to get there?

When we think about what makes it good open source features, it’s the layers that people are building against, that their applications are going to be committed to.

That I think people actually don’t want.

They don’t want to be tied down, they don’t want to be locked in. So there are things that are inherently part of the open source development.

Should we really think about it that way? You know, we want to make sure we have a good commercial feature set that is worth paying for, but we don’t really target the percentage of a developer’s hours, one way or the other.

Closing Advice

Michael Schwartz: Do you have any closing advice for those entrepreneurs who are just getting started in open source?

Jay Kreps: I think the open source businesses work well when there’s kind of some depth to the problem, and where you’re really building the platform that other things will build around.

I think that computer industry just loves open standards of all kinds, x86, the operating system layers – all of these things have created these platforms in ecosystems that people could build around in it. It’s turned out that open source is a great way of building that kind of platform.

So the internet maybe it’s built around the TCP/IP, but not everything can be a protocol. X86, I don’t even know the right way to describe what it is, but not everything is in instruction set. For everything else, I think that we found that the best way to build kind of an open platform is open source.

That tends to have the best ecosystem, it tends to have all the right feature set over time – those are the areas where I think it makes sense.

I think when people target some kind of point wise solution or application that’s kind of limited in scope and not really a platform in any way, I actually think open source tends to not win out in those domains.

When people talk about something that’s going to be a platform, many applications or systems will be built around that will have an ecosystem of other tools, and they’re great with it, that’s where open source seems to dominate.

So I would look for those opportunities, and I would look for an area, where there’s going to be enough value that the important thing is to become kind of ubiquitous, and even though you may not capture all the value as a company, you can still be incredibly successful.

And I think if you pick those areas, that’s kind of where I think open source companies can really thrive. And then of course, all the difficulties of building a company still apply. All the hard things you have to do, it doesn’t get you out of any of those.

But it does solve some of those problems in good market that I described – how you find customers, how and what you sell to them, and so on. I think that can be really helpful.

Michael Schwartz: Jay, thank you so much for sharing your thoughts on this.

Jay Kreps: Yeah, my pleasure. It was wonderful to talk.

Michael Schwartz: That’s it for episode 13. Special thanks to the Confluent team for helping us coordinate with Jay.

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 publishing one of the interviews we’ve been looking forward to since the start of this project Mark Shuttleworth, Founder and CEO of Canonical. The company behind Ubuntu Linux – don’t miss it.

Until then, thanks for listening.