Michael Schwartz

Episode 41: Apollo GraphQL, revolutionizing how developers write modern applications, with Geoff Schmidt, CEO and Co-Founder

Geoff Schmidt, CEO and Co-Founder of Apollo GraphQL, says you don’t get to pick your business model, you get to pick your problem. As part of the team who authored one of the most popular monolithic JavaScript rapid application development frameworks, MeteorJS, Geoff describes how they applied their experience to address an even bigger challenge–how to build more flexible backend data services.

Episode 40: Pivotal, enabling enterprises to manage a unified multi-cloud software infrastructure with James Watters, SVP Products

James Watters, SVP, Products at Pivotal Software, is a veteran of the unix and open source software business. With a broad breadth of products, including Java Spring and many other essential tools for developers, Pivotal has built a business of enormous scale in record time.


Michael Schwartz: Hello, and welcome to Open Source Underdogs. I’m your host Mike Schwartz, and this is episode 40 with James Watters, SVP of Products at Pivotal.

Pivotal is probably best known for the success of Spring, the most popular way for developers to write Java applications, but they built a great business around the Pivotal platform, which enables large businesses to manage a unified, multi-cloud software infrastructure.

Pivotal is a little different than your typical open-source startup. Spun out of EMC and VMware in 2012, and IPO in 2018, and shortly before I recorded this episode in August of 2019, VMware announced the definitive agreement to acquire Pivotal, a combination that’s expected to close in 2020.

James makes the case that open source is winning because it’s innovative feature-rich and enterprise-ready. He has a deep understanding of both the technical and business mechanic that make open-source companies tech. I’m sure you’ll enjoy this interview, so without further ado, here we go.

Pivotal Background

Michael Schwartz: James, thank you so much for joining the podcast today.

James Watters: Great to be here, Mike. Hi.

Michael Schwartz: So, you were trying Pivotal in 2012 when it was formed, and for the listeners who don’t know the backstory, maybe you could just drive a little bit about how that came about, and perhaps about how it’s coming full circle to some extent.

James Watters: I was fortunate enough to join a open-source research and development team at VMware in 2010, working on an open-source project named Cloud Foundry, and we didn’t really know what it would become as a business. It ended up, they decided to spin that out along with another open-source project called Spring Source, or Spring, into its own company, and that was one of the foundational product elements of the company called Pivotal.

Michael Schwartz: What’s your current role with pivotal?

James Watters: I’ve done a lot of product work at Pivotal. I’m currently SVP of Strategy, focused on new parts of our product. I’ve been focused on things like streaming, container-as-a-service, function-as-a-service, all the emerging areas of our product.

Size Of Product Team

Michael Schwartz: Just to give everyone a sense of the scale, could you give a rough estimate about how many product managers are Pivotal, and the total size of the product team?

James Watters: It’s pretty expensive. There’s hundreds and hundreds of engineers that work on the platform at Pivotal, and I would say 50 full-time product people working and supporting them.

How The Product Management Has Changed In The Last 15 Years

Michael Schwartz: When you were at Sun a while back, you were a product manager of Solaris, which is a pretty epic assignment for those of us geeks who revere Solaris. Since then I’m wondering, could you comment about a little bit about how has been an open-source project manager evolved? Like, what’s different now?

James Watters: That’s a great question. The cycle time was so different on Solaris. And that was an 1100-person engineering team. And then, on the kind of customer-facing product front, I think we were under 10 people. It was very much engineering organization, product provided a bit of input and amplification of key customer themes. We worked on often multi-year release cycle.

In the new world of open-source, the community input comes so fast. It’s a different release cadence. Our core platform PCF at Pivotal, we released every quarter. And that was a big mindset change for me versus some of the older world at Sun. It was just how fast everyone expected you to respond. It’s not uncommon now to meet with a client. And in a matter of weeks, we will have a feature changer update shipped to them.
It’s a completely much more iterative world of continuous delivery, both at the platform as well as what we’re trying to inspire our customers to do for their end users. So, I think that’s dramatically changed since.

How Smaller Organizations Can Improve Product Management

Michael Schwartz: If you’re not Sun, you are VMware Pivotal, but you are so much smaller. Do you have any suggestions for some of the little things that you can do, or that it open-source company might do around product management?

James Watters: I think that’s really opening a question, and I don’t want to speak conclusively on it, but I think what I’d say is, there’s kind of two ways of coming at it. And my specialty is always being understanding the enterprise organization that the product fits into.

There was a point in our journey, where we felt adding additional features around security would probably be neutral to the developer audience that was using the platform, but what actually bring like the chief security officer and her team deeper into the conversation.

Suddenly, we approached a few banks, and we said, “What if we could rebuild this entire platform infrastructure every day for security?” And we had a really brilliant product person at the time named Justin Smith, who let this initiative to articulate the idea of the much more ephemeral approach to the platform.

I think the reason I mention this is, you could have gone deeper on just developer experience, but by finding that other constituent in an enterprise that come to the negotiating table around why we’re giving money to this company, that really changed the game for us and a few clients, because the chief security officer was now also an advocate.

I think it’s challenging you doing open-source products because you might get a lot of feedback from your immediate community and immediate users. But in order to sell the products to a larger organization, you need to think about articulating investments to a broader set of constituents.

Pivotal Products

Michael Schwartz: You mentioned PCF for Pivotal, Cloud Foundry. For those who don’t know, maybe you could just tell us a little bit about what that is, or also walk us through some of the other product offerings at Pivotal.

James Watters: I’ve been fortunate enough, Palmer at VMware hired couple of Google engineers in 2009-10, to come build this platform out. It was really like what you might call the Cloud Native platform world today.

At the time, there was no such thing as container-as-a-service, and at the application level, there really was no micro-services, and continuous delivery was sort of a very radical idea of enterprise. It was sort of the first platform built with the container first design, built to enable continuous delivery of things that look more like micro-services than monolithic applications.

And kind of was the first investment in this Cloud Native space, in terms of application platform and culture, all coming together in a platform.

That was really what PCF did, and we were able to scale it from zero sales in 2012. Or the spin that was first contemplated to hundreds of millions of dollars in sales, and ultimately the background of a public company.

Market Segmentation

Michael Schwartz: Cloud Native is a broad horizontal market. Do you segment the market at all by vertical industry or use case?

James Watters: This is another thing around products. For me, products strategy is that I do think that vertical use cases are critical. I’ll give you two examples. In the banking world, there is a huge focus on Java, because it’s traditionally a Java-centric custom application world.

Banks were always willing to invest in the high-end applications that often was built by Java developers.

When I first started and till this day, banks are, I would say, the number one language in banking is Java. They are very security-centric, they operate in a highly-regulated world, and they tend to be very hybrid cloud. There’s very few banks that run public only.

They were a tremendous fit for the design of PCF, both from support for Spring Boot as well as its core security differentiation.

We absolutely thought of a lot about banking, insurance, regulated industries. Then, manufacturing and industrial was a little bit different space. There you had a lot of the IoT world, you had streaming data, you had a completely learning how to build software for the first time way of engaging, where industrial companies were just getting started on major software investments.

I definitely think about vertical segmentation. I think for anyone who’s contemplating a sort of customer first approach to product thinking, vertical segmentation is a good early model to take on.

How To Decide What To Open Source?

Michael Schwartz: Pivotal has 73 projects in GitHub, and I’m sure that there’s more in private repositories – how do you decide which projects to open-source?

James Watters: I think, by and large, we tend to be an open first-style company, as I mentioned on the Andreessen Horowitz podcast awhile back, I am an advocate for sometimes keeping the UI, closed-source can be a simple way of differentiating between the pure-community efforts and the final enterprise products. But in general, we’ve tilted towards open source first.

That’s also been a key part of our relationships, like I mentioned, with certain banks.

A lot of the core security infrastructure of the platform was all kept open source, because the banks felt more comfortable consuming a platform that was opened first, even in those core areas.

Value Prop

Michael Schwartz:  When you have a lot of projects, is it difficult to position the value proposition of the company?

James Watters: That’s a great question. If you think about how many projects you want to take on, like say, MongoDB is a fairly focused company. One core thing, Elastic are fairly focused company, but you get into the platform world, companies like HashiCorp are very successful at doing multiple projects. I think Pivotal is probably one of the broader breadth open source company is out there, certainly Red Hat has a pretty broad breadth. You hit a point where you become the platform provider of choice for their next generation of design, and actually the pressure comes to do more and more and more.

One of the biggest pressure points for us was always like, “Okay, we love this as an application platform. Now, provide us the whole universe of data services on the platform.” And so you have to achieve a certain critical mass to have the scale to invest like that.

But I do think that in enterprise segmentation, it’s powerful when you can start to have people accept the offerings you do have. And then, the biggest pressure is, “And now add this, so I can have one coherent approach. And I think that that’s something really important for open-source companies to think about it. Like, “Look at how Amazon operates. They are not a federation of hundreds of little hosting providers all coming together. They really have that sort of single point of interface to all of their abstractions.

I think that’s an interesting dynamic in the world right now. Open source is like, how broad you should go in your portfolio, do enterprise buyers favor that, is it better to be lower and single products – that’s something we discussed.


Michael Schwartz: With a lot of products, containers, Cloud Native services, it seems like it’s harder than ever to figure out how do you price. There’s more things you could gate on and the more elasticity is given, I know us, at my company Gluu, a lot of challenges because of CPU that depends upon the time of day. Can you talk about the evolution of pricing, and did you get it right initially, or did you have to make some tactical adjustments along the way?

James Watters: I think that’s a great question. I think it’s never easy or straightforward, we made a decision that we were going to go after the largest thousand companies in the world predominantly. We were going to supply a lot of technical resources to them, to ensure that they were successful with our product, and very much be an outcomes-focused company.

I think we intended to price at the higher end of the market, and that was a very deliberate choice. And I think as we’re growing now, we’re seeing more opportunity to start to segment the offer. To have a more transactional approach, we reintroduced the container-as-a-service product that didn’t have as many features as the full platform, but was something that people were ready to pay for more on a transactional basis.

I think that there is this tension between the desire to have a broader platform versus to be more transactional, and that very much comes back to customer segmentation. I would think of pricing in terms of how transactional you want to be, and then what the customer really expects out of you to make them successful.

Like, what does customer success really look like – it has to be at the core of your pricing model. If the prices are really low, and they’re not successful, that’s actually not on either of your interest.


Michael Schwartz: Does Pivotal actually have competitors?

James Watters: I don’t think that Pivotal has a company that is assembled just like us. We have some unique assets, one of the reasons we were successful in enterprises is, we have the number one way that enterprises build apps in the Spring Boot.

So, when it comes to like how enterprises are building applications in the Spring Boot, it’s probably easily the number one, and it might be over 50% market share of net new enterprise applications today.

There’s not another company that has that. We also had a very big git, and we were owned by kind of the Dell VMware family of companies ultimately. So, we’ve always been able to go to market with them, but we really still did have to earn our own way. But we could get introductions.

I think all of those things came together in a way that allowed us to build a higher-end platform to focus on the top 2000 companies in the world, and to go make them successful, and to price and package accordingly.
I think one of the challenges right now for smaller open-source companies is, these cloud platforms that are open-source, they keep adding features that are pretty high rate. So, you may think that one day, you have a company, and the next day, that’s a feature of a cloud platform. And I think that’s attention.

Certainly, in the service mesh world, you see disruption of kind of traditional networking and API management, coming in the way that people are adopting a service mesh, etc. Is that a company, is that a platform – I think that’s a very dynamic part of the market right now. It’s pretty important, and I don’t talk about it too much, but I really do enjoy working on open-source projects because they can have a breadth of impact that’s pretty unimaginable to something that you have to commit a sales transaction and for software before someone can use it.
We have an asset at Pivotal, Spring Starters, and they’re the number one way that people get started with a new job application. And that’s start.spring.io. You start a new job project there.

Every two seconds a developer on average is going there to kick off a new project.

And the top three countries for it are China, United States, and India, but these are the kind of impacts that open-source can have worldwide, deep into developer impact that you can never do with closed-source only, enterprise sale only products.

I think just the unimaginable breadth that open source can get you in ubiquity, that it can get you in the modern world is stunning. So, that’s what I’m humbled to work on. I think the challenge is then like, “Well, how do you make sure that the largest 5,000 organizations in the world are contributing to that?” And that’s where I do have a passion for enterprise monetization of open source, and finding ways of partnering with those organizations, and packaging, and pricing things, such they feel that there’s good value. And partnering with these open-source companies and making them their most meaningful platform.

I think I’ve got there two minds, number one, open source is super important just from a long-term impact the world, it’s harder to work on projects, they can have a bigger one than open source ones.
And then there is the challenge of like, “Well then, how do you build the economic model around that when it’s so ubiquitous to begin with? That’s the kind of challenge that I’m taking on, and I’m humble to be able to work on open source for enterprises for that reason.

What Types Of Software Should Be Open Source?

Michael Schwartz: Do you think that certain types of software lend themselves to being open source?

James Watters: I would say that the developer workflow today – and that’s not my line but I like it – it starts with “Git clone.” And I think any saying, where a developer is initiating a project in this era, it better be either a really easy to use API, I think Stripe certainly has proven that, or, it better be something like start.spring.io. Or, git clone, something that a developer could just go grab in a permissionless kind of way.
And Adrian Cockroft at Netflix said that, back when he was at previous companies, there were these big architectural debates for months before a project would start. And that in Netflix you really implemented the running code talks. It’s all about running code. I think that that is the reason why open source is really powerful for anything having to do with developers.

And then, on the infrastructure level, open source has become the most profound way that large vendors collaborate. If you look what’s happening in the Kubernetes community, where you have every major public cloud contributing to Kubernetes, IBM acquiring Heptio to make major contributions to Kubernetes, in infrastructure, open source has the way that these, what you might have had standard bodies before, there’s sort of like a running code way that large vendors are collaborating. Both, in the end-user developer space as well as in the infrastructure space, open source had a huge impact.

But if you think those worlds are slightly different, the dynamics of start.spring.io, which is very end-developer focused versus the way that every public cloud is normalizing how they run Kubernetes are slightly different, they’re all open source but they have slightly different behaviors and attributes. And it’s kind of fascinating to see database companies like MongoDB a little bit different than the way that the Kubernetes community is operating.

Do Enterprises Care About Open Source?

Michael Schwartz: Do you think that customers actually care about open source? I mean, large enterprise customers?

James Watters: I think large enterprise customers absolutely have seen the tremendous benefits in just frankly the innovation velocity of open-source products. And I think the biggest change is that in the early days, open source was a cheaper version available for free of the enterprise products. That’s what I think it was especially hard to monetize.

If you’re just going to be the cheaper thing and the low-cost provider, and not the premium product, a lot of enterprises might look at that and say, “Hey, we’re an enterprise, we can afford to buy whatever we need. We just really want innovation leverage, like we want the best product.

But I think there’s a new whole category of products, or there’s only an open-source player that is creating it. Like PCF was the kind of first micro-services platform in the world for enterprises. And it was built a 100% open source. It was both the market leader in terms of features and the open play.

I think the open-source market is changed, where there is room to be both innovative, or the expectation is that they’re both innovative, higher-end, feature-rich as well as enterprise-ready – all of that is expected from open source today. I think that’s where the innovation is happening.

If you look – here’s an example – Amazon has a service Kinesis, which is how they were doing messaging, and it did a pipelines. And now they’ve switched that to a managed Kafka service. They had to do that because the innovation was really happening in the Kafka community in open source. Even on Amazon scale, they couldn’t keep up with it.

I really find that to be the best part of the market right now is that you can’t out-innovate the open-source players.

Cyclicality Of Centralization

Michael Schwartz: It seems like there’s sort of a cyclicality between centralization and decentralization. For example, a couple years ago, everyone was at full tilt towards “Go to the cloud.”, and now, it’s almost like with Kubernetes and other technologies – is there any shift away towards maybe bringing more of this type of functionality in-house, and does that help a company like Pivotal?

James Watters: When I talked to CIOs about this, I tried to help them deconstruct the current cloud market, and what I told them is, “Public cloud is not one thing. It’s really three different zones of features that you need to think about. The first is the commodity layer, which is, “Hey, I’m just buying virtual machines, networking disc, the basics, and that’s kind of where public cloud started.

There, you can use a platform like Kubernetes, and run those system resources in similar ways, if not identical ways, across public-private, hybrid multi-cloud. So, I think Kubernetes has done a tremendous job of making those system resources normalized across all the clouds.

Then, I think there is this emerging space within the Cloud Native community around the open-source developer focused projects that run on Kubernetes, like Kafka, like Spring Boot, really like Pivotal’s platform. That’s where the developer innovations come. That’s like the open developer innovation community, that’s number two.

And the number three is, they selectively are these managed services like Google Spanner, Google Machine Learning, or you might be ahead of the market, where there might not be an open play there yet, where Spanner requires dedicated fiber networks between data centers to make the database magic work. So, there are areas we are the managed cloud or head.

Our perspective is that innovation in the core, where you are really arming your developers, continues to happen in open source. Commoditization can be achieved through technologies like Kubernetes running in a normalized way across clouds.

And then, technologies, like the Open Service Broker, relay to buy these managed things. Long story short, I think what’s happening is, the CIO’s are getting smarter about deconstructing cloud from this monolithic idea of “I go all in one cloud.” to like, “How do I selectively use what’s best about each cloud?” I think open source is playing a huge part of that.

Should Open Source Be Less Expensive?

Michael Schwartz: You touched on this a little bit before, about how open-source software maybe should be cheaper. I think that there is a sort of perception for some reason that even though you get more rights with the license that the software should be less money – do you think that that is changing, or is that something that is an industry we need to work on with customers?

James Watters: I’m a maybe a contrarian here, my dream was always a very open product that generated a lot of value that enterprises were excited to invest in the platform partnership in. And, essentially, I don’t think that open source should have to have cut rates levels of investment into research and development vs. closed source.

My contrarian nature there says, “If you really have the right relationships with these customers, they’re going to be just as happy giving an open-source provider money as they are giving Oracle money.” I mean, if anything, I think that open-source partnerships are valued in a more profound way in the modern enterprise that might be even happier to give you more money than Oracle.

I do think that that something is happening. That also comes back to how these open-source companies engage with these large enterprises, are they focused on them, do they understand their vertical needs, do they put security first, are they able to measure the outcomes that are achieved with their platforms?

Closing Advice For Entrepreneurs

Michael Schwartz: Last question. Do you have any advice for entrepreneurs who are starting new ventures based on open-source software?

James Watters: I think my advice would be, if you really develop a community around your open source, you’re one of the luckiest people in the world. That’s a tremendous gift. Save and invest in that community, but also spend some time understanding how that technology fits into the value chain, in the largest thousand companies in the world, and investments they are making in technology.

Try to balance the needs of the developer who’s approaching it from a ‘git clone, let’s get started’ perspective, as well as the more complex matrix or matrices of a large enterprise organization, and what they need across security, operating, certainty SLAs, etc. If you can get those two forces right, then I think you’ve got a remarkable opportunity. But I do think that monetization, and ultimately funding a great R&D team behind your open source project, takes a balance side towards both.


Michael Schwartz: James, thank you so much for taking your time today in this really pivotal moment in Pivotal’s trajectory.

James Watters: One last pivotal word joke.

Michael Schwartz: Thanks, James.

James Watters:  Thank you, Mike.

Michael Schwartz: Thanks to the Pivotal team for making this happen.

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 by Natalie Lowe. Operational support from William Lowe. Transcription by Marina Andjelkovic.

The Twitter handle is @fosspodcast.

Next week, we have Geoff Schmidt, Co-Founder and CEO of Apollo GraphQL.

Until then, thanks for listening.

Episode 39: Rancher — A support-based business model that scales, with co-founder Shannon Williams

Shannon Williams, Co-Founder and VP Sales of Rancher lays out how a great team with deep domain knowledge can actively identify a product market fit in a crowded space, and emerge a winner. It’s an inspiring story of a plan perfectly executed. This is a MUST LISTEN episode of Underdogs!


Michael Schwartz: Hello, and welcome to the Open Source Underdogs podcast. I’m your host Mike Schwartz, and this is episode 39, with Shannon Williams, Co-Founder and VP Sales of Rancher.

Let’s go for a minute into the land of hypothetical. If I can ask all 38 previous podcast guests a question, “Is monetizing support a good idea?”, I think there would have been virtual consensus that support doesn’t scale. Except, Rancher is perfectly executing a business plan to do just that.

I hope you’ll enjoy this episode. Tweet your comments at @fosspodcast, and we will asynchronously discuss in the Twitter sphere, but for now, here we go with the interview. Shannon, thank you so much for joining us today.

Shannon Williams: Thanks for having me, Mike. It’s exciting to be here. Looking forward to our conversation.


Michael Schwartz:  Can you just fill us in a little bit about how Rancher got started and what was the mission?

Shannon Williams: We’ve been going now since 2014. In a lot of ways, it feels like we started before that, because my co-founder Sheng Liang, Will Chan and I, the three of us started another company called Cloud.com back in 2008. And, for all intents and purposes, we’ve been working together every day for 11 years now. That company was an early developer of open-source infrastructure-as-a-service software.

We built a product called CloudStack with the founding members of the OpenStack foundation. I had a really fun run there for about three years before being acquired by Citrix, and spending another three years at Citrix.

In our work on CloudStack, we learned a lot about, as you can imagine, managing infrastructure at scale, building out private clouds, helping a lot of large companies build public clouds. At the time, everything we were focused on was how do we deliver virtual machines to developers quickly from anywhere.

But over the course of working on a lot of private clouds, we noticed that we had a lot of conversations with people trying to figure out how to blend their on-premise infrastructure with this growing amount of cloud infrastructure.

One of our early customers was GoDaddy actually. They were looking at building a public cloud, and Darren Shepherd, our fourth co-founder of Rancher, was a Chief Architect there. We got to know Darren really well.

We started talking in 2014 about what could be done to bring together the on-premise infrastructure, the cloud infrastructure, into something that overlaid it all, and to really allow people to treat infrastructure like Cattle, like a disposable commodity. And Docker was just getting started, the concept of Containers was emerging, and we thought there was a really cool opportunity to look at leveraging that, to build out management tooling, infrastructure services, and kind of imagine the next generation of infrastructure management, which would hopefully enable people to do computing anywhere, with really consistent deployment experience, management experience, monitoring experience, all these types of things.

And so, Rancher was born. For almost 5 years now, we’ve been working on continuing that journey, how to build open-source products that are available to anyone, and really allow them to run workloads anywhere. So, that’s really where we came from.

Value Prop

Michael Schwartz: This market, it’s really diverse. There’s a lot of tools and tooling in this area. I’m wondering, what’s the exact value proposition for Rancher service?

Shannon Williams: Rancher is open-source software, we have a number of open-source projects but our most famous is called Rancher, and it really sits at the management playing around Kubernetes. Organizations use Rancher because they are deploying and managing more and more Kubernetes clusters.

Rancher provides distros of Kubernetes. We have one called RKE, which is a pretty typical, upstream distro, it’s really good for deployment, automation. Then, we have one that’s optimized for the Edge or other low-resource utilization called K3s.

We provide distros of Kubernetes to people that need to run Kubernetes, but Rancher itself actually sits above those distros, it’s the management client. What’s cool about it it’s really distro agnostic. It actually manages any Kubernetes. And by managing, what that means is an organization implements Rancher so that they can deploy and control, and then grant access to dozens or hundreds of Kubernetes clusters – some running in the clouds, some running as hosted services like GKE, and EKS, some running on premise, maybe on the Edge.

By bringing all those clusters together, what Rancher allows them to do is, dictate policy, control access, monitor availability, manage deployment of applications, manage catalogs, attach additional open-source services, like Prometheus for monitoring, or Fluentd for logging, or Istio for service match, and so, Rancher sits at that next. So, how do I manage Kubernetes everywhere according to my organization’s policies.

By doing that, it enables them to then really deliver their service reliably. For organizations, they think of Rancher as the Kubernetes platform, it’s Kubernetes as a service, it’s how they deploy apps and run anywhere.


Michael Schwartz: The Rancher GitHub repository has 14,000 forks, which is really a lot. But there’s only around 60 something developers, which I could see is probably primarily being the people in your organization – can you talk about the relationship between the open-source project and the activity there, and the SaaS service?

Shannon Williams: Just to be clear, we don’t offer a SaaS service. Rancher is open-source software only. We only provide open-source software that people use, but what we sell is support for those open-source projects.

On any given day, there’s about 30,000 teams around the world running Rancher. Those teams, they may be a smaller group that’s deploying it for one application. There’s maybe somebody doing a Dev lab, or test lab, but of those about 1%, about 300 enterprise customers, these are companies that deploy Rancher, and whatever they are running on it, it’s critical to their business.

They contract with us to provide enterprise-grade support for Rancher, RKE, K3s, and really their whole Kubernetes stack up and down. By providing that Enterprise-grade support, what they get from us is the confidence to run really important workloads on the open-source Rancher, but what they like is that we don’t have your classic open-core only model, we don’t sell version that’s different to them. They just pay an annual support subscription, and they use it.

A year later, if they are no longer using it, they are not paying an annual support subscription. They can keep using the software, but they would be using it again without support.

Our model is geared around helping organizations that need support, get the best possible support in the world for Rancher, Kubernetes, Prometheus, and Istio, and all the pieces of technology that we deliver to them.

Why Open Source?

Michael Schwartz:  Has open-sourcing the code really made a meaningful contribution to the company?

Shannon Williams: It’s at the root of our success. By open-sourcing the code, we enabled a startup with relatively no name recognition obviously, to come into, in a lot of ways, it’s a very crowded market.

Think about the companies that are dealing with application management platform as-a-service. When we started, you can imagine Docker, Mesosphere, Red Hat, Pivotal, these companies were already out there. You know, Docker, in their sense with having released the Docker project, orchestration and building different types of management tools, and with enormously more funding than us, much, much, much bigger brand recognition teams.

We had to find a route to market with limited funds, we needed to let our product be our best piece of marketing, and so we took that approach. We believed in this for a long time. In our last company, we had a very similar approach. We made Rancher fully open source and free because we felt that it was the best way to get adoption, to plant seeds in organizations that would need this technology.

By putting it out there, we really bet on two things. We bet that people would like it, and that they would want to use it, but we also bet that this technology was crucial. And that at least a good chunk of people who use it would find value in getting support for it and find value in having SLAs that they can rely on for that application. And we’ve been thrilled. I mean, our company’s now almost 200 people, we’re more than doubling this year. In terms of revenue, it’s really worked out really well.

People really do love Rancher. It’s something that makes me really confident with the model as you have to believe in your engineers, you have to believe that products can be great. We also spend an enormous amount of investment of time working with our open-source community. We have a huge Slack community of thousands of users who come in with suggestions and ideas on how to make the product better. We get thousands of issues, and feature requests, and bugs filed by the community.

I don’t think we have more of a user community then of a contributor community. I love it because they come to us with real problems that need to be solved, and I identify them. Often, their use cases sometimes are pushing the boundaries that we may not see out of a Fortune 500 company that’s using Rancher. So, it all sort of pushes forward with the hopefully creating a great product for everyone.

More On Why Open Source…

Michael Schwartz: So, just to sort of dive a little deeper on that. If you made the software commercial tomorrow, do you think the 300 or so Enterprise customers, who are using the software, do they really care about it being open source? Or is it just a non-sequitur, or they just want the best software? So, if you made it commercial tomorrow, do you think that that would be bad from where you are today?

Shannon Williams: Yeah, I do. When I talk to organizations about our business model, they get really excited because there isn’t one of them which hasn’t been in a position of really limited leverage against their current vendors. Everybody has been staring at just massive renewal orders.

We closed, just this quarter, today is the end of our third quarter, and we closed three deals with organizations that are spending a lot with us, half a million a year in recurring revenue, for example, to support environments. And their frustration in some cases was platforms that they had built, PaaS platforms, where the cost had grown exponentially. And they just had no ability – even though these were all based on open-source, they weren’t themselves open source. I mean almost everything is based on something, open source at this point.

What people really like is, they like an open-source product, because they always have the option to leave it there, let it run, support it themselves, hire some engineers and figure it out. In the end, if you are running a proprietary tool, and you don’t pay, you have to yank it out of production. And that is impossible for most companies.

I think our business model, yes, some people would still buy a Rancher, and be fine with it, but I think a lot of the smartest CIO’s I talked to are really excited to see a company like us, that embraces open source for commercial purposes, provides really good support, and is committed to building open-source products. For us, it’s allowed us to grow faster than any other approach I’ve been able to come up with.

Pivot To K8S

Michael Schwartz: Seems like Rancher made an epic pivot towards Kubernetes at some point, I guess, fairly recently – what did you learn from that process?

Shannon Williams: Well, the hardest part about getting into any market is making bets, and then figuring out where they come down. Rancher started about the same time as Kubernetes. Right around 2014, Kubernetes was starting at the same time we started our company.

At the time, we really thought Docker and their Swarm and stuff were probably more likely to win out. They had so much momentum. But it only took a year to realize that Kubernetes was actually really well-built piece of code.

So, when we first started working with them, we were kind of thinking we would be managing Swarm clusters and Mesos clusters, and then, even before we launched our 1.0, we decided to support Kubernetes, because it was a really good piece of software.

So, we released our 1.0, our first product to the market in 2016, Rancher 1.0, at the time, if I was talking to them, I would have said something like, “You know, it seems like different companies are choosing different orchestration approaches to containers because they need different things from them.”

Some people want to scale really big, like Twitter. So, they’re using Mesos, other people really focused on the developer experience, and they’re choosing Swarm. And it wasn’t really clear yet that one standard was going to emerge, but what we started to see was some stability issues with some of the other orchestrators that we saw as a manager. It was like, “Ah, these things aren’t stable as I would have expected them to be.” What we found is that Kubernetes is really reliable.

So, as we imagined our business, and trying to support these technologies and helping companies implement them, we felt like it was safe to bet on something reliable, and that did require pivot that moved away from messaging, and product development had gone into supporting, we built our own thing, we had Swarm, we had Mesos, we weren’t really sure what orchestration was going to take off. But as we got more comfortable with Kubernetes, and luckily, we started working on it early, it made it really easy for us to honestly commit to something we liked.

By that point, by 2017, we were all in on Kubernetes building on that. And since then, we already had a lot of people using it in our 1.0 product, we also had a really nice base installed, we didn’t just lose.

So, a lot of times, you have a pivot, and it means almost starting from scratch. But actually, we didn’t really lose hardly anyone because it was very much in line with the direction that most of our customers wanted to go as well. Even if they maybe chose a different orchestrator, they also saw the market going this way, so they were really, really appreciative that we gave them a path to get to Kubernetes off of maybe something else they had chosen when the market was still a lot less clear.

We found that that wasn’t nearly as big a problem. Now, what is hard in pivoting, especially, one of the things we built was our own orchestrator called Cattle, and one of the hardest things was actually convincing our own engineers that the Kubernetes was actually superior to what we had developed ourselves.

That’s a hard thing to do because no matter what, if you built something, you’d always love it. And at the same time, in an early market like we were in, lots of people loved the thing we built, a lot of people telling us, “Hey, we really like this Cattle. It’s really good and you should just keep improving that.”

But as an entrepreneur trying to build a business, you have to be really, really honest with yourself, and you have to really look at all the signals, not just the ones that maybe are giving you the positives you want to see.

All the signals told Sheng, and I, and Will, and Darren, that we needed to really focus our business on solving the problem that we thought most organizations were going to have. And that was, how to take Kubernetes to scale, how to bring together a really complex ecosystem around it, how to build a platform that would work.

That meant really having long conversations with our engineers, convincing them if they weren’t excited about this, that maybe there are other things they could work on in our team and finding the team focused on doing this.

It worked out great, but it was not trivial. We have a small team, I can only imagine when you see big companies today trying to pivot to Kubernetes, you’ve got years and years of customers install base, and how difficult that might be for them.


Michael Schwartz: Great. It takes a lot of leadership. Most sizable organizations are using Containers today, so if you can sell to anyone, it becomes sort of challenging, so who do you sell to? I’m wondering, do you segment the market at all?

Shannon Williams: One of the nice things about open source is, it has allowed us to, give an idea most, I would say the 300 Enterprise customers, like every quarter now we’re closing about 50 new customers. Every quarter we are closing, we look at what the source of those are. I would say 30 of the 50 came from open-source Rancher users.

They started with open source, they used it at a business-unit level, or line-of-business level, and it became important to them, and they needed support. Those deals, they are not very competitive, they’ve already kind of looked at Rancher, they have a relatively short sale cycle, they’ve done the proof-of-concept – we don’t have to go in and prove that Rancher is the right solution for them.

What we found is that we don’t really need to segment that. The product pricing was probably the most important thing to segment. We did find that with such a huge install base, one of the mistakes we couldn’t do is, we couldn’t support everyone for free, for a small amount of money. We needed to kind of keep a relatively medium-sized bar, to ensure that people who needed support had to make an investment to get it.

For example, we could have gone with a lot of SaaS models, $10 a month or something like that, but the reality is, infrastructure and Containers, Kubernetes – these are all really complex. The support is quite real. We provide a lot of advice, a lot of architectural help with these organizations doing it. So, there was a real risk that we would price the product so low, and that we would then be trying to do this for lots of companies with very different levels of technical skills.

I’d say, the closest thing we came to segmenting the market was providing a lot of free open-source support for people who are trying to figure it out themselves, but then, charging a reasonably significant fee to come in and get support. Our customers had to invest tens of thousands of dollars on an annual basis to get support with us.

By doing that, it allowed us to work with companies that really valued this. We’re investing their time and the money into making it successful. That was really the best qualifier. It allowed us to focus on teams that really could help us grow the business at the same time.

We’ve seen some industries become really big with Rancher, but it’s more just a sign of who uses Containers. It’s companies, and certainly the internet, and the technology industry, but there’s a lot of financial services, companies, fintech companies, biotech companies, universities, research organizations, we’re seeing adoption in government and military use cases. It’s really broad now.

Retail, Edge’s driving, all sorts of interesting use cases, oil and gas, all sorts of interesting use cases in manufacturing, automotive – just lots of cool things that people start to imagine, a model where Kubernetes becomes this grand unifying theory for computer, where it runs everywhere. It runs in their single node, base station, it runs out in the windmill farms, it runs in Chick-fil-A shops, it runs in factories, it runs on cruise ships, it runs in data centers, it runs in the cloud. It’s a really exciting time to be working on tech, I would definitely say that.

Pricing To Value Ratio

Michael Schwartz: Normally, it’s really hard to get pricing right. Did you have to pivot your pricing model a couple of times? Or how was your experience like, figuring out what are the right price points?

Shannon Williams: Oh, man, that is a good one. We learned a lot from our last company. I made every mistake you can make last time. This time, we definitely had to pivot a little bit to be quite sure what the right element was to scale on with the number of clusters, or containers, or nodes, or CPUs, or things like that, but we decided pretty early on that the size of the implementation was probably a good way to judge how the cost should change from a small deployment to a large deployment, the number of hosts and servers, things like that.

Actually, I would say we learned a lot, we’re fortunate, that were a lot of indicators from the market, as people talked to us I would say. Your first 10 – 20 customers give you a lot of feedback on pricing, whether you want it or not.

Usually, I think most people price to low, just by nature. We all want to just make it both amazing and cheap prices. Like, who wouldn’t love this thing? It’s the best and it’s the cheapest. But you have to be realistic about what it takes to fund a business, what it’s going to take to build a profit, and what you can do with those engineers you can hire, and then you have to convince people of the value. It can be tough.

I remember I walked away from a lot of deals in open source. I just said, “I’m sorry. I totally appreciate that you’re telling me you could use the software for free, so you couldn’t possibly pay me more than $10,000 or $20,000. But if I did that, I wouldn’t be able to build a business, I wouldn’t be able to write open-source software, and I wouldn’t be able to give you the level of support you demand from your other enterprise software vendors. So, I’m sorry, we can’t do business with you.”

And sometimes they come back, sometimes they don’t, but being willing to walk away from deals – for our business model, it is absolutely critical to have to be able to do it. Otherwise, again, the car I’m selling you is available for free. You can take the same car with the exact same features, you’re not paying for a special version, it doesn’t have a better horn or better tires –it’s the exact same car. What I’m offering you is the confidence of working with me on it, and the world’s best support for that technology. If you don’t value those things, then, we can’t come to any business relationship between us.

Technology Partners

Michael Schwartz:  Have you used partners to help you deliver to customers, especially globally? Or are there any other business partners that have been important for you to build a business?

Shannon Williams: Yes, yes, yes, yes. Over and over again – yes. The critical partners for us have been really two big buckets. We have found that the other companies who are building critical technology for teams adopting containers. It’s a company that’s called Portworx that builds a really nice storage, and a company Aqua that builds great security, Sysdig who creates monitoring, Gitlab who does really cool tools for CI and Git deployment – all really commonly chosen by our customers.

But partnering with those companies, companies that fit into the same solution stack, we have been able to do two things: we’ve been able to build a much more credible solution for our Enterprise customers. And we’ve been able to align messaging and go-to-market together, and take maybe a couple of other organizations who are our size, venture-funded startups, and take our stories, and show them to larger organizations together.

And we would’ve done this through, we’d run online meetups, where our partners come and present to our users about their technology, and how they work with Rancher, and how they work with Kubernetes. That gives us a lot more credibility, and helps those company succeed, which helps the market grow because the market is vibrant. So, we invest a lot in partnering. We’ve also partnered really closely with the cloud providers.

We work really closely with Amazon, Google, and Microsoft in the U.S., and large providers around the world, to ensure that their implementation of Kubernetes works really well with Rancher. And that’s been fundamentally critical, especially because what we see is we see a market where, if you are in the cloud, you are probably going to use the cloud providers Kubernetes.

So, we want to make sure that we’re not trying to convince you to use Rancher’s Kubernetes on Google, take Google’s Kubernetes engine, which is great. Let us provide you with the common frameworks, whether using Google’s in Google, and Amazon’s in Amazon, on premise and Edge, or different types, everything is consistent, everything is managed the same way, everything is deployed, monitored, upgraded consistently. And you have a platform that really is this UberCloud we set out to build in the beginning anyways.

Integration Partners

Michael Schwartz: If a customer says that services aren’t enough, they want on-site engineers, they want sort of higher-level design consulting – do you do that as expert services, or do you work with delivery partners to do that?

Shannon Williams: We tend to work with delivery partners. We work really closely with both big and small delivery partners who had built expertise. In Rancher, we have a platinum partner program, which is made up of some amazing companies that have implemented Rancher for others multiple times, and really have deeper understanding often not just of our ecosystem.

So, companies like RoundTower, CloudOps, Readapt, Accenture. We work with quite a lot of the large multinational services companies. We work with different regions around the world. These companies, BoxBoat and other really good ones, these guys, they’re really staffed to provide ongoing services for organizations in a way that we’re not.

Like, we are great at coming in and giving you a ton of information about Rancher and helping your architect your Rancher deployment, but a lot of times, technology is only a chunk of the solution. The solution needs to include some transformation of how you do things, how you do DevOps, how to train all your developers around microservices, how they start thinking of some of these new service matches, and how they might get into solving business problems for your company.

We can point you in the right direction and help you with those things, but we’re very laser-focused on the Kubernetes platform. And these companies are much better than we are at providing the transformational experience around there. So, yeah, we very much partner, especially in those longer-term things.

What we have found as really critical is the actual investment of our own on customer success. I would say, one of the things that’s got a lot better as we’ve grown is, we’ve invested more and more in — I think it was like the first 90 days when an organization becomes a Rancher customer.

I think this is really important for open-source companies because if you are a SaaS provider and somebody’s using your product, you have a pretty good idea what they’re doing with it. But as an open-source software companies, especially ones that support that open-source software, organizations can have very different processes, they may have more or less mature implementations, they may or may not have built-in an HA deployment. And they’re coming to you to provide support. You really need to make sure they understand best practices, that you reviewed their deployments, you helped them understand how we recommend doing things.

We invest a lot more now in customer success than we did in the early days. When a customer comes on board, we really spend a lot of time going through their architecture, helping them make improvements that they will achieve their goals, whether it’s stability, multi-cloud implementations, or they might try to do something, there’s a lot of scale. And then, there might be something we’ve learned already that can help them. I would say customer success has been a big learning for us.

Net Retention

Michael Schwartz: Has that investment in customer success also translated into increased revenues per customer year-over-year, so they’re buying more, or other products, or other divisions?

Shannon Williams: Well, it’s still new enough that I wouldn’t say if I know how correlated those two things are, but we certainly believe they are. We are investing in it because our bet is helping a customer be successful, with even a departmental implementation or a single app deployment is going to pay dividends for both retention of that customer and that workload.

So, a year later, when they decide they want to renew that support they bought last year, they have a really good feeling that, “Yeah, that was a great investment. Partnering with these guys has been useful.”

But certainly that also works internally. As they use it, they seem to spread the word. I mean, we have seen over and over and over again the power of the success of a Rancher deployment spreading within a company.

Users love Rancher. It’s a user-oriented product. What’s so cool about a product that has 30,000 open-source users is, it says something about how usable it is. It’s like terraform, you use it, it’s pretty straightforward, you like it and you go, “Cool. This is easy. I can get this.” You tell your friend, “You should use terraform. It would help you do something.” It’s kind of same with Rancher.

If all those users are using it, they are clearly getting some value from it. When somebody in your company says, “Hey, use this.”, and you’ll probably benefit from it. And there’s no barrier. I don’t have to start by going and getting a license to try it. I can just use it. It tends to spread the same way. It’s just the word of mouth and the power of it kind of spreads.

So, we found that making them successful and making sure those early champions are well-armed to explain why they chose Rancher, and they got a really good implementation, they don’t get bitten by a bad config, or maybe not knowing the best practices, it helps us in the long run for sure.

Cloud Strip-Mining

Michael Schwartz: I’m sure you’ve been hearing about open-source strip-mining from large cloud vendors, but what I’m wondering is, do you think it would be good or bad if some mega cloud company offered a Rancher-based service?

Shannon Williams: I think it would be great personally. From our perspective, the value of these mega cloud providers is always tied into a big ecosystem that they’re trying to build around. What we find is that organizations want to live in those ecosystems, and leverage those ecosystems, but they know they’re not going to live in just one of them. So, they want lots of them. And the more that those ecosystems interact or work together, or do things that help them work together, the better off they are.

In so many ways, I think the strip-mining analogy is that it’s a rough analogy because, well, it’s true that some of these providers don’t put a lot back, and there’s definitely been some ugly competition between open source and commercial. For the most part, I think their relationship has actually been pretty beneficial, mutually beneficial between the cloud providers and the open-source software developers.

It’s often where it’s really struggling, where you‘ve seen it’s struggling is when organizations haven’t had a great business plan our route to market, or they haven’t been able to commercialize their own products. And then, all of a sudden, it gets embedded into something larger. And then, the only monetization of it happens in the cloud.

I think that’s where we see most of the problems. I think that’s going to continue. I think that that was happening before as well. You know, ideas are developed, but are never really taken to market fully or are not pushed into the market aggressively. Organizations build upon those something new, or something tangential, or something that accelerates them. And that is what ends up being the big success.

To me, that’s business. That’s something that’s going to happen in any space, whether it is open source or not. And, yes, in our world, people can take and build on it very easily, but that’s what you know you’re getting into when you’re starting an open-source software business. And if you don’t, you really should research a little bit more.

This is a knife that cuts in many ways, from a business perspective. And I certainly would look at the world, and I certainly wouldn’t call foul if that happened to an open-source project. I’ll give you a feel, in China, Rancher is incredibly popular.

From early days, my co-founder Chan grew up in China, and so, you have someone who can speak Chinese and talks about it in China – Rancher became really famous. We’ve had multiple times where startups have kind of emerged competing with us in the market, selling Rancher and providing support around it.

Our experience has been that that, as long as we continue to push forward the innovation and organizations really value what we do, they’re going to want to work with us. They are going to benefit from working with us.

As long as we keep pushing it forward and building the product better, that will continue to be the case. But you have to know what you’re getting into. I don’t feel like there should be a huge shock if you build an open-source product, and someone forks it, and does something cool with it, that’s kind of the idea.

When To Use Open Source

Michael Schwartz: Moving to slightly higher level, do you have any thoughts about when entrepreneurs should use the open-source development methodology to develop a commercial product?

Shannon Williams: For me, I think it’s about the product you’re trying to build, and what you think your route to market needs to be. If you’re entering a market that you think is pretty competitive, and has a lot of different products, and you know you’re going up against much more well-funded organizations than you, then, I think open source is a really, really important one to consider and to look at. Because it allows you to get adoption in what would otherwise be a really hard market.

If your only feedback is going to come from a handful of companies you can convince to POC you or pay for it early on, you are going to have a hard time building momentum. And you’re going to have a hard time having good conversations with users who either like or don’t like what you’re building.

To me, I don’t know, I’ve been building nothing but open source for 11 years, so it kind of feels to me like everyone should just build open source. I don’t find that it’s ever slowed down our monetization. It’s always been a benefit. But I certainly would say that if you’re building something that you think is transformational, that actually has a broad audience that will adopt it, open source should very much be what you’re considering.

If you’re building something that’s probably a service, and it’s going to be hosted, I think open source can be enabling capability, but I wouldn’t worry too much about the open-source side, I would just focus on building the SaaS platform product tool that you are building a cloud service.

Because I think in those cases, open source is less important than it is an on-premise software or fundamental software. You’ve seen with Docker, open-sourcing, and having an open source success is not by any means enough to guarantee a commercial business success, but it puts you in a position where you have a great chance to engage with users, listen to what they think is necessary. Next steps, what they’re excited about your platform for, your product for, and what they’re willing to pay for, and build on that.

Advice For Entrepreneurs

Michael Schwartz: Last question, any advice for new entrepreneurs starting a business around an open-source platform?

Shannon Williams: Of the four of us who started Rancher and started Cloud.com and everything, I’m the non-engineer. My role in the early time of building a company, I was considering my role then to be how to connect with users, like how to connect to people even before you have a product.

When we were in our first 6 months, our first year, I spent all day, every day, thinking about who are potential users could be, based on the direction we think we were heading, and reaching out to people, introducing myself and introducing the idea we’re building, and getting feedback.

You always have to be thinking about the next milestone of users, “My gosh, how do we possibly get to 10 companies using our product?”

And the only way I can ever found that works to get to 10 is to find them by hand. To think, “You know, I think this makes sense for somebody in that space.” I really believe that if you as a founder can’t explain your value proposition enough to get someone to sit down on the phone and talk to you about it, and maybe watch a demo.

Especially when you can tell them, “Hi, I’m Shannon. I’m one of the founders of this new startup called Rancher. We’re trying to solve this problem, and I thought it might apply to you guys. I really love your feedback. We are not trying to sell you anything, we just want your feedback on what we’re doing.”

If someone doesn’t want to talk to you with that pitch, you might be barking up the wrong tree with your idea. That initial response, if you can’t just explain what you’re trying to build to someone right away, and if you can’t get a meeting, it’s probably worth reflecting on what you’re doing, and maybe tweaking, and then trying some different approaches, trying some different messages.

Because if you can’t get a meeting, it’s going to be really hard to get a sell. It’s going to be really hard to get a user, it’s going to be really hard to convert them into a paying customer.

But if you explain to someone, most people love to talk to entrepreneurs starting companies, especially if they can really clearly communicate what it is they’re trying to solve. And that validation early on goes enormously towards then calling that person back in three months, and saying, “Hey, we got a first beta ready, would you like to take a look at it?” And getting those first 10 is hand-to-hand combat.

Really the first hundred is hand-to-hand connecting to people, showing them the product, showing them the value, and getting to use it. Every once in a while, you have these runaway crazy successes, where everyone’s like, “Oh, my gosh, I can’t believe – how did we live before this existed?” But most of the time, it doesn’t work like that. Most of the time, you have to connect, talk, demo, listen to the feedback, and go back and consider how far on or off your strategy you are.


Michael Schwartz: I said it was my last question, but now you just raised another question, and I can’t resist. Previously you mentioned that a lot of the leads for customers were from inbound, from customers who use the software, liked it, and then called you to purchase a support subscription. But 50 deals a quarter – that’s a lot of business. That’s really pretty stellar. And I’m wondering, what’s the right mix of inbound and outbound marketing sales to push for, or how do you balance that?

Shannon Williams: First step for all of this is find a real market. When you find a real market, things get a lot easier. Because you have to have something going on that’s causing people to look for a solution, they have to have a problem.

So, to your question, if I had my druthers, I’d have a 100% coming inbound, so everything coming inbound means that the market is actively looking for solutions. My brand is well enough known, we are the company they should at least talk to about this to get a demo. Ideally, it’s open-source, just download it, and install it, and try it, and see what you think.

I, from day one, believed in inbound as our goal. So, that meant, instead of spending a lot of our early dollars on advertising, for example, I spent almost everything we did, online communication to users. And that meant, oh, my goodness, we wrote dozens and dozens of pieces of content explaining how to use Containers, and Kubernetes, and Docker, to help people find us.

They may not be looking for Rancher, but they were looking to solve a problem. And so, we really tried to build a list of the lots of the problems they were trying to solve.

We hosted an online meet-up every month that grew to have thousands and thousands of people register every month. It was crazy. We just run them today – I just did one last week.

And what we said was, “Hey, come, it’ll be our smartest technical people. We will stay as long as you need. We’ll demo whatever it is we say we’re going to do. I won’t just show you a bunch of slides, we’re actually getting this code, we will teach you how to do it. And we will stay until every Kubernetes questions are answered.”

So, these things would run two hours, three hours, but they allowed people to cross hurdles, to learn how to build the CI/CD Stack on Kubernetes, or how to do monitoring on it, or how to deal with logging, or how to use containers and the cloud – whatever it was we were trying to solve that month, we really focused on it. It was really that. It was education, community, content that, coupled with early references that we built by hand, in that hand-to-hand phase, got the word out.

By continuing to invest in that, we were able to kind of sow so many seeds of open-source users that as they matured, and liked what they usd, they contacted us. The right mix for me is a 100% inbound from the open-source community. But what we did find was, as we grew, we started to run into bigger organizations. They have entrenched vendors.

All of a sudden, we might have won a line of business users, and then they just said, “Hey, we love this Rancher. We are going to use it for application A, B, and C.” But 80% of the company was using something else that they’ve maybe built themselves, or maybe they bought something, some other product a couple years ago to do PaaS, or something.

And so, because those organizations started to look and say, “Why aren’t you using this? Why are you using Rancher?”, we had to support them and show other people in the organization, “Well, actually, this isn’t the same. It’s different, and here’s why it’s different.” What we did find was there was longer Enterprise sales cycles, so we needed good high-quality sales people to work with bigger companies.

But the positive was, we found that those companies actually really appreciated that it was open source. And the fact that you already had one over, a group of people who really loved it internally, meant that you kind of solved, in a lot of cases, the biggest problems these IT teams were facing, which was, they were building stuff and no one was using it anyway because they were just going to the cloud, they were building something themselves.

So, when we could tie together, the IT organization, which is like doing everything they can to support forward-looking development while still being secure and still being cost-conscious. And teams that have usage and feel like they’ve got found something cool, it was just like made it for a much easier sales motion than your traditional either selling top-down or kind of getting some executive buy-in, and then hoping people use your product once it was brought in.

I don’t know, does that answer to your question, Mike? I kind of feel like I ramp up there.

Michael Schwartz: Yeah, that’s lots of great info. Shannon, thank you so much for joining us today, and being so honest with your answers.

Shannon Williams: Mike, it was my pleasure. Thanks for doing this. I love your idea of open source entrepreneurs just sharing and talking about what we do. I think it’s a phenomenal business model. It is a real transformation of the relationship between the developer of a really powerful software and the consumer of that software. So, it’s something I have enormous passion for.
Michael Schwartz: Best of luck with Rancher, and congratulations on all the success.

Shannon Williams: Thank you so much, Mike. You too. Have a great one.

Michael Schwartz: Thanks to the Rancher team for making this happen. 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 by Natalie Lowe. Operational support from William Lowe. Transcription by Marina Andjelkovic.

The Twitter handle is @fosspodcast. Rate us on iTunes if you like this episode.

Next week, we have James Waters, SVP of Product at Pivotal. Until then, thanks for listening.

Episode 38: npm Inc.– From Software Registry to Software Business, with Isaac Schlueter, Chief Open Technology Officer

Isaac Schlueter emerged as one of the most important leaders from the Javascript community. As Chief Open Technology Officer of npm Inc, the company behind the essential software registry, he has a bird’s eye view of what makes Javascript such a unique ecosystem. And his mission was also unique: to transform a free public utility into a viable enterprise software business. This episode was recorded in person at the Open Core Summit.



Michael Schwartz: Welcome back to Open Source Underdogs. I’m your host, Mike Schwartz, and this is episode 38, the last in-person interview recorded at the Open Core Summit. Our guest is Isaac Schlueter, CEO of npm Inc.

Many programming languages have a central software registry, but the JavaScript npm Registry is unique. It’s the biggest and the busiest by far. For example, it has around four times the number of modules as a number two registry, which is Maven for Java.

If you want to learn more about npm, Isaac was a guest on Founders Talk Episode 61. And for an interesting perspective on the npm ecosystem, you might want to listen to Changelog Episode 355 – it’s an interview with C.J. Silverio, as a former CTO of npm Inc. She provides an interesting perspective on the economics and the technical challenges of running the world’s largest package registry.

I hope you enjoy this episode. And if you like it or you’d like to start a discussion, tweet at us. Our Twitter handle is @fosspodcast.

So, without further delay, onward with the interview. Isaac, thank you so much for joining us today.

Isaac Schlueter: Hey, happy to be here.

What Is Npm?

Michael Schwartz: Some business people listening to this podcast might not know what npm is or what it does – can you give a really quick explanation?

Isaac Schlueter: Sure, this is my very fast 50-cent tour. Basically, npm is a way for JavaScript developers to share modules of JavaScript code. So, if you have some reusable function, something that you’re using in a bunch of different places, they can publish that up to the npm Registry. Other developers in other projects can use npm to install that dependency and also keep up-to-date when there are updates to it.

If you’re depending on a platform, or a module, or a library, or something, you can automatically pull in all of those updates and keep your app up-to-date.

Why Inc. Not Foundation?

Michael Schwartz: Most other package ecosystems are supported by a foundation, for example Ruby, or maybe Python – why didn’t that work for JavaScript and npm?

Isaac Schlueter: There is a couple of reasons for this. The first one is, if we go back to the kind of the history of npm, when I decided to start a company around it, it was my side project for about four years.

And it grew in popularity. It was running on donated infrastructure from this company, Iris Couch. We just grew to a point where the scale was too massive for them to be able to afford to keep doing that.

I looked at my options, and starting the foundation was definitely on the list of things that I could do. Another option was, find a home for it in some big company, try to get hired by Google or Microsoft, or somebody.

The reason why I decided to start an independent company was simply owing to the scale and the rate of growth that we were seeing. So, the typical way that a foundation operates, you raise a bunch of money from a bunch of companies who have some vested interest in whatever the thing is, whether that’s an open-source project or some other thing. And then, you spend that money on keeping the thing going, so that might be, having developers work on the project, your managing governance, or marketing, whatever.

Within npm, we had this exponential growth curve that we are still at the very beginning of, in terms of the number of users on the npm platform. We’d grown to about a million users. Our rate of downloads and package growth was just astronomical.

The JavaScript language is used in pretty much every application out there. There are Ruby developers, there are .Net developers, there are Python developers, but the front-ends are all running in JavaScript, and everybody was increasingly putting more and more stuff into npm and using it very widely.

So, we kind of did some back-of-the-envelope math and realized like, “Okay, well, we could go, raise a couple million bucks to start a foundation and be able to put some resources behind this thing. But what are we going to do next year? We’re going to need 10X as much. And then, the year after that, and the year after that.

The task of just kind of continually being in fundraising mode was pretty daunting. Especially because it’d be hard to justify that the benefits to each of those member companies would also keep increasing enough to justify them, increasing their investment.

On the other hand, if you have an exponential growth curve of almost anything, even rising costs, you can take that to an investor and say, “Here’s the thing: it’s a thing that’s growing, it is a thing that’s exciting.” You can tell a story about how you’re going to go about monetizing that in the future, and that’s something that is sort of a good fit for a venture-back startup.

Npm Products

Michael Schwartz: Most people use npm for free – what do you actually sell?

Isaac Schlueter: We sell two main things right now. The first is npm Orgs product, which is a multi-tenant SaaS thing that you can use to store your private code within your organization. That’s used primarily by smaller companies or front-end development teams within larger companies.

The price point there is $7 per user per month. It grows depending on the size of the Org, you can have multiple packages all underneath that same Org.

The other thing that we sell is our product called npm Enterprise, which is a single-tenant instance of the npm Registry and website. It has some additional features, like single sign-on, or security policy enforcement, that kind of thing, which is more of a need at bigger companies.

Market Segments

Michael Schwartz: What kinds of companies use the Enterprise products – do you segment the market at all?

Isaac Schlueter: The sweet spot for us is about development team of 50 or more. We do some market segmentation to go after different sectors. There are some sectors that we focus on, but obviously, we will sell it to anybody who wants it. There’s a fair amount of inbound that comes in as well.

We’re seeing the most traction in sectors that have really high compliance, policy and security compliance needs, so financial industry is a really big one. And there’s also a ton of customers with money to spend on their development practices, and they get a lot of benefits by having their developers able to build things in a more frictionless way.

The other sort of category of markets that we go after, where we’ve seen some good results, are companies where there is sort of an internal agency model, where you have a web development team that has multiple different website properties.

There might be hopping between different websites that are all kind of under one big corporate brand. And in that case, there’s a lot of benefits to being able to reuse those modules.

Also, frequently, in both types of companies, once a company gets to a certain size, there’s often like a tools team or kind of a platform team that’s in charge of all of the reusable JavaScript code that’s used across all of the different properties. And in those cases, they also benefit a lot by having something like npm in-house.

Marketing / Sales

Michael Schwartz: In terms of marketing, you were sort of starting from a nice position because everyone knows npm – how do you organize sort of the marketing effort so that people know what the commercial offering is? And how do you organize the sales – do you just wait for inbound or you do any outbound marketing?

Isaac Schlueter: We do a fair bit of outbound marketing, and it’s a little bit of a double-edged sword. Everybody knows npm, but not everybody knows npm Inc. or npm Enterprise.

One of the challenges that we ran into, which I think is common among a lot of companies that are operating in open-source communities, is that people have heard of the thing but they haven’t really heard of the product.

One of the things we heard is, “Oh, npm? That’s a company??” I just thought packages came out of the ether. I didn’t realize it was downloading from somewhere.”

So, when it comes to our marketing efforts, a fair amount of the work there is in continually beating the drum of like, “Yeah, we have things for you.” “If you need policy compliance, if you need security, if you need proprietary code, and you want to manage it, using the things that your developers already know and love, then we have a solution for you.”

When we go through the sales process, typically we have an internal champion, which is usually engineering architect, or engineering manager, or something like that, who sort of intuitively understands the benefits of npm.

Then, the sale process tends to be one of making the case to folks who are not already deep in this ecosystem. That tends to be people in kind of like internal development tools, purchasing team, the CIO’s office – it can take a couple of different shapes, but, you know, the folks within a large Enterprise who managed to spend on development tooling.

Free V. Commercial

Michael Schwartz: Diverting a little bit from marketing, one of my guests said to me that it’s almost better to start a company around a product that you don’t write, an open-source product that you don’t write, because all those engineers who are working on the open-source thing, they’re not billable, or they’re not contributing to their commercial product – do you feel that friction at all, where maybe part of the team is really committed to the community mission but maybe other parts of the organization are more interested in the product than actually generate revenue? How do you reconcile that?

Isaac Schlueter: It can be a tough needle to thread. I mean, not to dispute the past guest who said that, there’s some sense in what they’re saying, but obviously, I do disagree because of what I’ve done.

I think that the challenge, or at least the puzzle, is to figure out how do we continue to make good on our community mission in such a way that it serves our product interest, and how do we design our product interest in such a way that they’re served by the success of the open-source community.

We have certainly made some missteps in the past. One of the biggest things that makes good intuitive sense. You have an engineering team, you have a web team, you have a backing team. Of course, you’re going to have an open- source team, but the minute that you start doing that, you create this unhealthy dichotomy.

Even if it’s just in your own thinking as a founder, and as a manager, as an entrepreneur, where it can be very easy to get into these dysfunctional patterns of being resentful about, “Well, these five engineers are spending all their time on the open-source stuff, and we’re just giving that away, and how is that helping the company?” “And here I am, busting my hump every day, trying to make our website better, and trying to sell products and trying to get new log-ins and new sign-ups.”

And every time you want to build some new thing, it’s like, when we run into this case of like, “Should we give this thing away or should we charge for it?” And the thing that I’ve come to after five and a half years of doing this is – if I was smarter, maybe I would have come to it sooner –
is just that that’s the wrong question.

The minute you find yourself asking, “Should this be free or should it be paid?”, you’ve already kind of committed the fundamental thinking error of putting those two things at odds.

The better way to think about it is, “What is the free thing that will get someone to pay for this?”

So, what can we give away in such a way that it will open the door for an upgrade path, and that will open the door for a paid product that is a very clear enhancement to the thing that they’re getting for free.

Some of the best companies in the space that I’ve seen tend to have an approach of, like, their explicit goal is that individual developer should never have to pay for our product. But, a company should almost always have to pay for it.

And that really clarifies the thinking, and it clarifies a puzzle in a really interesting way. Because anything that involves a team of ten people, writing a proprietary application, like, they got to pay for that. That’s a company, that’s a for-profit company.

Now, okay, it could also be like a school or it could be a nonprofit org – you can always give those folks a coupon, that’s not actually a problem. But with our Enterprise product and with our Orgs product, I think we’ve done okay. Orgs are free if they’re open source.

If you have five people collaborating on an open-source project, and they want to keep a bunch of modules under a namespace, they don’t have to pay for that if it’s all open source. And we really see that as part of the nice, easy transition from like an individual working on open-source, a group working on it, and then up to a group working on some kind of paid product.

One of the things that we did not anticipate when we made Orgs free was actually it increased our paid Orgs signups.

We’d always intended to do some kind of, like, first month free, type of trial type of thing, and just kind of didn’t get to it because it takes time and attention, and there’s only so many people and only so much code you can write in a day.

And we decided that we want to make Orgs free for open-source projects. Because there was a handful of different open-source projects, and we gave them an Orgs, one of our database markets just went free. And we were kind of like, “We should just make this a thing.”

When we did that, what was surprising was, people at companies would sign up for a free Org, add their whole team, try it out for like an hour, go, “Okay, this is going to work, and then, they’d flip the switch to be a paid org.

That’s for me when kind of the light bulb went off. Like, “We should not be thinking about what is paid and what is free, we should be thinking about what is free, so that it makes it easier to buy the paid thing, if you need it.


Michael Schwartz: So, it was all on the honor system? You could sign up as an Org?

Isaac Schlueter: You couldn’t publish anything private. You couldn’t have a package in your organization that had access control attached to it. Anything you published in a free Org would be open to the entire world.

Michael Schwartz: You really almost had to invent a business around this because I can’t say there was like any direct model you could choose. And one of the hardest parts of that is figuring out what to charge for that, especially because you didn’t have a lot of data. I’m wondering since you started the last five years, have you had to pivot on the pricing model a couple of times? Or has it been relatively stable, and did you get it right?

Isaac Schlueter: Yeah, we just stuck the landing – it’s been perfect. No problems at all. I wouldn’t say that we’ve pivoted on the pricing model. We have made some changes that I think are somewhat subtle. And most of those I’ve been owing to user experience.

Around in 2016, or beginning 2017 I think – I forget the exact dates now, it’s all lost in the mists of time – when we originally released our Orgs product, our paid Orgs product, basically an organization, again, you build things in the simplest way possible with the stuff you have because you’ve got to ship something, and if at one point it was perfect, you waited too long. And just the easiest way to do it was to say, “An organization is a subscription that belongs to a particular npm user.”

That gets us into some real interesting subtlety I think that not a lot of Org users, then or now, really fully appreciate it. But the idea was, your Org would have an owner – that was an npm account.

The real big problem that came up, and it came up fast, was, well, what happens when that user goes away, what happens if they leave the company and now what. It’s still billing to their account and their account has this credit card attached, it is a corporate credit card, and like, the only way to resolve it was actually to go through our support team, which, I love our support team, I think that they’re great, they do great work, and I’m really happy that they’re there, and supporting our community, and our customers, but every time somebody has to contact support – that’s a mistake we made, that’s something that we needed to fix.

So, we kind of went back to the drawing board and said, “How do people think this works? How do users think this Orgs thing works?” They think that they create an Org, and they think that they just pay for the Org, and the Org has some user who is administering it, but they can change that user.

So, what that said to me and what we kind of landed on was, the organization itself should be the primary first-class kind of billing entity. And then, the user account of the subscription, and everything else, is attached to that organization, not to some individual user.

Then, that shift, due to some other sort of subtleties, and how it was implemented, we realized that if we made this transition, a bunch of Orgs, who are currently not paying for users who have access to their packages, would suddenly have to start paying for those user accounts.

And the way that we addressed it was, we just collected all of those cases where that would happen, and we applied a coupon to all of those accounts to give them a discount and said, “All right. Like, your bill isn’t going to go up.”

Yeah, we probably could have just said, “Well, bad news. I know you’re paying $7 a month now, but it’s now going to be 21 because you got these other two users that technically are part of this other Org, even though they’re in your Org also.” And it got really hairy, but we figured that the user experience hit just wasn’t worth it like, “Thank you for being an early subscriber, an early adopter.”, but moving forward, it really vastly simplified it.”

The organization is a top-level thing, it’s like a first-class entity in our system. Every user account costs 7 bucks a month – that’s it. There’s no like discounts if you’re in multiple Orgs or anything like that.

Nobody complained, some folks got an email that said, “Hey, you know, we’re changing our pricing model. This would make your bill go up, but here’s a discount, so it won’t.” There was basically no reaction, which is what we’re hoping for.

Now, our Enterprise product, regarding pricing, yeah, we’ve been all over the map there. You talked about there not being data, well, with a self-serve product, you have quite a bit of data. It’s really easy to just throw a survey out there, and like, yeah, it’s going to be noisy, and you’re going to get a dozen people were like, “Oh, I wouldn’t pay more than a penny.” But you can wipe out the outliers, and get some kind of at least directional data.

One of the things we found was, there’s already some services out there, like GitHub costed 7 bucks a month for Orgs at that time. I think they’ve since changed their pricing model for their Orgs products, so it’s like $25 for the first 5 users and then $9 after. We thought about doing something like that in our sales, mainly in the future. Just to kind of help people get over that initial hump.

But once you had your first 5 users, it’s very, very sticky. The easier we can make that seem, it’s like 25 bucks and you get 5 users – that seems cheap. But if it’s $7 a user, and you only had two users, there’s a pretty good chance you might not like stick with the product. If you get those 5 users in, now you’ve got five people all collaborating on code, and they’re not going to abandon that for anything because now it’s kind of in their process.

So, with the Enterprise product on the other hand, there really is almost no data, and it’s very difficult to get that data. A lot of Enterprise products, even if you go to like companies, providers, websites, and you look at their Enterprise products, it says, “Call us.” You are kind of in this like arm wrestling match with the procurement department, where your price is, like, you give us ‘whatever we can get out of you’ basically is the price.

I think with our Enterprise product now we start at $50 a seat, and the product has quite a bit more features in it than our previous generation of our Enterprise product which was quite a bit cheaper. And we also have a minimum number of seats in order to qualify for an Enterprise product. We don’t offer it for less than 20 seats.

The nice thing about that is that it immediately selects out everybody who’s not actually going to need the benefits of this product, who is not going to need the policy enforcement and security features of it.

They are not going to be as well served by that product like they should really be buying Orgs. So, it’s tempting to look at pricing as like the way that you make money, but really, another way to think of it is like, how does a pricing act as a filter for who should be using this thing, and how does it work as a signal.

If you have a product, and you have your product break down your pricing page, or whatever, there are companies that are going to just look, and they’re going to say, “I don’t want the cheapest one, I don’t want the most expensive one – give me the one in the middle. I don’t want to look at all these words.” And they’re just going to buy it.

You need to think of, like, who is that user, who’s that persona and kind of focus your research there, and then, work backwards, like, “What is their budget? What can they pay?” And then from there, you’ve got pretty good answer about your price.

Every Enterprise is going to try and make some argument for why they should be paying less. So, start high and let them push you down. And also, like, if you don’t start high enough, then they’re not going to think that it’s legit.

More On Pricing

Michael Schwartz: Was that one of the hardest parts of migrating from I guess open-source repository or open repository to business? Just getting that right?

Isaac Schlueter: On the list of hard things, that doesn’t even make it top 10, there is quite a bit that’s much more challenging. I mean, the other thing about product is, I think it’s really much more art than science, and certainly, there’s product managers out there who are like pounding the table as they listen to this, and sure that I’m super, super wrong about it.

But, so much of it is, you need to figure out a price that you won’t go bankrupt. And then, you need to figure out how to sell that at that price. And the specific number, is it 8, or is it 9, or is it 20, or is it 25.

I think at the end of the day, that probably matters a lot less than have you built a product that people want to use, and have you priced it in such a way that it sends a signal that those people actually are the ones who should be using it.

If you look at the pricing of wine, great example of this — I don’t know, I’m going to offend some wine snobs in your audience, I apologize – a lot of the pricing of wine is like completely arbitrary.

It’s like, are you somebody who likes the expensive wine or who doesn’t care, or you’re like somebody who kind of wants, “I want it to be good, but like I don’t want to spend a lot.” I mean, all wine, it’s all fermented grape juice. It’s not that different, it’s essentially just overstock of wine, that’s why they’re able to sell it so cheap.

But that price signals a particular kind of buyer who is likely to benefit from that product. And on the other end of the spectrum, it’s the same kind of thing. You’re buying this $500 bottle of wine because you want to show off how rich you are, and in order to show off how rich you are, it has to cost $500. And so, that’s why people buy that.

In the world of software product management, we like to pretend that we’re a little bit more rational because we’re all like tech people and we are very cerebral and logical. We do math, and it still largely just kind of comes down to like, what are the products that your product is like, how much do they cost. If you just copy them, it’s probably you could do a lot worse.

Lessons Learned

Michael Schwartz:  So, now I have to ask a question – what were some of the hardest challenges? Please, take top, one or two.

Isaac Schlueter: I set myself up to that one, didn’t I? I mentioned a kind of the split brain that can happen within an organization when you separate out your free, or open-source, or community offerings from your paid offerings, and think of them as different things. That’s a very, very easy error to make, but it’s a very pernicious one that really gets in everywhere.

And I think it, in order to avoid that error, you have to think about that design, not just in your product design but actually in your organization design, in your strategy, in your go-to-market, in where you get your investment from, and who you have on your board. Like it has to really, really inform everything about your company in order to steer yourself away from that kind of problem.

Another big and easy mistake to make is having an on-prem and a SaaS product at the same time early in companies like them. Eventually, you’re going to need to have an on-prem product. And if you’re positioned well to do a bottoms-up sale, that has to be a SaaS.

Because no development team — if it’s five people on a Dev team and you’re trying to convince them to use this tool, they’re not going to spin up a server and install it and operate it themselves – they’re just not set up for that. If there’s a SaaS offering, they’re going to take that one.

And as an early stage company, when you’re talking about like 10, 20 people, if you are building products, like you’re going to take every single shortcut you possibly can. And the biggest shortcut you can take, if you have an on-prem product and a SaaS product, is to start putting big ‘if blocks’ in your code base. And you can tell yourself like, “Oh, they’re the same code base, were totally keeping them in sync.” It’s all one big Dev team.

What’s going to happen is, even the same developer working on both things is just going to put a big ‘If Block’ and say, if process dot, end of dot enterprise equals true, and then basically fork in place, which is even worse than actually forking two code bases. Because now you have this kind of like convoluted ball of mud.

We originally did have an on-prem Enterprise product, we still have some customers who are using it, even though we’re still trying to kind of like nudge them to our Enterprise SaaS product. We reached a point as a company, where we sort of realized we can’t keep running this Enterprise product, we’re actually losing money on every sale, because the cost to support and operate and get a customer up and running is just too high.

So, we pivoted somewhat, we kind of instead said, “How do we take what we do with the registry and with the website, with the Orgs and everything else?” “How do we make a SaaS offering there?” And what do the Enterprise customers actually need for that?”

We’re still figuring out kind of how to play in that space, and how to best have that integrated and connected with our self-serve products, but it’s still a huge step in the right direction. I think hindsight being 20-20, going out the door really in our first year with an on-prem Enterprise product and a SaaS team’s product at the same time, seemed fine. It seemed like a good idea at the time.

A bunch of people told me, “Well, you need to really make sure that the code bases don’t diverge if you do that.” I heard that from a bunch of folks at GitHub, who made the same kind of error, and I was like, “Okay, noted. Don’t let the code bases diverge.” Got it. What they didn’t tell me was, “You’re going to let the code bases diverge. That is absolutely going to happen – it’s inescapable.” You can either be a SaaS company or an on-prem product company, and those two companies are very different shapes.

If you’re going to be an on-prem product company, that means there’s a lot more of a top-down sale most likely. Or it just has to be so easy to install and start running like on a laptop. It’s almost certain that you’re going to need some really good professional services skills within your company, because making a customer successful with that product is going to require that you have somebody who knows how to stand it up, and how to operate, and kind of which buttons to push, and which knobs not to push, how to tell if there’s a problem – all of that stuff.

That means training, that means customer success, that means like really building in good metrics into the product itself, but in such a way that they’re not going to offend people who don’t necessarily want data collected about them, or if it’s behind the firewall, like, how that all works.

On the other hand, the way that you go to market with a SaaS product is completely different. It’s more about adding hooks and adding limits and adding these pay walls within your free product. So, when you go to your settings page, or you go to like view some metadata, or you go to view a report, or you go to add a new package, they can say, “Hey, you need to pay to use this feature. And those are two completely different mindsets.

At a certain point of maturity, you could reach a point where you have enough, maybe you fall of the bottoms up path, the bottom up path eventually gets to the top, and the top down path eventually gets to the bottom. But if you try to approach it from both sides at the same time, I just feel like that almost never can work out well. Now, there are companies that end up doing both, but if you really look carefully at the companies that are successful doing both, most of them started on one end, and then made it to the other.

Either they started as a top-down company, and they did well enough with like evangelizing, and marketing, and getting adoption, and gaining traction within these large companies that it became sort of a de facto standard. And then open-source parts started to kind of become the way that developers expected to do things.

Or they started as a bottoms up strategy, where every developer just eventually started to expect that this is how things work. And when they came to a big company they said like, “We need to sign up for these.” And then, eventually, they built out features that built up to that enterprise-level. And obviously npm loses position to do the bottoms up thing, and so, approaching both the same time was — I would not do that again.


Michael Schwartz: What’s your approach to building the team?

Isaac Schlueter: Before there was a company, there was me and there was one guy who was in Thailand. Another couple of folks, one was in Eastern Europe – again, this was a whole donated infrastructure stuff, so whatever that other company was doing. I didn’t really recruit them, it was kind of just like who I ended up with. And luckily, some of them were really good. A lot of npm’s success really owes to that.

When we founded the company, you know, it’s easy to forget now, because it doesn’t feel like it was that long ago, but video conferencing was not as good as it is now. Chat apps were not as good as they are now. Slack didn’t exist, Zoom didn’t exist. I think Zoom might have existed, but it wasn’t what it is now. It wasn’t back then easy-to-use.

So, initially, we would focus our hiring on the Bay area, which seemed reasonable. It’s what you do, it was a Bay area startup. We opened an office in Oakland, mostly because that’s where I live. We went from there, so that the initial team was almost all coming from Oakland. There’s one person we got doing op stuff, who is in South Africa. And part of the challenge was like adding remote people was really hard, because the whole team is there in Oakland.

Like, we’re talking about strategy, and tactic, and products, and technical direction, and stuff over lunch, out everyday, like, it’s really, really hard to keep people in the loop if they were not colocated with us.

We eventually moved from IRC to Slack, and we started doing more and more stuff on Slack. We found that we actually needed to have a little bit more time zone coverage. So, we added some other developers, we hired somebody who was in Europe, and that really pushed us to operate in a more distributor friendly way. So, doing more of our discussions on Slack, having our meetings with Zoom.

We kind of just kept adding remote people. It was like, “Well, there’s those two developers we want to add, we want to hire.” And like, can they do remote, and one of them is remote, and you do that again, again, again, and after a while, it got to a point where like, our CEO is in Halifax, our CTO is in Toronto, I’m here in Oakland. We have this big beautiful office, and I’m one of like four people in it.

When we rented that office, we had this plan to like eventually grow to 50 people. And we were looking at the office we were in. We were 13 people, and we did not fit. We had a single conference room, a single room with a door that closed, and we grew to about 13 people, and we were just like, “This is ridiculous, we got to get out of here.”

We found a bigger space, we knew that we would end up growing to between 30 and 50 people over the next couple years, so we’ve rented the space that could house that many. I think it was just a few weeks or a month ago actually, or maybe a couple months ago, where we had this interesting situation where our landlord wanted to move us to a different spot within the building.

You know, we’ve been thinking for like a year how stupid it was that we had this big Oakland office, and like, we’d really like to get rid of it, but we’ve got another year on the lease. And they’re like, “Hey, we want to move you from the 11th to the 5th floor.” And we’re like, “How about we just leave?” They are like, “Yeah, cool. We get to rent the space out at 2019 prices instead of keeping your lease? Yeah, go.”

So, it actually worked out great. It was a little bit sudden, the way that sort of fell on our lap. But yeah, now we’re just 100% remote, everybody works from home, and that freed up a lot of capital for us to actually offer like a monthly work from home allowance, to cover things like internet, and the desk light, or whatever work expenses you might have, whereas previously, it was like we really can’t afford to do that because we’re spending our whole office budget on an office.

If you want to work in the office, like, we got this great office, but most of our staff was not in the Bay Area. So, in terms of like, where do we recruit people or how do we find talent, we do get a lot of resumes, we do get a lot of interest especially in technical roles.

When it comes to other roles, when it comes to non-technical roles, things like sales or marketing – I hate that term ‘non-technical’, like, the profoundly technical jobs, but if I want to hire a product manager who doesn’t write JavaScript, if I want to hire a VP of finance, it’s kind of the same thing every other company does.

We use a combination of just our networks, which has some pros and cons. The obvious pro, hiring somebody you know is you know them, so there’s a good chance that there’s a little bit more of like a connection, they may be a little bit more motivated to make it work, etc.

The downside is, you probably know people who are like you, and so you can very quickly and easily get into a bad cycle, where your kind of diversity just goes off a cliff. Or even worse, we’re like people who are kind of in the crowd, or like included in decisions, or have a little bit more power or authority within the company, then they probably sort of can get very like toxic and weird that way. I think that we’ve avoided that for the most part.

The other thing we’ve done in, especially tough to find rolls, we’ve had some success with executive search firms, we’ve done that a couple of times. And then, also posting stuff on LinkedIn, on Lever, on our other social media channels. We have our own npmjs.com/jobs that shows what roles we have open, and people apply for them.

Advice For Entrepreneurs

Michael Schwartz: The last question. Any advice for new entrepreneurs who are starting a business where open-source is a part of their business model?

Isaac Schlueter: I talked about this a little bit, but I’m going to go ahead and just repeat myself, because I feel like this is really important and really easy to miss and really easy to not understand the importance of it.

You have to craft your plan such that doing the free thing actually serves your strategy. And there’s a lot of subtlety to that. I don’t have like one weird trick that will fix everything. But you definitely need to think of, like, “If we give this thing away for free, what happens?”

Part of the thinking there is, imagine that you have like ants roaming around on a dirt floor or on the ground, if you pour some honey in one spot, that’s going to change the whole ecosystem. And that’s kind of what happens when you start giving away something for free, whether it’s an open-source product, whether it’s a service that you say, like, “This is free for open-source packages or for open-source projects, or for open-source users whatever.”

You’re creating a pile of honey in the middle of all these ants that are currently just kind of roaming around in their own different ways, like, they’re all going to find it, and they’re all going to come to it. It’s like, “Okay, now what?” What I mean by that is, when you get something away for free, you are fundamentally kind of like disrupting an ecosystem.

It’s important none of the ants are complaining about the honey, but you’ve now changed the shape of the scenario. And that can be really, really good, or that can be really, really hazardous.

It’s tempting to be like, “Oh, I’m charging for this thing and I’m giving this thing away.” And how do I convince the free people to buy the paid thing? Like, you’d really need to back several steps up and think, “What do these people need? What’s the thing that I can sell them that will address that need? And what’s the free thing that’s going to drag them over?” Instead of saying, “What do I give away for free?”, and then separately from that, “What do I pay for it? How do I balance these two?” They have to be one thing in your mind.


Michael Schwartz: Isaac, that was super interesting. Thank you so much for joining us today.

Isaac Schlueter: Thanks for having me.

Michael Schwartz: Huge thanks to the Open Core Summit for connecting us to Isaac and for volunteering their only sales office to provide a quiet place to record. Don’t miss the next Open Core Summit. It was one of the best conferences I attended in 2019. Where else can you get a critical mass of open-source founders in one place?

It’s essential that we foster an event like this so we can share experiences about what’s working in open-source business.

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 by Natalie Lowe. Operational support from William Lowe.

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

Please, subscribe to the podcast on your favorite podcast platform. Every subscription helps. Next week we have Shannon Williams, one of the founders of Rancher. He was fantastic, so don’t miss this one.

Until then, thanks for listening.

Episode 37: Storj – AirBnb for Your Disk with CEO Ben Golub

Ben Golub has lead several open source software ventures, including Gluster and Docker. Storj monetizes open source by creating a distributed file storage network. Using the network, people can securely store files. And owners of Internet connected computers can put their unused disk capacity to work. To lower transactions costs, Storj launched a true utility token, which has intrinsic value. It simplifies transactions of an alternate 150+ fiat currencies. This episode was recorded in person at the Open Core Summit.



Michael Schwartz: Hello, and welcome to Open Source Underdogs. I’m your host, Mike Schwartz, and this is episode 37, with Ben Golub, CEO of Storj.

I was really excited to schedule this episode because for a few years I’ve been wondering if there’s some cryptocoin business model that might work in the open-source world.

This is the second of three episodes that we recorded at the Open Core Summit in San Francisco in 2019. It was a fantastic event for open-source teams and founders, and I highly recommend attending the next one.

Ben was previously the CEO of Docker, he was also the founder of Gluster, which was sold to RedHat. He has a pretty deep understanding of the trials and tribulations of building a business around open-source.

After finishing the interview, I wasn’t 100% sure this was really an open-source business model after all, but Storj is definitely one of the most unique companies I’ve ever learned about. So, with that said, let’s roll the proverbial tape.


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

Ben Golub: My pleasure.

Michael Schwartz: Ben, before Storj, you helped found a company that launched a little product called Docker – can you tell us a little bit about your journey? How did Storj come about, and why did you move on from Docker?

Ben Golub: Yeah. I’ve now been at 8 startups, four CEOs, so I’m a glutton for punishment. I actually started my career doing international development, so my first failed startup was a business school in Uzbekistan that had a business model, which was I think, “Teach people how to read a balance sheet and then democracy will flourish.” And that didn’t quite work.

But from then on, I’ve been involved in sort of the first version of the web, ran a number of businesses at VeriSign, was the CEO of Plaxo, was the CEO of Gluster, which we sold to Red Hat, and then ended up at what was dot.Cloud, and it eventually became Docker.

Right at the time, Docker had this crazy notion of taking a container that we used to run a PaaS and said, “Hey, can we make this available to the world?” And Solomon Hykes, the founder, and I introduced this notion of a container. And I think in sort of excellent open-source fashion embraced the community, embraced something that was disruptive.

We saw it grow, and it became tremendous. I think it helped change the industry and became a driving business. I’m an early-stage startup guy, I’m not a late-stage startup guy, and I think that once you want to get to a certain size, where it’s 500, 600 people, and you’re closing in on a hundred million revenue, there are people that are better at scaling PaaS than I am.

So, I moved on. I still obviously love the company. And then, I got approached by Shawn Wilkinson, who had this crazy notion as a student at Morehouse College that you could build Airbnb for disk drives, and that’s what I’m doing now.

Is Storj Distributed S3?

Michael Schwartz: I think of Storj as decentralized S3.

Ben Golub: That’s absolutely accurate. Deliver something that’s S3, its cloud storage, but it’s delivered across a huge network of disk drives that we don’t own, that are run by individuals and data centers.

How Does Storj Make Money?

Michael Schwartz: So, for every dollar raised, 60% goes to the person with the hard drive? The other $0.40 I guess goes to storage, the company – how do you use that $0.40 to help build the ecosystem?

Ben Golub: It’s a really good question. One of the most important things that we do is, we sort of build equivalent of really large self-storage data centers, without spending any capital, and we just compensate the people who run the nodes.

We are onto the same thing on demand side as well, so rather than hiring hundreds of salespeople and giving away open-source software for free, we’ve come up with the notion that open-source drives 2/3 of the cloud, so we give a portion of our $0.40 to any open-source software company.

Usually, our way is, we also have partners in the Storj space, we are partners like Mongo, FreeNAS, FileZilla and Influx, and it’s really a great win-win.

Who Are The Users Of Storj?

Michael Schwartz:  Who are the users of Storj? What type of applications is it good for?

Ben Golub: Its really general object storage, which means that anybody who’s generating a large file that is going to be read a lot, it’s an excellent use case for us. That’s good for backup, it’s good for serving videos. It’s good for distributing software.

 The world of course creates lots and lots of data every year, and about 90% of it that’s being created is sort of large files, which is a perfect use case for us.

Why Use Storj Over S3?

Michael Schwartz: Some would say that you have to be ten times better than a previous existing solution to motivate people to move – why would someone use Storj over Amazon S3?

Ben Golub: That’s a good question. And they almost have generalized it to the centralized cloud storage offerings. One interesting note is that while the price of disk drives has come down roughly 50% over the past five years, the price of cloud storage has come down maybe 10%, during a period in which the amount of data of course has exploded.

We are significantly cheaper, we are also profitable. We are also significantly, we think, a much better security model. And we can’t read your data. It is almost impossible for a hacker to get your data, or get a treasure trove data – it’s like sort of encrypted sand on an encrypted beach.

We also happen to be faster. We happen to be 100% durable, and at a significantly lower price. What we’ve found is, there’s almost insatiable demand for people to try us out. Now, it’s early, so people are dipping their toes in the water, using test data first, or you know, low value use cases, but we think when they see what we’re doing, they’ll be here.

How Does The CryptoCurrency Work?

Michael Schwartz:  Google tells me that Storj as a cryptocurrency issued on the Ethereum platform. The price they told me is $0.1514 cents, and a 24-hour trading volume of three million, prices up 3% in the last 24 hours.

Ben Golub: Oh, it must have been my speech.

Michael Schwartz:  It is a circulating supply of $144M coins, of max coin supply of 425M coins. So, my question is, how does a cryptocurrency relate to the monetization strategy of the company?

Ben Golub: Our basic economic model is that we quote prices for Storj, and we quote them in dollars. And as a consumer of our service, you can either pay for storage with us in dollars or in our cryptocurrency.

If you are a provider to us, if you are renting out your disk drive, we pay you a dollar rate, we pay you using our cryptocurrency.

And you can either hold onto that, you can use it to buy storage on your own, or you can trade it on one of the 11 + exchanges that are using us.

Unlike a lot of other crypto companies, we’re primarily a decentralized storage company. And the crypto is a great accelerant, it lets us have hundreds of thousands of people get paid in 180 countries and build things like smart contracts. But we’re not a mining company, we are a company that is first and foremost about delivering a much better approach to storage.

Why Use A CryptoCurrency?

Michael Schwartz:  Why was the cryptocurrency a better way than just settling in cash?

Ben Golub: Well, it turned out to be very difficult to settle in cash in small amounts. It’s very difficult to do things like smart contracts using cash money. We are in 180 countries, so what we found is that having the cryptocurrency made it much better for us to build a large network.

Now, we could certainly be entirely fiat-based, but then, there would be additional fees, but this seems to align well with our interests.

What Is The Disconnect With Value And Economic Empowerment?

Michael Schwartz: You’ve said in the past that there’s a disconnect between the value created by open-source software and the amount of economic empowerment – what did you mean by that?

Ben Golub: If you look at for example the cloud market, which is now a 180-billion-dollar market, over 2/3 of all of the workloads are open-source based. In fact, if you were to include Linux in that, it’s about 90% of the workloads.

It is very clear statement to make that open source built the cloud. If you look at the total revenue generated by pure-play public open-source companies, like the Red Hat’s, and the Hortonwork’s, and Cloudera’s of the world, their total revenue is about 5 billion. So, 5 billion out of 180 billion.

If you talk to any open-source company that’s doing things in infrastructure, what you’ll find is that the primary way in which they are being monetized now is by Cloud companies, who, for rational reasons, basically give away the software for free, in order to drive consumption of additional compute cycles, or additional storage cycles.

And unfortunately, cloud computing is the biggest trend and monetization by giving away for free is the biggest way that open source is getting monetized. And there are really only four companies on the planet that are capable of running large public clouds. That to me is a huge disconnect.

Is Cloud Strip-Mining A Victimless Crime?

Michael Schwartz: On this podcast, we’ve had several guests who are worried about what we called Cloud strip-mining of open-source software, and they see it as really an existential threat to the open-source ecosystem.

And yet, Elastic, Redis and MongoDB are doing pretty well. Is this a victimless crime? And is it desirable for the companies that develop the open-source companies to capture all, or even a majority of the revenues, in the ecosystem?

Ben Golub: I agree that there are a handful of successful commercial open-source companies, I happen to have been at a couple of them, but these are just a handful of them. And almost all of the ones that you mentioned have essentially gotten to their state by spending hundreds of millions of dollars to go directly to the on-premise businesses.

And while I think it is wonderful, and it’s great that there are success stories that there are, I don’t think we would be happy if we said, “Hey, there are only five successful farmers in the world out of millions of farmers.” We wouldn’t be happy if we said, “Hey, there are only five or ten, successful companies in general.”

There is so much potential, and so much of these trillion-dollar IT industry, and 180 billion-dollar Cloud industry is being driven by open source, but if it isn’t flowing back in, then, we’re really not going to see the potential that open-source could really bring to us. In much the same way that I don’t think telecommunications was delivering on its full potential until we went to the internet.

Does Decentralized Cloud Offer An Alternative Business Model?

Michael Schwartz:  So, selling to these large enterprise customers, as you mentioned it, an on-premise software product is really expensive to scale support in sales. And it could be tens of millions or even hundreds of millions of dollars actually build that kind of infrastructure – but does decentralized cloud approach change that for these companies?

Ben Golub: Yes. For an open-source company that partners with us, if they have an open source project, whether through paid users or free users, generates lots and lots of storage. My guess is that they are generating lots and lots of money for one of the big four cloud providers, but are not seeing any of that.

Instead of trying to come up with a new kind of license, we come up with a new kind of cloud, a centralized cloud, like Storj, it’s entirely in our rational benefit to say, “Hey, if you have an open-source company that drive storage to us, we will give you a healthy chunk of the revenue that we get. And so that’s what we do.

All of a sudden, they’re able to build up a sustainable revenue source that doesn’t require hiring lots of salespeople, it doesn’t require trying to solve the multi-cloud problem for the 500 large companies in the world that they can do that.

Now, we may not be-all and end-all, we may give them the first two years of additional runway, so that they can build a sustainable base, and then go after the enterprise – and that’s fine. But getting from big community to successful enterprise sales is a really hard gap to close without the cloud.

Does The Market Value Open Source?

Michael Schwartz:  Recently I was reading an S,  and I did a search for open source, and the only place I found it, was in the risk section that, you know, somehow using open-source might come back and bite us, and we might have a liability. Do you think that the public is really aligned with this view that open source is a good thing?

Ben Golub: I think there’s no question to me that open source itself is the dominant way that software is getting written and consumed. Go to any enterprise, and it’s far more likely to find that they are open-source first rather than proprietary.

If you look, all these same things are happening, whether it’s Containers, or Docker, Kubernetes, or Mongo, or databases, or in operating systems, or in machine learning – it’s all happening in open source.

But the monetization of that is broken. It’s not that anybody questions that open source is a right way to build great software, it’s that the monetization model that used to be fairly clear has now gotten disrupted by the public cloud.

Michael Schwartz: Because one of the best monetization strategies of offering and as-a-service is now not available?

Ben Golub: It’s not available. If you are a small company, it is almost always a much better idea to say, “Hey, let me service lots of small and medium-sized customers first with something that looks like a service, rather than trying to do on-premise.”

You might eventually get to on-promise, but unfortunately, that model, which used to work pretty well for open source, is really difficult now. And it’s not only that you sort of have this gap between large community and getting to on-premise, but increasingly, even the on-premise market is now becoming dominated by public cloud.

Does Open Source Materially Contribute To The Business?

Michael Schwartz: Do you think that using the open-source development methodology materially contributes to the business?

Ben Golub: It really depends. I’d say open source is not a strategy, it’s a tool. And you have to find the right approach to open source that matches with your business strategy. But, if your strategy — Docker certainly could not have happened had we been proprietary.

We could not build a huge ecosystem and get so much usage and integration if we were proprietary. And then, the challenge becomes okay.

Now, we’ve got millions of users and billions of downloads, and lots of enterprises are interested in how we turned that into monetization. But, honestly, that’s a much better problem for me to try and solve than, “Gosh, I’ve got some proprietary. I can’t take anybody even take a look at it, and it doesn’t work with anybody else’s stuff.”

When To Open Source

Michael Schwartz:  What do you think are some of the indicators as to when the project should be — where open-sourcing it might be helpful?

Ben Golub: I think that there are a few different things to look at. I think, first of all, you want to, in any project, do that 10x thing that you said. If you’re just coming up with an open-source version of salesforce, and the only difference is, it could be slightly cheaper, that is not going to happen.

The disruption was being SaaS, the disruption isn’t on the code side. But I think that, to the extent, what you are building requires a strategy that wants to build a large top of the funnel. You know, if it’s something that’s developer-centric, if you have a strategy that depends on having lots of integration, if you have a strategy that depends on being disruptive, then those cases, I think, you want to look at open source. If you’re just an end-user application – probably not.

Storj Virtuous Cycle

Michael Schwartz: You mentioned that with Storj, there’s a virtual cycle of investment, growth monetization, and innovation – can you unpack that a little bit because that’s very concise?

Ben Golub: Sure, again, we are a different kind of cloud, and since 2/3 of cloud workload is given by open-source, we’ve sort of elected to try and make the open-source community part of our go-to-market, but in a mutually beneficial way.

In the model that we have, if you’re an open-source company, and your product generates lots of data whether by your free users, by your page users, it doesn’t matter, backups, if you build a connector that gives your user the option to send that data to us, versus another form of object storage, will give you a chunk.

What does that set up? It sets up a nice virtuous cycle, in which open-source innovates, open source generates revenue for us, like in similar decentralized networks. We, in turn, send revenue back to open source, which allows them to innovate further and build their own business models, and it continues.

Other Decentralized Opportunities?

Michael Schwartz: You mentioned that decentralized cloud is potentially a new business model for open source. And I understand how you’re saying, if you write an open-source piece of software that uses Storj for file persistence, that you could generate revenues from that. Can somebody build a company like Storj that uses a decentralized approach to something else?

Ben Golub: Yeah. There are companies – we are sort of decentralized S3, as you said. There are other companies out there, like Xiamen and others, who are trying to do decentralized DC2.

Of course, there are a lot of interesting decentralized payment companies, there are interesting decentralized CDN companies. Each of these has basically been taking a fairly horizontal use case that the cloud companies deliver, but deliver it in a decentralized way. And I think, in all cases, we would all be well-served by embracing this notion of mutually beneficial relationship with open source.

Other FOSS Cryptocurrency?

Michael Schwartz: The only company that we’ve interviewed, who has issued a cryptocurrency, do you think that there’s opportunities to use cryptocurrencies for other purposes? Maybe to help either fund or reduce transactions cost for developing or monetizing?

Ben Golub: Absolutely. I’ve seen lots and lots of interesting crypto companies, and there are lots of not so interesting ones that are just ‘fly by night’ operations. But, among the interesting ones, with blockchain and cryptocurrency, what we needed to do is sort of create these large decentralized networks, where trust is sort of built into the network, rather than residing in a particular individual.

And you can make payment algorithmic. There are a lot of interesting experiments, for example, to say, ”Hey, let’s reward people for contributions to open source based off of using crypto currency, and doing it in an algorithmic manner.” And it gets really an interesting idea.

But ultimately, for anything like that to work, somebody has to be able to drive economic value for the open-source to begin with.

And my guess is that’s not the people who today are generating the value, which is the public cloud companies.

Challenges Of Launching A CryptoCurrency

Michael Schwartz: From a legal business perspective, it’s fairly technically challenging launching a cryptocurrency.

Ben Golub: Yeah, we were sort of fortunate that we did it right. And we also, in 2017, we had a network built and launched before we did a token sale. The token sale had utility from day one, and we’ve tried really hard not only to be enterprise-grade in terms of our product, but to be in a serious enterprise-grade in terms of our governance and management of the token and our treasury policies, inside our trading and governance, all those good things.

Treasury / Governance Of Currency

Michael Schwartz: Storj actually holds cash or an amount of cryptocurrency that’s let’s say unissued – is that how it works?

Ben Golub: Yes. We generated in our token sale 425 million tokens, and then in essence, we broke the mold. So, there will be no more ever created. We sold 75 million in our initial token sale. Since that time, of course, review tokens to compensate people who are running nodes, some people have paid us back in tokens.

Right now, there’s about a 125 million storage tokens in circulation, and then, the remainder we have, the biggest chunk of that, is in time lock, so that it won’t be entering the market in an undisciplined way.

View On Red Hat Acquisition

Michael Schwartz: I could probably keep asking you questions about cryptocurrencies for the next half an hour.

Ben Golub: Oh, that’s okay. Happy to answer that, but now, I’ll be honest, I find cryptocurrency far more interesting than decentralization. Because, ultimately, I think that if that’s a tool, and cryptocurrency is a small part of blockchain, and blockchain is a small part of decentralization. Decentralization is in some way even bigger than Internet, because Internet in itself is decentralized.

Michael Schwartz: Slightly off topic question, but is the acquisition of Red Hat by IBM a good thing for the open-source software segment?

Ben Golub: I think it really depends on how IBM manages it. Some companies do a great job at acquisitions and some don’t do a good job. I have to say that I actually sold a company to Red Hat Gluster, which, of course, Red Hat has now become part of IBM.

I think to the extent that IBM enables, or allows, Red Hat sort of to open-source roots, but helps it sort of continue to flourish as a shining example of commercially successful open source, I think it’s great.

Personally, last year, I was able to say, “Hey, it’s fantastic, we now have more than Red Hat.”, as an example of a public open-source company, and Red Hat, and Hortonworks, and Cloudera and RealSoft and, and now Mulesoft has been acquired. Cloudera and Hortonworks have combined, and Red Hat is now part of IBM. Elasticsearch entered, but there’s fewer public open-source companies.

Michael Schwartz: Now, we have less.

Ben Golub: Yeah. And, of course, the largest one is now no longer independent.

Move To Open Source License

Michael Schwartz: Recently, several prominent companies in our industry, like Cloudera and Chef, moved to an all open-source strategy, then moved away from open core. Do you think open core has peaked and will move back towards a more truly open-source model?

Ben Golub: Well, it’s interesting, because on the one hand, you’ve seen some people become more permissive with their licensing, and then you’ve also seen other companies become more restrictive, and come up with a sort of new licenses to deal with the Cloudera.

I don’t have a dog in that fight, except I think that the answer to monetizing the cloud isn’t a new kind of license, I think it’s a new kind of cloud. And that’s where we come from. Because, ultimately, yes, you can add value to open source by making it better for large enterprises, whether it’s through proprietary modules, or services support, or subscriptions, or packaging.

I think there’s all kinds of variations on a theme. What we need to do is find a way that you can make open source monetizable for large numbers of small and mid-sized companies, or even larger companies that are running in the cloud.

Biggest Challenges For Open Source Businesses?

Michael Schwartz: Putting storage solution aside for one second, what do you think are the biggest challenges today facing entrepreneurs who want to build a business around an open-source software project?

Ben Golub: I think that the first challenge most have to do is, like any great open-source project, build something compelling and build an exciting community around it – that’s a hard thing to do.

I think that what they then need to figure out is how do they build a sustainable business model that can carry them from the time they have a really big community to the time that they have a sustainable economics.

Along the way, it gets really difficult. Even if your community is successful, how do you manage your community, how do you monetize, how do you make it possible for people that participate in your community, without undermining it, and how do you avoid going down to the point where all that you get from a large company is just charity.

I’m not saying charity in a bad way, but I’m saying, when I was running large open-source communities, what I wanted from the cloud companies wasn’t some cloud credits. I didn’t want them to say, “Hey, I’ll put two people on your thousand-person projects.”

It’s nice, but what we really needed to do was have a mutually beneficial business relationship, so that we could invest and grow.

Advice For Entrepreneurs

Michael Schwartz: What advice do you have for the entrepreneur who needs to lead this open-source effort? You’ve been through the entrepreneurial journey many times, and I’m just wondering if you have any advice for the person who is actually going through that journey?

Ben Golub: Well, of course, it is a journey. As they say, it’s a marathon, not a sprint. I think, personally, what you have to do is, you have to love what you’re doing. And I think especially for an open-source, you have to believe that the journey will be worth it even if you can’t feel the successful business.

Because, what you are doing, it’s interesting enough for you, and it’s going to be hard to build something interesting enough for the community. But having done that, I think you need to think really clearly about where you want to be each year over the next five years. I think you need to think really clearly, from my point of view, over what your monetization strategy is going to be, and who are your users, and what is your use case.

I think far more startups fail because they don’t pick a direction than because they choose the wrong direction. I think if you articulate internally a really clear direction, and then, you’re consistent in saying that’s your model, whether it’s open core, or service and support, or access, or whatever it is, and then you are relying on everybody in your company – I hope choice of strategies is right.

But even if it’s slightly wrong, at least you’ll all be running in the same direction, and you can change course. The worst thing that I’ve seen in startup after startup after startup is, they don’t pick a direction.

Everybody runs at five different directions, and they know they are failing and they don’t know whether it’s because one of those is wrong or because all of them are wrong.


Michael Schwartz: Ben, thank you so much for taking the time out of the conference today to record the podcast.

Ben Golub:  Great questions, thank you.

Michael Schwartz: Huge thanks to the Open Core Summit for connecting us to Ben, and for making space to record at the 2019 Summit. Don’t miss the Open Core Summit next year. It’s a fantastic event for founders and open-source teams.

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.

Please, subscribe to the podcast, or add it to your favorites on your platform. Every subscription counts.

Next week, we have Isaac Schlueter from npm, the last of the in-person interviews from the Summit.

Until then, thanks for listening.

lliam Lowe.

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

Please, subscribe to the podcast, or add it to your favorites on your platform. Every subscription counts.

Next week, we have Isaac Schlueter from npm, the last of the in-person interviews from the Summit.

Until then, thanks for listening.

Episode 19: WSO2 – API Management Platform with Tyler Jewell

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



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

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

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

Tyler, welcome to the podcast.

Tyler Jewell: Hey, thank you for having me.

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

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

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

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

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

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

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

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

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

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

How Does Open Source Enhance The Business Model?

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

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

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

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

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

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

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

Value Prop

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

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

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

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

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

What Does Open Source Mean To WSO2

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

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

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

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

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

What Types Of Software Should Be Open?

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

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

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

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

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

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

Community Projects

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

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

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

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

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

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

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

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

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

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

Revenue Streams

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

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

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

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

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

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

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

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

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

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

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

Customer Retention

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

How To Build Culture

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

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

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

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

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

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

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


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

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

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

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

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

Experience From Cloud

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

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

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

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

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

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

Sales Cycle

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

WSO2 In The Next 20 Years?

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

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

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

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

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

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

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

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

Final Advice

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

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

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

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


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

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

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

Music from Broke For Free and Chris Zabriskie.

Audio editing by Ines.

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

Follow us on Twitter, our handle is @fosspodcast.

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

Until then, thanks for listening.

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

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



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

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

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

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

Martin, thank you for joining us today.

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

Michael Schwartz: So, how did Moodle get started?

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

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

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

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


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

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

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

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

Why Free

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

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

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

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

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

Investor Objectives

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

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

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

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

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

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

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

Evolution Of Business

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

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

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

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

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

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

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

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

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

Royalty Collection

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

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

Other Licensed Tool

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

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

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

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

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

Customer Segments

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

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

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

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

Moodle SaaS

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

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

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

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

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

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

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

Moodle App

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

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

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


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

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

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

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

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

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

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

Moodle In 20 Years

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

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

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

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

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

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

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

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

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

Open Source V. Cloud

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

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

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

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

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


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

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

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

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

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

Moodle Users Group/Foundation

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

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

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

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

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

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

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

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

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

Protecting IP/Brand

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

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

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

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

Closing Advice

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

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

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

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

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

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

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

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

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

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

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

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

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

Introducing our new editor, Ines.

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

Follow us on Twitter. Our handle is @fosspodcast.

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

Until then, thanks for listening.

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

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



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

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

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

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

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

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

What Is A Time-Series DB

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

Ajay Kulkarni: Thank you for having us.

Mike Friedman: Thanks for having us.

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

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

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

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

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

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

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

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

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

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

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

Origin Of Timescale Company

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Community Contribution

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

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

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

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

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

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

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

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

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

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

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

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

License Design

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

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

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

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

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

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

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

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

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

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

Enterprise Value Prop

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

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

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

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

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

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

Competitive Differentiation

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

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

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

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

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

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

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

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

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

DB As A Service?

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

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

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

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


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

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

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

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

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

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

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

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

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

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

So, there was a backlash then.

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

And there was a backlash.

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

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

Why Same Repo

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

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

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

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

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

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

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

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

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

Mixed Bits

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

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

And the answer is GPL is restrictive in other ways.

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

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

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

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

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

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

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

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

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

Transition To License

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

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

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

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

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


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

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

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

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

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

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

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

Thoughts About RedHat

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

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

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

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

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

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

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

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

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

When Software Should Be Open Source?

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

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

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

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

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

Advice For Entrepreneurs?

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

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

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

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

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

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

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

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

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

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

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

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

Ajay Kulkarni: Thank you so much for having us.

Mike Friedman: Thanks for your time.


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

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

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

Production assistance and transcription by Natalie Lowe.

Operational support from William Lowe.

Follow us on Twitter, our handle is @fosspodcast.

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

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

Episode 16: Liferay – Digital Experience Software with Bryan Cheung

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



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

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

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

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

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

1. Canonical
2. NextCloud
3. Liferay

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

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

Bryan, thanks a lot for joining us today.

Why Bryan Joined Liferay

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

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

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


Michael Schwartz: So how did Liferay actually get started?

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

Maintenance Period

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

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

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

Portal V.CMS V. DXP V

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

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

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

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

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

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

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

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

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

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

Value Prop

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

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

Enterprise-Only Features

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

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

And so that really got us into a lot of our initial customers as well as in our expansion period that they continued to help us.

With that groundswell of support from developers that got us into a large enterprise, we then started to get recognition, both in the industries that we served, but also with some of the analyst firms like Gartner and Forrester. And then that sort of event gave us the peer recognition and the analyst recognition that gave confidence to some of the mainstream companies to adopt Liferay, because we had to track record.

What then happened, I would say, is that there were two kinds of system integrators. One was smaller maybe boutique integrators that’s had a track record of taking open source software, understanding it, and then implementing it.

Again, MySQL, certainly JBoss and Tomcat, later Liferay, Pentaho, maybe even MuleSoft, and the smaller integrators found that they could provide more competitive bids for building solutions by having open source foundation. And then the larger integrators, companies like Accenture, Wipro, Cognizant – these came later and saw really the strategic value of open source. That the flexibility, the security may be the way that you could better build best-of-breed solutions for complex, digital transformation problems, was an advantage for their customers. And so they started to engage with Liferay and others for some of their strategic customers.

And so that kind of was a very organic process for us, it wasn’t a strategy that we had thought up beforehand, but it’s worked out really well for us.

Startup Marketing Advice

Michael Schwartz: I’m curious if you had any insights to what are some of the more tactical marketing investment you can make as a startup.

Bryan Cheung: Thinking back on our history, so again, following that arc of that early grass roots adoption by developers – a lot of our early investments were in events like JavaOne.

I remember our first JavaOne, one of the things we did was we bought baseball jerseys that had sort of Liferay scripted on the back. And then instead of the player names, we had things like Ajax and JSR.68, which were kind of the things that developers cared about back in the day. I’m probably dating myself a little bit with some of these terms, but we had an ideological discussion about this like, “Hey, no one’s going to take us seriously if we’re wearing these baseball jerseys. “

If we mean to be competing with IBM and Oracle, these are the people that companies take seriously. And then the ones I think that really understood developer’s hearts and minds were like, “No, this is our way of saying we are not like Oracle and IBM.” And we needed to apply our strengths.

We invested in the booth at JavaOne, but instead of having expensive giveaways and kind of large gimmicks, we did the baseball jersey thing. And people noticed, and then they would start a conversation with us, and once they started talking to us about the technology, that’s what got them really excited. And I think we were able to get people to be invested in the community and just start evangelizing Liferay back into our organization.

In a way, we played up our outsider or maverick position, especially for the developers who didn’t want to go with the status quo. And what we found is that those tend to be the most passionate people, the ones who were really going to go above and beyond to sell your brand and your company to their stakeholders. So that really worked for us, certainly in the beginning.

Now in 2018-2019, I think JavaOne maybe is part of the establishment, so I don’t know if that specifically would work but I think the principles would still apply.

DXP Cloud

Michael Schwartz: Is there a cloud-hosted version of Liferay?

Bryan Cheung: Yes, we introduced Liferay DXP cloud earlier this year, and it’s exactly that.

It’s a cloud-hosted version of Liferay, but it’s actually more than just a place to put your Liferay-based solution. DXP Cloud actually provides a full Enterprise pass for managing the life cycle of your software project, from build to deploy to managing our production.

It has a full set of tools and frameworks to do everything, from continuous deployment integration to testing to auto-scaling, to an auto backup service.

It is built to work on top of AWS, and will be supporting other cloud infrastructure in the future, but it’s got another layer on there so you are not just doing AWS but you have all of that functionality there.

It’s really nice, so our team what we found is, when we were starting to deploy complex projects based on Liferay to production, there were all these things we had to figure out. How do you configure Jenkins, how do you deal with Kubernetes. How do you deploy Liferay to Docker and manage those containers, get them all talking to each other, how do you deal with elastic scaling when demand goes up.

So instead of having our customers figure out all those things on their own, we decided to figure those things out for them, and really save them time, effort and money doing that.

We really think DXP cloud is going to be a time saver, and again, on this theme of how do you deliver value to large enterprises. Large enterprises, they don’t want to have to deal with the DevOps aspects of their solution, they just want to get to market quickly so that they can engage customers faster, learn what the customers want, and then evolve quickly to meet those needs.

Michael Schwartz: I realize it’s early, but how is it going in terms of uptake from customers on the cloud offering?

Bryan Cheung: I was actually really surprised because we introduced three or four different products this year, and DXP Cloud, I would say, had really strong interest, maybe the most of all of those products. We actually already have a pretty significant pipeline of opportunities for people who want to use DXP Cloud, so it’s definitely been really successful.

Advice For Bootstrappers

Michael Schwartz: Do you have any advice for entrepreneurs, specifically who want to grow the business organically?

Bryan Cheung: Don’t do it. I’m just kidding. Definitely do it, but it’s a lot of work, and it takes a lot of sacrifice. But I do think the rewards make it very, very worthwhile.

I think one thing is that you have to be very clear with yourself and with your team on what the goals of the business are.

I think for us, I shared a little bit about my background, I never had ambitions to have a position at a company, or to make a lot of money, but I did want to live life meaningfully, and to use it in a way that would benefit others.

And I think that sort of motivation really is shared by a lot of people at Liferay, and we are able to do that through Liferay I think because we have control over how we grow the business, how quickly we grow, and how we balance the needs of the financial success of the company, and the non-financial success factors.

And because we have that strong vision and purpose, I think it makes the sacrifices required of being self-funded worthwhile and meaningful. And what I found is that the people who work at Liferay, who believe in what we’re doing, they are able to get behind that, and they’re willing to make those sacrifices as well.

We have some brilliant people at Liferay, a lot of them work really, really hard, they’re super talented, they can probably be much more financially successful in many other places. You know, maybe you would argue that that would be true of the founders as well, but there is a sense that we’re all in this for something greater than ourselves. And that’s what really holds it together.

So I think, you know, if we were to change that, or if we were to engage with an outside investment firm of some kind, I think we would lose a huge part of who we are and the value we have as a company.

Liferay Non-Profit

Michael Schwartz: I read in one of the interviews that there was a nonprofit associated with Liferay. Can you maybe just come in a little bit about how and when you were able to do that, and what’s been the experience in balancing, I guess, the goals of the nonprofit and the goals of the business?

Bryan Cheung: We are a for-profit company. From our inception, we have used some of our earnings to support nonprofits of various kinds. A lot of it is around problems that we believe can’t be solved in for-profit ways, things like disaster relief or fighting against human trafficking.

I personally think that a lot of people actually don’t want a handout. When I talk to, let’s say, young folks who have been incarcerated and come out of prison, or when I talk to people who live in developing areas of the world that are maybe economically depressed… What they don’t want is some Western entity, whether it’s for-profit or nonprofit, to come in and just build them a school or build them a well, or give them food and clothing. They actually want to find a job, and they want to earn their own money, they want to develop their skills, and help themselves.

One of the things that made it possible for me to get behind Liferay emotionally was this realization that for-profit companies can actually do a lot of good.

It’s good for people to work hard and to feel that sense of accomplishment from building something meaningful – that’s why we believe in so much of what we do as a for-profit business. But, again, you have to complement that sometimes with non-profit means because some of the very big problems are just really hard to solve, let alone do it in some kind of economically self-sustaining way.

Our vision is that the two sides of Liferay can complement each other. I would love to see that play out in a local community. So are there ways where the places where we have offices and do business are complemented by non-profit activities that also served that local community. I don’t think we’ve gotten the formula right yet, but we have some inklings of it.

One of the things we’ve done, for example down in Brazil, we have a very successful for-profit business. They’re members of our open source community decided to join Liferay and start Liferay Latin America, but one of our most talented developers down there came out of the public school system, and in Brazil, the public school system is not as well funded, and even a lot of the middle-class, they’re going to private schools.

Unlike in USA, here I think you can’t find public schools that are very good, and most people do still go to public schools. In Brazil though, being from public school means that maybe you didn’t have as many opportunities as some of your peers. So this developer, he was telling the story that one of his mentors, when he was growing up, was a developer and show them how to write code, in the sense of empowerment and possibility that he experienced when he wrote his first software program was really life-changing.

And so even though he came from sort of this more challenging background, he was able to follow this session around software development and build a career. He has since gone back to the public school where he grow up, and he has organized funding for a library. But he’s also been able to get some of his co-workers from the Liferay office, who were also developers, to go back to that school and teach these kids and expose them to coding and software development.

It really changes the trajectory of their lives, so boys and girls who maybe otherwise wouldn’t see those role models and maybe who had seen just soccer players and kind of dreamt about doing that, now they’re kind of seeing this new world of possibilities.

And, first of all, that is not really a for-profit activity, but I think even on the nonprofit side, I wouldn’t say that it’s required a lot of investment, but really is just people taking their time out and building relationships with that school.

So that’s the kind of impact we want to make, we want to be a for-profit company that engages the community, maybe identify some of the ways that money can help kick-start or catalyze some kind of change in that community, and then hopefully there are ways for those efforts to sustain themselves in the future.


Michael Schwartz: Awesome. Bryan, congratulations on all the success at Liferay, and all the commitment over the years. Thank you for your hard work, and thank you for being a guest on the show.

Bryan Cheung: Thanks very much.

Michael Schwartz: Special thanks to Yotam from Liferay, for coordinating the interview.

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

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

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

Follow us on Twitter. Our handle is fosspodcast.

Next week, stay tuned for the founders of TimescaleDB.

Episode 15: Camunda – Workflow and Decision Automation with Jakob Freund

Jakob Freund is the Co-founder and CEO of Camunda, an open source platform for Business Process Management. Camunda’s customers include AT&T, Wüstenrot building society, Lufthansa Technik and Zalando. In this episode, Jakob discusses Camunda’s unique journey from consulting to a product-based company.



Michael Schwartz: Welcome to episode 15 of Open Source Underdogs, the podcast where the founders of open source software companies explain the process of defining a successful business model.

Jakob Freund is a Co-Founder and CEO of Camunda, a Berlin-based company that is reinventing workflow automation.

I recorded this interview back in November but I’ve been a little backlogged. In December Camunda announced the completion of a € 25 million series A.

Although Jakob told me it was in the works, I didn’t ask him about it in this interview because it wasn’t finalized. But Jakob has a great story to tell, and Camunda is a business that we can all learn from.

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

Jakob, thank you for joining us today.

Jakob Freund: Yeah, sure, I’m happy to.

Michael Schwartz: So, tell me a little bit about yourself, what did you do before Camunda?

Jakob Freund: Before I started Camunda, I used to work with another software vendor, in the same industry, Business Process Management.

And that was just about a year or so, and before that I actually went to university. So I did start Camunda pretty soon after I finished my studies basically.

Origin Story

Michael Schwartz: Tell me a little bit about how Camunda got started? What’s the origin story?

Jakob Freund: As I just have mentioned, I was already in this industry called Business Process Management, which I always found very interesting. I did work in that industry as a consultant, and I figured that I could actually do that as a freelancer.

And then I met my Co-Founder Bernd. He was already freelancing in the same industry as basically a Java developer, doing workflow automation with open source BPM technology back then.

So the two of us met up, and we had this idea about starting a consulting business around BPM – that was back in 2008. And that’s how Camunda basically came about.

Customer Segments

Michael Schwartz: Who are the customers of Camunda? Do you segment in any way?

Jakob Freund: Yes, maybe just to complete that story, so Bernd and I started Camunda as a consulting business for BPM, and we did that for about five years, on 2012-13, more or less.

And as consultants, we understood that market quite well. We saw all the technologies out there, and we saw that there were BPM process automation products delivered by the big players, like the IBM, Oracle, Software AG.

And it looked like a good number of the relationship consulting struggled with actually applying those products.

So they had software developers themselves, they wanted their software developers to do process automation projects, and those developers struggled to use the IBM’s Oracle’s, and other products because they were so heavy-weight, and not really open, in a sense of an architecture, not easy to embed, and things like that.

We decided then, in 2013, that the time was right to deliver a BPM technology that would be appreciated by developers, and we started that as an open source project.

This is basically how Camunda transitioned from a consulting business to a software business.

So, to answer your question now, this kind of open- source process automation technology applies to basically any organization that wants to automate their business on one hand, and at the same time, see IT as their core business infrastructure, therefore, also entertain their own software development teams.

And you will find that kind of organization in different industries. So, for example, insurances in the German-speaking area, but also banks of course, in a broader sense, in national services, telecom companies, media companies, eCommerce – in that says, it’s a real horizontal technology applied in different verticals.

Why Open Source

Michael Schwartz: Why do you think it was important to make the product open source?

Jakob Freund: For two reasons really.

We have already engaged with another open source project, so the initial version of our project was basically a fork of that project because we didn’t see it really evolving and moving.

So there was some history behind it on one hand, but then again, also, we figured that since this is a product that is built with developers top-of-mind, it’s meant to be used by developers.

It’s kind of a natural thing to say, okay, let’s make this available open source, so that developers can adopt it very easily, without signing up for anything. That developers can also contribute to it, if they’re missing features, some of their spot box, not so much in order to get that work force for free, but in order to actually do not get them engaged and excited about the technology, and also to understand where we should be headed in terms of the next features and the roadmap.

So it’s kind of a product management treat that you will get when you deliver such a technology open source.

Revenue Streams

Michael Schwartz: So how do you monetize what things do you sell at the company?

Jakob Freund: I guess it’s a pretty common approach really.

You could say it’s an open core based business model, so we have to workflow the engine, you know, the actual thing under the hood in the headless fashion that executes those business user-friendly flowchart diagrams in order to orchestrate services.

For example like microservices, but also in order to orchestrate human work, and things like that.

This is headless so developers can embed it in their own architecture, and that’s all open source.

Then it comes to putting your processes into production, then running them, and you can still deliver the open source version, that’s fine, it’s stable and everything.

However, you might want to also have additional features around operations, for example.

So there is a tool that we deliver, which is called Cockpit, which comes with pretty powerful features for operating complex ecosystems of automated workflows.

And that tool was partially open source as well, but the majority of features is available to Enterprise customers.

Another tool for example is called Optimize, which is more about business users.

So business users get the ability to look into the running process right away, in real time, they get nice reports, and for example, heat maps on flowchart diagrams. So I, as business user, have this direct access to the technically running business processes.

In terms of adoption, it means that developers adopt technology right away, it’s open software, they can use it, they propose to put this to production towards their management.

At some point, the management might wonder about, “yes, of course, support and maintenance.” But also about, “okay is there any additional tooling available for operating this, and is there any additional tooling for making our business sponsors happy?” And that is available with Enterprise.

Breakdown Of Revenues

Michael Schwartz: In terms of revenues, is the greatest percentage of your revenues from license or from support?

Jakob Freund: So the support is part of the license subscription, so we don’t unbundle that, to sign up for the Enterprise version of the product, to get all the additional tools, and features, and the support.

So since it’s not unbundled, I could not say that the revenue can be split between those two elements.

But when we look at consulting, which is about best practices and more consulting coming on site, and reviewing your architecture, and stuff like that, that consulting comes on top of that.

When we look at our revenue, we could say that about 90% is coming from the Enterprise subscription, which is a license business, including the support service. And 10% is around consulting services.


Michael Schwartz: Are other companies or software vendors taking your open source and building it into their product?

Jakob Freund: Yes, absolutely.

We have customers for example as Gainsight, a customer success management firm, which embeds Camunda in their product, there’s Autodesk, for example, and many others.

It’s pretty straightforward for software vendor to embed Camunda in their product, in the headless fashion, so their end-users wouldn’t be aware of Camunda, but they get those workflow management features.

If I was, for example, a vendor that had a product that it’s about email automation in whatever way, like for marketing or others, and there’s those drip campaigns, where I send out an email, and depending on the reaction of the recipient, I might send out a follow-up email – that’s a workflow.

And you can design that workflow in a graphic away in Camunda, and then let Camunda run that workflow, and all within your product, without exposing Camunda to your uses.

Have Productizers Been Beneficial?

Michael Schwartz: How are those relationships going? Do you see contributions back from those partners? And I’m just wondering, has it been really beneficial, or sort of neutral, or how’s it gone with those types of deals?

Jakob Freund: Well, I would say it’s extremely beneficial for us, but not so much in the sense that they would contribute large amounts of code, in that sense, that they were actually, like rebuilding the code features that we then simply merge, get app, and then we’re done.

So that’s not what you should expect when you bargain on open source, or when you pattern open source as a vendor yourself, but you will be getting a lot of very, very helpful feedback from the people actually using your technology. That can be just individuals, open source users, they can also be organizations, like those software vendors.

By looking at what they are asking for on the forum, by looking at their pool requests, or things that they are building on top of all product and then contributing that as what we call “community extension,” which we also feature then into our ecosystem.

We understand pretty well what now should be the next steps in terms of making the product more powerful.

One example, I just mentioned this heat map feature that shows which part of our process is executed most often – that was an initial version, not developed by ourselves but by a partner of ours, as a plugin.

And then we looked at that, and we actually redeveloped that from scratch.

We didn’t actually merge a single line of code, but we got a pretty good understanding of how the feature could look like.

Soon our developers ended with stuff like, having a Spring Boot integration, for example, that can also be related to more business-user related features, like the heat map that I just mentioned, and many more aspects.

Productizer Revenues

Michael Schwartz: Do these customers, who are productizers, do they buy a subscription?

Jakob Freund: There are both.

There are software vendors that sign up – for example, we have Aion fashion with us, and then we even get Royalties, based on their own success with the product that’s out there, but of course there’s also other companies that use the open source version and don’t pay us.

And I’m quite sure there’s many more of that category. We can’t really track that since we don’t ask people to leave their email address in order to download Camunda.

It’s not that we have a direct tracking of who’s using the open source version, they are not paying us, but, of course on an anecdotal level, when you look at our meetups and other community events, we actually do encourage and invite those companies to present there just as well.

It’s not important for us in that sense that they’re paying customers in order to get presents in our community.


Michael Schwartz:How do you look at sales and marketing – is it mostly in-bound, or how are you sort of approaching it?

Jakob Freund: Well, as of today, it’s 100% inbound, in fact. So we don’t do any cold calling or, otherwise, outbound prospecting.

So, what happens is that we basically have the website of course, and the website is about the open source community, and it’s also about the Enterprise offering, so people approach us asking for quote, for example, also putting that pricing request form, things like that.

And, of course, there’s also some classical general marketing activity, it’s like content that we provide, and they would sign up for that content, becoming a lead, and things like that.

But there’s no open activities, as of today at least.


Michael Schwartz: So, in terms of partner development, is a partner important to you as a channel?

Jakob Freund: I would say it’s very important to us, in a sense of having resources available, people available, who can help our customers to implement their workflows with Camunda.

We have a lot of system integration partners that you can find on the website that have to go through a certain program of getting educated and certified eventually, etc.

So we have those partners in basically any region of the world.

And they are helping us a lot because our clients when talking to us often asked about, “okay, are there any local resources available that can come on site and help us implement Camunda in our organization?”

This is where our partners are extremely valuable.

I wouldn’t say that as of today that they are super important channel partner, so of course we have a few, especially, the bigger ones, who are also proposing Camunda to their customers, and bring new business to us. But I wouldn’t say that we have come to this point, as of today, thanks to that channel.

Open Source V. Enterprise Priority

Michael Schwartz: Where do you draw the line with open source? You mentioned that you are Open Core. How do you prioritize which features are contributed to open core or the core product, and which features are going to be Enterprise?

Jakob Freund: First of all, I know that there are some companies who would just use open source in order to piggyback on this tournament, and deliver what you could call a triple software, which is not really production ready, or not really usable. That’s not how we see it.

We really committed to that ideal, and that’s why we want to deliver a great technology and open source, that developers can adopt and use right away, and build great stuff with that, and then also putting that into production.

In that sense, when we look at new features, if we should make them available open source or not, we have that in mind.

It means that when things about a core engine that especially apply to developers – you know, we have really called it the “rainy Saturday.”

If you imagine a developer, sitting at home on a rainy Saturday, that’s just browsing around the internet, and checking out technology. And perhaps they have some project in mind that they are looking at work right now.

For example, we want those developers to be excited and be empowered to solve their problem or build exciting stuff with Camunda right away.

When it’s about feature stat that would support that idea and would support the developer’s life basically, then this feature is a natural form made available open source.

It applies to the core engine, the headless engine, but it also applies to a tool that we deliver, which is called the Modeler, which is a nice application to create those BPM flow chart diagrams.

That tool is available open source as well, and it’s a whole ecosystem of plug-ins contributed by other developers that enhance that tool. So it’s not just about the core engine stuff that is open source.

Then we have other features, which are more about also other personas within the organization.

For example, when I look at, let’s say, CIO or executive manager in the IT department, they might worry about certain stuff that really kicks in when you go alive with a large set of mission-critical business processes.

Like high availability and data replication across data centers, or update mechanisms, if you want to have like an update of Camunda and your cluster with zero downtime, and stuff like that.

Again, the majority of things that we deliver here is open source still, but here is also the possibility to provide features that you can rightfully say – “okay, do you launch organization, do you want to use this technology on a large scale for your mission-critical business?”

It’s fine and fair for us to ask you to sign up for an Enterprise subscription in order to get nice features that you would need to build yourself, but you couldn’t, if you wanted to use it that way, and everyone’s fine with that approach.

How Much PS To Take On

Michael Schwartz: You mentioned before that you were still providing some professional services within the organization. How do you draw the line with when to refer to partners in a certain region, or when to maybe take on those professional services yourself?

Jakob Freund: Well, our PS team is steady, specialized obviously in technology and surrounding best practices.

Like for example, how to involve business stakeholders and capture the ideas about to be processed, and to put that into a BPMN flowchart diagram that can be executed.

That’s not so much even about coding or architecture, it’s about simple best practices to talk to business’s user.

That kind of skill set you will find with our consulting team, and it’s a small team really. They’re not supposed to implement, or do the heavy lifting of the project implementation work.

So, when you are in organization and say, “I want to start my Camunda adoption journey, and I need some guidance on how to do that.” then our consulting team is happy to help, let it be on site or remotely.

But, when you say, “I need someone who will actually be with me, let’s say, a team even of developers or consultants on site for the next six months, supporting us, implementing this, etc, then we would actually refuse that request, we wouldn’t deliver that.

That’s the situation where it’s pretty clear that our system integration partners are actually to go-to people.

Range Of Customer Relationships

Michael Schwartz: No one has enough people to serve all of the customers out there. When customers buy a subscription, do you provide different levels of service, based upon different categories of customers?

Jakob Freund: When someone buys a subscription, they are just a customer, and we value each customer very high obviously, so we do not distinguish in that sense.

What we do have sometimes customers are in specific situations.

For example, if someone says, Okay, I have the situation, I want to go live next month, I’m having issues about performance. Or I don’t know, I need some guidance regarding tuning of the engine, or you know, with optimize or using Elasticsearch, its repository.

So, if they’re struggling with that for whatever reason, then of course we will prioritize, and we will help. But it doesn’t really matter if it’s a mom-and-pop shop, so to speak, or if it’s like Fortune 500 or Blue Chip company.

Value Proposition

Michael Schwartz: There’s other BPM tools out there, you mentioned some of the larger companies like Oracles and IBM, etc, so what’s the value proposition actually of Camunda versus some of the other offerings out there?

Jakob Freund: If you compared it to the ones that you just named, the IBM, the Oracle, we believe that Camunda is much more developer-friendly in the first place.

If you look at other open source technologies nowadays, like Elasticsearch and Apache Kafka, etc, it’s pretty clear that they are geared toward developers.

But, if you look at classical so-called BPM’s products, not so much. That other value When you look at classical so-called BPM S products, not so much so that other value propositions in mind like, hey, we are empowering your business users to drag and drop and point and click, and do everything in a model- driven way, and it’s pretty much of a closed proprietary suite basically.

We actually distinguished it coming on from day one and said, no, we’re actually blending the mindset and attitude of the Apache Kafka and Elasticsearch projects with the use-case of business process automation.

This means that we see Camunda as the most developer-oriented and most lightweight, and therefore for developers, easy to use technology on one hand, and two, allow developers to meet the business needs around business process automation on the other hand.

This, we believe, is our sweet spot. It’s kind of right between super low-level developer-oriented technology and relatively high-level, business-oriented products.

Camunda Pivots

Michael Schwartz: One of the challenges of starting a business is figuring out how to create the right offering, that includes both pricing and what’s included in the offering. Camunda’s been around for 10 years or so, has the offering changed a lot? Have you ever had to sort of tweak the offering or pivot a little bit, just wondering like what the process was like for you?

Jakob Freund: First of all, as I explained, Camunda has been around as a company for 10 years, but the product only for five years. However, we didn’t have to pivot the co-product so far. And I believe that’s because of the first five years of consulting.

For those first five years of consulting helped us to understand very well how a product should look like to have a great product market fit. And which is certainly our biggest asset right now, the product market fit.

Regarding the Camunda BPM product in its essence, we didn’t have to pivot at all actually.

Where we did pivot, however, on a smaller scale was when we added new features on new components to the product stack.

Just to give you one example, Camunda supports BPMN, which is a standard for workflow automation, and at some point we also wanted to support a standard for case management. And we added that to the stack – didn’t really take off, to be honest.

I wouldn’t say yet that it doesn’t make any sense at all, but we had to realize at some point, okay, this case management thing. I mean, yes, of course, there’s a market for that, and it’s important. But, to be honest, I mean, the actual thing that is going on in business IT is automation.

So it’s not so much about supporting knowledge workers, but if you want to be extreme, actually you could play some other tools you want to automate. Therefore, we decided to double down on this aspect of business process automation, these little iterations, like a year or so, of trying something out and then tuning that, letting go of something, maybe doubling-down on other stuff – that’s what we have suddenly seen.

Open Core V. Tools

Michael Schwartz: Would you say that your open core strategy is more about adding features, let’s say, extra features like you mentioned, better DevOps, deployment, scaling options for large Enterprise? Would you say it’s more about adding different features into the core products or a JSON tools to the core product?

Jakob Freund: It’s both really.

No matter if it comes to the community-driven innovation in the product, I would say it’s, to a large extent, adding features to the core.

I just mentioned Spring Boot, for example, that’s a great example, that’s really something that the community asked for at some point and even did a bit by themselves, the plugins, etc. And we were really amazed by their activity and engagement.

So, at some point, the community asked, “Okay, guys, could we make this part of the co-product so that it’s supported and included in the next release, etc.” So, that’s the kind of innovation that happens in the core that’s very much driven by the people using the product are also paying us for using the product for Enterprise version – that’s one end.

Then we have that other end, where, I would say, it’s a bit more proactive, where we collect all those impressions from different sources, and figure that, hey, there’s actually some problems around, for example, business visibility and the business really being involved in processes at one time.

And then there’s some vision coming about, okay, what if the business could look at what’s going on any time, in real time, and even get machine-learning back to advise about how to improve their processes. And this is more of a proactive creation of a tool as you just said, and its particular example is optimize.

It’s really both happening, you could say.

5-10 Year Vision

Michael Schwartz: When you look at long-term planning, do you have a vision for where Camunda will be in 5 years, or 10 years?

Jakob Freund: You know, on a fundamental level, we would love workflow automation as a technology and as an instrument to achieve this automated Enterprise.

If this would be recognized by the developer community, on the scale of the most popular open source projects that are around as of today.

Because if we’re honest, if you look at Camunda and Google trends, you’ll see a pretty nice trend. But when you compare it to the Elasticsearch and Apache Kafka project, and absolute numbers, of course it’s not as widespread. So there’s not so many developers coming as of today.

And we would love to change that, we really believe that it’s great fun to use Camunda, that it solves serious problems in developers’ lives, so this is one part of the vision that I would see for the next 5 years that we have this visibility into awareness of the top 10 open source projects. Of course as well as there are certain things around the products stack.

For example, right now, Camunda has delivered on premise, so you can download it yourself and upload it on premise.

We are also looking into offering it as a managed service, and things like that, so there’s a certain vision-based road map for the next years.

But at the end of the day, it’s really about creating this awareness among developers, try the technology that is compared to classical open source text, relatively business-oriented.

So, this is what we are pioneering in fact. BPM is a business thing really, but doing it in a developer array, I believe can propel any organization forward, that sees themselves as a technology company, like any bank, or insurance, is actually a software company of a certain flavor, and this is actually where we kick in.

Biggest Challenge For Open Source Startups

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

Jakob Freund: You asked that and I already drew the line between open source and Enterprise features. I think that’s a classic one. I think the pattern that I explained, it’s the “rainy Saturday” pattern, I think that works pretty well, at least for software products that I geared towards developers.

But as of today, I wouldn’t start a company that has a product that is meant to be used by businesses users and business users only, and make that available open source.

I don’t really believe in that approach, but if you have a product that is meant to be used by developers, or like in our case, developers plus business users, then open source may sort of make a sense.

The challenge is still to, of course, balance the open source adoption on the one hand with your investments, and the conversion into paying customers on the other hand. Once you figured that out, you can simply hit invest in your pattern, and it works pretty well.

So, the challenge, of course, can be that there’s other vendors, piggybacking on the success of your open source project and competing with your Enterprise offering.

The most prominent example right now is Amazon web services, giving MongoDB and Elasticsearch, a headache because they are offering that open source stuff, with not connecting back to the community or signing up with a REM license, or whatever, with the vendor.

So they are actually competing with the software companies on the open source community. And I know that there’s some companies now, wondering about whether they should change the license, for example, make it more difficult, etc.

I don’t really think that makes sense, so I think having a clear idea about the buying center and then deliver, and then respect the features for each persona in that buying center, either open source if it’s more developers, or Enterprise if it’s more business users.

I think if you do that, then you have a clear conversion channel, or clear conversion track, and you also have a more defensible position when it comes to those cloud vendors, hijacking, so to speak, your open source projects.

Because they can only offer the open source project, they cannot offer those Enterprise features – that’s the challenge that I would say I’m away off right now, but that’s also what I believe will be the right approach to take a look.

I mean, look at, for example, Elastic – that’s how they do it right now, in a sense.

Current License

Michael Schwartz: Which open source licenses are you publishing Camunda under right now?

Jakob Freund: If you like at it, like on the top level, you will read the Apache license, which is just the vast majority of source code you will find on github and our repository is license on Apache, that’s also some MIT licenses.

But in a nutshell, those licenses would permit you to use it, in more or less, whatever way you like. It’s not stuff like GPL or things like that.

Personal Advice

Michael Schwartz: Do you have any personal advice for entrepreneurs who are getting started and want to use open source as part of their business model?

Jakob Freund: I mean, my experience is limited, I have only built this one company, I’m not an entrepreneur. I have this one experience, and as I mentioned before, we started as a consulting business, and this worked extremely well for us.

So, being consultants first, building expertise and reputation and a strong home market, like the German-speaking areas, where there’s not a lot of competition that you could find in the US, which is also kind of helpful, of course, to get going.

And then using that expertise, reputation and profits to start a software business – that works super well fast, and I believe it can work for most people. You would just need to be aware that big investments take time.

It took us 5 years before we started the software business. The question is if you have that time, of course.

Besides that, the thing that we’ve just discussed around, how to define the business model and how to find what’s open source and whatnot – that’s certainly crucial. We didn’t talk so much about talent and the people that you hire and that you work with – that’s of course a very crucial element.

As you can imagine, open source helps attracting great engineers. So there’s engineers who really identify themselves for open source – that has an impact on that they want to work with us.

Here, however, you need to be honest and authentic. Are you doing this only because you’re, for example, idealistic about open source, and it is like, your personal crusade against the evil capitalistic vendors? Or do you actually have a business you’re passionate about?

And it can be both. I guess in our case a bit of the first but probably more of the latter, and that’s fine. But then you should be honest about that also towards your team, and they will appreciate that.

And those that are really like zealots about open source, they might leave at some point, because, you know, “we should make everything available open source. No features Enterprise,” and that kind of stuff. And then, it’s better to part than to not be honest about that.

That’s another advice that I would give about that.

Michael Schwartz: Jakob, thank you so much for your time.

Jakob Freund: Yeah, happy to. Thanks.


Michael Schwartz: Special thanks to the Camunda team for hosting the interview.

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

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

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

Follow us on Twitter, our handle is @fosspodcast.

Next week we’ll have a remote interview with Liferay Founder, Bryan Cheung.

One of his interviews inspired this podcast – don’t miss it. He has a lot of brilliant and inspiring insights into life and business.

Until then, thanks for listening.