Episode 35: Sysdig – Native-Cloud Visibility and Security with Loris Degioanni

Loris Degioanni is the Founder and CTO of Sysdig, a platform for cloud-native visibility and security for workload production. In this episode, Loris discusses how his past entrepreneurial experiences have helped shape a successful business at Sysdig.



Michael Schwartz: Hello and welcome to Open Source Underdogs. I’m your host Mike Schwartz, and this is episode 35 with Loris Degioanni, Co-Founder and CTO of Sysdig.

For you, older geeks out there, Loris is a legendary technologist who is one of the authors of Wireshark, a tool, which used correctly, could seem like black magic to layman. So, hearing the voice behind Wireshark is probably reason enough to listen to this episode.

Sysdig has raised over $120M on revenues of $30M, employees around 200 people, so to say that they’ve been successful for a company founded about six years ago is an understatement.

Loris has some unique metaphorical advice for entrepreneurs at the end of this interview, so make sure you hang in there. Enough of my blabbering – let’s get on with it.

Loris, thank you so much for joining the podcast today.

Loris Degioanni: Thank you for having me.


Michael Schwartz: What was it about Cloud Native infrastructure that gave you the idea for Sysdig?

Loris Degioanni: This is actually sort of a long story. Cloud Native infrastructure is, in my view and in terms of the rationale and motivation to Sysdig, just an inflection, one of the many inflections and radical changes in computer architectures.

We’ve seen several of them in the last couple of decades, the switch from physical servers to virtual machines, the generated arrays of VMware and similar companies, the evolution of virtualization into public Cloud, like Amazon AWS and so on, and most recently, the birth of containerization and modern application orchestrators like, for example, Kubernetes, created by Google.

Each of these big radical changes in the ecosystem typically require to reinvent the functionality that was available before, because the whole ecosystem needs essentially to update to the new paradigm. That’s essentially what I’ve done when I started Sysdig.

I essentially reapplied my previous experience in open-source and commercial products, and I just tried to make something that would be perfectly suited for the new world of cloud computing and Kubernetes.

To give you a little bit more context essentially, I come from a background, I’ve done computer networks and network packet capture for the first 10 years of my career, started in 2000. In particular, my first company was called CACE Technologies, and was behind an open-source packet network analyzer called Wireshark that essentially reshaped the industry of being able to essentially capture network traffic and look into networks.

That company was acquired in 2010 by a bigger company called Riverbed. When I was at Riverbed, I became the CTO of one of their business units, and I was in charge of the product roadmap for the business unit that was doing visibility and performance management for networks and applications by using essentially network packets and so on.

I realized that despite the business going very well, the world was changing, and so, I tried to essentially reapply what I did in open source and commercial, in the previous generation to the new world of Cloud Native and Cloud Computing. That was the summary of the basic reasons why I started Sysdig.

Project Or Company First?

Michael Schwartz: When you started Sysdig, did you start by writing some tools? And I’m wondering if a community coalesced around those tools from the beginning.

Loris Degioanni: Yes. And again, I’m going back, and I will do it probably multiple times during this podcast, to my previous experience with Wireshark, with network packets, because there are several parallels.

When I started my first company, essentially we already had Wireshark, and even before that, a network packet capture for Windows as strong established open-source projects.

That allowed us, me and my co-founders to bootstrap a business in a way that was very efficient, with minimal cost, and allowed us to create a brand and reach a pretty substantial market by just essentially having a very strong and very visible open-source property that was very relevant for our class of buyers.

In that first experience, first myself, and other people in that community that then started the business with me, operated the open-source tool and worked with the community for many years before we started a business.

When I started Sysdig, my second company, I definitely tried to leverage as much as possible the learnings, and in particular, I already knew how effective an open-source tool, adopted by the broader community, would be to bootstrap an enterprise and infrastructure company.

When I started Sysdig, I was in a different situation because I didn’t have an established open-source property, but I decided essentially to create one, to leverage its properties to successively create a business.

First, you need to make something useful. And you need that to be useful enough that people at least want to install it, try it, use it, maybe use it in production. And that both is validation for your idea and also as your initial source of marketing, visibility, lead generation and so on.

What I did with Sysdig was, essentially the basic idea was like what I was doing before with packets was going to be irrelevant because packets as a data source are not accessible anymore when you have, for example, virtual machines instances that are running on Amazon AWS.

You just have machines that are floating on somebody else’s network or infrastructure. You don’t really have access to the router for example to extract these packets to get inside.

Similarly, when you are running containerized infrastructures, based on Docker or Kubernetes, you have these many, many little elements that are pretty opaque, and you cannot really see what they’re doing from the network point of view.

I created a technology that would allow people to gain these insights again, by essentially sitting in the operating system, like for example Linux, and collecting signals, like system calls from this operating system.

Long story short, I sort of came up with a technology that would work again and reestablish that kind of visibility. By doing that, I stumbled into something that would have quite a bit of value for the community.

I decided to release this technology initially as open source, to create essentially a tool that would gather a community around it.

This was in 2014/15, so the very first release that we did of Sysdig was bringing these technology as open source to the community. And to the point Sysdig was born, and to the point the community noticed us, and to the point we started having people talking about us, we started having people installing our tools, and that was how Sysdig was bootstrapped.


Michael Schwartz: I see. So, Sysdig, the company, actually predated the first release of the software?

Loris Degioanni: That’s correct. Sysdig was incorporated a few months before the very first release of the software. Then, of course, the company created a bunch of commercial tools on top of the Sysdig technology. But the timeline was, company started, open-source Sysdig released, and then, commercial products came like two years later.

Michael Schwartz: Sysdig has several product offerings delivered both as software and as-a-service. Today, what are the most important products from a revenue perspective, and which products do you think have the greatest growth potential for the future?

Loris Degioanni: I was saying before I’m going back again to the analogy of network packets, and if you look at network packets, they are a very rich and powerful data source, on top of which you can build many different things.

On top of network packets, you can build a router, a firewall, an intrusion detection system, a forensics tool, performance management tool, visibility monitoring. It is just because packets are data source that is a very horizontal, very rich in content, and typically pretty straightforward and lightweight to collect.

As I was saying before, with Sysdig, the original technological advancement that we did was inventing the new data source that would be similar to packets in terms of properties for Cloud Native in the next generation, which means that similarly to packets with these data source, you can create several classes of tools.

Sysdig in particular has multiple open-source solutions and multiple commercial solutions built on top of them. In particular, from the open-source point of view, we have Sysdig, which gave the name to the company, which is a command line open-source tool that is comparable to like TCPdump or Wireshark, but for modern cloud-based Kubernetes-based infrastructures.

Then we have a tool called Falco, which is a rule-based intrusion detection and runtime protection tool, which I often compare to open-source tools like Snort, or Suricata, but for modern Kubernetes environments.

Falco and Sysdig are completely open-source and are completely community-oriented. On top of them, we’ve built two commercial products. One is called Sysdig Monitor, and it’s for visibility, performance management, alerting, dashboarding, and so on.

The other one is called Sysdig Secure. Sysdig Secure is a bunch of functionality to essentially protect modern workloads that are based on Kubernetes, including forensics, including runtime detection and protection, including vulnerability management and image scanning, and many other things.

Michael Schwartz: Do you bundle those two together, or do you sell them individually?

Loris Degioanni: We bundle them together. Of course, you can buy them individually, but the majority of our customers buys them together.

Michael Schwartz: With regard to cloud, or as-a-service delivered vs. software delivered – which one is more important to you?

Loris Degioanni: I would say equally. As-a-service is the future, is our preferred way to deliver our product to our users. At the same time, Sysdig has many enterprise customers.

Actually, we mostly serve as target customer demographic enterprises, like financial, healthcare, media, and so on. As you can imagine, the SaaS model is something that everybody aspires to follow in terms of vendors, but some of these customers are still not ready for that.

As you can imagine, a substantial portion of Sysdig’s biggest customers’ demands from us software that they can install in their data centers.


Michael Schwartz: The commercial tools – are they commercially licensed, or is it just a commercial’s binary?

Loris Degioanni: These are commercially licensed. Essentially the model that Sysdig is following is our core technology, and some of our core pieces of functionality are open source.

I was mentioning Sysdig and Falco before. Those are part of our commercial offering, but at the same time, the commercial offering, instead of just being like licensing and support for our open-source tools, tries more to create bundles that include some of our open-source technology and orchestrate it to work essentially at large scales, and complements it with some proprietary functionality that we’ve built on top of that, which includes both pieces of functionality that are missing in the open-source offering, and workflows and user interfaces on top of everything.

Open Core

Michael Schwartz: Would you say it’s an open-core business model?

Loris Degioanni: I would say Sysdig is a unique open-core model. It is open core, but, for example, I do not compare it to — I have no idea – your typical MongoDB. There’s open-source core is more like a relatively small piece of a broader offering, rather than just the core of what we do. This is by design, by the way.

I always found it a little bit challenging to just commercialize what we’ve built in open source because you tend to pretty quickly fall into the dynamic, by which you’re always thinking about every new feature that you build.

Should I open-source it, or should I “make money” out of it. And I typically don’t like to be in the situation. I like to have the freedom, to have this choice to take every time. I prefer to build stuff where there’s a more clear demarcation between what’s open-source and what’s commercial.

They work more like together in symbiosis, rather than being an extension of the other one, and you have more space to evolve two sides in a less, let’s say, stressful way.

Go All Open Source?

Michael Schwartz: Yes. Would you say then that it’s more tools, where certain tools are open-source and certain tools are commercial – and that’s how you draw the line?

Loris Degioanni: Yes. Tools and also use cases based on these tools.

Michael Schwartz: One of the things I have recently observed is Cloudera, the database company, and also Chef, have gone to a model, where they say everything is 100% open source.

Has this changed your thinking at all about maybe whether to open-source or not certain components?

Loris Degioanni: Partially, from one point of view, there’s the dynamic that you’re describing, which I’ve definitely noticed.

On the opposite side, there’s some other companies struggling a bit to decide exactly what their posture should be, in particular with regards to cloud providers like AWS, taking maybe their software and packaging it for the users.

Elastic was one of the most recent examples of that. I think that there’s no perfect mix, there’s no perfect approach. I think that every product is different, every ecosystem is different, every company is different.

Again, from our point of view, more than looking at what other companies are doing, which we definitely do and we take it into account, we try to do our best to find out what’s best for our users first, and then, what allows us essentially to grow our business.

Material Benefit Of Open Source?

Michael Schwartz: Do you think that open-sourcing of the some of the software has materially benefited the company?

Loris Degioanni: Absolutely. Has and still is material benefit in the company. One example that I can bring is, I mentioned Falco, as one of our core open-source initiatives. We’re putting quite a bit of focus around it because, as I was telling you, there’s an exploding ecosystem, the Kubernetes one, which is more and more shaping to become the operating system for the cloud.

So, the platform on which everybody will build their applications in the future. One thing that is interesting is that Kubernetes is really gaining a lot of traction, and nowadays is essentially been adopted by all of the major product vendors, because it was an open effort.

It was designed to be this kind of lingua franca, completely community-oriented, completely open-source to build your modern applications.

We at Sysdig strongly believe there’s the strength of Kubernetes, and every single component and piece of functionality in Kubernetes eventually will be community-oriented and will be open source.

That’s why we did something that is not super common in the security industry. We started open source first. Security industry, compared to other industries, is still quite a bit more protective and a little bit more proprietary in its approach.

But in Sysdig, we just decided, “Okay, first would be the tool.” It will be Falco. We try to make it part of the ecosystem, we try to make it part of the Cloud Native computing foundation, and we do our best to make it part of the stack.

This is, of course, with the goal of providing value and functionality and security for the broader community, and there is something that can be like a standard, a part of the stack in the future. But, of course, doing that also made us very quickly one of the key players in Kubernetes security as a company.

Despite us giving to our community this important component for free, it’s also helped us essentially grow our revenues in the space. So, yes, this has been very useful for us as a business.

Michael Schwartz: Attaching to this really fast-growing ecosystem and becoming part of the stack had a huge marketing distribution advantage for you.

Loris Degioanni: Yes, and attaching to an ecosystem like this is only possible if you’re truly community-oriented right. That gave us an advantage, compared to our competitors, and is allowing us to grow faster than our competitors in that space.

Is Open Source Value Perceived By The Market?

Michael Schwartz: You made an interesting comment about security not always being open source.  I don’t know if you know but my company is in the identity security area, and we’re open source.

I was just reading one of the S-1 of our competitor, Ping Identity, who’s going public, and I did a text search for open source and their S-1, and the only reference I could find to it was a mention of the risks of open source software, and how the use of open-source software might come back to hurt them in the future, and therefore was a risk to investors.

Do you think there’s a disconnect somehow between investors’ perceptions of open source and the reality that you see as a technical professional using open source?

Loris Degioanni: I think that traditionally, for sure, in the investment community at any stage, starting from seed to going public, there’s been skepticism in the investment community.

There’s been skepticism because one of the things that many people say is that open source has generated less winners than expected, and not a lot of these winners have become really, really big. We could argue with it, but I’m just reporting what I’ve heard several times in the investment community.

At the same time, I am seeing more and more investors becoming sophisticated, becoming smarter, understanding what open source means, actually supporting it. I can, for example, make two examples that are extremely close to me.

I have two investors that bet on Sysdig pretty early on, Bain Capital Ventures and Accel, and in particular, my board members, Salil Deshpande, and Ping Li, and Eric Wolford, from these two firms – these are really strong open-source believers that really understand what an ecosystem means, are able to drive it, have a track record of generating successes with open-source companies.

The investors are there, the mindset is changing. I’m seeing, even just recently, multiple funds, these funds being created to focus specifically on open source. I think that the enterprise space, which is the one where Sysdig operates, is particularly ripe for disruption from open source.

I think that despite things not probably being where they should be, they are changing quite fast especially driven by a group of people that are leading the charge. In the future, we’ll see more and more of this, exactly for the reason that you just mentioned.

Open source will become, even more than now, the approach that dominates the software industry, and software is becoming more and more important. So, there’s no escape. The winners will be generated, existing players will be disrupted, and sometimes, it takes a long time, but it always has effects.

Challenges For Open Source Companies?

Michael Schwartz: What do you think are some of the biggest challenges today for open-source startups?

Loris Degioanni: Since we were just talking about funding, related to that is business model. I think that in some verticals, for example databases, we now understand the open-source model, like the go-to-market model pretty well.

We witness MongoDB, Elastic — there’s many of them, Cloudera — we witness to many success stories that essentially leverage sort of a similar playbook, or at least a variation of two or three playbooks.

In those verticals, where the playbook is understood, I’d not say straightforward, but it’s pretty clear how you approach this – open source is everything. Open source is much more than databases, and ranges anywhere from the operating system to user interface stacks, or JavaScript stuff.

I feel that in many of these areas, the go-to-market motion is less established, less proven and still requires a lot of creativity and experimentation from the founders, which also means that at the beginning, the open-source model can be relatively expensive to fund.

From one point of view, you’re focusing on your community, and that takes work, especially when you’re a small team, and takes focus. You have to do that, which means that you’re investing upfront, and you’re spending time and money upfront, have to essentially figure out the approach to market and the business model.

In my opinion, having bootstrapped, two open-source companies – that’s also the most delicate and the toughest part of the journey.

Challenges For Entrepreneurs

Michael Schwartz: One last question, because you have started two businesses, and I would’ve imagined most people who started one would know the dangers and emotional roller-coaster of that journey and not want to do it again, but do you have any advice for entrepreneurs that people going through that process of starting a business and not only starting a business but starting using open source?

Loris Degioanni: I wish I was able to say something magic that teaches people how to do this. I think that the only thing that I learned about, especially about the very, very early stages of a company is don’t give up, it’s really inch by inch.

Celebrate every little small success because that’s how you survive. You will get a thousand punches for every little success that you have. You need to cling to those because it is really a game of inches. It’s just the way it is.

And number two is, jump in the pool on the deep end, in the pool with sharks, and this is the best way to find out if you can swim or not.

I think if there’s something that makes me different from other people that maybe have not started company or have not been successful, that is, I just do it to survive. And yeah, we’ve seen what happens with Sysdig because it’s still relatively early in the life of the company.

But at the same time, Sysdig has over 200 people now. So, it’s a pretty decent-sized organization, and I still try to learn how to swim even at this stage.


Michael Schwartz: Thank you so much, Loris, for sharing some of your thoughts today.

Loris Degioanni: Thank you very much for having me. It was fun and pleasure.

Michael Schwartz: Thanks for the Sysdig team for helping to organize and promote this podcast.

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

Music from Broke For Free and Chris Zabriskie.

Audio editing by Ines Cetenji.

Production assistance and transcription by Natalie Lowe.

Operational support from William Lowe.

Have comments? Tweet at us. The Twitter handle is @fosspodcast.

iTunes listeners, send us here five stars, and please subscribe to the podcast – that really helps us get the word out.

Next week, we have Bart Copeland from ActiveState, another legendary company in the open-source ecosystem. Don’t miss it!

Until then, thanks for listening.

Episode 34: Tidelift – Paying Open Source Maintainers with Donald Fischer & The Changelog

In this special rebroadcast episode, we revisit the conversation held by Adam Stacoviak, host of The Changelog, the renowned podcast for developers, and Donald Fischer, Co-founder and CEO of Tidelift. Tidelift offers subscription-based support and maintenance for open source dependency applications, powered by the project’s maintainers themselves. In this episode, Adam and Donald discuss Tidelift’s mission to elevate open source software by supporting both the users and maintainers of open source projects.


Michael Schwartz: Hello, and welcome to Open Source Underdogs. I am your host, Mike Schwartz, and this is episode 34, featuring an interview with Tidelift Founder and CEO, Donald Fischer.

Tidelift’s mission is to pay the maintainers of open source software, including the developers who maintain libraries buried deep in the stack.

They have a brilliant and simple way how to do it. This is a really special episode of Underdogs because we’ve been given the opportunity to rebroadcast one of the best open source podcast teams out there.
If you don’t know The Changelog, it’s an epic podcast with currently more than 350 episodes. The hosts are Adam Stacoviak and Jerod Santo.

I’d run into Jerod at the Open Core Summit this past September. This episode is Changelog #324, which itself is a rebroadcast of the related broadcast Founders Talk, which features in-depth, one-on-one conversations with founders, CEOs, and makers.

Founders Talk is hosted just by Adam. He asks all the questions that I would have asked and adds more.

A big thank you to Jerod and Adam for sharing this interview ad-free. Thanks a lot, guys. Without further ado, here we go.

Adam Stacoviak: What’s it like to be on a mission of making open source software better, for everyone? Donald Fischer is one of four co-founders and the CEO of Tidelift. Their mission – to pay the maintainers; to pay the maintainers of open source software and provide a new spin on the highly successful business model that’s a win/win for the maintainers, as well as the software teams using the software… So I asked Donald what’s it like to be on this mission.

Donald Fischer: It’s amazing, actually, to be on that mission… And it sort of naturally is an outgrowth of everything I’ve been working on for the last 15 going on 20 years, actually. I’ve built my career in and around open source, in a couple of different ways, and so when we saw this opportunity to sort of contribute something new to the equation with Tidelift, we decided we had to go for it, because we saw the opportunity to create a new win/win scenario for all kinds of different stakeholders in and around open source.

Adam Stacoviak: I wanna go back into your past and figure out what got you here. What makes you and the rest of the team at Tidelift the team that can make this happen? Help me understand more about you and Tidelift and what you’re doing.

Donald Fischer: We’re building a methodology with software, and a set of practices to help professional software teams make better use of open source software, and the way that we do that is by helping to address a bunch of pragmatic concerns that professional software teams have with the software that they use.

That’s in areas like security, licensing and legal issues, just everyday ongoing maintenance… And the way that we address those problems is really what’s new with Tidelift. We do it by partnering with the individual open source maintainers and teams of maintainers who work on open source projects, and we kind of ask them to provide these professional-grade assurances for their individual open source projects or components.

Then what Tidelift does is we basically join those together and we represent them to these professional software teams as a whole product. In so doing, we essentially address two different challenges. One is that professional software teams – they need support, they need maintenance for the software that they use, whether it’s open source or not. And on the other side, it creates this economic opportunity for open source maintainers to do something that’s very closely related to the ongoing development of their software, and something that they’re best equipped and best situated in the world to do, but now for the first time for many of them, they can do that in a context where there’s an income associated with it, and an income that scales.

Adam Stacoviak: To kind of give some – maybe I’m speaking for you in some sense, so help me course-correct what I’m saying and make sure it’s accurate, is you did a lot of interesting things with Red Hat, there’s a lot of things you and some of your team members have learned from the experiences of Red Hat, and obviously, Red Hat is one of the most successful with supporting paid versions of open source, and support, and things like that.

Are you bringing a lot of what you’re doing now from your experiences with that? Is that safe to say?

Donald Fischer: Yeah, definitely.

I had the privilege of being part of the early development of Enterprise Linux at Red Hat, and all my co-founders also had tours of Red Hat around the same time; we all knew each other back then and worked together and stayed in touch since then.

But honestly, what we’re doing now is also informed by an awful lot of other experiences, in other open source communities and commercial ventures around open source communities; it’s not just a Red Hat copycat, it’s actually – if you want to put it in reference to Red Hat, it’s almost a generalization or an evolution of the Red Hat business model.

Adam Stacoviak: Yeah, where like their focus was one single open source project and one right way to scale it, to enterprises, and support, and all the things that everyone’s aware that Red Hat does – you’re doing it at scale across open source.

How do you make the decisions then to choose which projects to work with?

How do you determine what matters? Do you go to the community and say “Hey, which maintainers should we work with?” or do you go to the maintainers and say “Which maintainers of–” and maybe you’re even agnostic – not just JavaScript, not just Go, not just Rust, or other languages… How do you even choose where to place your focus?

Donald Fischer: Ultimately, remember that the way that we frame our solution is that we’re solving real-world problems for professional software development teams who are already building with open source components, but don’t have the kinds of safety net assurances that they would expect traditionally from enterprise software vendors.

So to your question of how do we choose which open source projects and maintainers to engage with, actually our subscribers choose; the customers of the Tidelift platform – they essentially direct us towards the maintainers who are best suited to participate in Tidelift. There’s a mechanism for doing that whereby we’ve built a software platform that attaches to the software development process at our customers, it sort of integrates with their code collaboration platform, sort of in a similar way to how a continuous integration system would connect, and we look at the open source components that our subscribers are using in their projects, in their applications, and then we go and recruit the open source maintainers of those projects to provide professional assurances around them.

So we just kind of follow where our customers are voting with their feet, so to speak.

Adam Stacoviak: And potentially their money too, since it’s a subscription.

The word alone elicits that there’s some sort of recurring payment into some sort of system that’s monthly, yearly, biannually, or whatever that might be; some sort of commitment on the long-term (or some sort of term) that says “We wanna use enterprise-level type software that’s open source, that includes support, includes SLAs (or whatever they may be needing) on a certain duration” and their vote is essentially participating in that subscription, but then saying “Hey, this is the software we’re using.

Can you go out and establish these relationships with those maintainers?” Is that how it works?

Donald Fischer: Yeah, exactly. So in other words, a customer of ours will subscribe to Tidelift for one of the applications that they’re building, connect to our software, connect to our software infrastructure. Now we have a lens into what are the actual open source components that they’re using…

Adam Stacoviak: Dependencies.

Donald Fischer: Yeah, I was about to say, not just the top-level components, but we look at the transitive dependencies as well, all of the packages that those depend on…

Adam Stacoviak: The entire tree.

Donald Fischer: Yeah, we build the tree.

And then the way that we’ve packaged it is we charge the subscriber a fixed cost for all of the packages in the Tidelift subscription. It’s sort of like a Netflix subscription in that way, where Netflix might not have every movie that you want to watch, but if it has a lot of the kinds of movies that you like, it’s gonna be interesting for you to be a subscriber; there’s always more movies joining the catalog.

So we sort of simplify it by charging one blanket subscription price, and then we bill the subscribers on a monthly basis for that. Then at the end of the month we take each subscriber’s payments for that month and we split them up and allocate them specifically to the participating maintainers of the packages that they use.

So a subscriber’s dollars only ever get directed to the participating maintainers for the actual packages that that subscriber is using, and that’s one of the ways that we align the interests up and down the system.

And if there’s not a participating maintainer for a particular package that the subscriber is using, we sort of note and increase the potential payment that would be available for a new maintainer who showed up and agreed to participate in the Tidelift system. So we sort of create an incentive for somebody to – we signal the funded incentive for somebody to come along and take us up on following through on those maintenance tasks around that particular package.

Adam Stacoviak: So if I’m a maintainer and I’m participating in this, my “income” or “revenue” generated from this style of funding for my project or my teams – is that number coming from Tidelift, does it ebb and flow then because of that? Or is there some sort of barrier or predictability they can have into how they can begin to step away for their full time job or do this full time, or whatever it might be? How do they understand the income that’s possible, and even not just possible, but on a day-to-day or month-to-month basis, how does it ebb and flow?

Donald Fischer: This is actually one of the fundamental reasons why we started the company, and one of the fundamental contributions that we wanna make – it’s really hard to dedicate your efforts on an ongoing basis to an open source project if you’re not sure what you’re gonna be paid tomorrow, or especially if your income is swinging erratically in terms of what you’re receiving related to your open source project. So our goal, in other words, is to make it a lot more predictable month-to-month.

It doesn’t mean that your income could never ever go down in the Tidelift system; as I said, we pay the maintainers based on subscribers using their software, so if all of a sudden none of our subscribers are using that software anymore, the amount could go down. But in reality, once software is in place, it tends not to go anywhere; just new software gets added.

On the other hand, we’re growing quickly, the audience of participating subscribers, so the total dollars in and the number of potential teams that might be using your project for any given maintainer is increasing. We think that what will practically happen as a result of this model is that open source maintainers will see much greater predictability and have sort of a steadier income to depend on, which is in contrast to some of the other existing models for funding open source projects that might be more episodic if they’re based on grant funding, or sort of bounty kind of mechanisms.

Actually, I think all of those systems are great, and anything that is funding open source is laudable and awesome, but we just saw an interesting opportunity to contribute another model that’s additive and incremental on top of those.

Adam Stacoviak: I wanna rewind a little bit back to the dependency tree that you mentioned, just for those listening who may not be intimately familiar with how software works, which leads into one of your acquisitions, and you can speak to that if you’d like to. But it just kind of helps to get a lens into the dependencies of dependencies; so when you have an open source project or just a project in general and you’ve got an application you’re building, when you use Vue, for example, on the front-end, well Vue has so many layers of dependencies beneath it that whenever you, as you mentioned, come into the platform, you’re scanning their dependencies, and it probably points out some opportunities to grow as you’ve mentioned you are.

But I kind of wanna just touch on that a little bit, because not everybody listening to this is that familiar with the software process and what dependency trees actually are, how deep they might go as dependencies of dependencies; Vue has tons of different things it relies upon, and all those things tend to be other open source projects that are probably not receiving funding or really have any sustainable model behind it, aside from maybe side work. Which is fine, that’s open source, but we’re looking for ways to make it enterprise-level and enterprise-grade, I’m assuming. Is that right?

Donald Fischer: Yeah, that’s right. The issue of the lack of appreciation or really understanding of how much software exists below the visible water line is really remarkable.

For example, we recently wrote on our blog about look at React – super popular web front-end framework, born at Facebook. If you go through the prescribed Hello World creating a new React application, using the very well-executed Create React App tool, you’ll end up with a sort of Hello World web app based on React, and that thing by default will have 1,103 dependencies as of the last time we that we looked.

So that’s over 1,100 distinct packages coming out of the Npm JavaScript package catalog. Those are coming from a lot of different places. A couple dozen of those are coming from being authored by the Facebook React engineering team.

But the beauty of open source software is that the vast majority of those are coming from somewhere else, from somebody else. But all of them are getting built into your React application.

So if you’re a professional software team at a large enterprise that has a bunch of goals around security and compliance or needs/requirements, things that you need to comply with, it raises a lot of questions about “Who’s on the hook to support all that stuff, and why would they be on the hook?” To which our answer is the best reason for them to be on the hook, or a great additional reason for them to be on the hook is that they’re getting paid to do the work to make those things true about those open source components. That’s really the meat of what we’re trying to do.

Adam Stacoviak: An example that – I’m not sure if you’re familiar with Nadia or not, but Nadia Eghbal, when we first learned about her was several years back, and we’ve since done a podcast with her called Request For Commits.

Donald Fischer: I’m a long-time fan of Nadia’s and the show. I recommend it to all of your listeners who have not yet explored those paths.

Adam Stacoviak: And it is retired, so when you go listen, just know that, and send us your hate mail; we wanna hear more of it, because we wanna do more around sustainability of open source, but that show just is in a retired state, for its own reasons. But the last episode does tell you why, so if you’re really curious, just listen to the latest episode.

But you know, she’d written about the economics of open source, and the example she used was the rate at which Instagram was able to become a billion-dollar company and then be acquired by Facebook – I don’t mean to keep going back to the Facebook well, it just happens to be that example. But Instagram was built on open source software.

Now, I’m not that intimate with the details of what they’ve given back to open source; I don’t know what Facebook’s involvement is, and they’ve since acquired Instagram, but that was the initial yardstick, at least by Nadia, on like, you know, Instagram was worth – the acquisition was like four billion? One billion? I can’t recall right now. It was like 4 billion dollars from Facebook, so somehow they got to that value and they were built upon open source software.

So going back to your model – we have this economic need of all these dependencies, and they would have never been able to get there building all the technology on their own. They had to lean on open source. So there’s a responsibility there to support the dependencies beneath the tree.

Donald Fischer: Yeah, there’s a couple different ways to look at it, honestly. One lens of looking at it is to say if you’re building on all of this software, you owe it to the creators to allow them to drive some participation in the value that they’re creating. First of all, I agree with that; I think that’s a very reasonable worldview. But it’s hard to get large organizations to open up their checkbooks for things that are purely morally justified.

One of the things that we’re bringing to the table with our model is we’re just inviting professional software teams to act out of their explicit self-interest, and we’re helping open source maintainers create a new service offering that didn’t exist before, that we’re seeing as very appealing to a lot of the professional software teams who are using their software. And again, the specific service that we’re helping put together is a community of maintainers who are proactively committed to maintaining the individual open source packages to a well-defined standard, and then Tidelift’s role in that is to sort of be the intermediating agent that helps all of those individual open source maintainers and teams connect to a particular professional software team in an organization.

We’re not asking people to buy a Tidelift subscription mainly because it’s a morally correct thing to pay the maintainers; we’re inviting people to buy a subscription because it’s in your best interest to pay the maintainers.

When you pay the maintainers, the software that you’re using is better and more reliable, and we’re adding some business process and technology to the mix that helps you kind of define what is meant by more well-maintained and reliable, and sort of gets everybody on a common, shared mission.

Adam Stacoviak: So you say “professional software teams” – I think I know what you mean when you say that, but put it in laymen’s terms for me and the listeners. What is a professional software team as it relates to what you’re doing with Tidelift?

Donald Fischer: When we say “professional software team”, we’re typically referring to a team building software within an enterprise.

Enterprise is kind of a silly IT word, or entrepreneurship business word; it means a company, and often times like a larger company. Again, I’ve spent the last 20 years in and around open source, so I know one of the beautiful things about open source is that it’s accessible to all different kinds of audiences.

If you’re an indie developer – I mean, I started working with open source, getting involved in open source when I was a student. There’s individual entrepreneurs kind of picking up raw open source and building with it. It’s awesome; it’s part of the beauty of the whole thing.

There’s also big teams inside of mega-corps that are building with open source as well, and those different audiences have different needs in and around the software that they’re using. When I’m doing a side project on the weekend, kind of cobbling together some open source components to sort of scratch my own itch, for sure I do not need an enterprise support contract, I’m not super-focused on intellectual property documentation for this thing that’s only ever gonna live on my laptop and never go anywhere. But when you have a team at a financial services company, or a healthcare company, or an industrial company, and they’re building the core software that powers those businesses, and in 2018 for sure they are building that with open source software, they would love to have some additional guarantees around that software.

So the open source software, by the open source definition, gives them a bunch of capabilities right off the bat for software that’s under an open source license. They can access the source code, they can change it, as long as they adhere with the different requirements for what they need to do if they redistribute it.

But the open source license doesn’t give you somebody who’s on the hook to make sure that security vulnerabilities that arise will be dealt with in a timely way. It doesn’t give you any certification around the licensing of all the components of the software that you find that are connected to that, or that are dependencies of that… And it doesn’t give you any kinds of assurances about what’s gonna happen with the software in the future – is somebody gonna keep caring for it, and taking care of this essentially living organism that the software projects need to be, as the world evolves over time?

Those are the things that we think that professional teams need, that not all open source developers need, but professional teams do need it, and as a result, they’re willing to pay for it. One of the things we’ve done in the Tidelift context is verify that by talking to a lot of those organizations, surveying a bunch of those organizations; we shared the results of a broad survey we did this year that said something like more than 80% of professional software teams were very interested in paying for those kinds of assurances around the open source software that they use.

Adam Stacoviak: Another aspect to the professional software teams I thought you used in this context was describing the teams creating the software, meaning the open source software. Did you use it in that context as well? Like, when you’re identifying who to work with?

Donald Fischer: No. The way that I’ve been using the terminology “professional software team” – I’ve been focusing more on the subscriber side in our terminology, or the consumers of open source software.

I actually think there is a really compelling opportunity on the creative side of open source to also, in a sense, professionalize there. And I wanna be careful about what I mean by that word, professionalize. Open source maintainers, whether they’re paid or not, it is demonstrably true that they create amazing software that is prograde, is used in real-world applications all over the place.

I guess a missing part of the “professional” definition there is that often times they don’t get paid for the work that they do, so it’s hard for it to be a profession for the individual open source maintainer.

So I do think there is a double entendre there, which is “We would love to help open source maintainers make it their profession,” and that’s really one of our ambitions with Tidelift – to enable more open source creators to dedicate more of their time to their open source projects, innovating the features and functionality there, also just like doing the everyday kind of maintaining it tasks. And if we, all of the users of open source, give them the license to do that, and the necessary financial incentives to do that, then we’re gonna benefit, because the software that we all use is gonna be better. It’s awesome.

Adam Stacoviak: The reason why I asked you that question in the opening was I’d heard you use it and I thought that your reference was essentially helping to understand the type of maintainers or type of teams that maintain software describe them. That’s how I thought you were using it in that context, which is why I opened up with that question. Because I wanted to understand more so like when you focus your attention on – I know that a lot of your subscribers are the ones that are leading you to, down the dependency tree which matters to them, because they’re paying for the subscription, and essentially, you said they’re leading with their feet. That it would describe the kind of teams that are good candidates to be a part of this, because they can provide the support, they can provide the other assurances that enterprise teams need to rely on open source.

Like you said, in 2018 it’s pretty difficult to build software today in any real capacity without using open source… So we have to find ways to support it, and I asked you that question to think that maybe you’re describing a type of maintainer, a type of maintaining team, their philosophy, the way they organize, the way they govern, what are healthy balances in there… I thought that’s what you were talking about, that’s why I went that direction.

Donald Fischer: Yeah, so just to comment on one really fun part of what you were touching on there – I think the really happy news here is that teams inside of larger enterprises that have the requirements for security, licensing, maintenance kinds of assurances around the software that they use. It turns out the software projects that they’re picking to build their new applications out of, the software components that they’re taking out of the package managers, they’re the same ones everyone else is using. They’re using the same components at a big bank that I’m using to do my weekend project.

So it’s actually a really nice situation, where if those professional teams are interested in paying for these additional assurances, the creators of those open source projects and technologies can access that income that’s associated with that, it gives them the license to spend more time on the projects that they’re creating, and then the improvements or increases in functionality – that can be shared by everybody, the payers and the non-payers. That’s actually one of the beautiful things about open source.

Adam Stacoviak: That’s why I love your name, Tidelift. That’s the underlying (to keep the puns going) current of what you’re doing here; you enable subscribers to lift the tide of everyone. Like you said, I could be using whatever the library may be that’s part of the Lifter project you have going on, which we’ll dig into more. If I’m paying and they’re getting supported, then I’m just enabling others to benefit from my subscription, and then therefore funding of those maintainers in those projects. I love the name, it’s spot on.

So we spent the better part of maybe 40-ish minutes kind of digging into the context. I wanted to go into more of the getting started, where the idea came from, some of the background even, which is sort of like the crux of what this show is really about. Which I love doing – a deeper explanation of what Tidelift is and what you’re doing there, for the better part of 40 minutes.

Let’s kind of rewind a little bit and just get a picture of some of your personal experiences, and maybe the experiences of other team members. But maybe let’s start off with back in 2017 when this began – from what I understand, you were in venture capital, you stepped away, you had this idea.

I believe this began with a fundraising round; I’m not really sure. Can you go back to those details and help pave the way for how this got started?

Donald Fischer: My personal history briefly is I started out as a programmer, I studied computer science.

As we talked about before, I had a really interesting tour at Red Hat starting in the early 2000’s, and was able to be part of the team, participating in building the Red Hat Enterprise Linux business there, which is really an amazing thing, that is I think often under-appreciated in the IT industry.

Adam Stacoviak: Absolutely.

Donald Fischer: Red Had as a whole is an over three billion dollar recurring revenue business now. It’s really a beautiful and amazing thing, and there’s a lot to be learned…

Adam Stacoviak: Did you say billion?

Donald Fischer: Yeah, three billion dollars a year in revenue.

Adam Stacoviak: Three billion… Just to make you say it twice, because that’s pretty big.

Donald Fischer: Yeah, it’s big.

And you know, it just steadily grows. It was an amazing time when – you know, I did not figure this stuff out myself, by the way, but as a team, and as an organization, we learned a lot of things about what (again) professional software teams that are using open source really need, and that doesn’t just come for free. And we’ve figured out a model that was appropriate for that set of technologies at that time, and it has continued to evolve to support a steady business today.

What I did after Red Hat is I’ve spent almost a decade as an investor, working with early stage founders who were starting and growing businesses around open source communities, and I chose to focus on that theme… Because I’ve personally just always been fascinated and sort of in awe of how open source communities arise. This phenomenon where technology will come from a creator or a small band of creators, and then a crowd of individuals will start to kind of assemble itself around that technology.

You see technologies sort of form these tribes, and when I say tribes, I mean in a good way… Not in a tribalism kind of way, but in a sort of…

Adam Stacoviak: A Seth Godin way.

Donald Fischer: …collective way, yeah. It’s really amazing.

You might join the Python tribe, or the Ruby tribe; or maybe it’s not a programming language, maybe it’s the deep learning tribe, or something like that, right? But it starts to become part of individual people’s personal identity, their professional identity. It’s really a powerful thing, so what’s always fascinated me is if there’s this fundamental energy around technologists sort of assembling themselves in these tribes – there’s so much power to it – and what are the opportunities to add a commercial component there.

The thing that I’ve always really focused on is not just how do you go kind of harvest that energy from the community, which I think is a very pessimistic way to view the world, but can you build a complementary business that sort of amplifies the energy in one of those communities that helps capture more resources to invest more aggressively into developing the technologies, or advocating, evangelizing the technology? How can you build businesses that sort of amplify those communities and make them even more successful, and make the individuals within them more successful?

I think there’s a really fortunate history of startups and businesses of different scale being built over the last 15 years now that do that, and that’s just been a phenomenon that I’ve loved to follow, and sometimes to be part of.

Adam Stacoviak: I think the important thing to draw from this is it seems to me that you’ve spent a lot of your life trying to find ways to support open source, and it’s either helping certain types of businesses build themselves around open source through venture capital and investing, and I’m sure in a lot ways leading product, because that’s also part of the investor’s role, is to be somebody who is an adviser to the direction of the business and the viability.

I think the other important thing you said there was that you’re the support, rather than – I forget the exact language was that you used, but essentially, you’re there to amplify versus to draw and take away from the energy. What was the word you used of how you’re not attaching to the community?

Donald Fischer: I think the language that I used was instead of trying to harvest energy from these communities, it’s like “Can you actually build an engine that contributes net energy back to the community, that helps it grow and become more sustainable, as opposed to sort of drawing energy off of it?”

Those are the really powerful companies, and also I think they help to form really powerful communities.

If you look at the different businesses that have been built around Linux, or different big data technologies, or core systems-level databases and things like that, if you can get a community going that has complementary and additive businesses, that’s a beautiful thing.

And to connect that to the story of Tidelift, I’ve been a student of that phenomenon for a long time now, and I’ve had the great opportunity to work with a number of other folks who are also fascinated by the same kinds of dynamics.

One of the things that annoyed me about the existing models for commercializing open source or building these complementary businesses around open source is that, you know, if you look at something like the venture capital model, where I was personally quite active, there’s only a relatively small number of open source projects or communities or tribes (if you will) that have enough scale to them for the traditional venture capital model to work.

Adam Stacoviak: Yeah.

Donald Fischer: There definitely are some… At this point, there’s several dozen substantial venture capital-backed companies that have been formed, are performing, several have gone public.

It is a model that works, but it only works for a really pretty small subset of open source in general. And one of the really interesting things to me is that it only works for a subset of the commercially relevant open source projects.

So I would often, as a venture capital investor, meet with entrepreneurs, open source creators who had projects, they had lots of real-world professional users – often times the users that they had were asking them for “Hey, can get a support contract for this, or a service-level agreement for it?” and yet they didn’t really fit the venture capital model of going and raising X million dollars and then building a company from scratch with all that that entails; building a sales force, a finance function, a way to handle subscriptions, a level one support team and so on.

So when I started talking to my co-founders, the gentlemen who eventually became my co-founders at Tidelift, we looked at that problem and that opportunity and we said essentially “What if we build that go-to-market mechanism, like the sales and support and finance, back office kind of stuff, what if we just build that once, instead of asking every open source project to do it themselves, and then just let the open source projects and teams plug into it?” Sort of like in the way that creators plug into Etsy.

You know, one of the beautiful things about these marketplace models is if you’re amazing at creating some craft good, you can go to Etsy, and Etsy helps you access an audience of people who are interested in your kind of thing, they handle all the payments, and the logistics, and customer service issues and so on, and you don’t have to go learn how to do all of those things. Etsy is kind of your partner for doing that. You get to focus on conducting your craft. That’s one of the things we’re trying to do with Tidelift – we wanna make it possible for open source teams who are building technologies that are used by these professional organizations to be able to access some of that potential energy and income that can be associated with that, without having to go become salespeople, or customer support people themselves.

We’ll kind of do that with you, in the sense of do that for you, as the open source creator; you plug into our infrastructure and you focus on making the open source project amazing. We’ll help with all the bunch of the business stuff.

Adam Stacoviak: These teams generally would still have to be the ones providing the service-level agreement, right? If I understand correctly, you may institute it and do the business-level side of things to ensure that there are subscribers that have desires to bring on certain lifters or whatever, but it’s still the lifter’s job – which is a term we haven’t defined yet, so maybe it’s a part of your response, to help me understand really what a lifter is, or what that role is there. Because they’re gonna have to eventually support that software, and provide the enterprise-grade stuff that you’re selling as part of the subscription. This whole general sales thing – that’s what the product is, it’s reliable, it’s supported, bug fixes etc.

Donald Fischer: The way that it work is that one of the things that we add to the equation by creating Tidelift is we are an intermediary between the professional teams that are paying for these assurances and the individual open source maintainers.

A couple benefits of that – one is that we turn a many-to-many relationship that would basically be impossible for every open source application development team to strike a business agreement with every one of those 1,100 Npm module maintainers that goes into their web app; we allow them to have one place to go, which is Tidelift, and then we sort of federate all of the participating maintainers behind that.

So we have a relationship with each of the paying subscribers, and then Tidelift also has a relationship with each of the participating maintainers. And what we ask the maintainers to do – it’s actually detailed on our website, for any maintainers who are interested in understanding what we propose in our model…

We ask maintainers to look after their projects according to a certain set of criteria. These are things like work with our security response team if there is a new security issue that arises, sort of make sure that it’s addressed in your particular package, or if there’s an issue in one of your dependencies, make sure that your package is adjusted to take account for that, help us documenting new releases that are happening, any licensing changes – we sort of record all of that. Those are the kinds of things that we ask maintainers to do.

Just to highlight – at least for now, we’re not asking maintainers to fix a bug or add a feature, or provide help desk support for a runtime issue that was encountered by a subscriber. Those things — there are open source business models associated with that; they’re challenging business models, because they scale with the number of hours that an open source maintainer has in their day.

There’s only so many support tickets you can respond to, or so many consulting engagements that you can have. So since that’s already possible in the world, we’re trying to focus on sort of a new model, which is doing things that can be done once where many people benefit from them, like resolving the security issue – you do that once, and all of the users get to benefit from it.

Our part is to create the alignment of interest, so that those things always get done with predictability, and we do ask our participating maintainers (lifters, as we call them) to do those things, and then Tidelift’s role is to make sure that everybody is following through correctly, deal with any kinds of issues that come up.

Adam Stacoviak: You used the term “a well-defined standard” earlier in the call. I am assuming that that means that it’s either written down once, or it’s the way things are, or it’s maybe a case-by-case basis with each lifter or maintaining core team, that they say “Okay, Tidelift, we wanna be a part of this, we wanna be a lifter. Sign us up, we’re ready to go,” and then there’s something in these well-defined standards that says “Hey, this is what you’re committing to.” Is that accurate? Can you describe that?

Donald Fischer: It’s more like a set of open source project best practices that we ask our participating maintainers to follow.

And here’s actually another really great part of how this all works – most open source projects that have a substantial user base are already doing most of these things, or all of these things.

This is things like having a responsible disclosure policy and adhering to a responsible disclosure policy around security incidents, or using two-factor authentication on all of your systems that are involved in the build and distribution chain for an open source module. Sort of like checklists for healthy living as an open source project.

Those are the things that we ask open source maintainers who are participating in our system as lifters to do. And even though many of them are doing most of those things by creating a uniform standard where everybody who is participating in the Tidelift system is doing all of those things, it allows us to represent that this collection of software as a whole meets those standards to our subscribers.

And again, that’s worth a lot to these professional software teams that are building enterprise applications; if we can show them a menu of healthy open source project attributes that we’re ensuring are true for the dependencies that they use, they love it. And it’s a modest cost for them to pay, to ensure that the software that is really powering their business is well cared for.

Adam Stacoviak: Most companies have co-founders. In this case, you have three other co-founders, I believe. What’s the story there? Who are they and how did you all meet?

Donald Fischer: Yeah, this is the best part of Tidelift for me, it’s my co-founders, and then the team that we’ve built to go on this mission together with us, and it is an interesting story.

I have three co-founders – Havoc Pennington, Jeremy Katz and Luis Villa. We’ve all known each other pair-wise for at least 15 years, and a couple of us go back longer than that.

As I mentioned before, we all intersected at Red Hat in the early 2000’s, and then we’ve collaborated on different projects since then… And each of us sort of has a different ingredient that we contribute to the mix.

I talked about my background a little bit; a lot of it is sort of the business side of open source. Havoc, our co-founder, currently is leading Product for us. He is a long-time veteran of the open source world. He was originally one of the founding voices in the GNOME Freedesktop community, the Linux desktop, and co-led the creation of the GNOME Foundation, which continues productively to this day, and implemented a lot of the software himself that powers the GNOME desktop.

I got the chance to work with him first when he was leading the desktop development team at Red Hat. Then Havoc has interestingly gone on to do tours in a couple of other interesting and different open source communities. He was working for a stretch in the Scala community, in sort of the greater Java world, and then most recently was back in the Python data science community before we got together to start Tidelift.

Then the third co-founder is Jeremy Katz. Jeremy is an amazing technologist. I got to know him when he was one of the core developers at Red Hat, then he went on to sort of grow his professional portfolio beyond just open source – he was an early employee at HubSpot, the marketing SaaS company. He led the implementation of this product called Stackdriver, which was a startup that was sold to Google and now serves as essentially the management console for the Google Cloud platform, so really a seminal piece of software in the cloud generation.

And our fourth co-founder, Luis, has (I think) the most unusual story, which is Luis started with the rest of us as a programmer, open source developer, but Luis ended up going to Law School, and then closing that loop by becoming an open source legal expert, really, one of the widely respected voices around legal issues associated with open source.

He did a really interesting stretch working with Mozilla, where he actually led the drafting of the Mozilla Public License 2.0, and then he had a really interesting time at Wikimedia Foundation, the organization behind Wikipedia, dealing with a whole bunch of open content issues there, and sort of leading the community effort there as well.

So it’s a really interesting set of disparate backgrounds and professional experiences, grounded in having all been open developers, software developers, and open source participants in the early years. I guess what we’re trying to do is bring those different experiences back together and apply them back where we all started, trying to make open source work better for everyone, the creators and the users.

Adam Stacoviak: It’s an interesting mix of people. Obviously, you’ve got business, you’ve got — I’m sure everyone was somewhat involved in coding, at least at some point in their life, but taking a role on that, having a role in Google and what powers that, and then legal; the licensing part of open source is, to some, often overlooked, but pivotal to how it could be used.

We see license changes in business; there’s some recent news not long ago with Redis around Commons Clause, or License Zero. All those things have implications. And even React – because you’ve mentioned them earlier, and we even logged that, about who actually supports React.

They had – I’m not sure of the details because I don’t follow this closely, but it had some concerns around the community, the way Facebook licensed React. We’ve even had Heather Meeker on Request for Commits, since you’ve mentioned that earlier, and with Nadia – we had a deep conversation around the importance of licensing.

It sounds to me like you’ve got an ensemble of the right components to do Tidelift… And I don’t know how you did it, but that’s pretty insane that you have. And it’s even more interesting that you all intersect at Red Hat.

Donald Fischer: Yeah. I mean, I just feel so privileged to work with these gentlemen, and then again, the team that we’ve brought aboard to share this mission with us; it’s a lot of fun. But to the point around licensing – the legal code is one of the technologies that makes open source possible.

It is sort of a technology onto itself, and like other technologies, it’s complicated. It’s complicated for the creators to make the right sets of decisions around “Which license should I use? What are the tradeoffs?” and so on. It’s also really complicated on the consumption side, and that’s (again) one of the things that we’re trying to help address for professional teams that want to engage with open source in the right way.

They don’t have the time to each go become an open source legal scholar like Luis did, so we’re gonna try to create some tools and standard ways to approach this, that let them get the advantage of some of that substantial knowledge that Luis has accumulated in his days.

Adam Stacoviak: I’m sure this is the case for most founders or co-founders, but I find it kind of interesting that each of you have a particular milestone in your career, each of you can point to a particular thing you’ve done that is widely notable, to say – not so much that this is why you do what you do or you belong here, or you can trust you, but it’s like you all have some large-scale contribution to the community you’re currently serving through what you’re doing now. And to say “We’re part of the community. We’re not just entering (like you said earlier) and trying to solve a problem, and we’ve never been here before. No, we’ve been boots on the ground for decades, and our resumes and the work we’ve done before” is what you point to to prove it.

Donald Fischer: Yeah. I mean, the only caution there is that every situation is different. One of the things I always try to remind myself is to learn from the past, but not to over-apply models from the past, because sometimes they can be misleading. The world changes.

The world is a lot different now in 2018, in terms of where open source is in the software ecologies in general versus 2002. Back when we were doing the first version of the enterprise Linux business model in 2002, most professional companies looked at Linux and said “This thing looks crazy. What do you mean free software? How could this possibly work?” etc.

Now, fast-forward 15+ years later, there is no proprietary software to buy in most of these categories, right? It’s pretty hard to go find a proprietary application framework to build with these days. It’s almost complete takeover by open source, but our point that we’re trying to highlight with our work in Tidelift is just because open source is everywhere, it doesn’t mean that software doesn’t need to be maintained.

In fact, it sort of heightens the question of “Who is taking care of that software, and why?”

Adam Stacoviak: Right. Who is responsible, yeah.

Donald Fischer: Yeah, and who needs it to happen, and how do we connect the dots?

Adam Stacoviak: Well, let’s close the loop on this idea of sustaining open source, maintaining open source, this phrase that often gets put out there and talked about, and the actual mechanics of what that really means. There’s other models out there, and every model is needed, because you said earlier “Hey, if money is coming in open source – great! Let’s not say one way is wrong or right”, but I wanna kind of go into the differences of other models.

We’ve talked to Pia Mancini on here before around OpenCollective, we’ve talked to Eric Berry around CodeFund, previously CodeSponsor… I haven’t talked to anybody from Patreon before, but we’ve definitely talked to Evan You on Request for Commits and several others. Henry Zhu from Babel on how they’re leveraging their ability to go full time and using those platforms to really good advantages.

But then here comes Tidelift – so what is the biggest difference between Tidelift and other models where they could be seen as like more charity, or somewhat value-based?

Donald Fischer: First of all, just to get on the table – the more, the merrier.

Adam Stacoviak: Right.

Donald Fischer: I’ve said it before, I think every channel to pay the maintainers is additive, and so we’re just trying to add another option into the mix, and probably “the answer” is not one of these, it’s a polyglot solution of multiple of these working in different ways.

I do think that we have a somewhat different approach than a lot of the systems that have been implemented before, and it comes back to just being very practically-minded around not just asking organizations to pay back the maintainers that created software that they’re using because it’s the right thing to do, not only because it’s the right thing to do.

We’re seeking to give them the additional self-serving reason to do it, which is if I pay for a subscription that covers these open source components, I know that there is somebody who is committing to me that they’re gonna care for this software.

And when we say “care for the software,” it’s written down what we mean by it, and if an issue arises, I’m gonna have someone to go to; they’re committed to work with me. So it’s something that they don’t get if they don’t pay, and we think that’s compelling to a certain audience.

And again, we’re more oriented towards these software teams within enterprises. That’s not particularly compelling to most hobbyist developers. They’re not really the audience for Tidelift, at least at this moment. Not the one that we’re targeting, at least. And for hobbyist developers, I think there’s a bunch of other options on the table.

By the way, as a hobbyist developer on the side myself, I happily contribute to a number of different funding mechanisms for the projects that I use. I think it’s great, and I love doing it, and it makes me feel good, and everybody should.

Adam Stacoviak: I definitely echo what you’re saying on “the more, the merrier.” One question I have for you though is like, since you’ve said you’re a listener or this podcast, and you listened to one of the latest episodes with Eric Berry, one thing I can recall him saying in the conversation we had was around this extra layer. So the example we used in that show was Jack Lukic, who was the creator of Semantic UI, which we actually use here at Changelog; it’s the UI framework we use for our back-end.

And the question in the conversation there was essentially like layering on one more thing for a maintainer to do. So Jack may be really great with user interface, maybe really great with the framework, and that’s all he may really wanna do, but he’s hit a stopping point of time invested because of the lack of funding. So in the Tidelift model – and maybe Jack is not the perfect person. Jack may be considered a hobbyist, even though his project is used tremendously, and very vital to so many projects that are using it. But he may not have the time or the desire to wanna do the other things to support or to be in the Tidelift model; how does that fit in?

Donald Fischer: I think if I was to rephrase the question, it’s like “What if the open source maintainer or team isn’t interested in doing the Tidelift-style maintenance?”

Adam Stacoviak: Assurances, yeah.

Donald Fischer: We sort of look at that, again, from the – think about it from the open source user’s perspective. The user is still interested in having somebody look after the security, look after the licensing and the maintenance of this component.

So if the current contributors to that project are not interested in doing that, can we create an incentive for some new contributors to join the project to do that? And one of the patterns that I’ve witnessed being in and around open source communities is when somebody shows up in an open source community and they say “Hey, I’m interested in doing some of the grunt work around here, to sort of help with some of the day-to-day maintenance tasks,” especially if everybody else has already passed on volunteering to do those things, usually they’re accepted with open arms.

So I think that our model can potentially help in those scenarios by giving someone else a nudge to sort of show up and volunteer… It’s not really volunteering, because they get paid to do it.

Adam Stacoviak: They’re getting paid!

Donald Fischer: Yup. “Pay the maintainers” is our mantra.

Adam Stacoviak: I like that tagline a lot. It’s short, it’s three words, it gets to the point. Pay the maintainers.

I like that. And you said “The more, the merrier”, I think that’s what everyone is saying – let’s just find ways to pay the maintainers, so that they keep maintaining, so that they keep innovating, so they keep really just enjoying it. Open source is fun to be involved in.

What makes it not fun is whenever you’re not – not so much not rewarded, but just when you feel depleted at the end of the day because you wake up to 35 new issues, all these different things, and then you’ve got your day job, and your family, and your life.

That’s what drags it down and makes it very difficult to scale, and maybe why earlier you mentioned venture capital. Capital wasn’t a great option for it, just because of the way the market worked. There’s all these different ways, but this is just one of several ways we can pay the maintainers, and I like that mission a lot.

Donald, we’re coming to the close here. I’d like to end with this question. Super-secret – something’s going on at Tidelift that maybe people aren’t aware of; you know, I don’t know. Is it a new announcement, something coming up…?

What’s something that no one knows about that you could share here on the show today? Or even tease, whatever it might be.

Donald Fischer: Yeah, I’ll just mention a little tease.

We’re gonna have some really exciting to us, and I think relevant news coming out in the next couple of weeks, talking about getting to a certain kind of scale milestone on the Tidelift platform. Stay tuned for that.

Stop by Tidelift.com, depending on when you’re listening to the podcast, to learn more about sort of showing the model working at some interesting scale that we think people will find compelling.

Adam Stacoviak: When you say “milestone”, it means the big deal, right? So this is a big deal.

Donald Fischer: It means we’re reaching another waypoint on our journey to demonstrating the Tidelift model working at scale… And paying the maintainers.

Adam Stacoviak: Gotcha. So even if you’re listening to this distant in the future, and this announcement has since passed, we’re gonna update the show notes for what Donald is talking about; we’ll definitely link it up, whatever it might be.

I don’t know where it’s at, but wherever it is on the internet, we’ll link it up, so just go back to your show notes. We’ll make sure we have those up to date.

Donald, anything else in closing? It’s a fun journey that you’ve been on, from your history in open source, all of the different co-founders that have worked with you on this, the mission you have to fund open source, in particular “Pay the maintainers” – I love that.

Anything else you wanna say in closing to the listening audience that may be interested in the journey of open source and what it’s about?

Donald Fischer: First of all, I would just say thank you to you, Adam, and to the Changelog and Founders Talk for covering these topics, because I think you’re a really important voice and you’re shining light on important issues. I guess that would be my parting thought – these issues are important. As a lot of folks now have pointed out – you referenced Nadia did an amazing job shining a light on the importance of open source software…

Adam Stacoviak: Yeah.

Donald Fischer: We have now decided collectively to build our civilization largely out of software, and that software is open source.

So if we want our world to be a great one, we need our software to be great, and that means we need our open source software to be great. I’d just invite everybody who is interested in these topics – learn more about the different models that are being proposed.

I’d love for folks to come and learn more about Tidelift, and talk to us and help us evolve it in the right way, take it the right way; launch additional models. Let’s try a whole bunch of things, and collectively I think we can have a really positive impact on the world.

And thanks a lot for paying attention and putting this in front of an interested audience, Adam.

Adam Stacoviak: Absolutely, man. Thank you so much for saying that. This has been a labor of love for many years, turned business, and we’ve been fortunate in that. And if it weren’t for our listeners and those contribute to open source, and this entire community, we would not be able to exist obviously, because there’d be nothing to talk about.

But we’re just so thrilled that we get to be in this position; we’ve been down a long road, and I’m honored to have 1) you on the show, then 2) you as a listener… And when I mentioned things, even in the breaks, you were like “I’ve already listened to that.” I didn’t know that you were that passionate about – you know, sometimes people say thank you, but you’re an actual listener, who listens to every show, or at least a lot of them. That’s awesome, I love that.

Donald Fischer: Keep up the good work, man.

Adam Stacoviak: Thank you, Donald. It was a pleasure, and I really appreciate it.

Donald Fischer: Thanks for having me on.

Adam Stacoviak: All right. Thanks for tuning in for this week’s episode of Founders Talk. Do me a favor, assuming you’ve got some value from this episode, share with friends, rate this show on iTunes, favorite it on Overcast – this is the best way you can help me and this show, and help others to discover it too.

Find all our shows at changelog.com/podcast.

Subscribe to the master feed changelog.com/master. Get every single show in one feed.

Thank you for tuning in – I’ll see you on the next one.

Episode 33: Cockroach Labs – Cloud-Native Distributed SQL Database with Peter Mattis

Peter Mattis is the Co-founder and CTO of Cockroach Labs, the company behind the popular cloud-native, distributed SQL database, CockroachDB. In this episode, Peter discusses their experiences transitioning to a new, less permissive open source license, and how open source startups are evolving business models to maintain competitiveness.



Michael Schwartz: Hello, and welcome to Open Source Underdogs. I’m your host, Mike Schwartz, and this is episode 33, with Peter Mattis, Co-Founder and CTO of Cockroach Labs.

Peter has some hilarious insights into the open source startup world. To me, this episode highlights how open source business models have evolved, how companies who witnessed the proverbial carnage of the last five years are adjusting their license and business models accordingly.

I’m about a month behind schedule right now, this podcast was recorded September 11th, 2019. Peter was in New York City, as you can identify by the frequent sirens in the background.

So, without further ado, here we go. Peter, thank you so much for joining the podcast today.

Peter Mattis: Glad to be here.

What Is CockroachDB?

Michael Schwartz: Quick technology question, and then we’ll revert to business. In the database space, companies are moving into adjacent markets. So, Redis starts to add persistence, MongoDB starts to add caching – in this kind of market, what’s the sustainable advantage for CockroachDB?

Peter Mattis: It’s an excellent question. What we see as our advantage right now, is we’re a blend. We didn’t move into adjacent markets, but we saw a gap in the market.

There’s NoSQL databases that have been out for a decade and getting a lot of traction because they provide this ease of use and easy horizontal scalability. But we also saw those databases as failing application developers, because they put a lot of burden on the shoulders of application developers due to their lack of transactions, lack of schemas, lack of indexes.

We saw this place in the middle, where we could have a horizontally scalable, distributed SQL database. A niche we’re occupying is to actually make this a geo-distributed database, so we can scale geographically and support global applications.

This is becoming an increasing need in the market, with regulations such as GDPR, but also with the advance of new technologies, people are just adopting faster speeds from the products they use. A user in Singapore wants to access their bank data, and make it feel instant, not make it feel like they’re jumping halfway across the world to get access to their data.

Cloud Strip-Mining

Michael Schwartz: Your new BSL license, or Business Source License, states that the one and only thing you cannot do is offer a commercial version of CockroachDB, as a service, without buying a license. What I’m wondering is, would this actually be a bad thing? Because Elastic and MongoDB haven’t exactly done badly since Amazon offered their software as a service, so, maybe would it even help you?
Peter Mattis: That’s a fantastic question. The thing is, this is, to some degree, a risk mitigation.

Elastic and MongoDB, I think if they had the choice, they would go back and put a license like this in place. Especially in the case for Elastic, they’re too far upon to go back, and they can’t retroactively apply that license to the source code like that.

That threat from the Amazon’s and Google’s is real. They sure wish they could have taken business maneuvers three years ago. We’re not facing this threat this year, we probably won’t face the threat from the major cloud providers next year. But it’s two years down the line, by the time we get there, the opportunities, the moves we can make are much more limited.

We had significant internal debates about this, and this is a way to just kind of de-risk some of those eventualities. I feel that BSL has come out of this nice balance. Three years down the road, our current release of CockroachDB will be active and fully open source. But then, we’ll have another three years of time to have further improved it.

We actually kind of see that combining our incentives with the incentives that users and open source users, purely closed source software maybe never has a time frame where it’s going to become open, even when it’s reached end-of-life for the company.

Our software will have that time frame. Every three years, on a rolling basis, it will become an open source. And this is our means of protecting against eventualities that could seriously harm or completely destroy companies viability.

BSL License

Michael Schwartz: Was Michael Howard and MariaDB influential in coming to that conclusion?

Peter Mattis: MariaDB certainly was. We were looking out at ways that we could protect against the stripmining that’s taking place of open source, where company like Amazon can come in and take what has been developed by another entity, and just extract all the value from it, by providing it as a service.

Don’t get me wrong, what Amazon is doing, from the amount of work and the services there, can oftentimes not be flowing back to the original developer or developers, or open source companies. This is a huge existential risk, and for open source developers, independent ones, this is just kind of like supreme irritation, “Hey, I developed this work to make this awesome, beautiful bit of open source, and someone else is actually getting all this value from it.” That kind of sucks.

We were looking around for ways to protect against that. We considered a number of alternatives, we considered closed sourcing more of the product, we never wanted to do that. We considered not doing anything, we just continued with business as usual and tried to fend off the Amazon’s or Google’s, and that also felt insufficient.

Like I said earlier, the BSL felt like a nice balance between the two, and gives us a pretty strong measure of protection, but it doesn’t completely close off the source.

Value Of Community

Michael Schwartz: So, it’s pretty hard to write a database?

Peter Mattis: Very hard.

Michael Schwartz: Is the community materially adding value to the product?

Peter Mattis: I would say yes and no. I mean, databases – it’s yes, in a sense we get a lot of feedback from the community about the things they need to the things they want to use.

There’s modest actual code contributions from the community, not huge code contributions. The database is a complex piece of software, and there’s no way around that. You need to have kind of main specific expertise, and even within Cockroach Labs, the company behind CockroachDB, there’s main specific expertise within various teams.

People working on the SQL optimizer have expertise about doing the SQL optimizations; versus people working on a web UI frontend, need specific knowledge about observability patterns; versus people working on a transactional layer that need to know about distributed transactions and protocols like Raft.

What we see is, it’s not a very approachable product for a random person to come online and make contributions. That said, we have had contributions, people who have been able to do stuff, both at the edges and kind of deep within the product. Over time, I expect to see that increase. Especially, as the company grows, we have more energies to support those efforts.

Remote Workforce?

Michael Schwartz: Is the business team and the developers of CockroachDB – is everyone centralized, or is it remote?

Peter Mattis: It’s not all remote, it’s not all centralized. We are primarily based in New York City – that’s the headquarters, that’s the executive team is primarily based. We do have a remote office in San Francisco, one in Toronto, we have developers in Seattle, and then, a couple more scattered in other places.

This hasn’t been purely intentional. It’s been opportunistic, as we got these people, as we found people who had expertise in various areas. And of course we have the sales people distributed to their various regions.


Michael Schwartz: So, with containers and auto-scaling, the old way of pricing database seems to be totally broken – did you find that you needed to reinvent a pricing model for your product?

Peter Mattis: We were actively undergoing discussions about the way people want to consume and pay for databases and services internally right now.

We have a pricing model for, if you get an enterprise license and you want to deploy CockroachDB on premise. And that’s kind of the more the standard, you pay for a number of cores, paying is based on what kind of CP you’re using.

This is kind of translated over into our Cockroach cloud offering, which is still currently in private beta. But we’re very much looking towards a day in the future, where there’s more of a pay-as-you-go, usage-based pricing.

That seems to be the easiest thing for consumers and application developers to use. It eliminates a lot of the headaches of capacity planning, but in order to go along with that kind of model “pay-as-you-go,” you need to have a database that scales elastically. And that’s what we’ve also been developing and putting a huge amount of energy into.

Comments Of RedHat Acquisition By IBM

Michael Schwartz: I think the industry is reeling a little bit after the acquisition of Red Hat by IBM. Do you have any thoughts on what that means for the commercial open source market?

Peter Mattis: Red Hat was the original open source software company. They have a unique success in their model. And their model embraced open source tightly, and provided services and support for open source.

And the common wisdom is that other companies trying to follow those footsteps have run into difficulties of having just a pure support in services model.

So what does the acquisition of Red Hat mean?

One, it’s kind of a sign of like, “Hey, this company existed and grew to a massive scale.” And it was seen as a very strategic move by IBM to buy them. They worry a little bit about what’s it’s going to mean for all the open source goodness that Red Hat was doing, but I think also open source has evolved past with Red Hat.

We see the big companies, the Facebook’s, and Google’s, and Amazon’s, also embracing open source, but also an ecosystem of startups were embracing it from the early days.

So, coming to my overall conclusion, I think the industry had already moved past Red Hat by the time that acquisition had happened.

Is Open Source A Bait And Switch?

Michael Schwartz: MongoDB recently commented that their open source strategy was primarily related to marketing. Is commercial open source just sort of bait and switch?

Peter Mattis: What do you mean by bait and switch?

Michael Schwartz: The benefit of the open source, they’re saying really was to get you to use the product so that you would buy something, so it’s really just a marketing channel?

Peter Mattis: I mean, if something is viewed as a go-to-market strategy, then what I think about open source is, people can just download and start using your product without going through some heavyweight handholding from a sales rep – I think there’s a huge liberty in that.

I very much prefer to use products, so I can just download and start kicking the tires rather than going through whatever that is – giving someone my email address, or getting on a phone call. I see that as kind of a marketing strategy.

There’s also a strategy, especially with something like a database, that there’s concerns. A database is a very score of what businesses do. They’re storing data in this thing, it is holding the crown jewels for companies.

For us, there is a bit of a concern of, like, how do you get a closed source database going again in this day and age, when as a startup people are wondering like, “Oh, will you be there in two years?”

With open source, at least, it is a reassurance that no matter what happens with Cockroach Labs, CockroachDB the database will still be there.

I don’t think it’s a complete bait and switch. I think there’s aspects of it that are self-serving, there’s aspects that are altruistic as well. I very much know that I originally got into open source due to those altruistic aspects, seeing all that open source code out there, being able to get inside, tinker, learn from it.

I thought that was great. I wanted to get back to it, and I still have those feelings. I also have to balance that out if you want to have a company that’s successful and looking at how open source can be part of that.

Move By Chef And Cloudera To 100% Open Source

Michael Schwartz: Recently Cloudera and Chef have moved to an all open source strategy. Do you think we’re going to see more of that trend?

Peter Mattis: I think we’re going to see a period of time of experimentation in different models.

There was kind of this feeling that there’s wisdom about, here’s how you build a product that’s open source, you have open core, we saw Enterprise licenses. Then all this moved to Cloud. And being able to monetize your open source as-a-service has kind of flipped things up in the air and started creating a period of time of innovation.

So I’m excited to see this innovation happening because we’ll see what shakes loose out of it. We’re not taking that path and making everything open source, other companies are. Some of them are going to be successful, maybe we’re successful, and history will be the judge of that.

Market Segmentation

Michael Schwartz: Let’s talk a little bit about Cockroach. How do you segment the market?

If you have a database, you can sell literally to anybody. Do you just wait for customers to try it and call you? Or, is there any way like, you’re looking at the market to break it down and sort of attack the market?

Peter Mattis: We don’t necessarily do the segmentation in the same way you might see at other companies, where they might just segment it purely on, like, “Oh, this is banking, this is healthcare.” We do have those segments, but we’re also looking at use cases, and we kind of segment on use cases.

Broadly speaking, in the database market, there’s two huge segments – if you’re looking at the first level of division – and that’s between the analytics databases and transactional databases.

We very much have placed ourselves in the transactional database market. That’s like the kind of the first level of segmentation. It’s part of our marketing message, we want to be the system of record for various workloads.

And storing, knocking the analytics workload, but actually storing the transactional process, and storing the user records, ledgers, the healthcare records.

The further segmentation that takes place is, where we are getting traction with regard to these use cases that people are comfortable moving on to CockroachDB now, versus the ones that they will be uncomfortable moving in the future.

Part of this is like, we break down the Fortune 2000 we look at, we break down those big enterprises, all of them have heavy database usage. But also be looking at the startups that are coming new into the space. And for startups, there is doing our marketing message and then training our sales engineers or account executives to identify the use cases that fit nicely with the current CockroachDB capabilities.

License Enforcement

Michael Schwartz: Of course, there’s no license enforcement in your product, so you can’t force companies to get to call you and get a license. Is the business really on the honor system? How do you get customers to actually get a subscription?

Peter Mattis: We do have Enterprise functionality in the product. And you have to have Enterprise license to do that. In order to get an Enterprise license, this is where you need to get the subscription, you have to talk to our sales people in order to do that. But because it’s open source, there’s no strong cryptography around this. There is a little bit of cryptography but it’s nothing strong, it’s nothing unbreakable, because it’s open source; people could violate that.

That way, it’s on the honor system. Is that viable? I think in the U.S. it is viable, and in most of the world, it is viable.

In China, it’s kind of a notable exception, where they’re very willing to not play to that spirit and just take this stuff for free. But even there, we have a little modest bit of traction with Baidu, out in China.

I think the interesting thing and the interesting advantage that CockroachDB and Cockroach Labs has, is that it’s running a database without actually having a support contract; it’s a very foolish maneuver for any company to make.

It’s almost like another fiduciary duty to have such contracts in place because, if any, like risk offers, those company was to look and say, “Oh, hey, what are the risks to this business?” “Oh, I’m running on this open source database, we actually have no relationship, no support contract with the company behind that database.” They would be raising their eyebrows until they jumped off the top of their head.

I think that way, we’re in kind of a very nice position where people who come in, they use this as open source, with testing and development, they kick the tires of the product. And when they actually start getting production, they’re like, “Whoa, wait. We definitely need to come talk to them,” and that’s when they engage with our salespeople.


Michael Schwartz: Of the products and services you offer, which is the most important from a revenue perspective today? And which product or service offering do you think has the most promise for the future?

Peter Mattis: Today, it is kind of on-prem Enterprise licensing, where we deliver CockroachDB as “shrink-wrapped software.” We don’t actually deliver shrink-wrapped per se, we give people binaries. This is essentially binary software that they run in their data centers. Sometimes, they run it on the public cloud. Right now, that is by far the majority of our revenue.

We saw the writing on the wall way back, a couple years ago that providing CockroachDB as a service was going to be our future. And we’ve been working towards that future. We’re starting to have revenue come in on that. And I very much expect that to be increasing.

It’s hard to predict a time when those revenue streams cross, but I see that the revenue from the cloud over the next year will be increasing dramatically.

Frankly, the revenue from our on-premise deployments is going to be increasing too. It’s hard to say which is going to have the steeper inflection curve yet.


Michael Schwartz: Has Kubernetes and containers threw a wrench in your world at all?

Peter Mattis: No, Kubernetes has actually been great for us.

Kubernetes provides easy running administration of stateless services, stateless applications, but most databases don’t fit into that role very nicely. CockroachDB fits in there very smoothly. CockroachDB runs on Kubernetes nicely.

We have a ton of our customers. It’s the single most popular way to deploy CockroachDB is on top of Kubernetes. Additionally, we’re using it as Kubernetes is the backbone for a Cockroach cloud service. And that’s how we run CockroachDB. So, not only throwing a wrench, Kubernetes is a bit of a wave we’re riding like right now.


Michael Schwartz: Cockroach Labs has had some pretty epic funding rounds. I’m wondering if you have any advice for entrepreneurs on how to survive this process?

Peter Mattis: My co-founder Spencer, he is fantastic, he has a kind of a superpower at talking to the VCs. And I think you need to have one of the founders of the company be in that role, where he’s interacting with our VCs, our current ones, as well as potential future ones frequently. It is a little bit like a never-ending process.

You finish one round, and other people are candidates for the next follow up round. And you’re always kind of thinking out to that future.

Cockroach Labs is in a fairly nice position, where the database market is huge and well understood. And it’s well understood that it’s not going to disappear. It might get disrupted in various ways, and we see some of those disruptions happening. Oracle is the elephant in the database market, and yet, to some degree, a lot of people can say of them it’s yesterday’s news.

AWS is kind of the growing elephant, and maybe it’s the gorilla in the room to work with elephant, it’s the thing that everybody’s paying attention to. They’re kind of changing the revenue breakdown in that space, but there’s just such a wide market area. There’s plenty of room for new entrants, and that’s one of the things that our investors saw, and they’re excited to buy.

They know there’s money, it’s not like we’re out there developing a new market from scratch. We’re breaking into an existing market with entrants, who are both very aggressive as well as entrants, which seem to have befallen by the wayside.


Michael Schwartz: The business is not super old. I’m wondering if you have started to work on developing partnerships, or collaborations, or maybe what companies have really helped you so far in the market?

Peter Mattis: We do direct sales to companies, we also have partnerships with various companies, with ObjectRocket, it’s a Rackspace company, partnership with IBM, and a number of others – I don’t have a list in front of me. But a handful of partners we are starting to work with, integrators as well, and those are certainly important ways for databases to get used and integrated into the system.

We’re also trying to work with companies that aren’t buying us directly but are building their own products, top of databases, and want to work with CockroachDB. We’ve seen this in the banking sector for instance, where there’s companies that are running new infrastructure for core banking services to the major players. They’re looking at CockroachDB is enabling them to provide additional functionality.

Meeting Sales Goals

Michael Schwartz: When you raise VC money, there must have been a renewed effort to sort of shore up the sales and marketing – has it been working?

Peter Mattis: The history of Cockroach Labs is, we spent kind of two years getting to our first 1.0 release of the product. We built something, we’re always painting a vision of, “Hey, this is what we’re going to build.” And people are like, “Oh, no, it’s going to be too hard to build.” You get that first proof point you built, you get the 1.0 version out there, and they are like, “Ah, okay.”

People are saying they’re going to use it, but are they actually going to use it? So, that third year was about, “Okay… yeah.” We had users who started kicking the tires and a few risk tolerant users getting it into production.

It’s at the end of the third year, when we actually started convincing people to give us money for it. Those were very early efforts at the sales side.

Then, of course, as of 2018, last year, we really started seeing an increase or ramp up in the revenue to the point where we’re like. “Okay, it’s time to actually put more fuel onto that fire.” And that’s where the next round came in. This was just recently, but we saw that it’s time to start putting more sales teams together.

So, in 2018, it was primarily one sales team. Actually, I don’t even know the number of sales teams right now, it actually might be up to seven or eight sales teams. And that’s usually an account executive, plus a sales engineer, who are starting to flesh out professional services offering as well. But you do this all with the signals that these things are needed.

Buying our professional services, because we just had sales engineers acting that rule, now it’s gotten to the point where it’s a full time role, and we were actually looking to increase headcount there. We want to add account executives, which are just kind of pure overhead, until you actually can see that, “Oh, yeah, we have a product that you built that people are willing to give you money for.” And it’ll actually work for the customers and production.

That’s where we were getting all that evidence in 2018, whereas the timing of the fundraise is, like, you’re trying to get from milestone to milestone in the lifetime of the company. The first funding was to build the product, the second bit of funding was to get to an initial revenue, and this latest funding is to be growing the revenue to a place where we can really start expanding the sales team aggressively.

I mentioned marketing as well, meaning there’s more effort going on the marketing side as well. When you grow in sales, you often grow in marketing, kind of in tandem. The sales people need food, and the people put the food in front of the salespeople are the marketing team. They’re generally the initial marketing qualified leads, which get handed over the sales, become sales qualified leads, and eventually some of those become customers.


Michael Schwartz: Do you consider the training for it, to be part of the marketing of the product, or just part of the product?

Peter Mattis: Training is an important part of marketing, it’s an important part of delivering like the full product. There’s a basic way in which training is marketing, which is people who get certified or do training on CockroachDB, they’ll tweet about it, they’ll tell their friends, “Hey, I did this thing, this database is really cool.”

In some ways, it’s just kind of purely direct marketing in that sense, but it’s also part of the product. People need to know how to use it. CockroachDB, we put a ton of effort in making it simple, and yet, it’s still a complicated product, and they want to know how to use it.

By giving them that education, they self-service themselves, and we have to put less money into support. We still put a lot of effort in support, just hopefully there’s less of it, because people are trained up on how to use CockroachDB properly.

Open Source Again?

Michael Schwartz: If you were to start another software company tomorrow, would you make it open source?

Peter Mattis: I would love to make it open source. Probably would.

I think if I was to start another one tomorrow, the big difference is, it’ll almost certainly be some kind of SaaS offering. Software-as-a-service from the get-go instead of running it on-prem.

We were coming out with CockroachDB in an inflection point, where, even when we were founded four and a half, five years ago, when we were having these conversations, we knew database-as-a-service was the future. And yet, we’ve also seen it wasn’t quite here yet.

So, we’re trying to bridge this chasm right now between the old way of writing databases and the new way of consuming them to be as-a-service. The market overall, and all the big Fortune 500 companies, they almost all have cloud strategies to get off their private data centers into the public cloud. These things will take a while to unfold, but there’s just this huge, and we have seen only the tip of the iceberg of how that’s going to unfold.

My feeling is now, you can sustain yourself as software-as-a-service now, and it has been true for a while in a number of different markets. But I think you can do it for a database as well. I’d do open source, I’d do it database as a service, or I’d do whatever software-as-a-service, if I was starting up a company tomorrow.

Biggest Challenges

Michael Schwartz: Last question. What do you think are the biggest challenges for new companies trying to use open source as part of their business model?

Peter Mattis: The challenge is, you might be overly optimistic in how much impact open sources has, like the benefit you are getting from the community. And there’s success or disaster that can happen there.

If you develop something open source, and it actually gets incredible community traction, then there’s actually a huge problem that comes with that, which is managing the development at that point.

It’s almost like the open source product can become owned by the community, and they can take it and nudge it in directions that aren’t necessarily in the strategic long-term vision of the company itself. I think kind of struggling that is an enormous challenge.

Any company has this. People come and say, like, “I want X, Y, Z feature.” And you’re like, “But that’s going to conflict with this other feature that has been asked for.” With open source the challenge is, they can just go and do it. They can fork it, they know it’s open source, they can do what they want with it. And trying to manage that can become a huge, huge challenge.


Michael Schwartz: Okay, Peter, thank you so much for joining us today and sharing all that great advice and insights.

Peter Mattis: My pleasure. It was great chatting with you, Mike.

Michael Schwartz: Thanks to the Cockroach Labs team for helping to organize and promote this podcast.

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

Music from Broke For Free and Chris Zabriskie.

Audio editing by Ines Cetenji. Production assistance and transcription by Natalie Lowe. Operational support from William Lowe.

Have comments? Tweet at us. Our Twitter handle is @fosspodcast.

iTunes listeners, send us your five stars – this can be your open source contribution for the day.

Next week, we have a change of format. If you don’t know The Changelog, it’s an epic open source podcast currently with more than 350 episodes, the hosts are Adam Stacoviak and Jerod Santo.

We’re going to republish an amazing episode of The Changelog, you’ll have to tune in next week to discover which one it will be. A big thanks to Jerod and Adam for sharing this interview ad-free. Don’t miss it next week!

Until then, thanks for listening.

Episode 32: Mirantis – Run Kubernetes On-Premises with Boris Renski

Boris Renski is the Co-founder and CMO of Mirantis, an open source platform for Kubernetes on-prem container orchestration. In this episode, Boris discusses how Mirantis has been able to effectively pivot multiple times as technology has evolved.



Michael Schwartz: Hello and welcome to Open Source Underdogs, the podcast about successful open source business models.

I’m your host, Mike Schwartz, and this is episode 32, with Boris Renski, Co-founder and CMO of Mirantis.

This episode highlights how sometimes you have to pivot when your market reality changes. In their case, a way for managing virtual machines and towards containers and Kubernetes. Without further ado, let’s Boris tell the story in his own words.

Boris, thank you so much for joining us today.

Boris Renski: My pleasure, thank you.

What Does Mirantis Do?

Michael Schwartz: The Mirantis website says “Take back control of your container infrastructure.” Keeping in mind that this is a podcast for business people – can you help explain what that means?

Boris Renski: Basically, as anybody living in the open source world today would attest to, there’s a lot of talk about doing hybrid cloud, using containers, and Kubernetes. And this is one of a kind of most common waves that is happening right now, at least when it comes to a cloud infrastructure.

And one of the things that typically happens in hybrid cloud is that you need to find a way to very cost efficiently run Kubernetes container-based infrastructure on premises.

And the problem with Kubernetes and containers in general is that this is a cloud-first, cloud-native of technology that was initially adopted by developers for building containerized apps and running them in the public cloud.

In the public cloud, a lot of the low-level infrastructure constructs are solved for you. So, you don’t need to ever wire up the servers together, you don’t really need to connect the storage and deploy your custom storage enterprise solutions, etc. – it’s all there. It’s all within an API call.

So, now, with containers becoming a mainstream fabric for building applications and running hybrid applications, the problem of cost-effectively running them on-premises is becoming increasingly more acute. And the most common solution to that is to run them on top of some sort of virtualization layer, like VMware for instance. Which makes things simpler, but it adds a layer of complexity, and it also adds cost.

So, what we ultimately do is we enable companies to run hybrid cloud infrastructure with the on-premise piece, the containerized on-premise piece running directly on bare metal, leveraging exclusively open standards, and we do it in a very cost-efficient fashion.


Michael Schwartz: Ok. So Mirantis is in a fast-evolving sector, to say the least, and you’ve had to pivot a few times along the way. Can you talk about those pivots, and why they were necessary, and how they worked out?

Boris Renski: We’re kind of an atypical startup, I would say, because most startups that you would see coming out of the Valley is a couple of smart guys that built up cool open source software that has become popular. They’ve gotten some VC funding and off they go. And hopefully, they’d built a company out of that or maybe exited it or maybe not.

Our story is a bit different than that. We’ve actually been around for a while, we’ve been around for over 10 years. And the story of Mirantis is that of a continuous evolution and continuous pivoting.

So I started, I think it was a 2002-time frame, shortly after I moved here from Moscow. I started doing something that I would argue every other Russian of IT background tends to do, and that is sell Russian engineering talents to Silicon Valley-based companies.

I guess not so much through my personal talents but through some degree of luck and the fact that I was able to find a very talented group of engineers, I was able to scale that company to about 50 people. And in 2006, merge it with another company that was doing pretty much the same thing – and this is how Mirantis was formed back in 2006.

It was myself, my partner at the time, Alex Friedland, and this company of about 100 people altogether, that was just kind of a generic software outsourcing.

Shortly after the merger, I would argue this was the first pivot to your question, because it was clear that just doing generic selling of engineering talent that the scale of a hundred people is not something that you can build a huge company out of. It was clear that we needed to specialize.

And we had at the time already a bunch of customers that we were doing some infrastructure stuff for. For example, Cisco was a customer for whom we were doing some hardcore networking stuff at the time. And this was 2006, time of cloud and kind of this infrastructure cloud revolution.

So, we started moving in the direction of just cloud infrastructure, and we started playing with everything that’s hot out there – big data, all the different open source cloud technologies. But in general, we moved from being completely generic to be more specialized, but we stayed, as far as our value proposition, focused on just services.

And then, we, I think, spend probably 4 years or so in this configuration, slowly growing the business. And then, when the cloud became mainstream, again, we were doing a whole bunch of stuff, so we figured we need to kind of specialize further. And we need to just take one area, we can just be doing cloud and big data and everything that one can find.

So, we decided to focus on cloud and specifically on the technology that was kind of up and coming and cool at the time, called OpenStack, which I’m sure you’ve heard of. And at the same time, still stick to the kind of value proposition around services – no products, just selling services. So, this was I guess the second pivot.

The first pivot was from kind of a generic software to cloud infrastructure. Second pivot from kind of generic cloud infrastructure systems integration, to focusing on a specific layer, kind of OpenStack and OpenStack adjacent open source projects.

I think it was probably a year or two years in that mode that we ramped, that we were actually able to ramp quite a bit. I would say that the reason for that ramp is because unlike anybody else in the space, who was trying to immediately build a leverage business model around OpenStack at a time, we were just selling people.

We were just selling services, and we were the only guys that were in town doing OpenStack services and doing it in a very competent fashion. And, of course, most of the large companies adopting new open source technology, they tend to shy away from start up some products in the early days until the winner emerges.

So, they came to us to actually build some bespoke solution, using either OpenStack or some OpenStack adjacent technology, like, for example SAF or OpenContrail, because there’s a lot of open source projects you need to stitch together whenever you build infrastructure.

There was another next wave of growth, so to speak, that took us to the next level. The third pivot was actually trying to introduce elements of a leveraged business model. So, this happened already I think in maybe 2012/2013-time frame, when we were already pretty popular open source infrastructure and OpenStack specifically at a time.

And what we did is, we basically started trying to look for patterns of commonalities between all of the different projects that we would implement. A lot of them were very different, but some of them had a lot in common.

We’ve basically built this kind of a library that gathered a list of the different configurations, the common configurations for deploying on-premise cloud infrastructure. In plain words, it was just a bunch of puppet libraries at the same time, like puppet scripts.

We started collecting it internally at first for just being able to deliver services more effectively to our customers, and then, I think 2014-time frame, we actually open sourced it and made it publicly available.

We said, okay, we now have this set of a puppet script effectively for deploying OpenStack, and OpenStack adjacent projects that everybody can use, and if you’re within those configurations, if you’re deploying using the scripts, these specific configurations will be able to actually go ahead and provide some sort of SLA support for you. That was a third pivot. From just pure-focused OpenStack services to monetizing support SLA around it.

The fourth pivot was kind of both from the process and I will say technology-focused standpoint. So, between I think 2013/2014-time frame, where we emerged as this OpenStack implementation and support vendor, up until I would say 2017/18-time frame, we’ve been focusing on first of all evolving this leveraged business model.

So, basically, moving our support from just providing kind of like initial response and ongoing SLA, to more of, like, an uptime SLA. So, moving up the value stack and adjusting our business processes accordingly. We are therefore being able to extract more margin from the customers we already have.

And the second vector of evolution was around the technology itself because obviously the world has kind of moved on to containers and Kubernetes. VMs, on-prem VM orchestration has become more of a commodity.

We started building more and more competence around that, and moving our product from being exclusively focused on just VM orchestration on-prem to basically a container orchestration on-prem and hybrid cloud using containers and Kubernetes.

I would say that, probably, we are 80% of the way through our fourth big evolution at this point, and looking forward to the fifth one. That’s kind of been the long and winding journey for us, evolving the business model.

Most Important Projects

Michael Schwartz: So, there are 200+ repositories in the Mirantis GitHub. Are there any themes in the software, and which are the most important software projects for your business model?

Boris Renski: It’s a good question. I think out of 200, only a fraction of them is active and alive, because 200 – this is like from when we started. And then, the repos, we tend to commit more to, and then do kind of spikes, and then it goes into the maintenance mode or just goes away.

I wouldn’t say there’s just like one repo that’s the most important one, but there’s a collection of repos. But all of them are around a theme of lifecycle management of the software. So, we have this component tool product Mirantis cloud platform, called DriveTrain.

Back in the day it was extremely unique, but now it’s more kind of more mainstream. It’s a system for managing the lifecycle of a distributed system, using continuous delivery approach.
What that means is that for the private cloud, or the hybrid cloud that we have deployed for the customer, every single service, every single component, we treat as an atomic element.

And we separate the binaries and configuration, and we codify workflow for updating each one of these components, using a continuous delivery pipeline. And DriveTrain is a system that makes basically all this magic happen.

The core problem that this ultimately solves is basically keeping the main components of a distributed system up-to-date for the customer in a very seamless and non-disruptive fashion. Because in our view, the biggest disruption that cloud brings to the table, is the fact that you don’t really need to care about the lifecycle of the infrastructure software anymore.

So, if you get it from AWS, it’s just there, and they release new versions seamlessly, and new services, and then you can just start using them – you don’t need to go for the upgrade cycle.

The whole big problem that we were focused on solving back from the OpenStack days is how do we do that same thing, only not for the public cloud environment but for the hybrid cloud, and specifically for the on-premise piece of it.

And all of that, relay it, aggregate it under this project called DriveTrain, which consists of probably several dozens repos. And this is where we probably do most of our R&D and hard work. So, hopefully that answers it.


Michael Schwartz: Are Mirantis’ engineers the majority of contributors to these projects?

Boris Renski: The short answer is yes, but I want to qualify that a little bit. So, when we build a hybrid cloud environment for the customer, typically, there are kind of common upstream components like Kubernetes, like Ironic for bare metal management, like OpenContrail, or Calico for networking, Ceph for storage, etc.

Those are really what I would call pure open source projects with large community around them, where Mirantis is just one of the contributors, and we package them, and we deliver them.

And then, there is a number of components like, for instance, DriveTrain that glue these things together. And when it comes to the glue part, it’s mostly Mirantis contributors with some of outside community consisting of our customers or maybe just users outside of Mirantis.

Material Contribution From Open Source

Michael Schwartz: Do you think that open source software development has materially contributed to the business model?

Boris Renski: The whole company, the entire business model revolves around delivering open source infrastructure software to customers in cost-efficient, and simple to consume fashion.

So, the answer is absolutely yes. Our entire business model is predicated on being part of the open source community and taking the software that we helped build in the open to all customers.

Michael Schwartz: It sounds like some of those components, if you change the license on them, would customers really care? And if they’re mostly Mirantis’ engineers working on them… So I guess I’m wondering, yes, sure, you are deploying a whole stack of open source, and that’s mutually valuable. But I’m wondering about for the software development activity at Mirantis – do you think it being open source really makes a difference?

Boris Renski: It’s a good question. I think the answer to that question is still yes to a large extent. It has to do with the fact that one of the big advantages that we bring to the table, and one of the big things that we do that a lot of the competitors don’t do, is that we allow our customers to take complete control over the infrastructure that we deliver for them as an option, through what we refer to as a build-operate-transfer model.

And because our customers are large telcos and large Enterprise, being able to have that option and being able to actually operate the infrastructure that we’ve delivered for them independently, at some point in time down the road, is very important.

And having an Apache 2 permissive software license is instrumental for that happening. Because if we have some sort of license that requires them to pay fees or limits them from doing whatever they want to do with the software weakens the value proposition behind the build-operate-transfer model.

Build Operate Transfer

Michael Schwartz: Part of this process is used in complex systems, like Toshiba built the subway system for some country, they operated for a period of time and then they handed it over. But I’ve never actually heard this used in IT, build-operate-transfer. I’m wondering, has this approach been successful, and what did you learn along the way when you delivered that?

Boris Renski: Yes. It definitely has been working for us.

One thing that we have learned is that I guess the promise of the transfer is probably more important than actually doing the transfer. I would say that less than 20% of the customers that we do actually go through with the transfer. Most of them just prefer to a kind of have that as an option in the contract, should the situation change.

It is common in the pockets of the IT industry. And the reason actually, again, why we are able to do it, and why we’ve been offering it is because one of the pockets of the IT industry works common as exactly like IT staff outsourcing.

So, back in the day, during this pre-first pivot story of Mirantis that I told you, what we do, I just mentioned, would sell talented engineers to the Silicon Valley companies. But the way we do it is, we proposed the same exact build-operate-transfer model in that we would staff an R&D center that is offshore for the customer.

We would basically implement customer’s business process and culture in the offshore center. We would run it for them, and then we’d give them an option to actually buy it out and take over. And what they’ll have is their own offshore center.

And that’s extremely common in that segment. And when it comes to building hybrid cloud infrastructure, it’s kind of not that different, because it is a bit of a complicated thing. A lot of it is about actually implementing the process and not just the software.

So, you need to have the people that know their organization, that know the change management process for updating the software, that know the existing systems that the customer has. So, it’s not just like, “Here is a piece of software – go use it.”

It’s a big kind of a cultural transformation in a lot of cases. We have the roots of doing that back in the IT staffing industry, and we’re basically been able to transfer some of that to actually the notion of building hybrid clouds and implementing all the necessary kind of a cultural process associated with that.

Transfer People

Michael Schwartz: When you transfer the, let’s say, the operation to the customer, do you still offer to transfer some of the resources?

Boris Renski: Some yes, but it’s a little bit different from the previous example, where I’ve told you it’s just primarily the people that your transfer. Here, it’s a little bit more software and process biased, so typically you made a transfer of a few people, but most of the time it’s the people that the customer already has.

It’s kind of like, when we start this process typically, we would require that a customer would dedicate a number of people that would be effectively integrated into our Ops team, and will help run that hybrid environment that we are to leave behind.

So, in a way, you could say that with transfer people, it is just that they were all on the customer’s payroll day one. For a period of about six months, they are effectively operating as an integrated part of our team. But then they get transferred back onto the customer’s operational management.

Transfer People

Michael Schwartz: For customers who have transferred off, do they continue to renew their software subscription? And I’m wondering about how your renewal rate is for those customers?

Boris Renski: It’s a good question. The renewal rate is pretty good. We look at the software subscription as kind of like a spectrum. If you look at our subscription business, we have three offerings within the portfolio: OpsCare, ProdCare and LabCare we call them.

The OpsCare is typically the tier that the customers start with before they have transferred annual operations in-house. And at that level, we give the customer an uptime SLA on the environment. And it’s our team in collaboration with the customer’s team that is following a process that is actually delivering on that SLA.

And then, the one down from that, ProdCare is more kind of resembling of a typical software subscription that you get from somebody like Red Hat or Canonical, where we’re basically giving SLA on the initial and ongoing response time, and provide customer to the continued access to like bug fixes, patches and things like that.

LabCare is the lowest level, where basically it’s kind of like 8 by 5, you just get barely any access to the support line but you still get access to the software updates. If there’s any severity, one issue that you encounter, we are responsible for producing a patch within a certain given time and giving of the update.

Most of the customers that we see go for the build-operate-transfer cycle, they would start on OpsCare, and then, they would downgrade to ProdCare, and then eventually LabCare.

But, I think it’s only been a couple of instances where they went ahead and just completely disconnected, and did not even do LabCare at all. I would argue that probably both of instances where they just decided to discontinue the cloud, or they just did the different direction, or something like this.

So, most of the time, they downgrade a subscription, but they don’t move away from subscription all together.


Michael Schwartz: Obviously you have been used to building some of the team offshore – I’m wondering about what’s current strategy for building the team? Do you have a sort of central headquarters, and do you look to hire regionally? Is it very global, like, how do you meet the new demand?

Boris Renski: This is, again, one of the things that it’s kind of like it’s been hidden strength of the company, given our history that I’ve described, back in the day, core value proposition being building these distributive teams.

The area that we focused on kind of a building up is continuously changing, depending on the opportunity and market conditions. One of the big value propositions is cost-efficiency. We are able to deliver that cost-efficiency in part through having access to the global talent pool.

We have a tad over 500 people in the company, and most people are distributed across about 7 locations. Our HQ is in Bay Area in the Silicon Valley, but we have an office in Austin, where we do a lot of support.

We have an office in Poland, we have an office in China, we have an office in Ukraine, we have an office in Germany – basically all over the place.

The way we figure out where our staff is kind of continuously revalued. I’ll just give you an example. For instance, one of our competitors back in the day was Rackspace. And Rackspace is known to have a lot of good support people because their core value prop was fanatical support.

They’ve gone for some private equity acquisitions and restructurings and things like that, and they reprioritized some of the business directions, which, making a long story short, made it possible for us to go ahead and hire a lot of the people that were kind of like a fallout of this reorganization in Austin, Texas area, because this is where a lot of their support people were. We did this kind of a blitz campaign, and we built up a bunch of people in Austin to do the operations and support.

With these kind of opportunities, they continuously come around, and we tried to kind of recalibrate, and we tried to put emphasis on hiring in one area versus the other, depending on the situation.

Biggest Challenge For Company

Michael Schwartz: What do you think are the biggest challenges for open source software startups today?

Boris Renski: I can only competently speak to the challenges in the infrastructure space, which is where we’re focused on. And I think that the biggest challenge is figuring out the monetization strategy.

By that I mean, because the software is free, open source in the infrastructure space can be one of two things. It can be either a way to decrease your spent on R&D and leverage in ecosystem, that you can basically deliver particular platform more cost-effectively than proprietary alternatives because other people are building that software that you’re going to be reselling.

Or, even more commonly, it’s kind of like a marketing vehicle that will pull through some other value propositions. So, back in the OpenStack days, OpenStack was super hot – everybody wanted it. So, it was your way to get into an account and see if you can spread your wings there.

Now, it’s more like Kubernetes and solderless and things like that. So, you can grab onto Knative, or Kubernetes, or some of ours hot projects, and pick the interests of the Enterprise and then get in there. It’s a way to decrease your marketing and sales costs.

The software itself is free. You can use it to do one of those two things, but you can’t really make money on the software itself. There has to be something else that you’re selling. And that something else can be a datacenter space or hardware, which is what basically public cloud providers do.

People say that AWS is the most successful open source company out there because they built a 25-billion-dollar business by taking open source components and layering them as a way to sell commodity, datacenter, and hardware at the high margin.

In the case of Red Hat for instance, they sell support SLA, which is a more common approach, but that kind of boils down to selling people to a large extent.

There’s other more where you can sell, hardware appliances. Like a good example of that I think is Nutanix, where they’ve used a lot of the open source components to build their solution, but ultimately they are kind of pushing appliances as their main thing when they’re starting out.

Figuring out what that thing is, and understanding why you’re better at actually being able to deliver on that other thing than others, use core. For us at Mirantis, we were able to get some degree of success because we were always very good at selling people.

And when we layered things like OpenStack and Kubernetes on top of that, that made up easier for us and more cost-effective to sell these people because we were kind of like getting pulled through by what’s project being hot. And we were able to monetize this people thing. For public cloud, it’s hardware and datacenter.

So, the question is, what is it going to be for you that you’re going to be selling, because, for sure, it’s not going to be the software itself.

Advice For Entrepreneurs

Michael Schwartz: Any advice for the people, the entrepreneurs, who are starting these companies? Because you’ve had a couple of entrepreneurial experiences, so, just wondering if you have any closing advice for those poor souls?

Boris Renski: If you are starting a new company in the open source infrastructure space, I think you have to make a decision early on as to what your play is. And there’s generally two types of plays.

You can either focus on something important, industry-focused or vertically-focused value proposition, and build up a long-lasting business around it. And you can make that decision like Day 1, in which case, you should not tie yourself to any particular open source project or wave, but just focus on open source as a potential way of decreasing your expenditures on R&D and just stick to that strategy.

Or, alternatively, you can say that it’s going to be a two or three-year play, and I’m going to ride a wave, I’m going to ride like a Kubernetes wave, like what Heptio did.

The latter is actually, I would say, the play of the 80% of the VC-backed startups today. And I think that you need to be very conscious of what your play is and stick to it. What you don’t want to do is kind of try and mix between the two.

I would argue that we at Mirantis, for a period of time, were a little bit confused about “Are we like an OpenStack company, or are we an on-premise infrastructure company?” I think being very crisp on what you are out to accomplish, Day 1 and sticking to it, is key.

It’s easier to say, but it’s very hard to do when you’re actually trying to do it.

Michael Schwartz: Awesome! Lots of really, really good content and thoughts there. Boris, thank you so much for spending time with us today.

Boris Renski: Of course, my pleasure. Thank you, Mike.


Michael Schwartz: Thanks to the Mirantis team for helping to organize the interview.

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

Music from Broke from Free and Chris Zabriskie.

Audio editing by Ines Cetenji.

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

If you have feedback or comments, tweet at us. Our Twitter handle is @fosspodcast.

If you’re a fan of the show, and you listen on iTunes, please leave us five stars in a comment. That helps us get the words out to others.

Next week, we interview Peter Mattis, one of the founders of CockroachDB.

Until then, thanks for listening.

Episode 31: Percona – Open Source Database Solutions with Peter Zaitsev

Peter Zaitsev is the Co-founder and CEO of Percona, an open source database software and solutions provider. In this episode, Peter discusses how Percona has successfully built a multi-million dollar business around services and support without VC funding.

Here’s a link to Peter’s 2016 article How Percona Has Built a Successful Open Source Business Based on Support and Services Revenues if you’d like to learn more.



Michael Schwartz: Hello and welcome to Open Source Underdogs, the podcast about successful open source business models.

I’m your host, Mike Schwartz, and this is episode 31 with Peter Zaitsev, Founder and CEO of Percona.

Peter was one of the early MySQL team members. He’s also renowned for co-authoring the canonical O’Reilly book, High Performance MySQL.

This episode is a fascinating story about how you can build a fantastic business by curating some complex open source components while, at the same time, founding the availability of more open source features for the community.

Here we go. Peter, thank you for joining us today.

Peter Zaitsev: Thank you.


Michael Schwartz: Percona has a very different business model than many that we’ve interviewed – can you shed some light on the origin in the mission of Percona?

Peter Zaitsev: Sure. A while back, now it looks like in a different galaxy far, far away, I was an early employee of MySQL AB. That’s before Sun, before Oracle, long time ago.

And I really joined the company because we were on this very romantic mission to revolutionize the database, open source database, yet, as time went, I think MySQL AB pivoted from the company which would be really putting the customers first to this, I would say Venture Capital potential IPO track, where you can say, “Hey, you know what, we need to really hit the growth numbers at all cost.”

In this case, I think our romantic ideas and ethics in some cases would suffer. Or, at least, I saw it.

I decided to leave MySQL at the time and start Percona. The idea was we wanted to be a very much customer-focused company, put customers first, to do consultancy, which was our first focus, really doing what’s right for a customer, not having any other baggage or commitments that we would have.

That is pretty much how Percona got started.


Michael Schwartz: Percona has a number of open source projects. Could you just give a quick overview of some of the more successful ones?

Peter Zaitsev: Sure. First let me mention how our first open source project really originated. Really we went into this business as a professional services consultancy business, we didn’t really think about building our products.

But what we found is to help customers to solve their problems, in many cases, consulting is not enough. You really need the code, software products in many cases.

For example, we found there was no good open source backup solution for MySQL, and that is how we created Percona XtraBackup.

Also, this was the time when Oracle would own InnoDB, and MySQL would own the rest of MySQL, and all that MySQL engineering was very dysfunctional at the time. And that is how XtraDB and later Percona server was born.

So, it was very much, I would say, born out of a customer need, first and foremost.

If you look at, right now, we have a software, such as Percona server for MySQL, which is very popular MySQL, which offers a lot of additional enterprise features. In open source package, we also have Percona server for MongoDB with similar proposition. We have Percona Monitoring and Management purpose-built open source, monitoring platform for databases.

We also have Percona Xtra DB Cluster, which is our clustering solution for MySQL, which is really adopted by a lot of large enterprises with very high availability requirements, sometimes as a replacement for Oracle RAC.


Michael Schwartz: And who are the customers of Percona today?

Peter Zaitsev: If you think about open source database, we have a very broad applicability.

Customers come to us from all the countries, industries, in all shapes and sizes. From our focus, I think we are most successful with the customers which are running database at scale, or for business-critical applications. Because that is when they really want to invest money into having their database to run well and perform well.

We have many Enterprise companies though we have a fair amount of smaller companies and startups as well.

We serve a substantial number of companies in the finance industry, in healthcare, in retail, so all of those are obviously the companies which work with a lot of business-critical sensitive data.

Sales and Marketing

Michael Schwartz: Do you have any outbound marketing campaigns or do companies just find Percona through the open source and through the tools and contact you inbound?

Peter Zaitsev: Well, it is both. We do have our sales team, which is both supported by our marketing team and inbound leads, as well as is looking for the companies who would potentially benefit from Percona, and contact with them.

What we found is, a lot of especially larger companies, they are kind of lazy in this regard, where we say, “Hey, you know what, if you are somebody who matters, you will contact me.”, more than actually doing a lot of research to find the company they want to engage with, as with some of the smaller startups. So, we use a combination of that.

I think one of the things that we have been doing from very early days is we really focus on the thought leadership and educating our customers and community at large.

For example, our blog has about 300,000 attendees every month which is, of course, not Facebook, but if you think about a professional database industry, that is quite significant.

We do more of Percona conference talks. Every year worldwide, we run our own two conferences, so really rely on thought leadership right to get Percona message out.

Value Prop

Michael Schwartz: How has the value proposition for Percona evolved over time?

Peter Zaitsev: If you look at where we started, we started with especially consultant-focused on the high performance applications for MySQL and MySQL alone.

And this gradually extended both in terms of the services, the offer. So, right now, we have a support management services, and professional services such as consulting and training, and in terms of the technologies they cover; right now, we also cover MySQL, PostgreSQL, MongoDB and MariaDB.

Really the value proposition changes from essentially, “Hey, you know what, we can optimize your MySQL performance” to “What Percona helps you to run MySQL PostgreSQL, MongoDB best?”

Now, I think what is important for our customers is what we provide the fully open source solution, open source platform, if you like. It should help you to avoid vendor lock-in, and really save costs invent.

What our customers recognize after they have been customers for some time is the quality of our support and other help they are trying to get from Percona. But that is obviously something every vendor would say that, that doesn’t drive their buying decision, but that is a value they recognize later.

Support Other Products

Michael Schwartz: One of our previous guests said that if you’re going to sell support, it’s almost better if you don’t write the software because if you write the software, then those people who are writing it are not billable.”, and it is actually better to just support somebody else’s software – do you think that’s true? Is it better not to write the software?

Peter Zaitsev: Well, I don’t quite agree with that, because if you think about support, it can mean a couple of different things.

You can provide the operational support, and this would be something like your help desk. “Oh, you know what, I am having a problem with my Windows or Mac, I don’t know how to do that. And I go to somebody, and he gives me that support to use it for.” This is one kind of support.

Now, in this case, you are also relying on somebody to provide you bug fixes, the security fixes and so on, which is absolutely critical in the enterprise. And either you are going to provide it or some other vendors will. In this case, you obviously wouldn’t have provided a complete solution.

And I think what makes Percona unique is that we do both. So, when we support MySQL, we actually have engineering team on staff, so, when our customer is, let’s say experiencing some crashes or some other software-related bugs, we have people on staff who can actually fix those issues and deliver bug fixes right.

If you have no experience in writing software, then, of course, you cannot do that. The same happens with security issues. Of course, you need to have some software engineering to provide that. But that doesn’t mean you need to write all software.

For example, if you think about the Red Hat, and especially in the early days of the Red Hat, they would not write entirely of Linux Kernel, but they would have enough engineering experience to support their customers on the code basics when they have to.

And you can think about Percona, of course, we are much smaller one, as the Red Hat of open source databases.

Support Business Model

Michael Schwartz: I was reading an article you wrote in 2016, titled, “How Percona Has Built a Successful open source Business Based on Support and Services Revenues”.

In the last 28 podcasts I’ve recorded, the sentiment has been almost unanimous that it’s hard to scale this approach. In an early episode with MariaDB, Michael Howard was very dismissive of the support business model.

I’m wondering, how did you manage to scale this business, and how do you get enterprise customers to renew?

Peter Zaitsev: Okay. Well, I think that is a very good question. And I think this is very interesting in the open source community, what has been happening right now is, currently a lot of so-called open source communities, they don’t really have an open source business model.

They have an open source marketing model. They market something that is open source, but they sell you something which is actually commercial.

Think about MySQL, which markets itself as the most popular open source database. But if you come to Oracle, they’ll sell you MySQL Enterprise, which is of course proprietary.

The same happens to many other companies, and the reality of that is this, if you go ahead and erase their Venture Capital, then typically the growth curve and the revenue expectations you will have to provide will be much higher than the natural, organic open source community growth support.

You will have to turbocharge that by pretty much introducing the open core, source available or similar model, to force your customers to pay it – but that is not open source.

In our case, we are not venture-funded company. We have been bootstrapped, and in this case, we have been saying, “Hey, they’re going to accept the revenue growth, which the market is going to tolerate while they’re sticking to our values.” Of putting the customers first, they can take care of our stuff, and sticking to the open source.

Is that giving us larger growth – I don’t know, somebody likes it like MongoDB or Elastic. No, but we have been able to build a successful business for that. That is, I think, a very core difference.

Now, something else I would want to add here, which we recognize as very important: If you are really looking for an Enterprise, we’re not looking to do it alone, we’re not going to go with this kind of insurance. We are not trained to say, “Oh, we’re going to grab open source software and self-support it in-house.”

The Enterprise companies, in the end, if they are going to be adopting open source software, they are going to buy support services from somebody. If you provide a good value, that somebody is going to be you.

Give Open Core a Break

Michael Schwartz: Sounds like you haven’t really changed your opinion about open core. But given that, how hard it is to start open source businesses, or let’s say businesses that lead the development of an open source project? Do you cut them a little bit more slack today, or do you still think that you should either be open core or open source?

Peter Zaitsev: Oh, no, no. I mean, let’s be clear. In this case, my approach or my thinking is, open core has the right to exist. And that is a very reasonable business model to pursue. That is not a business model we have chosen.

We at Percona have been able to choose that business model. We are doing the fully open source at large extent because those larger vendors exist.

For example, they are not tricking anybody, so we could be able to do all their engineering for example which goes into Percona server just by ourselves. We are relying in this case on the Oracle pushing for the open source edition, and then, they’re doing that better.

I would say, if you’re doing the green hill development, trying to build up a completely new database from scratch, it can be very hard to succeed in the current market without some sort of an investment.

That is my take, but my point of thinking here is this: Businesses should come in all shapes and sizes, there is room for proprietary software, for open core, and so on and so forth. But if you look at the customers, everything being equal, the open source, the true open source gives you the best value, and we happen to be able to do a business by providing the best value to you.


Michael Schwartz: I think it’s kind of ironic that you’re saying that open source is the best value, but I noticed, in that same article that you mentioned that you think margins should be lower for open source software.

And if it’s the best value, shouldn’t the opposite be true, that you get better margins for giving customers more freedom?

Peter Zaitsev:Well, what I am speaking about here is a value for customers in this case. And I would say the value from customers, that desk responds to somewhat lower margins to you, if you will. Especially on the per-unit basis.

If you look for example some retail evolution, ranging from somebody like Costco or even Amazon, they are able to lower prices in many cases because their margins are lower but their costs are lower as well.

If you think about how much Costco marks their stuff compared to somebody like Nordstrom, then, that’s going to be night and day. And yes, we are much closer to Costco in this regard, and we are proud of it.


Michael Schwartz: That analysis assumes that you’re getting volume. If you use open source as part of your business model, must you then get volume?

Peter Zaitsev: I think in this case, of course in terms of my analogy, to think it is not super correct in this case is what stores like Costco sell relating to inexpensive products.
In the Enterprise space, you often have a dollar volume, which does not have to have the same customer volume. For example, I have looked, now probably like a year or so, as a fan of a pivotal event, and they listed just about 300 customers. But they would have more than a million dollars of average revenue per customer. They have a very high-end Enterprise focus.

So, I think you can get the volume driven this way. And what also happens in the open source case, and I think what is important here is, really in a successful open source project, you are able to save on the marketing costs because your community is going to be doing some marketing for you, to much more sense than property companies typically can enjoy.


Michael Schwartz: You have a lot of experience in licensing, I’m sure. Have your thoughts on licensing about let’s say within open source licenses?

Peter Zaitsev: Oh, yes. I think it is a very interesting time for open source licenses.

I think classically if you look at that, there have been two camps in open source software licensing – and again I am speaking about the open source only in this case – there have been one camp which would be the permissive licenses.

Think about Apache, BSD, MIT saying, “Hey, take our software, do whatever you want, if you want to integrate or modify it and ship it as a commercial version – it is fine.”

And then, there’s been this GPL license, which is led by ideas of Richard Stallman saying, “Hey you know what, to really promote open source software, we need to force companies which are modifying that software to open source that.”

And I think in the ‘90s, early 2000s, it looked like the GPL approach was winning. There is of course Linux, MySQL, and so on and so forth, but more recently, things have been changing with what we have interesting polarization going on.

Because from one standpoint, we see where technology features are more open, getting more traction, for example, PostegreSQL has the larger momentum than MySQL in those days, in part because of the underlying license.

From our side, we are seeing also people polarizing and evolving towards not completely open source business models. You can see business source license, which MariaDB uses, you can see the shared source licenses, which companies like MongoDB, Elastic, or Redis, has been adopting recently.

We can say this really polarization of the open source, some of the ideas are driven by “Hey, you know what, we want our adoption of software to be as widely used as possible, and kind of really focused on adoption.”

There is another thing in the open source, which is focused on protection and monetization, saying, “Oh, you know what, we kind of want to give something like open source, but we want to make sure cloud providers can just take our stuff and run with them.”

I think there is a space above, and I think it’s very interesting to see what this competition of ideas and business model is happening right now. And it’s very interesting where it is going to take us.


Michael Schwartz: Do you think that by introducing these more restrictive licenses that the companies are trying to gather a larger percentage of the monetization of the ecosystem? And they are basically making a call that they’d rather have more of the pie than, let’s say, have a slice of a bigger pie?

Peter Zaitsev:That’s right, that’s right. I think it’s interesting to use this analogy. That’s exactly something I use in one of the keynotes I gave recently. From a pie analogy, companies are focused on a bigger pie or getting a bigger slice.

And that is exactly that. And some companies and communities are exactly focused on the growth, on the project first and foremost. And in this case, we typically choose as permissive licenses as feasible, and of course if you want to have a control and really ensure what only you can monetize in your environment, then, that is a different choice.

For example, I would say, if you think about PostgreSQL community, that is extremely fragmented. And there is no large player that has a very large portion of that market.

And, generally, that community is very much focused on adoption. For example, if they say, “Amazon now has a PostgreSQL or a PostgreSQL Aurora.” That is fantastic, that means more Postgres, that means Postgres is more accessible for some developers which wouldn’t use it otherwise. They were excited about that.

Now, if you look at the opposite side of the spectrum, we have MongoDB. MongoDB is obsessed about having all the MongoDB revenue there is. And they’re doing good at this point in time.

You can see there is only one MongoDB Atlas. In this case, we’re not being kind of undermined by Amazon’s or Google’s Office old drive. But that also is just about now. We can see with those changes to not open source approach, for example it has even been dropped from some Linux distributions, or some projects that are moving away from using MongoDB because of that open source changes.

And we also see some alternatives popping up. Amazon says, “Hey guys, you don’t allow us to run MongoDB on Amazon? – That’s fine, we’ll create protocol compatible alternative, Amazon’s DocumentDB.”

I think if we look at 5 years from now, we’ll see what that strategy, to be kind of very greedy and selfish, has backfired from MongoDB.

Next 20 Years

Michael Schwartz: Switching gears a little bit, where do you see Percona in 20 years?

Peter Zaitsev: As a code someone writes, it’s hard to make predictions, especially about the future in this case.

The honest answer would be, I think how technology is evolving, it is really hard to tell.

What we are focusing on, if you look at the next 3-5 years, is we are continuing to build and improve our open source platform to run open source databases successfully. And we are investing a lot in Cloud offerings, especially in Cloud Native, which I think is fantastic open source response to that seductive convenience, which database-as-a-service offers.

And also, a lot of focus on really automation. I could call it Artificial Intelligence for databases, but really only some of the algorithms, which underpin automation, are artificial intelligence-based. So, that is going to be a good direction where we are going to.

If you think about reality, my approach has been growing successful, profitable, and what’s most important is a good company that I can be proud of, and our staff can be proud of. And because I didn’t raise any Venture Capital, I don’t necessarily need to provide an exit to anyone.

Even 20 years from now, we’re still growing, we’re still a private company – that is fantastic! I don’t see any problem with that. And there are some very successful companies like IKEA, which are very large but they are still private.

Of course, it is possible that somebody will come and make an offer I can’t refuse. Well, I’m a businessman, and I wouldn’t be telling you, “Oh, I never will sell it for any money.” Because I know when those words are said it is typically bullshit.

Avoiding Not-Invented-Here

Michael Schwartz: And the way that you position the business, in a way, because you write some software, but you’re also willing to look to what other people are doing, almost like it’s a better long-term strategy for you because you don’t have to be right on your software.

You’re willing to sort of jump ship and say, “There’s something better out there. We’re just going to use that because it’s open source.”

Peter Zaitsev: That’s right. If you look at our approach to innovation, we are looking, for example, at MySQL like a system or Postgres system, or whatever. We are really looking at the tools which already exist in an open source ecosystem, we are covering the gaps which we need to. But in some cases, we will have to write something from scratch, and in others, we will have to adopt some open source projects, and kind of integrate and test and so on and so forth.

But I think it’s very important in our business to be low on ego. Because if you let the engineering team to get that “not-invented-here” mentality, and you really started implementing too much stuff in-house, even if it doesn’t provide substantial value to customers and communion, you will raise your costs way too high and run into trouble.

Challenges For open source Companies

Michael Schwartz: What do you think are the biggest challenges facing open source startups today?

Peter Zaitsev: That is an interesting question. I think many open source startups are different. We are really looking at the different target audience, if you will, and different business models. Now, if you look at the open source database infrastructure, I think getting known is very tough.

Because if you look, compared to years ago, maybe 20 years ago, the open source ecosystem was small and everybody kind of knew everybody and lent you a hand.

Now, it is dominated by the semi-open source, venture-funded or either public companies in terms of voice share, in terms of how much marketing they do, it is very hard to become known, I would guess. That is a challenge.

Another hump of course is, if you are targeting Enterprise, those folks are very risk-averse.

If you, say, you are a two-people company, you have created some fantastic technology which can help a lot, then a question for enterprise is, “Can I trust you to be here in the next 10 years?” Because that is a planned horizon for many.

And on Fortune statistics, about how many startups go under – of course, they don’t. I think even for Percona, it took a lot of time for us to get that confidence of Enterprise customers.

I didn’t mention this in the start, but we have been in business for 13 years now, and our customer base has been evolving. Early on, I could not imagine the customers I have now taking us seriously.

We had to really provide services to much more startupish organizations which don’t quite care what’s going to happen in 10 years. They are just looking for somebody who is best to help them with their needs today, right now.

Advice For Entrepreneurs

Michael Schwartz: Maybe you could just talk about – forgetting the company and open source maybe – but just in general, you’ve got quite an entrepreneurial experience, any advice, just for entrepreneurs?

Peter Zaitsev: I think what is very important in this case is to understand who you are and what your goals are. Because I myself have a relatively unusual path. I came from a technical background, from engineering background to becoming a CEO, and I also chose to stay fairly technical.

I’m still going with the customers, and we discuss the technical problems with them because that is something I like. That really defined how the company management will have to be structured. I needed to hire a lot of people I could trust, to really focus a lot of business aspects.

That is not a road which is right for everyone, and that is not the road probably even possible for everyone. I would say it would not quite fit in the role of the traditional CEO in many cases.

Michael Schwartz: Peter, thank you so much for sharing your thoughts and being so candorous today.

Peter Zaitsev: Of course, thank you! That has been a pleasure.

Michael Schwartz: Thanks to the Percona team for helping to organize the interview.

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

Music from Broke For Free and Chris Zabriskie. Audio editing by Ines Cetenji.

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

If you want to comment on this episode, tweet at us. Our handle is @fosspodcast.

If you really like this episode, don’t forget to leave us five stars on iTunes. That really helps us get the word out.

Next week, we interview Boris Renski, the Founder of Mirantis.

Until then, thanks for listening.

Episode 30: Open Core Summit – The Conference for COSS with Joseph Jacks

Joseph Jacks is the Founder and Organizer of the Open Core Summit (OCS), the world’s first commercial open source software (COSS) event. Joseph is also the Founder and GP of OSS Capital, a venture fund that invests exclusively in early-stage Commercial Open-Source Software (COSS) companies. In this episode, Joseph discusses the exciting origins of the summit, and why today’s investors still grapple with funding open source software businesses.



Michael Schwartz: Hello and welcome to the Open Source Underdogs podcast. I’m your host, Mike Schwartz, and for this episode, we’re breaking format.

Today’s episode is about the Open Core Summit in San Francisco from September 18th to 19th.

That’s September 2019, in case you’re listening to this podcast after it’s too late. That’s really soon, so if you don’t have your tickets, get them now.

With me today is Joseph Jacks, Founder of OSS Capital and founder of the Open Core Summit. He’s going to help fill in some of the blanks about what this conference is about.


Joseph, thank you so much for joining us today.

Joseph Jacks: Thank you for having me.

Michael Schwartz: So, what’s the origin story of the Open Core Summit?

Joseph Jacks: The Open Core Summit really was an idea of a friend of mine, Marco Palladino, he’s the Co-founder and CTO of a really great COSS, Commercial open source Software company called Kong.

The company behind the Kong API Gateway Management Platform, and Marco and I were actually at re:Invent, I believe, late last year in 2018, talking about commercial open source business models.

Kong uses one of the most widely implemented and sort of successful business models for commercial open source companies, which is the sort of open core approach to have the open source permissibly licensed core project. And then they add value around that with differentiated experiences for enterprises that materialized as hosted cloud services, and packaged offerings, and security, machine learning, monitoring, and logging, and packaging, and, overall, sort of robust performance and security SLAs, and so on. They are a really interesting company.

Marco is a really smart and brilliant friend, and I sort of took that idea and sat on it for several months. We wanted to actually do conference in May, but the last nine months have been pretty insane.

So, Open Core Summit is really about galvanizing and celebrating the category of commercial open source software, which really represents the companies that exist to commercialize core open source software projects that are the fundamental basis for a given company.

For example, like RedHat wouldn’t exist without Linux, Elastic wouldn’t exist without Elasticsearch, Hortonworks Cloudera wouldn’t exist without Hadoop. Redis wouldn’t exist without Redis the project, Alfresco Acquia without Drupal, Databricks without Spark, DataStax without Cassandra, and so on.

We sort of classify Commercial open source Software companies, or COSS companies, as companies that fundamentally wouldn’t exist if the core open source project didn’t exist. And sort of thinking pretty deeply about this, tracking the fundamentals of the ecosystem plus activity, particularly over 2018, the timing for a community ecosystem conference on a global basis that really serves to kind of bring together a wide range of ideas, and perspectives, and opinions across, in particular, founders and open source maintainers and contributors, but also executives, enterprises, enterprise customers, cloud providers, investors, analysts and so on. Really in a sort of format of a conference that could sort of scale geographically, and serve to kind of be the basis for knowledge sharing and networking and best practices and collaborations, and sort of like a common meeting place for ideas and evolution.

That was really the core inspiration for Open Core Summit. We are obviously really excited to have a first one coming up in a few weeks here in San Francisco, September 19th and 20th. I’m really honored to have a phenomenal lineup of founders of companies like Fastly, Elastic, Confluent, Kong, Alfresco, RedHat, Amazon, Google, and many other companies.

Who Is Attending?

Michael Schwartz: Awesome! What types of people are registering for this event?

Joseph Jacks: It’s a combination of all the folks I mentioned, kind of all those different constituents, open source maintainers, founders, executives that work at kind of commercial open source ecosystem landscape.

So folks in product marketing and engineering, hiring, strategy, finance, licensing, go-to-market, and lots of cloud provider kind of community is attending and supporting. We’re seeing a good amount of infrastructure, IT, enterprise end-user community.

We actually have a track dedicated to the enterprise voice and perspective, so, enterprise is consumed and purchased commercial open source technology from the vendor ecosystem. If you look at a bank or insurance media, Telco, Fortune 2000, Fortune 500 company, they are on a sort of buy-side, kind of a consumer procurement side of a commercial open source.

So, increasingly two big shifts and things are happening there. Obviously there’s a move to the cloud, move to managed services, Amazon, Azure or Google, but also a simultaneous and sort of in tandem move to commercial open source, which is sort of relying and leaning on the vendor ecosystem there, as every enterprise is adopting open source from the bottom up through developers, into a corporate IT.

And they really need to work with vendors to kind of pardon and build trusted solutions and kind of lean on those vendors for production insurances, so vendors like Elastic, Confluent and obviously RedHat, and many other companies that provide a variety of business models and services around the open source projects they maintain are very appealing to CIOs and CTOs at Fortune 2000 companies. We hope to see overtime lots of participation from that user community as well.

I think the biggest concentration we’ll probably see at the first conference is a lot of interest, at least from what we are seeing so far, in registrations over the next few weeks – I think that will further materialize – is open source containers and founders, sort of aspiring founders as well, along the spectrum.

So, from sort of idea stage to folks working on a company, or interested in building and scaling a company, looking at potential options for funding, looking at potential options for hiring, and strategy, go-to-market, various things like that.

And really kind of selfishly, people want to pay most attention to that constituency, mostly because I think part of the sustainability conversation is really going to concentrate around how we can support, and enable, and provide tools and learning frameworks and access into folks who have built and scaled projects and repositories, from sort of like first commit to through to an IPO, for the next generation of open source founders, open source creators and maintainers.

Biggest Challenges of open source Startups

Michael Schwartz: What do you think are the biggest challenges today for companies using open source as part of their business?

Joseph Jacks: I think some of the biggest challenges kind of revolve around contribution and sort of expectations and dynamic around security, the vendor ecosystem and really what open source means fundamentally.

At the end of the day, a lot of those issues and challenges don’t really look like challenges and issues if you dig hard enough.

Basically, every company on earth uses open source, and they use it very heavily. The sort of converse is not true, in terms of contributing back and giving back to those projects when it comes on to co-commits and actual engineering investment, a very small fraction of enterprises would actually go and have dedicated explicit mandates to contribute backup stream.

Having said that, even if those mandates and explicit initiatives and open source program offices don’t exist, even if they don’t exist, what does happen, which is great, is a pretty significant fraction of developers, who are actually using consumed open source, will file a bug report, or potentially fix something really minor, if potentially, something really jumps out to them, and then, touches and inspires them, while actually maybe spending time and maintaining and contributing engineering time to a project.

I think it’s sort of a high entropy, very hard to measure, and make universal statements about kind of dynamic. Mostly because we don’t really know and we don’t have a way to determine the extent of contribution back at open source, from the consumer side, from what as enterprise or cloud providers, what have you.

It’s quite a lot of important and interesting things there, but I don’t believe we can make categorically sort of universal statements about what is or isn’t happening. Obviously, there are instances where most companies consume and take more than they give. But, I guess, having said all that, whenever this question comes up – because this is a very common question – what are the biggest challenges, sort of contribution getting back topic always comes up.

I always think of a quote by Doug Cutting – who was the engineer creator behind Apache Lucene, Apache Hadoop, and a few other things – and what he said is sort of insane, to expect proportional contribution back to open source, relative to value received from it, or benefits received from it – I’m paraphrasing slightly. I tend to agree with Doug, and I think that that’s sort of correct way to think about open source in terms of the give and take dynamic. There’s lots of interesting evolution here, lots of really cool projects and initiatives happening these days, so, it’s a cool time to be in a community.

Do Investors Care About Open Source?

Michael Schwartz: Putting on your investor hat for a second, I was recently reading an S-1, and the only mention of open source was as a risk that there could be some liability around this company’s use of open source. Is this view changing? And the company’s use of open source to investors, just sort of like a non sequitur.

Joseph Jacks: I think probably more the latter, and I hope it changes. We’ve seen, one, commercial open source IP of the Sierra is Fastly. So, Fastly fundamentally wouldn’t be where they are today and arguably, wouldn’t exist without, Varnish, the Edge Cache proxy technology, they build a wide range of products on top of CDN, among other things.

And Fastly calls out open source quite extendible. It has a pre-promised position. I think it depends on the company. If you look at WeWork or CloudFlare, and other companies, maybe Peloton, I think Ben Thompson, from Stratechery, actually wrote a post earlier today about what constitutes a tech company, what’s a sort of definition of a tech company.

If we sort of like follow logical reasoning of, are all companies becoming tech companies – or, maybe let’s just say yes, and they are all tech companies, software companies – most tech companies use software pretty heavily. And further, all software companies rely heavily on open source – that’s a definite yes.

You need to sort of like make the recursive loop back to all companies are becoming tech companies ultimately are all companies heavily relied on open source. So, that’s kind of like massive, global macro dependency.

I’d say that in that light over time, I think we’ll see more prominence and understanding in the public markets, the retail/investor landscape, and whether it’s IPOs, or increasingly direct listings that are potentially more appealing and interesting than IPOs.

Recognition and acknowledgement of open source is sort of a fundamental driver for innovation. I hope we see that shift. One of the passing things that we have on our plate with OSS Capital is to dig into the recent flurry of S1s that really are software company S1s, and determine how extensively they call out open source as part of their company positioning and product strategy, differentiation, and so on.

As you point out, most of the references of open source are listed in the risks section due to trademark, IP protection, and risks around that. So, it’s kind of like a common land out there in the risk section that lawyers kind of put down. In fact, if you look at every five or ten S1s, the wording is almost identical, it is kind of boilerplate.

But companies like Elastic, or Pivotal, or Fastly, Hortonworks, a handful of others, that are commercial open source companies, having IPO over the last 18 months, you’ll see much more extensive acknowledgement and sort of elaboration on open source as part of their strategies.

But I think even in those cases, it’s not quite articulated enough as a sort of fundamental driver in building block for why those companies are different, and why they sort of like have the ability to create more value than, say, companies that are fundamentally closed and proprietary at the core.

Common Themes

Michael Schwartz: Do you see any emerging themes in the sessions?

Joseph Jacks: I think the biggest common theme that the speakers are looking to talk about is how business models are evolving, and the topic of what defines open source, and what does open source licensing look like in the era of core license innovation.

We’ve seen lots of “source available” licenses that actually are not open source licenses in the sense of adhering to permissiveness, definitions laid out by the OSI, or, for that matter, free software foundation, or the copyleft evolutions of the last couple few decades.

I’d say that more interest in business models and licensing will probably be the case for this first conference. And over time, I think what we hope will happen is the sort of elaboration and content focus on why product development is different in a commercial open source context, why go-to-market is different, why engineering is different, why hiring is different, because all those functions, quite differently – from a behavioral and implementation perspective – inside of these commercial open source companies as compared to previous generation fundamentally closed-source proprietary software technology companies.


Michael Schwartz: I’ll just say that sounds like it’s going to be quite an event. And I wanted to say thank you for joining us today, and we’ll see you in about two weeks.

Joseph Jacks: My pleasure. Thanks so much for having me, Mike.

Michael Schwartz: Joseph has just done a fantastic job putting together an Action Packed 2-Day Agenda.

Many of the guests that you heard on this podcast will be at the Summit, like Ofer Bengal of Redis, Martin Dougiamas of Moodle, Tom Hatch of SaltStack, Emil Eifrem of Neo4j, John Newton of Alfresco, Jay Kreps of Confluent, Michael Howard of MariaDB, Paul Dix of InfluxData, Sid Sijbrandij from GitLab, and several others you’ll hear in future episodes.

In fact, we’ll be recording two episodes in person at the Summit. So, if you’re a founder, developer, investor, analyst, or just a person excited to learn, meet and collaborate, and all things, at the intersection of open source software and business, this conference is definitely for you.

Thanks to Melissa Park for helping to schedule the podcast amidst all the chaos of planning a conference.

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

Music from Broke for Free and Chris Zabriskie.

Audio editing by Ines Cetenji.

Production assistance and transcription by Natalie Lowe.

Operational support from William Lowe.

If you have any comments or thoughts, tweet at us. Our handle is @fosspodcast.

As promised, the next podcast will feature Peter Zaitsev from Percona. We’ll push up one next week. Until then thanks for listening.

Episode 29: Chef – Rapid Configuration Automation with Corey Scobie

Corey Scobie is the Senior Vice President of Product and Engineering at Chef, maintainers of the popular open source configuration management tool. In this episode, Corey discusses the “4 freedoms of open source software,” and various challenges associated with building a business around open source software.

Interested in learning more about Chef? We encourage you to check out The Changelog‘s podcast episode featuring Chef Co-founder Adam Jacob!



Michael Schwartz: Welcome back, Underdogs. This week, we have Corey Scobie, VP of Product and Engineering at Chef.

If you want to hear even more about Chef, you should check out Episode 353 of The Changelog, where Adam Jacobs, one of the co-founders, gives his perspective on “The war for the soul of open source” – it’s a really interesting contrast with this podcast.

Like WSO2, Cloudera, and you could say Red Hat, Chef has moved to an all open source code base. They are licensing what Corey calls “The post-production binary.”

I don’t want to spoil much more, so let’s just cut to the tape.

Corey’s Background

Michael Schwartz: Corey, thank you so much for joining us today.

Corey Scobie: Thanks, Mike, it’s great to be here.

Michael Schwartz: Can you just tell us a little bit about when you joined Chef and how your role has evolved since you’ve been there?

Corey Scobie: Sure, absolutely. I joined Chef in March of 2018, so a little shy of 18 months ago.

At the time, Chef had been through some really interesting expansion of the product portfolio. And so, I was brought in to lead the product and engineering team and vision overall around bringing together the parts of the product portfolio that we put on the table at that point, which included the traditional original Chef project, InSpec, which is our open source project around security and compliance, and then Habitat, which is our open source project around application, orchestration and deployment.

Revenue Model

Michael Schwartz: Recently, Chef announced that it was open sourcing 100% of its offer under the Apache 2 license, and at the same time, announced the Chef Enterprise Automation Stack. I’m wondering what’s in the Enterprise Automation Stack, and how do you get people to pay for it if it’s provided under Apache2?

Corey Scobie: Sure, that’s a great question. In order to answer that, I need to sort of take you back a little bit in time.

Chef was founded in 2008 and started an open source project shortly after under an Apache 2 license, the original Chef project, and went through years of development.

Overtime, as the product portfolio evolved, Chef had become essentially what we described as a loose open core company, which meant that there was a core product which provided value to customers in the Chef Engine, the Chef infrastructure automation suite of tools.

And then, we had created some proprietary software on top of that to help fuel the monetization value of using the underlying open source project. For us, that was a product called Chef Automate, which was our enterprise access control plane.

Ultimately, at the end of the day, we went through sort of an existential discovery of our own last year to figure out how we would take the parts of the product portfolio.

We continued to take the parts of the product portfolio forward, honoring the open source nature of the way that Chef was started, and that most of the other projects, InSpec and Habitat were started, and yet, being able to effectively deliver value and monetize commercial customers in that realm.

We announced in the beginning of April that we were going to do exactly what you just said, Mike. We were going to open source the entirety of our kit, so for us, what that meant was, we were going to take any of the additional on top of the open source project software development that we were doing.

For us, that was Chef Automate, and about 50% of the company was of the engineering team anyway, was primarily focused on delivering Chef Automate, as a proprietary piece of commercial software on top of Chef and InSpec.

We decided to take all of the remainder of the product work that we were doing and open source it, to attach it to the Apache2 license, because we believe in the alignment and the permissiveness of Apache2, as a license vehicle for open source software development.

Today, if you look at today’s Chef, a 100% of the work that we do in product engineering, so a 100% of the work that we do that results in software distributions that customers use first order in their environments, is done in open source. It’s done with the Apache2 License, it’s done in an open and collaborative way that you would expect well-run, open source project, or multiple well-run, open source projects to be.

And for what it’s worth, we have somewhere around a thousand repos today in Github. So, that gives you some sense of the expansiveness of the product portfolio. Now, a lot of those repos are around specific components that we built for Habitat, but nonetheless, there’s still hundreds of sort of core repos that are the tools that make up the Chef ecosystem.

We open source everything, and in the belief that being transparent and having that software development process be accessible to our customers with value to everybody, we can build better software if we collaborate with the people that use the software.

The flip side of that is that we’re still venture-backed commercial entity, and of course, our goal is to get people to pay for the value that they get in Chef, and InSpec, and Habitat, and Automate, and all the rest of our product portfolio.

So, along with the announcement and the move to move all of our software development to open source, we also decided to make a change about how we distributed the software that we built and maintained on a regular basis.

The coupling of that was that, moving forward, we decided that all new builds or new releases of Chef software, of InSpec, of Habitat, and ultimately of Automate, would come with a commercial EULA attached to them.

The EULA basically sensed if you are a commercial customer, a commercial user of the software, and you’re using it for commercial gains. You’re obligated to license that distribution from Chef.

And so, the combination of those two things means that, essentially, we were able to resolve two core questions that were really hampering us in our relationship with customers, and with users and open source.

One of them was, “Explain to me what’s free and what’s proprietary.”, or “What’s open source and what’s proprietary?” Let’s call it that.

That was a very difficult question to answer, and we would have to draw across the various different projects, a very wavy line, that differed by project, on how much of it was proprietary, how much of it was open source, where did the features go, etc.

So, by moving to a 100% open source, the answer is very simple, 100% of it is open source and 0% of it is proprietary. And we’ve got a very simple way to answer that question to anybody in the Chef community, or ecosystem, or customer base.

The other question that customers often asked us was, what was free and what was commercial. That of course also had a very wavy line. It was very difficult to explain to anybody the difference between the free or the commercial parts of our offering.

And, of course, as an open source company that it’s trying to commercialize on it open core model, you’re motivated to try and put more of the feature functionality into commercial or proprietary software, to try and ensure a value proposition, by going to a 100% open source and going to a commercial distribution of the software that we use. So, distribution being the software that we produce after we go through our release engineering and testing cycles and everything.

The actual binary packages that we distribute to the world, those come with the commercial license attached to them. And so, the answer is 100% of the intellectual property is free, and you can do with it what you like, but if you want our post-production version of how to easily install turn-key software into your environment, that comes up with a commercial license, and we expect customers to honor that with a relationship with Chef.

Does No Binary Distribution Hamper Adoption?

Michael Schwartz: Do you think that not providing a binary for the community hampers adoption?

Corey Scobie: Well, interestingly, I think if you were starting out as an open source company, you really want to ask yourself, like, what are your goals, and why are you choosing open source as a software development methodology.

In many cases, if you’re starting out and you don’t have an established community, established user base, established brand, etc., one of the things that you can do is you can offer yourself for free to the world, free as in beer as opposed to free as an available intellectual property. That can definitely help you with adoption.

We have a relatively, you know, Chef goes back a decade now, and we have a strong base of users, what we’ve decided to do in order to try and maintain the grassroots adoption of our software is, make it as accessible as it was before.

So, in other words, anybody can land on Chef.io and download our binary software in the exact same way as they could before. So, the availability of this offer is not different.

The license terms that come with it simply say: if you’re using it – it doesn’t matter what kind of organization you are – if you’re using it in an experimental way, or you’re trying to learn about it, for your own benefit, or to evaluate, fit in your organization – that is for use, and you’re not obligated to have a license relationship with Chef.

If you were using it in a commercial way, you are obligated to have a license relationship with Chef to use that package of that software, and so in that regard, I suspect that we probably will turn down our grassroots adoption a little bit.

For us, it is a mature open source company – that’s a trade-off that we’re willing to make.

But if you are a brand new company, and you’re trying to get adoption and validation of the technology in the field – that probably could be a major hamper for sure.

Customer Segments

Michael Schwartz: Enterprise Automation is a huge horizontal market, and I’m wondering if you segment the market in any way?

Corey Scobie: We don’t naturally. In other words, there’s not specific vertical industries that we try to focus on, although I will say that if you look at the demographics of our customer base, there are industries that naturally lend themselves to Enterprise Automation more than others. And those industries tend to be industries that are heavy in computes, environments, and transactionality, etc.

So, if you look at financial services, for example, financial services is a strong sector for us, it’s a strong sector for I think most companies in the Enterprise Automation space. We don’t specifically target financial services, but the characteristics of financial services is, they tend to have lots of compute resources in lots of hybrid environments, both on premise and in the Cloud, and the management of those environments is a material cost to them and also a material opportunity for efficiencies that get them to the next level of execution in their industry.

So, they tend to go together well. Other sectors that are strong for us are things like governments, where there’s a lot of computing in certain types of both civilian and DoD kinds of government environments, the hospitality industry, the logical places where you see companies, larger companies deploying larger fleets of computing resources.

Value Proposition

Michael Schwartz: So, when you changed – and I realize this change is very recent – but when you changed to, I guess, tweak the business model, did you think that that affected the value proposition for the commercial offering?

Corey Scobie: What’s interesting is that I actually don’t think it really affected the value proposition that much, because before we changed our commercial licensing on the binary distribution, the reality was that the customers that were paying us money for Chef were paying us money for Chef because they wanted to get their software from us, they wanted to have assurance and support that somebody was there to stand behind the software when they needed it.

They wanted all of the things that are basically the core value proposition. And today, if we describe the value proposition of having a commercial relationship with Chef, it’s that you get the best word-class distribution of the software that’s available.

Currently, there are no other alternative distributions of the software available. However, our community is working hard at building some community editions of that, and we have been welcomed with open arms, and we’ve been collaborating with them to do that in the most constructive way possible.

There’s no other distributions of the software broadly available today, but I suspect that that will be a true statement in the future. Red Hat and CentOS are probably the historical example of that kind of thing.

But the core value proposition is that they get software from the Originators of the software, who have more people working on the open source project than anybody else. They get the insurance and support of having Chef to be able to stand behind that in an Enterprise Plus way, 7/24 support availability, SLA is on things like bug fixes and security updates, etc.

They also get access to the people that we have at Chef, many of whom are very, very skilled field operators that help customers with complex Enterprise Automation needs. And then, we are also working on building content that really couples well with our commercial distribution of the software and is available to commercial customers, that is, you know, there’s a world of Chef content available out there, cookbooks and InSpec’s profiles, etc.
We’re trying to build a small set of the best curated version of that content, and then manage that in the same kind of software development loop that we manage our core software engines in.

Foss Principles

Michael Schwartz: I was just giving the press release, and one of the lines that stood out to me was, “Vendor-driven development and distribution models that closely align with FOSS principles,” and I’m wondering what are those FOSS principles that aligned with vendor-driven development and distribution?

Corey Scobie: When we talk about FOSS principles, we talk about the Four Freedoms of open source software. And it’s interesting because the Four Freedoms are age-old sort of documents around, you know, new project, and what are the essential freedoms that you need to really be able to claim that you’re an open source software project.

And the freedoms are really succinct, every time I read them, I read them like they are amendments to the constitution. They were written a long time ago by some people that really had a great vision of where it’s going. And I realize that today, this is super controversial because there’s a lot of conversation in the marketplace about what does actually conform to the Four Freedoms, or whether the Four Freedoms should really be the definition of open source going forward.

But the freedoms are, the freedom to run the program as you wish, for any purpose, to not have an assumption about what you step program might go to. The freedom to study how the program works and change it, so access to source code is a precondition for this, the freedom to redistribute copies, so that you can help others.

And for what it’s worth, we do have some restrictions in saying that the license is not transferable, but the binary distribution of our software is redistributable in many cases. And we use RubyGems and other distribution mechanisms in order to get broad distribution of the software out there.

And then, the freedom to distribute copies of modified versions of the software, which, for us, the example of that is that the community is actually building and modifying the software, to create a new open source and free as in beer version of the Chef client as an example.

They may not recreate the entirety of the ecosystem of the Chef client for companies that don’t want to use our commercial distribution, or for people that don’t want to use commercial distribution like ours. And there’s no problem with that.

The one rub that we have in our open source strategy is that Chef is unlike many other projects, which emanate from free software islands like an Apache project or something along those lines, we are Chef, we actually invented the project to begin with, Adam Jacobs is one of the founders, he founded the first open source project around Chef, and Chef, the company owns the trademark to that.

We are protective of our trademark in that other people shouldn’t be allowed to use our trademark, really just the same way that you can’t build running shoes and call them Nike.

But beyond that, beyond the trademark limitations that we have around the brand itself are open source projects that are available to anybody to use, and to modify, and to redistribute as they see fit.

Investing in Project

Michael Schwartz: The one and the best position to nurture the project are the ones who have invented and continued to drive innovation?

Corey Scobie: To continue to drive innovation and continue to invest. One of the great things about open source is that people show up and will invest their time and their effort, but there’s real capital required to make a lot of the open source projects that we really value broadly applicable and broadly valuable to the market at large.

And so, for us, one of the things that we bring to the table as vendors, we brought a hundred million dollars’ worth of VC money at the table to invest in the projects over time.

Where Does the Community Add Most Value?

Michael Schwartz: Where do you think the open source community makes its most valuable contributions?

Corey Scobie: To me, it’s really about the idea of identifying a problem. I’m going to take it to the existential line and say it’s really about the idea of identifying a problem or a gap in the market and building a collaboration around how to solve that.

And the reason I think that that’s really important is, because one of the ways that you build great products is by bringing multiple viewpoints into the picture, and then, collaborating with those viewpoints to come to sort of the most broadly commonly applicable aspect of the problem that you’re trying to solve.

And one of the great things about open source as opposed to proprietary software, particularly – you know, my history is largely with proprietary enterprise software – historically, is that those viewpoints, those different angles of the problem-solving often don’t come in in an open source software development life cycle until the very end, until you’ve done 95% of the solutioning and engineering problem solving.

The way that open source makes such a great contribution is, it usually takes the problem and sticks it right out on the table, right upfront, and then, people get to collaborate. And those opinions and the ideas of how to solve that problem are integrated right from the get-go. And I think that what results in that is just better quality solutions to the challenges that you’re trying to solve overall.

And so, it’s the super existential version of that question because there are many, many other versions of that answer that point at specific parts of the technology stack that are pervasive in the industry, etc., but for me, it’s really about trying to make the best of whatever problem you’re trying to solve, and that’s where open source shines.

Conversion Rate

Michael Schwartz: Do you have any numbers or thoughts about the percentage of open source deployments that convert into Enterprise subscriptions?

Corey Scobie: You know, I should. We’re definitely able to measure that better since our open source/license model changes this spring, but it’s very early days, and so we’ve seen some conversions and some returns on that front.

But what I would say is this, it is part of the challenge of being an open source company, particularly one that delivers enterprise software to proprietary computing environments in the enterprise – it’s hard to get real telemetry.

So, what I couldn’t tell you today is, how many companies, or how many versions of companies, or how many nodes of software I have deployed in the world, both are a combination of open source and proprietary.

I can certainly give you statistics on what I have in terms of commercial licensing on the one side, but the part of the equation that isn’t clear because we don’t have good product telemetry on that front is, how many nodes of software are actually deployed.

So, we don’t know what the conversion rate is, we don’t know how many people will come to a decision point, at a point in the future, where they have to decide whether they want to continue on the open source path or the commercial path and make an explicit decision there.

Unfortunately, Mike, today, I don’t have very good statistics about that. I can tell you that we suspect that we will see some uplift in companies deciding to follow the commercial path, now that we are driving that decision point at some point in the future, but it’s going to be difficult to calculate how that converts to the distribution of software in the past.

45 million downloads of Chef for over the last 10 plus years. So, there’s a lot of it out there.


Michael Schwartz: It could also become more challenging if there is another distribution that’s not distributed by you, so that the objectives of that other distribution may not be to include the telemetry or to do a deploy squeeze to get information on who’s deploying it – do you see any friction there?

Corey Scobie: Yes, it’s possible, for sure. I mean, one of the things that’s interesting, and I think somewhat unique about how things are shaping out in our community is that the alternative distributions are, as opposed to a group I’m coming along and hard forking the project.

What we’ve done with the community is that we’ve sort of collaborated on an additional distribution, or making it easier to create additional distributions of the software, by staying on the same core-source tree.

Just as an example, if we decided to put telemetry into the product, and that went into the core-source tree, a downstream distribution might choose to exclude that, or they might choose to stay compatible, in which case, they would have the opportunity to collect, and maybe show that telemetry as well.

So, I guess the answer is it could go either way. There, from a technology perspective, the path of least resistance is for us all to stay on the same source space. And that way, we can try and guarantee for the backward compatibility across the different distributions of the software, which is something that we, as a community, have to decide if it is important for our users, but it could go different ways too.

Sales and Marketing

Michael Schwartz: Switching tracks a little bit towards sales, are most of the leads inbound? And I’m wondering if – you haven’t been there that long – but do you have any visibility of how the sales teams evolved over time?

Corey Scobie: One of the things that we decided to do when we made our sort of our licensing changes, and what-not, is to really focus on the fact that we are a company that largely delivers to enterprise-class customers. So it’s the global 5000 industry players.

On that front, it’s a good mix. I mean, we still have lots of inbound interest, it comes at different levels, and it’s sort of more curated now than it’s been in the past, I think.

If you would have talked to Chef of 2015, the answer would have been, “Everybody and anybody is our target market.” With that, leads or inbounds, we do a lot of prospecting ourselves as a sales force. But where there’s no real opinion about whether we should be tracking down a lead, based on the potential size of a commercial opportunity, or what-have-you.

I think the Chef of 2019 is a lot more focused on really being outbound-driven on the enterprise-class customers. And then, inbound-driven on right-sizing the inbound leads into the appropriate bucket.

So, for us, we have partner offerings that are focused on sort of smaller scale, small footprint customers, often in a hosted environment, so we have a relationship with Amazon web services that has our product offering, a certain Chef product offering called OpsWorks for Chef Automate.

That’s often a place where small and medium customers gravitate to because it’s more of a consumption-based model. And then, the larger enterprise customers tend to want to have a relationship directly with Chef. Ourselves and those customers tend to be larger contract values in a longer-term commitment.


Michael Schwartz: The pricing is one of the hardest parts of tech entrepreneurship, and I think it’s really hard for infrastructure software when you say, “Well, what’s the value of this infrastructure? – Well, your company maybe couldn’t run without it.”
I’m wondering if you struggled with pricing, or change pricing, and sort of how you’ve approached, like how do you figure out what’s the right value?

Corey Scobie: So, what we didn’t do is, we didn’t change the market, the established market value of our suite of infrastructure automation security compliance. So, overall, the net value of that in the marketplace is exactly the same before and after the business model.

What’s interesting about what we did with licensing is that prior to changing the commercial terms on our distribution, customers really bought a license to Chef automate which was our proprietary management console. But they paid by the number of systems that they were connecting up to that management console.

It was sort of a proxy value to the real value that they were getting, which is, they put Chef on a server, and it does configuration management for them. But then, they paid us, by paying us, to foresee and manage the visibility of that in an Enterprise console on top.

That was a side effect of the open core proprietary open source software of the relationship that we had, all of those products. What we did host the license and packaging change as we said, “Chef itself has a value, and that value is the thing that customers experience the most value in.” So, we’re going to put a specific price point on Chef.

Same for InSpec, which is around security and compliance, and continued security and compliance there. And the aggregate of those two was the same value as they were paying us before on a per note basis for Automate.

We basically did unbundle the pricing to create distinct, unbundled pricing, as well as creating some easy-to-consume Enterprise skews on top of that. Because often, Enterprises don’t want to buy a bunch of part pieces but what they want to buy is the solution that does infrastructure automation, or security compliance, or for us, the ES bundle is all of the pieces of the puzzle together, into one pricing bucket, into one easy-to-consume skew.

So, the short answer is, we didn’t change the market value, but what we changed is how you count the pieces, the components that go into that market value, to make it easier to understand and see the real value of what you were licensing in our commercial relationship with Chef.


Michael Schwartz: I’m wondering about, if you have any channels, or have you built partner networks, and does that account for a meaningful amount of sales?

Corey Scobie: We definitely do have partner networks, and often, they take different forms. Like, most commercial software companies, some of our partner channel is about fulfilment, like how people actually create a contract vehicle and purchase things. And it’s easier for them to do that with – if it’s a new customer, for instance – it’s easier for them to do that with a partner who may have an established business relationship with them. And it might then bring on a new vendor.

We also have channels that are about, both software and services delivery, and building solutions channel is on top of that. Enterprise Automation, as you said, it’s a complex, horizontal landscape.

We have a number of partners, where they are sort of value-added partners on top of the software core. So, what they’ll do, they’ll bundle on services or other kinds of consulting engagements on top of that.

Overall, our partner channel does account for a meaningful, not a huge, but a meaningful part of our annual recurring revenue footprint as an example. And then, the last thing is, of course, we are strategic partners.

I mentioned Amazon and the relationship that we have with Amazon and OpsWorks for Chef Automate. We also have a relationship with Microsoft, relationship with Google, and of course, these platforms are the dominant platforms of the next generation of Enterprise computing, are important, have strategic relationships with as well.

So, yeah, we continued to build and invest in our integration there from a software and a valued perspective, and we also are building our commercial relationships with them over time as well.

Challenges of Open Source Software Startups

Michael Schwartz: What do you think are the biggest challenges facing new open source software vendors today?

Corey Scobie: The attractiveness of open source is that you get this great collaboration with the community of users that you’re trying to solve problems for. You probably get them uplift in terms of the community coming along and adding value to the amount of investment that you as a new open source company are able to put into that code base.

So, those are both positives. And plus, you get, depending on what you choose from a licensing perspective, so choosing to be an open source company and choosing a licensing path are sort of two different things, and they should be thought of as two separate decisions that come together to help reinforce your business strategy overall.
But if you look at it from a licensing perspective, whether you go on a freemium, or a truly free distribution to try and amp up acceptance and distribution of your technology, you can definitely get more eyes and more interest and more potential users to your door that way.

I think the real tricky part is to understand clearly the dynamics of the relationship between the value that you provide as a software company, and how you expect customers to realize and pay for that value in the long term.

I think that is a really tricky thing. And it’s not static for the lifetime. At least, in my opinion, it is not static for the lifetime of an open source company.

You may choose open source as a business strategy and a software development strategy early in your life cycle for one set of reasons, and then, choose to continue, or expand, or refactor that open source capability later in a lifecycle of your company, depending on where you’re at in that evolution. And it’s something that you should revisit on a regular basis.

I think the other thing that’s really hard for open source companies today is to choose – there’s a lot of political and other thoughts going on in the industry around open source, and the existential threat of Cloud vendors, and whatnot – that’s a whole sort of political hotbed of topics that I think has spawned a huge derivative of interpretations of sort of open source licensing and open source licensing strategy, etc.to try and protect the intellectual property based from something.

And gosh, I think, you got to go into it with the idea that you’re going to be the best at solving the problem that you’re starting right now, and let the market play out.


Michael Schwartz: Corey, that was really fantastic. Thank you so much for your sharing all your thoughts today.

Corey Scobie: Thanks for having me, Mike. It was great, and obviously something I’m passionate about is the evolution of open source, and how we can all be better open source stewards.

Michael Schwartz: And best of luck with Chef.

Special thanks to the Chef team for volunteering Corey.

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

For this episode, we also added a link to The Changelog #353, if you want to hear the interview with Adam.

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

Production assistance from Natalie Lowe.

Operational support from William Lowe.

Please leave a review or add Open Source Underdogs to your podcast favorites list. That helps us get the word out.

Our Twitter handle is @fosspodcast.

Next week, another bootstrapper, Peter Zaitsev, Founder and CEO of Percona, he’s one of the early engineers at MySQL. He’s had a ringside view of the open source database landscape, and he’s super interesting – don’t miss it.

Until next time, thanks for listening.

Episode 28: InfluxData – Purpose-Built Time Series Database with Paul Dix

Paul Dix is the Founder and CTO of InfluxData, creator of the popular open source time series database, InfluxDB. In this episode, Paul discusses finding balance between commercial and open source offerings.



Michael Schwartz: Welcome back! You’re listening to Open Source Underdogs.

I’m your host, Mike Schwartz, and this week, we’re honored to be joined by Paul Dix, Co-founder and CTO of InfluxDB.

The goal of this podcast is to gather first-hand accounts from the founders who helped build successful open source software companies.

Started around seven years ago, InfluxDB is a time-series data platform that’s achieved significant market adoption, including deployments and more than 450 Enterprise customers, like Cisco, IBM, eBay, and Siemens.

The company has raised around $120 million dollars, which its using to expand operations around the world.

As both the founder and longtime developer, Paul has some deep insights about open source business. So without further ado, let’s cut to the tape.

Paul, thank you so much for joining us today.

Paul Dix: Thanks for having me.


Michael Schwartz: I guess you were a developer before you started InfluxDB. I’m wondering about how did the company come about?

Paul Dix: Yeah. As you mentioned, I’m a developer. I guess I should probably start – I’ve been in developing software for a long time, since I got in the computer industry in the late nineties.

And the experience that I have that is most direct relevance to Influx is, in 2010, I was working at a fintech startup in New York City, and we had to build essentially a time series solution for tracking market data in real-time. We were building a pricing engine that would update prices, price predictions once every 10 seconds for the hundreds of thousands of different financial instruments.

Building a solution around that was my first foray into time series. And for that, I used web services written in Scala, with Cassandra as the long-term data store, and Redis as like a real-time indexing engine.

From a developing background, that was kind of my background. But from an entrepreneurship perspective, I always knew that I wanted to start a company, and it was basically just a matter of building up enough experience along the way – like working at other startups, working at large companies – and getting to a point where I felt comfortable venturing out on my own and trying to start something.

Is Cloud Best Monetization Strategy

Michael Schwartz: In one of your talks, you mentioned that open core and cloud are two viable revenue streams for pure play open source companies – I’m wondering if you think that that’s still true?

Paul Dix: I guess, depending on your viewpoint, open core is not a pure play open source strategy, strictly speaking. If you’re thinking pure play open source, like, everything you do is open source, and basically you just charge for services, whether those services are professional services, or cloud hosting, right.

Realistically, I think successful businesses that are built around open source have to be open core in some way. And I definitely count SaaS platforms in that vein.

Basically, I think the key is, you have to have something in open source that’s interesting enough that people can solve enough of their problems with, where a large community of users can build on top of that, or use your software without becoming customers. That just has to be the case where it can be a successful open source project.

And then the core part, that’s the open core. It has to offer some value that’s interesting enough, that some small percentage of that community will pay you for it. I think, if you’re looking at infrastructure software, the best method for building a business on top of that now is basically as a cloud-hosted service.

Now, obviously, not all infrastructure is in the cloud, and there’s obviously still a very large component of on-premise enterprise software. But I think, as a software delivery mechanism, like a SaaS hosted service is just so much better because you have the ability to fully instrument it, to fix bugs quickly, and to really do a bunch of things that just are basically impossible if you’re delivering on-premises software.

As from the business perspective, if you look at other open source companies, that’s largely played out over the last few years, where the companies that are most successful has essentially SaaS products that use their open source core but have a bunch of closed source software around them: MongoDB’s Atlas, Databricks is basically a SaaS product of Spark, Redis Labs obviously hosting Redis, Elastic has their own hosting stuff.

Support As Revenue Stream

Michael Schwartz: Your original monetization strategy was around support, and I’m wondering why you think that didn’t work?

Paul Dix: I think part of it has to do with our project maturity at the time. I think support works well if you have a piece of software that has become what I call ‘critical path’ for larger customers who are willing to pay for support.

Critical path generally, in the database world, means an LLP database, that is used directly in an application.

Influx frequently is used in monitoring cases, where the data is important for monitoring system, but it’s not what, as a user, your customer sees.

Particularly at the time, when we first offered support, which was in the summer of 2015, there weren’t as many people yet using Influx in production, in a setting where they just needed support, and that they would pay for.

Ultimately I think, support as a business model for open source, it kind of pits you almost against your community. Because the thing is, if your software is too easy to use – or too good – people won’t need support.

The only thing they’ll purchase support for basically is an insurance policy, to make sure you’re still around and pushing the software forward, which is a limited audience that you can sell to.

The other thing is – as an open source project becomes more and more successful, other people will come in and offer support around it.

In my talk a couple years ago about open source business models I said, “If support is going to be your plan, as an entrepreneur, you’d be better served by picking an open source project that’s already popular, and offering support around it.” Because, if you’re building the open source project yourself, like, all that engineering time that you’re putting into it, are basically billable hours that you have consultants not billing. If you are consulting shop, you need your people billing.

This is why Percona offers support for MySQL, and other databases, because it’s better to build a consulting organization around existing projects.

Market Segmentation

Michael Schwartz: Right, I think that’s true.

Time series databases are used by a wide array of companies – practically any organization could be your customer. I’m wondering if you segment the market at all, to figure out who do you sell to?

Paul Dix: There are definitely different market segments, but normally what we do is we segment on use case.

We have what we call a “DevOps monitoring,” which can be server monitoring or network monitoring, or monitoring services, application performance monitoring, real-time analytics – which could be business intelligence, it could be all sorts of things.

Sensor data is a big use case, particularly in the industrial sphere; think like oil and gas wells, power generation, power plants, solar, wind, all that kind of stuff.

And then, finally, financial market data is an obvious choice for time series. That’s kind of how we segmented it.

In terms of what industry verticals we’re playing, like I said, in IoT alone, you can track a bunch of different verticals: Oil and gas, renewable energy, factories, different stuff like that. And then server monitoring, again you could have different verticals, like we have eCommerce retailers, we have other software startups that use our stuff as a platform. We have people in finance, research. All that kind of stuff.

Project Or Company First?

Michael Schwartz: Did you start the company and the project at the same time?

Paul Dix: The company actually predates the projects, which is not very common for most open source businesses. Usually there’s an open source project that you then try to commercialize later.

The company was started essentially as SaaS products were doing real-time metrics in monitoring, kind of in the same vein as like Datadog or Stackdriver, or some pieces of New Relic. And when we were building that company initially, what we found was: One, our product wasn’t really taking off, we didn’t have a good clear differentiator on the product; but the other thing was, we had to build all this infrastructure to actually build that product. We essentially had to build a time series platform.

I started the company with my co-founder in 2012, halfway through 2012. We did a Y Combinator until 2013. And by September of 2013, I realized that that wasn’t going to take off, and I thought, “Well, let’s just take this infrastructure stuff that we’ve been building for this application,” it’s called the Errplane – “Let’s take that code, let’s take that package, like start fresh, add a couple of things that we learned building it, and start as a fresh, new, open source project.”

Myself, my co-founder, and one other guy, iterated on this for about five or six weeks. First commit was September 26th of 2013. We put together basic documentation website, and I arranged to give a couple of talks at meetups in New York City. One was the Ruby programming meetup, and the other was the open statistical programming meetup.

I gave those talks in early November of 2013. And the project just immediately took off.

People were very interested in it. The docs site got posted to Hacker News and was on the front page all day. And I basically just kept giving more and more talks about it. It was obvious that we kind of struck a nerve and found a real need that wasn’t being addressed, at first in the database space, because we were just focused on the database.

But, over the course of 2014, I built out this bigger vision of creating a platform, essentially for solving problems for which time series is a good abstraction, and these are those use cases I mentioned earlier: Monitoring, server monitoring, real-time analytics, sensor data, and fintech data.

Over the course of 2014, gave more talks. I raised the Series A round of funding, which closed in November of 2014. It was an eight million dollar round led by Mayfield Fund and Trinity Ventures, and then we just kept going from there.

But, like I said, I think most other open source companies are actually created after the formation of the open source projects.

Although I guess Docker, for example, there was a company called dotCloud that existed for well over a year before Docker came to be. And actually, Dan Scholnick, the partner of Trinity Ventures who co-led our Series A, was the first money into dotCloud, which is the company that became Docker.

Has Open Source Been Materially Beneficial?

Michael Schwartz: Would you say that the open source community contributions have been materially valuable to the company?

Paul Dix: I would. But it depends on what parts of the project you look at.

Over the years we’ve had over a thousand people, at least, contribute to code to different parts of the stack. But the thing is a database is not a very welcoming thing to contribute to. It’s pretty esoteric. Even though it’s written in Go – which makes it a lot more accessible than let’s say something written in Erlang, or C++.

So we’ve got contributions there, but I think where we’ve had the best community engagement contribution is actually in our data collector, Telegraf.

Telegraf has 200 plugins that allows it to collect data from various network services and stuff like that, and then ship it to other places – InfluxDB happens to be one, but you can also ship it to other databases, and even other SaaS vendors who are competitors with what we do.

Because of the fact that Telegraf is liberally licensed, it’s MIT with no restrictions, just MIT license, and we haven’t put a limit on what it integrates with, namely it can integrate with competitors, and that’s okay – it means that most of those 200 plugins have actually been developed by the community.

So Telegraf, from an open source perspective, and a community perspective, is actually our most successful project.

Telegraf Distribution

Michael Schwartz: Do you facilitate Telegraf through a marketplace or some other way to help it grow?

Paul Dix: No. It’s just all just bottom-up. As I said, it’s a data collector, so people deploy it widely to their infrastructure. We have no visibility into where it’s running or who’s running it, other than community members who raise their hands and tell us they are. Obviously, the pull requests that come in on the repo, and our customers who use it.

Now, we have relationships with like Microsoft, for example, who has Telegraf as an agent that you can deploy across all of your Azure infrastructure, to send system metrics and things like that to their metric service. So, we know it’s running there.

There’s obviously their Docker images for it, and there are Telegraf images, and pretty much every cloud provider at this point. But the same is true for InfluxDB.

Commercial V. Open

Michael Schwartz: Going back to InfluxDB a little bit. I’m wondering about how you find the balance between what to make commercial and what to make open source?

Paul Dix: This is a really tricky one. It’s something we talk about all the time internally. And it’s not something that I got right out of the gate.

In late 2013, when we were first building the project, it was me and two other people, with a seed round of funding. We had enough money in the bank to last us, like, a year. And my only goal at that time was to get as much visibility for the project as possible – everything we did was out in the open.

And then 2014 we raised the A. 2015 comes by. And then in 2016, I knew that we were going to have to go out and raise a Series B round of funding for the company, to continue to work on things. And we still didn’t have the real clear delineation of how we would actually turn this into a business, beyond it just being a popular open source project.

And as I mentioned, in the summer of 2015, we offered support contracts as something that we hoped would materialize into actual revenue. But up until early 2016, I think we signed up maybe like one or two people to a support contract. Not enough to build a real business on.

So, basically in early 2016, I started talking to other open source founders, and everybody in the company at that time. And where I landed was, basically what we would do is, for future versions of InfluxDB, we would make high availability and scale-out clustering commercial, and closed source. And basically anything on a single server would be open source and licensed under the MIT license.

We kept that same line, that same delineation since I announced that in early March of 2016. But it’s definitely something we revisit periodically, just like say “okay, should we change where this line is drawn?” Generally, what we want to find out is how can we put more of our code into the open? How can we put more of our code into an MIT license codebase?

What I learned from that experience of writing that blog post and seeing the reaction in the community about it was – once you put something out in the open, it is incredibly hard to pull it back. People get really upset, deservedly so.

But the thing I tell people then, and still now, is that – if we hadn’t made that decision in 2016, all of the code that we developed in the open since then would not exist. Because we wouldn’t have a company. There’s no way that the company would still exist if we hadn’t done that.

Basically, as we do stuff now, essentially we still have the same drawing line – if it’s multi-server, then it’s closed. But, we periodically think, “Okay, is this something we can actually release in the open source area?” We still revisit that all the time.


Michael Schwartz: Pricing is one of the hardest things for tech entrepreneurship. I’m wondering if you struggled with pricing; how often you have to change your pricing over, let’s say, since you went to the open core model?

Paul Dix: We basically have two products.

We have the Enterprise product, which is on-premise software. And that’s always been licensed on a per-core, or per-server basis, which is very similar to like whole other database vendors license their software. That price, I think it’s changed once or twice since we released it. The first release of that product was in early September of 2016.

The other product is our cloud offering, which right now is only in AWS. You can actually spin it up in JCP as well – but that’s actually our on-premise version that you are spinning up.

With the cloud offering, we price based on the amount of storage you want and essentially the size of the servers that you’re going to be running, in the cluster that we run for you. Essentially what that is, it’s a single-tenant service, we spin up a new cluster for each person that comes in and signs up, and that’s on-prem Enterprise software but run as a service for people.

We repriced that once we launched it, we launched that mid April 2016. But what we’re doing right now is, we are actually in the process of creating InfluxDB 2.0.

InfluxDB 2.0 is almost like re-envisioning the platform, not just the database.

So the idea is the platform as a whole offers an API and a user interface for collecting data, defining collection rules, storing data, querying data, visualizing it in dashboards and that sort of stuff; also processing it, be it for ETL, or monitoring alerting, and that kind of stuff.

We deliver that in three different form-factors. Open source, which is a single server, and that’s MIT licensed. A cloud product, which for version 2, we are going to price it as a usage-based model: Bytes written into the API, bytes out of the API, number of API calls, compute time for queries like ad hoc queries, or for background processing, and storage hours.

It’s basically like 5 different pricing vectors. They’ll be familiar to anybody whose a customer of AWS, or JCP, or Azure. It’s basically a multi-tenant platform – you pay for usage, and you don’t have to worry ahead of time of like, “Oh, I need two VMs with this much memory, and this much CPU, and all this other stuff.”

The 2.0 offering is something, from an engineering perspective, we’ve had in process for a year and a half at this point, but the vision for the 2.0 cloud offering of being able to offer usage-based pricing is something that we’ve known we wanted to do for over two years.

Business Built Around Pricing?

Michael Schwartz: Sounds almost like you built the product around the business model.

Paul Dix: Because I’m an engineer, it’s hard for me to decouple the things, and also, like I said, the experienced early on, of trying to create the open source project, to make it popular – and then suddenly trying to figure out how to make a business out of it – made me very sensitive to the 2.0. version of thinking about everything as a whole.

Ultimately, like I said, all open source software development is subsidized. And the subsidy has to come from somewhere.

Either, it’s going to be a foundation, which pays for developers to work on things. Or it’s going to be other companies that fund it, they have their own successful business models and they have developers working on it. Or, it’s going to be a single business that creates a successful business around that project.

I think it’s useful in the open source software to think about the business at the same time as you’re thinking about what this software is going to be, how it’s going to be designed, and how you’re going to ship it to your users and then also to your customers.

Sales Process

Michael Schwartz: Talking little bit about sales: Are most of the sales leads inbound? I’m wondering about your experience, growing the sales team in the traditional sales process?

Paul Dix: Yes, most of the sales leads are inbound.

Most people who come to us, say they want to become a customer, started with the open source code, probably actually got it in production in some way, and they had been using it for a while by the time they come and talk to us.

But even within that, I would say there are two kinds of important distinctions between how software is sold, and we kind of have both in our environment, which, I think it’s becoming more common with open source vendors, but which 10 years ago it wasn’t.

Usually, you have what’s called an Enterprise sales model which is, you have expensive sales people, who are doing outbound sales motion, or even inbound sales motion, where you line up contracts, annual contracts, or whatever.

Or you have, what I call, like a self-serve business model, which is: Anybody can come to your website, they can sign up with a credit card, they can become a customer, and they can buy as they go and actually increase their usage over time. We actually have both.

The thing that has been shocking to me over the course of building this company is just how much friction there is in the Enterprise sales model. But it continues to be something that exists because many companies actually want to do business this way.


Michael Schwartz: Do you have any channels other than direct that account for a meaningful amount of sales?

Paul Dix: We are just now ramping up partnerships.

We do have a partnership with PTC ThingWorx for their IoT platform, where Influx is a key component of that. We’re having some customers come to us for that.

In April, we announced a big partnership with Google Cloud. Google Cloud is making a move to a big push to support open source technologies, and InfluxDB is one of their best in class solutions that GCPL offers as a full service.

They have this whole video with other open source vendors that they picked to partner with. We’ll have that launching later this year for our 2.0 products.

Cloud Strip Mining

Michael Schwartz: In the past, you expressed concern about the large cloud companies potentially being at odds with open source companies. I’m wondering if your concern is somewhat abated?

Paul Dix: No. It’s still a concern for me.

Some people will say MongoDB is no longer an open source company. They relicensed their code under the SSPL, which is not recognized by the OSI, so in theory MongoDB looks more like, what I call a “Freemium” software company. There’s a free product that you can use, which is the MongoDB community, and there’s a premium product.

The same goes for Elastic, for the parts of Elastic that they don’t have license under standard Apache 2 License. They’ve made a number of moves over the last couple of years to carve out pieces of their platform that are either not open source at all, or source available, but under licenses that essentially make it a non-open source thing.

Yes, those companies are thriving, absolutely, but the moves that they have made, with regards to their licensing, are basically direct responses to the threats that they see from cloud vendors.

By all back channel things I’ve heard, AWS makes more money off Elastic than Elastic does.

I think the tricky thing is when it comes to if you’re going to make a business out of open source software, and what you want to provide is a hosted service, your cloud vendors have a competitive advantage that you cannot possibly hope to get, which is economies of scale.

You cannot buy hosting cheaper than they can. You can’t buy hardware cheaper than they can. You can’t buy network bandwidth cheaper than they can.

So, they’re more than happy to essentially commoditize the software – commoditize the platform – so they can sell more and more hosting, which basically, like, if you want to get in the hosting business in a meaningful way, requires billions of dollars of upfront capital expense.

I think that continues to be a problem, and honestly, I think open core is still the best solution for that, which is: Keep some of your software closed-source, develop a service around it or develop it as on-premise Enterprise offering. And just make sure that what you have closed continues to be a big enough investment and competitively differentiated, so that even if one of those vendors decides to go after it, you still have some meaningful way to differentiate from that.

The truth is like, if Amazon, or Google, or whoever wants to come for you, there’s nothing you can do about it – they can outspend you. Guaranteed.

It’s just a matter of doing the best you can with the software you are delivering, and hopefully, the fact that you are the creator and the steward of the open source project gives you a little bit of an advantage in terms of creating service around it that is better, or at least preferable.

Innovation To Battle Cloud Giants

Michael Schwartz: Right. And I would hope innovation, also. That as a creator, you have an advantage of releasing new features, and keeping ahead of them.

Paul Dix: Right, absolutely.

Again, this is another question, I think it raises another question essentially, which is: Once infrastructure software gets really mature, how much innovation is there in it? How much people just wanting it to be stable in terms of API and stuff like that?

As you get more and more mature, maybe the innovation curve, or at least a feature delivery curve, it becomes less important, so it becomes easier for a larger vendor to keep up with what you’re doing.

Pay For Old Versions?

Michael Schwartz: You want to run by one business model that I heard of last week in an interview – which I’m embarrassed to say I have never thought of it, but it’s pretty obvious when somebody said it to me.

But the idea was basically that older versions would not be updated unless you had a commercial license. So if you want to update the open source, you have to go to the latest version.

So Java, for example, if you want to use Java 1.4, you need a license; or you need to pay Oracle. I’m wondering what you think about that idea?

Paul Dix: On some level, this is what Red Hat does. It’s kind of their thing. Even though they don’t have closed software, if it’s all about supporting older versions.

I think, as a developer, it’s painful to support those older versions. That’s why there’s maybe a business for it, but again, it’s still fairly limiting.

I think, also, if your software is being delivered as a service, there is less value in that, because you kind of punt on that concern to whoever it is you’re paying to deliver that service. Honestly, to me, that doesn’t seem like a very good model.

Advice For Startups

Michael Schwartz: Last question. I’m sure you’ve had a couple of really interesting years starting the company, and I’m wondering if you have any advice for entrepreneurs who are about to embark on a similar adventure?

Paul Dix: I think it is pretty important to come up with a bigger vision in terms of what you want to do fairly early on.

I know I’m saying this even though when I first started this company, we ended up changing that.

I’ll stick with open source because it’s easier there, which is, if you’re going to start a business around open source software, I think it’s important in the very beginning to actually develop a point of view behind what is commercial and what is open.

And basically, I would say, it’s worth thinking about that as part of your product design. Making sure that the product design actually matches well with how you plan to actually turn it into a business.

Michael Schwartz: Okay. That was fantastic. Paul, thank you so much for your time today.

Paul Dix: Sure, no problem. Thank you for having me.

Michael Schwartz: And thanks to the InfluxDB team for helping to organize this interview.

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

Music from Broke For Free and Chris Zabriskie.

Audio editing by Ines Cetenji.

Production assistance and transcription by Natalie Lowe.

Operational support from William Lowe.

Follow us on Twitter, our handle is @fosspodcast.

Next week, we’ll chat with Corey Scobee, Senior VP of Product and Engineering at Chef.

Until then, thanks for listening!

Episode 27: Alfresco – Digital Business Platform with John Newton

John Newton is the Founder and CTO of Alfresco Software, an open source digital business platform specializing in ECM and BPM software. In this episode, John discusses community building, the “open core” business model, and his perspective on the atmosphere surrounding pure play open source businesses in the market today.



Michael Schwartz: Welcome back, Underdogs! You’re listening to the podcast where we document the business models of successful open source companies.

It’s episode 27, and we’re lucky to have John Newton, one of the founders of Alfresco.

Alfresco was one of the first vendors to perfect the commercial open source business model.

It’s one of the leaders in document management, a segment that’s undergone massive change in the 15 years or so since it started.

John has a deep perspective on open source and entrepreneurship – he also founded Documentum, a commercial software platform in the same segment.

So, enough of me blabbering, let’s just cut to the tape.

John, thank you so much for joining us today.

John Newton: Yeah, it’s nice to be here.


Michael Schwartz: You founded Alfresco 14 years ago with John Powell. What was the original idea, and why do you think the timing was right?

John Newton: Both he and I were looking at new businesses to start, and my background was in enterprise content management, which I have been in since 1990.

I was the Co-Founder of Documentum, and in that time the industry went from nothing to about 4 – 5 billion dollars at that point.

And what we had seen was that there were a lot of business models, and some were working, some were not. We both lived in Europe, and we’re trying to figure out what would work from Europe – and it looked like open source would work.

We saw a lot of successful open source projects get started like Linux, and JBoss, and MySQL, that all came out of Europe by Europeans.

And so my background, being in enterprise content management, seemed like, “Hey there’s nothing like Documentum, FileNet, and OpenText, or even a SharePoint in open source – and someone’s going to do it, might as well be us.”

So, that got it started probably at a really good time. The first wave of open source applications coming out, I think our timing was actually pretty good.

Business Segments

Michael Schwartz: Alfresco has a few products and services – what are the most important business units from a revenue perspective, and which units do you expect to grow the most in the future?

John Newton: Traditionally, most of our revenue has come from what is now known as content services. As content is created and used in many different areas, the market that was Enterprise content management has now become content services. We added process services as well, and that grew very rapidly.

But I think it’s all the bits coming together – the content services, the process services, the search services, the governance services – all coming together to solve a lot of digital transformation challenges.

Companies are looking to serve their customers more effectively in the digital world, and all those things working together will actually become the most important. So, I think selling them all together in what we call the Digital Business Platform will be the fastest-growing and ultimately become the biggest.

But we still sell content services, and also process services, governance services, sometimes stand alone, and they do well. But I think that’s where the growth is going to be.

Cloud V. On-Prem

Michael Schwartz: How about in cloud-delivered vs. on-premise?

John Newton: When you look at the industries that we’re involved in, they tend to be highly regulated.

This is an area that has been slower to adopt the cloud, but there’s been a real sea-change in how regulated industries are starting to look at the cloud, and the benefits of the cloud.

So, still the majority of our customers are on-premise, but increasingly, a lot of them are playing on AWS and Microsoft Azure, some on Google Cloud as well. And I’m sure ultimately those will become the dominant platforms upon which people will deploy these digital services.

But it’s a real mix right now.

And actually that helps with open source, because when people try open source, they tend to do it on their own local systems, or perhaps they’ll deploy it on something like an AWS instance, or something like that.

So, it’s good to be flexible and how it gets deployed, and how it gets used.


Michael Schwartz: Maybe I misspoke. I said cloud but I think what I meant was as-a-service. Does Alfresco offer a hosted version? How has that been, and how’s that growing?

John Newton: Yes – we have offered a content services as-a-service, and it’s something that we are expanding on this coming year.

Taking some of the benefits of on-premise, and isolated instances, and providing the level of security and control that people expect from on-premise, but making it available as-a-service. So, you get to keep all the keys, you keep control of where the content is stored, no one else can see how your indexes are created, you can control all aspects of security – which is important in the industries I mentioned, the regulated industries that we’re dealing with.

So it’s a smaller portion of our business, but one that we expect to grow pretty rapidly in the next couple of years.

Market Segmentation

Michael Schwartz: Alfresco must appeal to a wide array of organizations. Do you segment the market in any way?

John Newton: Yeah, we tend to segment the market, primarily along vertical lines.

You see how Alfresco got adopted over time. Very rapidly, the industries that liked open source and started to pick it up pretty quickly were governments, particularly over here in Europe. Also financial services – banks love technology, they like to tinker with technology and just enjoy open source, in terms of building solutions on top of it.

And then the third that really grew rapidly early on was the high-tech manufacturing, where there tends to be more of an engineering mindset. So, being able to see the source code, having the openness and control over your destiny with this product, were very important.

We have taken and grown that verticalization – starting to look at more specific use cases in each of those and providing those use cases. And so we’re doing more with government than ever before. Especially when we started to build in some of the records management capabilities that were expected of the US government – that really opened up the doors for us to sell it to federal, as well as some state, local, and European organizations.

Over time, the interest in financial services, and open source, and also the freedom it gives, not being locked into any particular vendor, also became more important in areas such as insurance, that were pretty conservative when we first got started, but are actually doing some of the most interesting digital transformations that are going on at the moment.

You see more insurances as an extension of that financial services. And then also business services – anything from payroll services, to marketing services. Logistics, event services, things like that have also brought on open source as well.

Those industries, along with high-tech manufacturing, account for probably more than half, maybe more than 60% of our revenue.

And then there’s a long tail after that, but verticalization is the main way that we segment it.

We do some segmentation along the size of companies in terms of how we sell this in our sales organization. But we were sort of surprised. We were thinking that early on, when we had brought out an open source model, it’ll be small and medium-sized businesses that would adopt Alfresco. And it turned out to be actually the largest companies started adopting open source and adopting Alfresco.

So, it was a pleasant surprise because it tended to bring along bigger deals as well. But that isn’t the primary way that we look at it, we want to look at it in terms of the use cases and solving specific problems.

And looking at it from a vertical perspective, it ends up being the best way to do that.

Value Proposition

Michael Schwartz: Has the value proposition of Alfresco changed over time?

John Newton: In some ways, not that much, but in some ways, considerably.

Early on it was basic document management that brought people to Alfresco.

I think experimentation with open source actually widened out the number of different types of use cases. You saw a wide variety of things being done.

And also the industry – I’ve been in it since 1990 – in some ways, it is a lot of the same types of industries that need this level of control of their most important content, and most important information. And you’ll see some of the same types of services.

But we were seeing ourselves injected in a lot of digital processes that when we started simply did not exist.

In that time frame, we’ve seen massive globalization. So things like logistics and coordination across multiple geographies become a new value proposition that probably wasn’t quite as important in 2005 as it is today.

To see the digital value chain and the digital supply chain being just as important as the physical supply chain in terms of distributing information for things like financial services.

But even in manufacturing as well, the digital artifacts will be sent ahead – in terms of specifications, digital assets, and coordination information, logistics – well ahead of the actual physical goods. And so it’s becoming part of the supply chain as well.

I think in a lot of ways it has changed quite a bit, but some of those standard use cases of: Let’s get control of our contracts; let’s get control of our web content; let’s get control of some of the records and specifications, and things like that, is still very important, still very valuable for companies.

It’s often some of the most important intellectual property, and most important information that the company has, and needs to safekeep.

Community Building

Michael Schwartz: So, as I understand it, you started the company and the open source project roughly at the same time.

John Newton: Yes.

Michael Schwartz: How long did it take for the community to achieve critical mass?

John Newton: Actually a lot faster than we had expected.

How we got started was, it started as a hypothesis. I have a team here in the UK, I knew what we could build. And the question was could we build and distribute it faster using an open source model?

We tested it out on people who might know, so people who were prominent in open source at the time. Whether it’s, I think it was Bob Bickel at JBoss, and Mark Fleury, David Axmark, and Martin Micko at MySQL. Many people, as well as some leading CIOs I knew from previous roles that I had. Talking to some of the CIO’s of some of the banks, it seemed like, yeah, there’s an opportunity.

I asked one of those guys, “If we got, say a hundred thousand downloads by the end of this year, would that be good?” They said, “Yeah, that’d be pretty good.”

So, we went out, and we just built this thing. We just, hell for leather, to build out a demo and get it out.

And we tried to time it around a major industry event, which was JavaOne at the time. You know, it was just good confluence of interest in open source, an event where we could launch this thing. And also my background as well, being from traditional Enterprise software, being the Co-Founder of Documentum, meant that I had kind of instant credibility in the space.

So I got on the cover of InformationWeek, and that just launched everything.

We hit a hundred thousand in like a week, or something like that. We did well over a million, I don’t remember exactly how many we had by the end of the year.

We started in January 2015, well, more or less around the beginning of the year. And by the end of the year had about a million downloads.

So, from the launch of the first beta to critical mass on the community, from the release of a product was probably about six months, we got critical mass, if not sooner.

And then in terms of actual sales, starting to sell an Enterprise version, there was some experimentation on that – what works, what doesn’t work. We were starting to get our first sales early in the first year, and we were doing pretty well in the next full year of existence of Alfresco.

So, getting that first sale at the beginning of the new year, and then by the end of the year, I think we had about a million and a half, and it was just a hockey stick from there.

Community Contribution

Michael Schwartz: How would you say that the open source community has materially contributed to Alfresco, the company?

John Newton: Very early on, we learned a lot from existing commercial, open source companies in terms of what to expect, in terms of contributions.

I think coming in where there had been no open source alternative at that point, opened up just a flurry of innovation from people who like the area. Again, it was like a four or five billion dollar industry with people building solutions around it, and just wanting certain features and just adding and contributing to it.

Still, by far, most of the contributions were from our company.

But over time, we started getting some from some of our partners as key participants in the open source community. We got some important extensions, important new core capabilities as well, in terms of adding new intelligence into the system, or transforms, or various components like that.

Over time, the community itself started to organize some of its own events, and we’ve been quite happy to participate in those events, with a bit of a more independent feel, in terms of what we do, and to protect the integrity of the open source community. So, it’s called the Alfresco Order of the Bee.

They’ll have events around the world, and in some really interesting places sometimes. But they’re very important core part of who Alfresco is, and the Alfresco community.

Open Core

Michael Schwartz: Alfresco is probably one of the first companies to define an open core business model. Did you have to tweak or adjust that strategy?

John Newton:Yeah, I think we experimented with the license, that’s been an important part of how you build and deliver an open core model.

We experimented with LGPL. Then went to a modified Mozilla license. Then went to GPL, and then finally settled on LGPL as well.

As part of that, we had to carefully choose what elements we were going to be Enterprise.

So, yeah, it’s an open core, but it’s a pretty big core as well. It was really important for us for the people who download the product to have something useful, to have something successful that they can work with. And that, on its own, should be able to do something of good value.

And just putting out a demoware, and open source as demoware, is not really going to get you what you want in terms of a thriving successful community. So, what we ended up doing after a few experiments of what would work, what wouldn’t work.

We experimented with just pure security being an Enterprise feature – that didn’t really cut it. So, we made that community, but maybe degrees of security, degrees of deployment, degrees of configurability, are some of those things that you could do.

And so, what we ended up doing is coming up with a set of principles as to what we felt was fair to be able to monetize as opposed to making that line arbitrary.

It’s almost like a social contract between us in the community. Like – you’re getting software, in fact, more than 90% of what’s being delivered is being delivered for free as part of the community. But it’s that other 5 – 10% that’s really important for us to be able to have a sustainable business model to continue feeding into the development of Alfresco.

That open core model did evolve, and I think it’s been pretty successful in terms of how we’ve approached it.

Some of the capabilities – particularly when you get into the Cloud, how you deploy in the Cloud, how you look at Cloud native capabilities – things are changing.

Also, some of the business models of the components that we use have changed as well in terms of search, and databases, and things like that. So we need to be able to adapt to those more effectively.

And if you do it from a principled point of view, to say, “Here are the principles by which we are living,” then I think people tend to buy into that, and it makes for a more successful open core model.

Updates to Old Versions

Michael Schwartz: I read that Alfresco only releases bug fixes for the current Community Edition. I thought that was a really interesting nuance.

Has that been an effective incentive to get customers to upgrade to an Enterprise subscription?

John Newton: Yeah. I think for a lot of professional, commercial open source companies – my understanding is that it’s a pretty common model.

Customers tend to want to be able to live on a stable version for, sometimes for years. So that’s part of the incentive, yes, to be able to move over.

As far as up-keeping older versions of open source, I think that tends to be the way most open source projects work as well. We’re not going to go back and fix that in the older version, move onto the new version.

And it’s ever onward, ever forward for most open source projects.

That stability that large Enterprises in particular want, that is part of the incentive, is to buy into that. Also things like indemnity on the software, and warranties on the software. So that is probably that the majority of what people buy into. Perhaps even more so than some of the Enterprise features.

Sales and Marketing

Michael Schwartz: Can you talk a little bit about sales and marketing – was it initially mostly inbound? And have you evolved to a more traditional Enterprise sales organization?

John Newton: When we started, it was almost entirely all inbound, so your open source community is your sales force.

They’re going out, they are trying it, and they’re proving for themselves that it can solve their problem. And then you just create a low-friction sales process that – if you like it, and you want to buy into it – you just call up, sometimes you just email in, and you’re negotiating, and you get the contract done.

We were doing anything up to six figures with an entirely inbound process, and sales people who were not heavy-duty enterprise sales people as part of it. But when you start getting top-tier banks and also major government agencies, and you’re getting on the radar of the major software vendors, non-open source software vendors, then the process can become longer but also much bigger.

You know, the whole concept of land and expand. The inbound model is just land, and if you’re lucky, it’s land, land, land inside of an organization. But if you really want to get these things joined up and start to move up as part of the CIO agenda, then you have to have a proper enterprise sales force.

Trained Enterprise sales people as well are new to open source. They may be very familiar with your software and how things are done, but the whole idea of giving software away is kind of new to them, and something they have to get their head around. And generally, they do get their head around it. Sometimes, there’s a little bit of friction between Enterprise sales and the ommunity.

In the end, it’s the community that’s feeding a lot of those Enterprise sales, whether directly or indirectly, because it could have been a project earlier on using the open source model that may have gotten the whole ball rolling – even if the economic buyer was not even aware that their technical people had downloaded it at some point. But those are the people who will be involved in those sorts of conversations.

So, a lot of the time, at that scale, the Enterprise sales end up being very different than your typical open source engagement, even still fact that it is open source is important for those customers in banking, insurance, and government.

When you ask them why did you buy Alfresco, often the number one thing that they say is because it was open source.

Partner Channel

Michael Schwartz: It seems like Alfresco has a really strong partner network, and I’m wondering if you can talk about what percentage of, let’s say, business comes through the partner channel, and how you see the partner channel growing?

John Newton: The difference between the partner channel and the direct channel is sometimes regional.

Even in a non-open source model, I’ve seen it, where the European sales process can often be more partner-lead than the US, which might be more direct.

I think it’s the behavior of everybody involved – the customer, the sales organization, and the partners – just different mindsets and different ways of looking at problems; different ways of being solution-oriented – who initiates it: Is it the partner is it the customer?

Traditionally, it’s been sort of a 50/50 mix between the two, a bit more direct in the US, and a bit more partner-oriented in Europe. And regardless, partners will probably still be important as part of the sale overall.

Sometimes it’s just a matter of who takes the paper as opposed to who’s leading the sale.

Demand is sometimes created by the partners. They have a solution, they take the solution in, and they can bring it in sometimes as a cookie-cutter into different parts of a similar industry. And that’s great, that works for us quite well.

Sometimes, we are the ones doing the demand generation, and then we do the direct sale, and we’ll bring a partner in for implementation if the customer isn’t capable of doing that.

It’s all part of the ecosystem and all part of the sales process.

We try to treat our partner channel just like our sales channel – they’re involved in our sales kickoffs, they get the same information, and the same rah-rah events. And they’re sort of part of the family as well, just as much as our employees are sometimes.

Impact of PE Buyout

Michael Schwartz: So, last year, Alfresco was acquired by a private equity fund. I’m wondering if that’s resulted in any pressure to tweak the open source strategy?

John Newton: Not at all. It’s really sort of a substitution of investors more than anything else.

We were funded using the traditional venture capital model. We had four rounds of funding. There’s just the time limit on the venture capital funds in terms of putting their funds to work.

We got a new set of investors, and the lead investor from T.H. Lee happens to have a very strong software background, what has been a customer of Alfresco in the past, and just understands exactly the importance of both the open source model as well as what our objectives are.

So, this is still very much a growth opportunity.

We’ve grown very nicely in the first year that we’ve been owned by T.H. Lee. And I would say it’s a good combination of helpfulness and sometimes hands-off, sometimes hands-on control of some of the things that were going on, but very supportive as well.

So, it’s not like trying to squeeze blood out of a stone, quite the opposite. We are growing, we are profitable, very profitable. We are having a nice combination between those two factors that are important for us to sustain our business.

Challenges For open source Companies

Michael Schwartz: In general, just to go off-topic of Alfresco for a moment: What do you think are the biggest challenges facing pure-play open source startups today?

John Newton: Well, I’m a little bit concerned about the economic environment right now.

If you’re starting up right now, I hope you are well-funded. There are venture capitalists here in London who are saying get a hold of 18 months worth of runway.

I think economic headwinds, if we still have trade friction around the world, are going to take their toll.

There’s always going to be an opportunity for open source startups that will help cut costs. In fact, they will absolutely thrive in a tough economic environment. However, when a recession first hits, which it’s got to at some point – I’m not saying it is right now or that’s going to in the next year or even two years, but at some point it will hit – and any young company is likely to hit economic headwinds in the medium-term.

So, just be prepared for that.

But if you are in a position that your value proposition is really clear, you can help cut costs, then that always does well in tough economic times. Especially if you are a cost-effective technology replacement for something that exists that’s very expensive. That’s probably the biggest one.

Also, established players are far more familiar with open source now. They have their arguments lined up, but then also customers are more savvy, in terms of what open source is, and more understanding in what it is – in fact, actually really want open source.

But there’s an interesting sales playbook that they use against open source, they’re just not quite as effective as it was before.

And then, also, just really look out for crowded marketplaces. Don’t go where there’s lots of people already.

One thing about open source right now, it’s been such a successful model. You just see a lot of people in the same space, don’t go in the same space, go where there’s an opportunity to differentiate and create real value that no one else is creating overall.

That would be my recommendation right now.

Advice For Entrepreneurs

Michael Schwartz: You started two companies. And I’m wondering, do you have any closing advice for entrepreneurs – the people versus the companies – about entrepreneurship specifically with open source, or just in general, even?

John Newton: Well, what I’ve learned is life-work balance is important.

My first company, I just overdid it on the work side, and I don’t necessarily recommend it. In fact, my very first company was Ingress, and I definitely overdid it there too. Take time for your family, take time to step back and reflect, and it’ll be a much more enjoyable ride.

It is a marathon, it’s not a sprint. So in order to have the staying power, work-life balance has to come into that overall.

In terms of open source, I would say what’s really important is to have a passion for the technology that you’re working with. You can have a passion for open source, but if you don’t have a passion for the technology you are working with, it’s going to get old pretty soon.

Just do what you feel interested in, and what gets you really interested. There’s going to be lots of times where you just can’t wait to get up in the morning to work on that thing or solve that problem and just get going.

When you have that passion, it just gives you the energy to get stuff done. You will need the energy to get that stuff done.

Those are probably the two most important bits that I could probably give right now.


Michael Schwartz: That was really fantastic. Thanks so much, John, for sharing your insights.

John Newton: Thank you very much, it’s been fun.

Michael Schwartz:Thanks to the Alfresco team for helping to organize the interview.

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

Music from Broke For Free and Chris Zabriskie.

Audio editing by Ines Cetenji.

Production assistance and transcription by Natalie Lowe.

Operational support from William Lowe.

Follow us on Twitter, our handle is @fosspodcast.

Next week, we interview Paul Dix, the Founder of InfluxDB.

Until then, thanks for listening.

Episode 26: GitLab – DevOps Lifecycle Tool with Sytse Sijbrandij

Syste “Sid” Sijbrandij is the Co-founder and CEO of GitLab, a DevOps lifecycle tool. In this episode, Syste discusses product pricing and their approach to hiring a globally-dispersed team.



Michael Schwartz: Welcome back, and thanks for checking into Open Source Underdogs.

We have an epic interview this week with Sid Sijbrandij, Co-Founder of GitLab.

GitLab provides an on-premise platform for code management and continuous integration. In some ways, their story proves you don’t always need to be first. GitLab didn’t invent Git, Linus Torvalds did that in 2005. GitLab was started well after GitHub.

Sid has some great advice for open source startups. I don’t want to give it away, so let’s just jump in.

Origin Story

Michael Schwartz: Sid, thank you so much for joining our podcast today.

Sid Sijbrandij: Thanks for having me.

Michael Schwartz: So, how did GitLab get started?

Sid Sijbrandij: Yes, so GitLab got started by my Co-Founder Dmitriy.

Two things he wanted to improve in life: He didn’t have running water and he didn’t have great collaboration software at work.

He didn’t have budget to pay for either of them, so he did what he could do, without spending any money, and he built better collaboration software.

300 people joined him in contributing to that, and I saw it when GitLab was one year old, and there were 300 people contributing. I thought, this is great. All the software I use is open source, so if anything should be open source, it should be the software I collaborate with, that should be open to contributions.

I started GitLab.com – I thought a SaaS model made a lot of sense. I sent Dmitriy an email saying “Hey Dmitriy, I’m going to work on this, if you’re not going to be part of it. I hope you don’t mind.

And he sent back, “No, it’s fine. It’s open source, just go for it. I hope you make GitLab more popular.” I thought that was pretty open-minded of him.

A year later, I learned a few things. First of all, most big Enterprises are self-hosting GitLab, and they had a big need for more features.

Another thing that happened was, Dimitry tweeted out “I want to work on GitLab full time.”

So I sent him an email like, “Hey – can I hire you to pay you to make those features that customers want?”

We agreed on a price, I went to the local Western Union money station in the Netherlands, and I said I wanted to wire some money to Ukraine. They asked me, “Do you know this person, or is this someone you met over the internet?” because there were a lot of scams going on.

I took the risk, made that wire, and we were in business. We started making those features that people asked for. Dmitriy also got around a couple years ago.


Michael Schwartz: GitLab is more than a version control tool – it’s a single application for the entire DevOps lifecycle. Why did you evolve the product in this direction?

Sid Sijbrandij: Dmitriy never wanted to upgrade another Jenkins server again, so he built his own CI system.

That was kind of a side project, it wasn’t official GitLab project. We published source, and we had to improve it a bit for our own needs, and then people started contributing to that too.

And at a certain point, we got an amazing contribution from Camille in Poland, and we said, “This is amazing, we’ll make your version the official version from now on. And by the way, do you want to work at GitLab?”

And we hired him, and after a couple of months, he said to Dmitriy “Look, I think we should integrate the two projects. I think we should make it a single application.”

Dmitriy pointed out how it was wrong because everything in the marketplace, it’s separate, like there was not a single version control tool that also had CI. He disagreed, said it would be better, and he convinced Dmitriy who came to me, I also pointed out that we should have many sharp tools that you could compose together.

He said, “Well, if you don’t believe it’s better for the user, at least believe it’s less work.” Efficiency is one of our values, so we did it, and it turns out he was totally right – it was a much better user experience, which was kind of intuitive to us.

We integrated the two applications, to get it really tightly, we had like custom APIs to make them work together. But it was still so much better if you didn’t have to switch to another user interface, if you had a single-data model and could service all the relevant information. We realized that we discovered something, a secret, not in the sense that we wouldn’t tell people but in the sense that it wouldn’t be intuitive to them.

We started adding more and more features, and today, GitLab goes all the way from planning what you want to do to the point that monitoring that, securing and defending that, and managing that entire life cycle.

And it’s one of the top reasons that people like to use GitLab over stringing together 10 different DevOps tools, and then having to maintain all the integrations.

What is Open V. Commercial?

Michael Schwartz: As I understand it, GitLab is open core. How do you decide which features to make commercial?

Sid Sijbrandij: It is very hard for us to figure that out. We first tried to kind of charge for features that we thought were used by bigger companies, but that’s not a really clear distinction.

So, we settled on something we called buyer-based open core, where we have four different roles in companies that care about features, they are the individual contributors. And if they care about a feature most, we make it open source. That makes it very easy to contribute back.

Then, if it’s managers, directors, or executives, we place it in one of our price plans, going from the lower tier to the higher tier.

If an executive wants a feature, for example something compliance-based, it’s the most expensive price per seed. If a manager wants it, for example, to increase the performance of the GitLab instance, it’s the lowest price per seed.

How To Distribute the Bits

Michael Schwartz: GitLab Community Edition is MIT licensed – how do you actually publish and distribute the commercial version? And what’s the upgrade path to go from the Community version to a paid version?

Sid Sijbrandij: We distribute two variants of GitLab, Community Edition and Enterprise Edition – both are very similar, both are available, and both got like all the security updates. By default, we have people download the Enterprise Edition, and you can use that without a license key or anything else.

And then, you just get all the open source features. The advantage of that is that if people want to upgrade, they don’t have to do a reinstall, but they can just give it a license key and unlock all those additional features.


Michael Schwartz: Who are the customers of GitLab?

Sid Sijbrandij: It is a very wide variety of users of GitLab. There’s over 100,000 organizations that use GitLab.

The majority use the open source version, so they are users but not customers. Many customers range from people that buy a single seed all the way to Fortune 500 companies that use it with tens of thousands of people.

Market Segmentation

Michael Schwartz: Do you segment the market at all? It’s such a broad horizontal market, I’m just wondering if there’s any way that you break up the customers?

Sid Sijbrandij: Yeah, for sure.

For the open source, we have a developer marketing team that focuses on serving the needs of our users and to make it more popular. At the bottom of the pyramid, we got self-serve, where we do a lot of automated programs. We have people mostly help themselves by our website, or our pricing is public.

For the middle of the market, we are a bit more active. We do reach out to people, we have kind of inside sales representatives that help the customer.

At the top of that market, it’s a classic Enterprise sales motion, where you have strategic account leaders that visit the customer together with a solution architect; we have technical account managers to ensure that they are successful with the implementation.

Evolution of Value Proposition

Michael Schwartz: I imagine the initial value proposition was something like GitHub but deployed on your… or self-hosted, let’s say. Has the value proposition for GitLab evolved over time?

Sid Sijbrandij: We started making features that people really needed. For example, things like protected branches, and now protected environments, were first introduced in GitLab.

We also try to cater to the organizational complexity. For example, GitLab has subgroups, so that you can make kind of a hierarchy of projects, and have better communication and control throughout the company.

Apart from the open source, or apart from the version control, we also started doing other things, the CI, but also planning tools. We now have like portfolio management, packaging, for example. We have container registry as part of GitLab, but also configuration, continuous deployment, and monitoring. We expanded the scope of the product as well.

It’s always important to, in any case, you can also add to do that. What’s helping is that not only are we thinking of stuff ourselves, we also got open issue tracker, so people can contribute ideas, and we also get a lot of code from the wider community.

Last release, last month – more than 200 features came from the wider community that was shipped.

Evolution of Pricing

Michael Schwartz: One of the biggest challenges for any open source company is pricing. If you price wrong, you end up giving away too much value. If you price too much, you might price out an important segment of the market. What process did you use to figure out how to find the right price points?

Sid Sijbrandij: I did the classic thing that a technical founder does, and I priced too low.

So, our first Enterprise customer was using GitLab with thousands of users, they were prepared to pay tens and tens of thousands of dollars reserved for that. I priced it at $1500 for all the users of a Fortune 1 company. And so that was a big mistake.

Over time, we got better at it.

Our pricing was so off that in the beginning, we doubled the pricing, and all of our customers said, “This is fine – you were really too low, but just don’t do this again.”

So then we started thinking what to do next. And first we tried kind of price features – so we had 15 different features that were all priced separately. That tended to be very cumbersome to sell and to buy for the customer.

Then we switched to a pretty classic “good-better-best model,” and there’s a pretty steep change between the different plans: So our lowest plan is $4 per user per month, and our highest plan is $99 per user per month.

First we had the, kind of, the “good plan.” We introduced a better plan at a five times higher price. And in the beginning it was like, “Well, this is too expensive,” but over time we were able to add more features to it. And then we did the same thing again while we introduced a new tier, at five times higher price.

In the beginning it was too expensive, and we had to discount. But over time, we were able to add more features, and add more value to it. And over time, we were able to do it with less discounting. We have already started seeing that, where we’re now selling that at full price.

More On Pricing

Michael Schwartz: How many times per year do you tweak your pricing?

Sid Sijbrandij: So far, we haven’t done that. It’s a good business practice, I think, to adjust your prices, for at least inflation, once a year.

For us, because there’s a 25x difference between our lowest and the highest tier, the focus has been to move people up to higher-price tiers.

Michael Schwartz: I see. So, your pricing has sort of stabilized. Once you figured it out, you were able to sort of stabilize pricing, and you haven’t had to tweak it that much.

Sid Sijbrandij: Yeah, we tweaked it by introducing new tiers. And what’s really important to our customers is we didn’t take any features away from the existing tiers.

So if they paid for something, we didn’t change the pricing on them, apart from that one-time doubling of the pricing. But after that, we kept that stable, and we focused on convincing customers that there was value in moving to a higher-price tier, with more features, and functionality, and support.


Michael Schwartz: So, changing gears a little bit, I’m wondering about partnerships – were there any partners to GitLab that were materially helpful for building the business?

Sid Sijbrandij: I think in the beginning, it is very, very hard to partner because you’re so small. It can lead to a lot of wasted time.

For us, that changed after GitHub got acquired by Microsoft. And now other kind of platform partners, people that have Cloud or Kubernetes distributions, see the risk that if people stay on GitHub, that Microsoft and Azure are going to be very, very close to that customer.

So now we’re partnering with partners like AWS, GCP, VMware, and RedHat, to make sure that if people have a Kubernetes cluster, that we recommend the GitLab to them in order to deploy their applications there.

Community Cheerleading

Michael Schwartz: How have you energized the community to such an extent that you’re able to generate such a great amount of contribution?

Sid Sijbrandij: In the first place we’re really lucky, because we make a product that is used by developers, by security people, by operations people – and those people tend to be proficient at coding, so for us, it’s easier to get those contributions.

But as GitLab grows as a product, it’s harder and harder for people to see where they can contribute. So we label certain issues with accepting merge requests to say, “Hey, consider contributing here.”

People are free to contribute anywhere they want, and then when they do so, we have merge request coaches that help them get over the finish line.

Because sometimes the code is there, but it’s not according to the coding guidelines; or they have the code, but they haven’t written tests; or they have code and tests, but they haven’t written the documentation. And those merge requests coaches help with doing that.

We also make sure to kind of flag the contributions, especially first-time contributions that make sure our product managers are aware, and that we kind of take action on them in a
response, in an appropriate amount of time to the contribution. And then when it gets merged, we send them a thank you gift, just a small token of our appreciation for the contributions.

We also do regular hackathons.

I want to shout out to Ray – Ray is kind of like coordinating this effort. In the last six months, we’ve seen the number of contributions double from about 100 to about 200 every month.

So just being receptive and having a program around it has been a major improvement for increasing the number of contributions.

When to Open Source Software

Michael Schwartz: Do you have any thoughts about what type of software should be open source, and what type of software should be commercially licensed?

Sid Sijbrandij: Well, first of all, GitLab is open core, so we’re doing both.

But I think open source makes sense if you’re making something that is foundational to a lot of other things. If almost everyone in the world needs that, it makes a lot of sense.

Almost everyone in the world needs a database. Almost everyone in the world needs great DevOp software, like GitLab. So I think projects that are going to be used by so many people, then open source works.

I think when you make something that’s going to be very much aimed at a specific vertical, let’s say biotech, and the users of the software are unlikely to contribute back – it sometimes makes more sense to make something proprietary.

What you get with open source is that you create a ton more value because you get a ton more usage – but you can charge less relative than proprietary variance.

So you’ve got to make sure that increase in distribution that open source gets you will be so big that it compensates for, kind of, a lower take-rate or capture-rate in the form of pricing for your software.

Breadth of Depth

Michael Schwartz: I was reading the GitLab company handbook, which is quite extensive, and quite transparent. And in your strategy section, you mentioned that your competitor started before you got more capital, and that you needed to focus on breadth over depth. I was wondering what exactly does that mean?

Sid Sijbrandij: Thanks for asking that question. We have an amazing community that contributes back a lot of improvements to GitLab; and those tend to be things that are features that are missing within a specific stage.

So, we introduced a new monitoring stage, and hopefully at some point it becomes like interesting enough for people to start using it, and then they miss a certain thing, and they’ll add to it. What we haven’t seen from the wider community is biting off more scope.

When we had version control, the community contributed to that, but they didn’t add CI, we had to add CI. Once we had CI, the community contributed to that, but they didn’t add packaging. And the same story again for all of those at different stages.

That’s because, if you create a new stage, it takes a lot of coordination. It takes, like, working the user interface; it takes kind of fundamental architectural changes; it takes a deeper understanding of the product.

And to do that, it’s a full-time job. To make such big changes, you have to be well-versed, and it takes a team of people to do that. And someone making a contribution is unlikely to have that much time and that big of a team to make that change.

So, we as a company, want to focus on increasing the breadth of the product, biting off new scope, going into things that haven’t been there before. Then, the wider community helps us to add depth to it.

We want to till the land and then make sure it’s fertile, so that the wider community can grow things on it

Remote Workforce

Michael Schwartz: GitLab is sort of well known for being having a remote-only workforce. And I’m curious if you could share some of the lessons learned about pursuing that strategy for building the team?

Sid Sijbrandij: We’re an all-remote team, we have now 650 people across more than 50 countries. It’s been amazing that we’ve been able to hire people, in like 90% of the cases. Normally, you’re constrained to the places where your offices are. And at GitLab, we hire people irrespective of where they are.

Today, we got someone who moved from our Support team to our People Ops team. She lives in Kenya, and she mentioned that she’s regularly late for airplanes, which was a fun fact. We see people from all kinds of places all over the world, and because we don’t have a headquarters, nobody is, like, in a satellite office. Everyone is on an equal playing field. And we did that from the beginning to be on the same level as the wider community.

We work in our open issue tracker, so you can see the real work going on, all kinds of things, but also like a marketing and finance issue trackers – how we run the company. Not everything can be public but a lot of things are public, and you mentioned the handbook is over 3,000 pages with all of our processes.

Regarding hiring, it’s a pretty conventional part of our process. There’s different interviews, it’s all done over video – unless you are local to someone, you can meet up if you want – but most of the time, it happens over video. We make sure that people can get a good feel of the company before they join, so you kind of know what you’re getting into.

We recently hired Mike Pyle, our new VP of Enterprise Sales, and we said afterwards “Zero surprises, like I was completely aware of what I was getting into.”

We like to do it that way, and that way we can retain people longer.

What If GitLab Changed License To Commercial

Michael Schwartz: Here’s sort of a question from left field… If you made GitLab commercial tomorrow, do you think that it would negatively affect the business?

Sid Sijbrandij: I assume you mean that from tomorrow on, all of our code would be completely proprietary? Of course, we cannot take back the code that’s already there, so what would happen is that someone would fork the project almost immediately. There’s over a hundred thousand organizations using it, and a lot of them would like to see it open source.

I do think that short-term, we’d probably make more money. There would be more people willing to pay for the support and updates that would, from then on, only be available if people pay us.

But the flow of contributions would stop.

There would be a fork. I think the fork would not attract as many contributions as before. There’s confusion, there’s no merge request coaches anymore, there’s no people helping to get stuff over the finish line.

Both projects would peter out.

Our commercial variant would see almost no contributions, and the open source fork would have troubles kind of keeping up with the rate of contributions, and bugs that get released there – we pay full-time people to handle that, and they won’t have that.

I think our numbers would look better after a year, but if you look at a 10-year outlook, it wouldn’t end well for us, and it won’t end well for the community. We have stewardship promises, which you could Google by typing in “GitLab stewardship,” and we intend to keep those, and that includes always keeping this open core model.

SaaS GitLab

Michael Schwartz: You initially launched a cloud-hosted version of GitLab.
And we’ve heard from other open source entrepreneurs, particularly Eliot Horowitz from MongoDB, strongly advocate for a cloud model. But in your case, there’s another very well-known company called GitHub that is in a similar business – so you’re sort of in a unique position.

I’m curious about your thoughts about how you see the cloud-hosted version of GitLab progressing, and where you think that fits in the market?

Sid Sijbrandij: GitLab.com is our SaaS version. We tend to not call it “cloud” because most of our self-hosted instances, self-managed instances, are also hosted in the cloud on AWS, or GCP, or Azure.

But our SaaS business is growing at a very rapid pace, people are embracing that. We invested a lot of time and money to make sure it’s a great experience.

In the beginning of GitLab, I think we had an edge in that GitHub was paying more attention to their SaaS version than their self-managed version, and that was a way for GitLab to enter the market.

Although we’re still strongly self-managed, by now the product is so complete, that people that want an end-to-end DevOps experience don’t want to be maintaining all their tools, and they’re flocking to GitLab.com. So we’re seeing strong growth there.

Open Source Challenges

Michael Schwartz: What do you think are some of the biggest challenges facing open source startups today?

Sid Sijbrandij: One of the most obvious ones is how you monetize a product, and the threat of the hyperclouds commoditizing your product.

I did a talk about this on the Linux Open Source Leadership Conference. And I talked about like, how big is that threat?

I think it’s differs a bit from company to company. But if your product is kind of a service that other things are built upon, like a database for example, that has a limited API, and it’s already offered as a service by hyperclouds like AWS – there is a risk that they will kind of take the project over, or what they did in case of Elasticsearch – they forked and commoditized the project.

And that is within their rights, but that makes it harder to kind of start-up around open source. So people are exploring different licenses.

At GitLab, although that risk is there, it’s reduced. Although we have APIs, it’s also a user-facing application, with a user interface. And currently it’s not offered as a service by any of the hyperclouds.

So for us, the problem is less acute. Also, for us, it would not be possible to change our licenses as others did, because we switched to DCO, a Developer Certificate of Origin. So if you contribute to GitLab, you retain the copyright on the code you contributed.

Hypercloud a Victimless Crime?

Michael Schwartz: So, to play devil’s advocate a little bit. The companies – for example, MongoDB or Redis or Elastic – they haven’t exactly lost a lot of value. Is it really a victimless crime because they seem to be doing better than ever?

Sid Sijbrandij: It’s great to see open source doing great. I think we’re able to build companies on open source projects – that didn’t used to be the case, and now that’s possible. So, that’s a great benefit.

I think the whole industry is watching what’s happening with open distro for ElasticSearch, and whether that will bite into the monetization that Elastic, the company, is able to do.

Advice For Entrepreneurs

Michael Schwartz: The last question is more about the people than the company.

You’ve had quite an amazing entrepreneurial journey, and I’m wondering if you have any advice for the people who are starting these companies. What advice would you have given yourself if you could go back in time?

Sid Sijbrandij: I think one of the things I did that I thought was kind of a bad thing but turn out to be a good thing, is I optimized for interestingness. And if I find something interesting, I dive into that, and I follow that.

And it’s served me really well. And I thought that was a very selfish thing – I did it because I liked it – but it also tended to lead to great business outcomes.

So if you follow your own interests, it’s more okay than you might think.


Michael Schwartz: Sid, thank you so much for joining us today.

Sid Sijbrandij: Thanks for having me.

Michael Schwartz: Thanks to the GitLab team for helping to organize the interview.

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

Music from Broke For Free and Chris Zabriskie.

Our amazing 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 an interview with John Newton from Alfresco, one of the first pure-play open source companies. I’m sure John will be super interesting.

Until then, thanks for listening!