Episode 16: Liferay – Digital Experience Software with Bryan Cheung

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



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

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

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

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

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

1. Canonical
2. NextCloud
3. Liferay

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

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

Bryan, thanks a lot for joining us today.

Why Bryan Joined Liferay

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

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

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


Michael Schwartz: So how did Liferay actually get started?

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

Maintenance Period

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

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

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

Portal V.CMS V. DXP V

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

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

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

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

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

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

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

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

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

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

Value Prop

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

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

Enterprise-Only Features

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

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

And so that really got us into a lot of our initial customers as well as in our expansion period that they continued to help us.

With that groundswell of support from developers that got us into a large enterprise, we then started to get recognition, both in the industries that we served, but also with some of the analyst firms like Gartner and Forrester. And then that sort of event gave us the peer recognition and the analyst recognition that gave confidence to some of the mainstream companies to adopt Liferay, because we had to track record.

What then happened, I would say, is that there were two kinds of system integrators. One was smaller maybe boutique integrators that’s had a track record of taking open source software, understanding it, and then implementing it.

Again, MySQL, certainly JBoss and Tomcat, later Liferay, Pentaho, maybe even MuleSoft, and the smaller integrators found that they could provide more competitive bids for building solutions by having open source foundation. And then the larger integrators, companies like Accenture, Wipro, Cognizant – these came later and saw really the strategic value of open source. That the flexibility, the security may be the way that you could better build best-of-breed solutions for complex, digital transformation problems, was an advantage for their customers. And so they started to engage with Liferay and others for some of their strategic customers.

And so that kind of was a very organic process for us, it wasn’t a strategy that we had thought up beforehand, but it’s worked out really well for us.

Startup Marketing Advice

Michael Schwartz: I’m curious if you had any insights to what are some of the more tactical marketing investment you can make as a startup.

Bryan Cheung: Thinking back on our history, so again, following that arc of that early grass roots adoption by developers – a lot of our early investments were in events like JavaOne.

I remember our first JavaOne, one of the things we did was we bought baseball jerseys that had sort of Liferay scripted on the back. And then instead of the player names, we had things like Ajax and JSR.68, which were kind of the things that developers cared about back in the day. I’m probably dating myself a little bit with some of these terms, but we had an ideological discussion about this like, “Hey, no one’s going to take us seriously if we’re wearing these baseball jerseys. “

If we mean to be competing with IBM and Oracle, these are the people that companies take seriously. And then the ones I think that really understood developer’s hearts and minds were like, “No, this is our way of saying we are not like Oracle and IBM.” And we needed to apply our strengths.

We invested in the booth at JavaOne, but instead of having expensive giveaways and kind of large gimmicks, we did the baseball jersey thing. And people noticed, and then they would start a conversation with us, and once they started talking to us about the technology, that’s what got them really excited. And I think we were able to get people to be invested in the community and just start evangelizing Liferay back into our organization.

In a way, we played up our outsider or maverick position, especially for the developers who didn’t want to go with the status quo. And what we found is that those tend to be the most passionate people, the ones who were really going to go above and beyond to sell your brand and your company to their stakeholders. So that really worked for us, certainly in the beginning.

Now in 2018-2019, I think JavaOne maybe is part of the establishment, so I don’t know if that specifically would work but I think the principles would still apply.

DXP Cloud

Michael Schwartz: Is there a cloud-hosted version of Liferay?

Bryan Cheung: Yes, we introduced Liferay DXP cloud earlier this year, and it’s exactly that.

It’s a cloud-hosted version of Liferay, but it’s actually more than just a place to put your Liferay-based solution. DXP Cloud actually provides a full Enterprise pass for managing the life cycle of your software project, from build to deploy to managing our production.

It has a full set of tools and frameworks to do everything, from continuous deployment integration to testing to auto-scaling, to an auto backup service.

It is built to work on top of AWS, and will be supporting other cloud infrastructure in the future, but it’s got another layer on there so you are not just doing AWS but you have all of that functionality there.

It’s really nice, so our team what we found is, when we were starting to deploy complex projects based on Liferay to production, there were all these things we had to figure out. How do you configure Jenkins, how do you deal with Kubernetes. How do you deploy Liferay to Docker and manage those containers, get them all talking to each other, how do you deal with elastic scaling when demand goes up.

So instead of having our customers figure out all those things on their own, we decided to figure those things out for them, and really save them time, effort and money doing that.

We really think DXP cloud is going to be a time saver, and again, on this theme of how do you deliver value to large enterprises. Large enterprises, they don’t want to have to deal with the DevOps aspects of their solution, they just want to get to market quickly so that they can engage customers faster, learn what the customers want, and then evolve quickly to meet those needs.

Michael Schwartz: I realize it’s early, but how is it going in terms of uptake from customers on the cloud offering?

Bryan Cheung: I was actually really surprised because we introduced three or four different products this year, and DXP Cloud, I would say, had really strong interest, maybe the most of all of those products. We actually already have a pretty significant pipeline of opportunities for people who want to use DXP Cloud, so it’s definitely been really successful.

Advice For Bootstrappers

Michael Schwartz: Do you have any advice for entrepreneurs, specifically who want to grow the business organically?

Bryan Cheung: Don’t do it. I’m just kidding. Definitely do it, but it’s a lot of work, and it takes a lot of sacrifice. But I do think the rewards make it very, very worthwhile.

I think one thing is that you have to be very clear with yourself and with your team on what the goals of the business are.

I think for us, I shared a little bit about my background, I never had ambitions to have a position at a company, or to make a lot of money, but I did want to live life meaningfully, and to use it in a way that would benefit others.

And I think that sort of motivation really is shared by a lot of people at Liferay, and we are able to do that through Liferay I think because we have control over how we grow the business, how quickly we grow, and how we balance the needs of the financial success of the company, and the non-financial success factors.

And because we have that strong vision and purpose, I think it makes the sacrifices required of being self-funded worthwhile and meaningful. And what I found is that the people who work at Liferay, who believe in what we’re doing, they are able to get behind that, and they’re willing to make those sacrifices as well.

We have some brilliant people at Liferay, a lot of them work really, really hard, they’re super talented, they can probably be much more financially successful in many other places. You know, maybe you would argue that that would be true of the founders as well, but there is a sense that we’re all in this for something greater than ourselves. And that’s what really holds it together.

So I think, you know, if we were to change that, or if we were to engage with an outside investment firm of some kind, I think we would lose a huge part of who we are and the value we have as a company.

Liferay Non-Profit

Michael Schwartz: I read in one of the interviews that there was a nonprofit associated with Liferay. Can you maybe just come in a little bit about how and when you were able to do that, and what’s been the experience in balancing, I guess, the goals of the nonprofit and the goals of the business?

Bryan Cheung: We are a for-profit company. From our inception, we have used some of our earnings to support nonprofits of various kinds. A lot of it is around problems that we believe can’t be solved in for-profit ways, things like disaster relief or fighting against human trafficking.

I personally think that a lot of people actually don’t want a handout. When I talk to, let’s say, young folks who have been incarcerated and come out of prison, or when I talk to people who live in developing areas of the world that are maybe economically depressed… What they don’t want is some Western entity, whether it’s for-profit or nonprofit, to come in and just build them a school or build them a well, or give them food and clothing. They actually want to find a job, and they want to earn their own money, they want to develop their skills, and help themselves.

One of the things that made it possible for me to get behind Liferay emotionally was this realization that for-profit companies can actually do a lot of good.

It’s good for people to work hard and to feel that sense of accomplishment from building something meaningful – that’s why we believe in so much of what we do as a for-profit business. But, again, you have to complement that sometimes with non-profit means because some of the very big problems are just really hard to solve, let alone do it in some kind of economically self-sustaining way.

Our vision is that the two sides of Liferay can complement each other. I would love to see that play out in a local community. So are there ways where the places where we have offices and do business are complemented by non-profit activities that also served that local community. I don’t think we’ve gotten the formula right yet, but we have some inklings of it.

One of the things we’ve done, for example down in Brazil, we have a very successful for-profit business. They’re members of our open source community decided to join Liferay and start Liferay Latin America, but one of our most talented developers down there came out of the public school system, and in Brazil, the public school system is not as well funded, and even a lot of the middle-class, they’re going to private schools.

Unlike in USA, here I think you can’t find public schools that are very good, and most people do still go to public schools. In Brazil though, being from public school means that maybe you didn’t have as many opportunities as some of your peers. So this developer, he was telling the story that one of his mentors, when he was growing up, was a developer and show them how to write code, in the sense of empowerment and possibility that he experienced when he wrote his first software program was really life-changing.

And so even though he came from sort of this more challenging background, he was able to follow this session around software development and build a career. He has since gone back to the public school where he grow up, and he has organized funding for a library. But he’s also been able to get some of his co-workers from the Liferay office, who were also developers, to go back to that school and teach these kids and expose them to coding and software development.

It really changes the trajectory of their lives, so boys and girls who maybe otherwise wouldn’t see those role models and maybe who had seen just soccer players and kind of dreamt about doing that, now they’re kind of seeing this new world of possibilities.

And, first of all, that is not really a for-profit activity, but I think even on the nonprofit side, I wouldn’t say that it’s required a lot of investment, but really is just people taking their time out and building relationships with that school.

So that’s the kind of impact we want to make, we want to be a for-profit company that engages the community, maybe identify some of the ways that money can help kick-start or catalyze some kind of change in that community, and then hopefully there are ways for those efforts to sustain themselves in the future.


Michael Schwartz: Awesome. Bryan, congratulations on all the success at Liferay, and all the commitment over the years. Thank you for your hard work, and thank you for being a guest on the show.

Bryan Cheung: Thanks very much.

Michael Schwartz: Special thanks to Yotam from Liferay, for coordinating the interview.

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

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

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

Follow us on Twitter. Our handle is fosspodcast.

Next week, stay tuned for the founders of TimescaleDB.

Episode 15: Camunda – Workflow and Decision Automation with Jakob Freund

Jakob Freund is the Co-founder and CEO of Camunda, an open source platform for Business Process Management. Camunda’s customers include AT&T, Wüstenrot building society, Lufthansa Technik and Zalando. In this episode, Jakob discusses Camunda’s unique journey from consulting to a product-based company.



Michael Schwartz: Welcome to episode 15 of Open Source Underdogs, the podcast where the founders of open source software companies explain the process of defining a successful business model.

Jakob Freund is a Co-Founder and CEO of Camunda, a Berlin-based company that is reinventing workflow automation.

I recorded this interview back in November but I’ve been a little backlogged. In December Camunda announced the completion of a € 25 million series A.

Although Jakob told me it was in the works, I didn’t ask him about it in this interview because it wasn’t finalized. But Jakob has a great story to tell, and Camunda is a business that we can all learn from.

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

Jakob, thank you for joining us today.

Jakob Freund: Yeah, sure, I’m happy to.

Michael Schwartz: So, tell me a little bit about yourself, what did you do before Camunda?

Jakob Freund: Before I started Camunda, I used to work with another software vendor, in the same industry, Business Process Management.

And that was just about a year or so, and before that I actually went to university. So I did start Camunda pretty soon after I finished my studies basically.

Origin Story

Michael Schwartz: Tell me a little bit about how Camunda got started? What’s the origin story?

Jakob Freund: As I just have mentioned, I was already in this industry called Business Process Management, which I always found very interesting. I did work in that industry as a consultant, and I figured that I could actually do that as a freelancer.

And then I met my Co-Founder Bernd. He was already freelancing in the same industry as basically a Java developer, doing workflow automation with open source BPM technology back then.

So the two of us met up, and we had this idea about starting a consulting business around BPM – that was back in 2008. And that’s how Camunda basically came about.

Customer Segments

Michael Schwartz: Who are the customers of Camunda? Do you segment in any way?

Jakob Freund: Yes, maybe just to complete that story, so Bernd and I started Camunda as a consulting business for BPM, and we did that for about five years, on 2012-13, more or less.

And as consultants, we understood that market quite well. We saw all the technologies out there, and we saw that there were BPM process automation products delivered by the big players, like the IBM, Oracle, Software AG.

And it looked like a good number of the relationship consulting struggled with actually applying those products.

So they had software developers themselves, they wanted their software developers to do process automation projects, and those developers struggled to use the IBM’s Oracle’s, and other products because they were so heavy-weight, and not really open, in a sense of an architecture, not easy to embed, and things like that.

We decided then, in 2013, that the time was right to deliver a BPM technology that would be appreciated by developers, and we started that as an open source project.

This is basically how Camunda transitioned from a consulting business to a software business.

So, to answer your question now, this kind of open- source process automation technology applies to basically any organization that wants to automate their business on one hand, and at the same time, see IT as their core business infrastructure, therefore, also entertain their own software development teams.

And you will find that kind of organization in different industries. So, for example, insurances in the German-speaking area, but also banks of course, in a broader sense, in national services, telecom companies, media companies, eCommerce – in that says, it’s a real horizontal technology applied in different verticals.

Why Open Source

Michael Schwartz: Why do you think it was important to make the product open source?

Jakob Freund: For two reasons really.

We have already engaged with another open source project, so the initial version of our project was basically a fork of that project because we didn’t see it really evolving and moving.

So there was some history behind it on one hand, but then again, also, we figured that since this is a product that is built with developers top-of-mind, it’s meant to be used by developers.

It’s kind of a natural thing to say, okay, let’s make this available open source, so that developers can adopt it very easily, without signing up for anything. That developers can also contribute to it, if they’re missing features, some of their spot box, not so much in order to get that work force for free, but in order to actually do not get them engaged and excited about the technology, and also to understand where we should be headed in terms of the next features and the roadmap.

So it’s kind of a product management treat that you will get when you deliver such a technology open source.

Revenue Streams

Michael Schwartz: So how do you monetize what things do you sell at the company?

Jakob Freund: I guess it’s a pretty common approach really.

You could say it’s an open core based business model, so we have to workflow the engine, you know, the actual thing under the hood in the headless fashion that executes those business user-friendly flowchart diagrams in order to orchestrate services.

For example like microservices, but also in order to orchestrate human work, and things like that.

This is headless so developers can embed it in their own architecture, and that’s all open source.

Then it comes to putting your processes into production, then running them, and you can still deliver the open source version, that’s fine, it’s stable and everything.

However, you might want to also have additional features around operations, for example.

So there is a tool that we deliver, which is called Cockpit, which comes with pretty powerful features for operating complex ecosystems of automated workflows.

And that tool was partially open source as well, but the majority of features is available to Enterprise customers.

Another tool for example is called Optimize, which is more about business users.

So business users get the ability to look into the running process right away, in real time, they get nice reports, and for example, heat maps on flowchart diagrams. So I, as business user, have this direct access to the technically running business processes.

In terms of adoption, it means that developers adopt technology right away, it’s open software, they can use it, they propose to put this to production towards their management.

At some point, the management might wonder about, “yes, of course, support and maintenance.” But also about, “okay is there any additional tooling available for operating this, and is there any additional tooling for making our business sponsors happy?” And that is available with Enterprise.

Breakdown Of Revenues

Michael Schwartz: In terms of revenues, is the greatest percentage of your revenues from license or from support?

Jakob Freund: So the support is part of the license subscription, so we don’t unbundle that, to sign up for the Enterprise version of the product, to get all the additional tools, and features, and the support.

So since it’s not unbundled, I could not say that the revenue can be split between those two elements.

But when we look at consulting, which is about best practices and more consulting coming on site, and reviewing your architecture, and stuff like that, that consulting comes on top of that.

When we look at our revenue, we could say that about 90% is coming from the Enterprise subscription, which is a license business, including the support service. And 10% is around consulting services.


Michael Schwartz: Are other companies or software vendors taking your open source and building it into their product?

Jakob Freund: Yes, absolutely.

We have customers for example as Gainsight, a customer success management firm, which embeds Camunda in their product, there’s Autodesk, for example, and many others.

It’s pretty straightforward for software vendor to embed Camunda in their product, in the headless fashion, so their end-users wouldn’t be aware of Camunda, but they get those workflow management features.

If I was, for example, a vendor that had a product that it’s about email automation in whatever way, like for marketing or others, and there’s those drip campaigns, where I send out an email, and depending on the reaction of the recipient, I might send out a follow-up email – that’s a workflow.

And you can design that workflow in a graphic away in Camunda, and then let Camunda run that workflow, and all within your product, without exposing Camunda to your uses.

Have Productizers Been Beneficial?

Michael Schwartz: How are those relationships going? Do you see contributions back from those partners? And I’m just wondering, has it been really beneficial, or sort of neutral, or how’s it gone with those types of deals?

Jakob Freund: Well, I would say it’s extremely beneficial for us, but not so much in the sense that they would contribute large amounts of code, in that sense, that they were actually, like rebuilding the code features that we then simply merge, get app, and then we’re done.

So that’s not what you should expect when you bargain on open source, or when you pattern open source as a vendor yourself, but you will be getting a lot of very, very helpful feedback from the people actually using your technology. That can be just individuals, open source users, they can also be organizations, like those software vendors.

By looking at what they are asking for on the forum, by looking at their pool requests, or things that they are building on top of all product and then contributing that as what we call “community extension,” which we also feature then into our ecosystem.

We understand pretty well what now should be the next steps in terms of making the product more powerful.

One example, I just mentioned this heat map feature that shows which part of our process is executed most often – that was an initial version, not developed by ourselves but by a partner of ours, as a plugin.

And then we looked at that, and we actually redeveloped that from scratch.

We didn’t actually merge a single line of code, but we got a pretty good understanding of how the feature could look like.

Soon our developers ended with stuff like, having a Spring Boot integration, for example, that can also be related to more business-user related features, like the heat map that I just mentioned, and many more aspects.

Productizer Revenues

Michael Schwartz: Do these customers, who are productizers, do they buy a subscription?

Jakob Freund: There are both.

There are software vendors that sign up – for example, we have Aion fashion with us, and then we even get Royalties, based on their own success with the product that’s out there, but of course there’s also other companies that use the open source version and don’t pay us.

And I’m quite sure there’s many more of that category. We can’t really track that since we don’t ask people to leave their email address in order to download Camunda.

It’s not that we have a direct tracking of who’s using the open source version, they are not paying us, but, of course on an anecdotal level, when you look at our meetups and other community events, we actually do encourage and invite those companies to present there just as well.

It’s not important for us in that sense that they’re paying customers in order to get presents in our community.


Michael Schwartz:How do you look at sales and marketing – is it mostly in-bound, or how are you sort of approaching it?

Jakob Freund: Well, as of today, it’s 100% inbound, in fact. So we don’t do any cold calling or, otherwise, outbound prospecting.

So, what happens is that we basically have the website of course, and the website is about the open source community, and it’s also about the Enterprise offering, so people approach us asking for quote, for example, also putting that pricing request form, things like that.

And, of course, there’s also some classical general marketing activity, it’s like content that we provide, and they would sign up for that content, becoming a lead, and things like that.

But there’s no open activities, as of today at least.


Michael Schwartz: So, in terms of partner development, is a partner important to you as a channel?

Jakob Freund: I would say it’s very important to us, in a sense of having resources available, people available, who can help our customers to implement their workflows with Camunda.

We have a lot of system integration partners that you can find on the website that have to go through a certain program of getting educated and certified eventually, etc.

So we have those partners in basically any region of the world.

And they are helping us a lot because our clients when talking to us often asked about, “okay, are there any local resources available that can come on site and help us implement Camunda in our organization?”

This is where our partners are extremely valuable.

I wouldn’t say that as of today that they are super important channel partner, so of course we have a few, especially, the bigger ones, who are also proposing Camunda to their customers, and bring new business to us. But I wouldn’t say that we have come to this point, as of today, thanks to that channel.

Open Source V. Enterprise Priority

Michael Schwartz: Where do you draw the line with open source? You mentioned that you are Open Core. How do you prioritize which features are contributed to open core or the core product, and which features are going to be Enterprise?

Jakob Freund: First of all, I know that there are some companies who would just use open source in order to piggyback on this tournament, and deliver what you could call a triple software, which is not really production ready, or not really usable. That’s not how we see it.

We really committed to that ideal, and that’s why we want to deliver a great technology and open source, that developers can adopt and use right away, and build great stuff with that, and then also putting that into production.

In that sense, when we look at new features, if we should make them available open source or not, we have that in mind.

It means that when things about a core engine that especially apply to developers – you know, we have really called it the “rainy Saturday.”

If you imagine a developer, sitting at home on a rainy Saturday, that’s just browsing around the internet, and checking out technology. And perhaps they have some project in mind that they are looking at work right now.

For example, we want those developers to be excited and be empowered to solve their problem or build exciting stuff with Camunda right away.

When it’s about feature stat that would support that idea and would support the developer’s life basically, then this feature is a natural form made available open source.

It applies to the core engine, the headless engine, but it also applies to a tool that we deliver, which is called the Modeler, which is a nice application to create those BPM flow chart diagrams.

That tool is available open source as well, and it’s a whole ecosystem of plug-ins contributed by other developers that enhance that tool. So it’s not just about the core engine stuff that is open source.

Then we have other features, which are more about also other personas within the organization.

For example, when I look at, let’s say, CIO or executive manager in the IT department, they might worry about certain stuff that really kicks in when you go alive with a large set of mission-critical business processes.

Like high availability and data replication across data centers, or update mechanisms, if you want to have like an update of Camunda and your cluster with zero downtime, and stuff like that.

Again, the majority of things that we deliver here is open source still, but here is also the possibility to provide features that you can rightfully say – “okay, do you launch organization, do you want to use this technology on a large scale for your mission-critical business?”

It’s fine and fair for us to ask you to sign up for an Enterprise subscription in order to get nice features that you would need to build yourself, but you couldn’t, if you wanted to use it that way, and everyone’s fine with that approach.

How Much PS To Take On

Michael Schwartz: You mentioned before that you were still providing some professional services within the organization. How do you draw the line with when to refer to partners in a certain region, or when to maybe take on those professional services yourself?

Jakob Freund: Well, our PS team is steady, specialized obviously in technology and surrounding best practices.

Like for example, how to involve business stakeholders and capture the ideas about to be processed, and to put that into a BPMN flowchart diagram that can be executed.

That’s not so much even about coding or architecture, it’s about simple best practices to talk to business’s user.

That kind of skill set you will find with our consulting team, and it’s a small team really. They’re not supposed to implement, or do the heavy lifting of the project implementation work.

So, when you are in organization and say, “I want to start my Camunda adoption journey, and I need some guidance on how to do that.” then our consulting team is happy to help, let it be on site or remotely.

But, when you say, “I need someone who will actually be with me, let’s say, a team even of developers or consultants on site for the next six months, supporting us, implementing this, etc, then we would actually refuse that request, we wouldn’t deliver that.

That’s the situation where it’s pretty clear that our system integration partners are actually to go-to people.

Range Of Customer Relationships

Michael Schwartz: No one has enough people to serve all of the customers out there. When customers buy a subscription, do you provide different levels of service, based upon different categories of customers?

Jakob Freund: When someone buys a subscription, they are just a customer, and we value each customer very high obviously, so we do not distinguish in that sense.

What we do have sometimes customers are in specific situations.

For example, if someone says, Okay, I have the situation, I want to go live next month, I’m having issues about performance. Or I don’t know, I need some guidance regarding tuning of the engine, or you know, with optimize or using Elasticsearch, its repository.

So, if they’re struggling with that for whatever reason, then of course we will prioritize, and we will help. But it doesn’t really matter if it’s a mom-and-pop shop, so to speak, or if it’s like Fortune 500 or Blue Chip company.

Value Proposition

Michael Schwartz: There’s other BPM tools out there, you mentioned some of the larger companies like Oracles and IBM, etc, so what’s the value proposition actually of Camunda versus some of the other offerings out there?

Jakob Freund: If you compared it to the ones that you just named, the IBM, the Oracle, we believe that Camunda is much more developer-friendly in the first place.

If you look at other open source technologies nowadays, like Elasticsearch and Apache Kafka, etc, it’s pretty clear that they are geared toward developers.

But, if you look at classical so-called BPM’s products, not so much. That other value When you look at classical so-called BPM S products, not so much so that other value propositions in mind like, hey, we are empowering your business users to drag and drop and point and click, and do everything in a model- driven way, and it’s pretty much of a closed proprietary suite basically.

We actually distinguished it coming on from day one and said, no, we’re actually blending the mindset and attitude of the Apache Kafka and Elasticsearch projects with the use-case of business process automation.

This means that we see Camunda as the most developer-oriented and most lightweight, and therefore for developers, easy to use technology on one hand, and two, allow developers to meet the business needs around business process automation on the other hand.

This, we believe, is our sweet spot. It’s kind of right between super low-level developer-oriented technology and relatively high-level, business-oriented products.

Camunda Pivots

Michael Schwartz: One of the challenges of starting a business is figuring out how to create the right offering, that includes both pricing and what’s included in the offering. Camunda’s been around for 10 years or so, has the offering changed a lot? Have you ever had to sort of tweak the offering or pivot a little bit, just wondering like what the process was like for you?

Jakob Freund: First of all, as I explained, Camunda has been around as a company for 10 years, but the product only for five years. However, we didn’t have to pivot the co-product so far. And I believe that’s because of the first five years of consulting.

For those first five years of consulting helped us to understand very well how a product should look like to have a great product market fit. And which is certainly our biggest asset right now, the product market fit.

Regarding the Camunda BPM product in its essence, we didn’t have to pivot at all actually.

Where we did pivot, however, on a smaller scale was when we added new features on new components to the product stack.

Just to give you one example, Camunda supports BPMN, which is a standard for workflow automation, and at some point we also wanted to support a standard for case management. And we added that to the stack – didn’t really take off, to be honest.

I wouldn’t say yet that it doesn’t make any sense at all, but we had to realize at some point, okay, this case management thing. I mean, yes, of course, there’s a market for that, and it’s important. But, to be honest, I mean, the actual thing that is going on in business IT is automation.

So it’s not so much about supporting knowledge workers, but if you want to be extreme, actually you could play some other tools you want to automate. Therefore, we decided to double down on this aspect of business process automation, these little iterations, like a year or so, of trying something out and then tuning that, letting go of something, maybe doubling-down on other stuff – that’s what we have suddenly seen.

Open Core V. Tools

Michael Schwartz: Would you say that your open core strategy is more about adding features, let’s say, extra features like you mentioned, better DevOps, deployment, scaling options for large Enterprise? Would you say it’s more about adding different features into the core products or a JSON tools to the core product?

Jakob Freund: It’s both really.

No matter if it comes to the community-driven innovation in the product, I would say it’s, to a large extent, adding features to the core.

I just mentioned Spring Boot, for example, that’s a great example, that’s really something that the community asked for at some point and even did a bit by themselves, the plugins, etc. And we were really amazed by their activity and engagement.

So, at some point, the community asked, “Okay, guys, could we make this part of the co-product so that it’s supported and included in the next release, etc.” So, that’s the kind of innovation that happens in the core that’s very much driven by the people using the product are also paying us for using the product for Enterprise version – that’s one end.

Then we have that other end, where, I would say, it’s a bit more proactive, where we collect all those impressions from different sources, and figure that, hey, there’s actually some problems around, for example, business visibility and the business really being involved in processes at one time.

And then there’s some vision coming about, okay, what if the business could look at what’s going on any time, in real time, and even get machine-learning back to advise about how to improve their processes. And this is more of a proactive creation of a tool as you just said, and its particular example is optimize.

It’s really both happening, you could say.

5-10 Year Vision

Michael Schwartz: When you look at long-term planning, do you have a vision for where Camunda will be in 5 years, or 10 years?

Jakob Freund: You know, on a fundamental level, we would love workflow automation as a technology and as an instrument to achieve this automated Enterprise.

If this would be recognized by the developer community, on the scale of the most popular open source projects that are around as of today.

Because if we’re honest, if you look at Camunda and Google trends, you’ll see a pretty nice trend. But when you compare it to the Elasticsearch and Apache Kafka project, and absolute numbers, of course it’s not as widespread. So there’s not so many developers coming as of today.

And we would love to change that, we really believe that it’s great fun to use Camunda, that it solves serious problems in developers’ lives, so this is one part of the vision that I would see for the next 5 years that we have this visibility into awareness of the top 10 open source projects. Of course as well as there are certain things around the products stack.

For example, right now, Camunda has delivered on premise, so you can download it yourself and upload it on premise.

We are also looking into offering it as a managed service, and things like that, so there’s a certain vision-based road map for the next years.

But at the end of the day, it’s really about creating this awareness among developers, try the technology that is compared to classical open source text, relatively business-oriented.

So, this is what we are pioneering in fact. BPM is a business thing really, but doing it in a developer array, I believe can propel any organization forward, that sees themselves as a technology company, like any bank, or insurance, is actually a software company of a certain flavor, and this is actually where we kick in.

Biggest Challenge For Open Source Startups

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

Jakob Freund: You asked that and I already drew the line between open source and Enterprise features. I think that’s a classic one. I think the pattern that I explained, it’s the “rainy Saturday” pattern, I think that works pretty well, at least for software products that I geared towards developers.

But as of today, I wouldn’t start a company that has a product that is meant to be used by businesses users and business users only, and make that available open source.

I don’t really believe in that approach, but if you have a product that is meant to be used by developers, or like in our case, developers plus business users, then open source may sort of make a sense.

The challenge is still to, of course, balance the open source adoption on the one hand with your investments, and the conversion into paying customers on the other hand. Once you figured that out, you can simply hit invest in your pattern, and it works pretty well.

So, the challenge, of course, can be that there’s other vendors, piggybacking on the success of your open source project and competing with your Enterprise offering.

The most prominent example right now is Amazon web services, giving MongoDB and Elasticsearch, a headache because they are offering that open source stuff, with not connecting back to the community or signing up with a REM license, or whatever, with the vendor.

So they are actually competing with the software companies on the open source community. And I know that there’s some companies now, wondering about whether they should change the license, for example, make it more difficult, etc.

I don’t really think that makes sense, so I think having a clear idea about the buying center and then deliver, and then respect the features for each persona in that buying center, either open source if it’s more developers, or Enterprise if it’s more business users.

I think if you do that, then you have a clear conversion channel, or clear conversion track, and you also have a more defensible position when it comes to those cloud vendors, hijacking, so to speak, your open source projects.

Because they can only offer the open source project, they cannot offer those Enterprise features – that’s the challenge that I would say I’m away off right now, but that’s also what I believe will be the right approach to take a look.

I mean, look at, for example, Elastic – that’s how they do it right now, in a sense.

Current License

Michael Schwartz: Which open source licenses are you publishing Camunda under right now?

Jakob Freund: If you like at it, like on the top level, you will read the Apache license, which is just the vast majority of source code you will find on github and our repository is license on Apache, that’s also some MIT licenses.

But in a nutshell, those licenses would permit you to use it, in more or less, whatever way you like. It’s not stuff like GPL or things like that.

Personal Advice

Michael Schwartz: Do you have any personal advice for entrepreneurs who are getting started and want to use open source as part of their business model?

Jakob Freund: I mean, my experience is limited, I have only built this one company, I’m not an entrepreneur. I have this one experience, and as I mentioned before, we started as a consulting business, and this worked extremely well for us.

So, being consultants first, building expertise and reputation and a strong home market, like the German-speaking areas, where there’s not a lot of competition that you could find in the US, which is also kind of helpful, of course, to get going.

And then using that expertise, reputation and profits to start a software business – that works super well fast, and I believe it can work for most people. You would just need to be aware that big investments take time.

It took us 5 years before we started the software business. The question is if you have that time, of course.

Besides that, the thing that we’ve just discussed around, how to define the business model and how to find what’s open source and whatnot – that’s certainly crucial. We didn’t talk so much about talent and the people that you hire and that you work with – that’s of course a very crucial element.

As you can imagine, open source helps attracting great engineers. So there’s engineers who really identify themselves for open source – that has an impact on that they want to work with us.

Here, however, you need to be honest and authentic. Are you doing this only because you’re, for example, idealistic about open source, and it is like, your personal crusade against the evil capitalistic vendors? Or do you actually have a business you’re passionate about?

And it can be both. I guess in our case a bit of the first but probably more of the latter, and that’s fine. But then you should be honest about that also towards your team, and they will appreciate that.

And those that are really like zealots about open source, they might leave at some point, because, you know, “we should make everything available open source. No features Enterprise,” and that kind of stuff. And then, it’s better to part than to not be honest about that.

That’s another advice that I would give about that.

Michael Schwartz: Jakob, thank you so much for your time.

Jakob Freund: Yeah, happy to. Thanks.


Michael Schwartz: Special thanks to the Camunda team for hosting the interview.

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

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

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

Follow us on Twitter, our handle is @fosspodcast.

Next week we’ll have a remote interview with Liferay Founder, Bryan Cheung.

One of his interviews inspired this podcast – don’t miss it. He has a lot of brilliant and inspiring insights into life and business.

Until then, thanks for listening.

Episode 14: Canonical – The Company Behind Ubuntu with Mark Shuttleworth

Mark Shuttleworth is the Founder and CEO of Canonical, the creator and maintainer of Ubuntu Linux. One of the most popular platforms for cloud servers, desktops, and IoT devices, Ubuntu is the operating system of choice for new development. In this episode, Mark discusses the business model of Canonical and trends in the open source ecosystem, like the acquisition of Red Hat by IBM and the challenges of open source licensing.



Michael Schwartz: Welcome to episode 14 of Open Source Underdogs, the podcast where the Founders of open source software companies tell us how they achieved escape velocity.

As the Gluu World Tour extended to month four, we visited Cape Town, South Africa, and we’re honored to get a chance to interview Mark Shuttleworth, Founder and CEO of Canonical.

In the ‘90s, Mark founded Thawte, a certification authority, subsequently acquired by VeriSign for around half a billion dollars.

Not content to sit on a beach, Mark then pursued one of his lifelong dreams – space.

After training for a year, he became the world’s second self-funded space tourist and the first South African in space, blasting off on the Russian Soyuz TM-34 space mission.

But perhaps his most enduring contribution was still yet to come.
Mark embarked on a mission to bring Ubuntu Linux to the world. Canonical is the business behind Ubuntu.

Canonical is a fascinating business. It’s forged a powerful business model. For a large business, it’s surprisingly exploitation free.

Without outside investors pushing him for short-term gains, Mark has a freedom to pursue a truly long-term strategy.

Although how Canonical got started probably can’t be replicated, Mark has some deep insights into the open source ecosystem. And just like any business advice, take it with a grain of salt, but some of it you can hopefully repurpose for your challenges.

So enough of my blabbering, let’s cut to the tape.

How Was Space Like Entrepreneurship?

Michael Schwartz: Mark, thank you so much for joining me today.

Mark Shuttleworth: It’s a pleasure.

Michael Schwartz: My first question is a space question. Did your experience preparing for an undertaking a space mission change your approach on entrepreneurship?

Mark Shuttleworth: I guess I’d put it the other way around. I think my experience with entrepreneurship before going to space shaped the way I put together a space mission.

There were a lot of entrepreneurial elements to the way we put that project together, and being younger than the typical astronaut, cosmonaut, coming from a commercial background, having had to sort of drive a small business.

It was a lot of those skills mapped into negotiating with the various agencies and groups that were responsible for Russian space flight, telling the story of what we were trying to do, building a community around the mission, and then sort of making all of the pieces work out, managing operating controlling – all of that.

So I guess, it really was a personal project that benefited from an entrepreneurial perspective effectively, in an industry which is sort of the exact opposite of entrepreneurship.

Why Start Canonical

Michael Schwartz: We could probably spend the next half an hour just asking you questions about space, but this is a podcast about business.

Mark Shuttleworth: I’m pretty sure, I’m pretty sure many of us will get there.

We are at the dawn of much more transparent access to space. Pretty certain that the experiences that I had in some senses, hundreds of thousands people have similar experiences, or the opportunity to participate in some way with our next big steps as a species.

Michael Schwartz: That’d be amazing, I hope you’re right. But switching tracks to business and Canonical – why did you start Canonical?

Mark Shuttleworth: Before I went to space, I built a business in the field of security and cryptography and online commerce.

I had a great benefit of being able to pull together open source components to support and underpin that operation. And it struck me that this is a great way to accelerate innovation that the generosity of others was enabling me to go faster as an innovator and as an entrepreneur.

So I was in the fortunate position I could sit back and think about what kind of impact I wanted to have in the world. And it struck me that that would be a great way to return the favor, to simplify and reduce the cost of integrating open source would allow lots of other people, who were willing to take risks and had ideas, to move the ball forward faster than it would if it was just in the hands of a few large organizations, as technology.

The pendulum always swings, and back in the ‘90s, technology was very much in the hands of a few large organizations. I wanted to be part of breaking that open and enabling open source to be part of breaking that open.

There’s lots of different ways to do that, you can go chase a particular idea as open source, or you can look at the open source experience from end-to-end, and think about how to make that better for the people who are innovating and the people who are consuming and building on it, to structure the relationship between them so that it’s healthy and easier.

Challenges Of a Second StartUp

Michael Schwartz: Canonical is your second business, and one of the challenges around starting your second business is figuring out which lessons from the first business you don’t apply to the second business?

Mark Shuttleworth: It’s so extremely different that I really didn’t think that just because I’d been fortunate in one case that I could count on the same good fortune in other cases, or that certain instincts, which worked in the one case would necessarily apply in the other case.

When you do something completely different, foresight or folly to think that it’s something intrinsic, and that you have to study the problem.

And the sort of open source platform challenge is just completely different to many of the other sorts of opportunities in business, or even in open source.

So I still spend a lot of time thinking about the deep zen of what’s going on, which often isn’t the stuff that’s stressing people out, or the stuff that’s in the headlines – those sort of contextual reactions to something that someone did.

Most people tend to interpret what they see through the lens of the past.

I try to think about what it might be like if we weren’t concerned with the past. And so that’s the approach that I brought to the platform to Ubuntu and Canonical.

Who Is CEO of Canonical

Michael Schwartz: So you’re Executive Chairman of Canonical, not CEO – what does that mean exactly?

Mark Shuttleworth: What it means is that I’m really crap at updating my title on LinkedIn.

I am CEO of Canonical, and I’ve been for a while. I spent some time as Executive Chairman, and I just haven’t updated the bio.

Michael Schwartz: I did see your press release about some news about how your — I think the Wikipedia still says that you’re not.

Mark Shuttleworth: Well, equally, I was not interested in updating my own Wikipedia.

Michael Schwartz: If Wikipedia said it, then it must be right.

Mark Shuttleworth: It must be, yeah.

At one stage, I thought that the business needed a different focus from the CEO.

I was lucky enough to have Jane Silber in the business, and she took on that responsibility for a good stretch, 7 years, which allowed me to focus more on things that where interesting to me and kind of foundational for what we are doing now.

Today I’m sort of more in position of putting all those threads together as CEO. I guess I’ve enjoyed that return.

Thoughts On Red Hat/IBM

Michael Schwartz: Everyone in the open source community is trying to make sense of the IBM acquisition of Red Hat. Canonical has had a great relationship with IBM.

Were you surprised by the acquisition announcement, and what do you think it means for the community?

Mark Shuttleworth: I thought it was pretty clear for a long time that Red Hat wanted to find a buyer. So were the signals of that sort of preferred outcome.

I wasn’t surprised that in the end there was a transaction.

I was very surprised that one division in IBM was able to engineer such a large amount of debt for the whole business to take Red Hat on.

In a sense, it’s a great deal for Red Hat shoulders, investors, owners. It’s a great deal for the bankers, if it works out.

And it remains to be seen if it’s a great deal for IBM, but I buy the thesis that in a cloud world the ability to work well, on the public cloud and on your private infrastructure, is important.

And Raleigh is an important part of most enterprises private infrastructure, so the thesis of combining IBM’s public infrastructure with the Raleigh approach to private infrastructure, I think is a reasonable thesis. We’ll have to see what the execution around that looks like.

And the end of the day, because of the economics of the deal, there is an enormous amount of money that has to be brought in by IBM, through the deal, to justify the purchase price. And I’m pretty sure customers are going to end up being faced with that price.

That creates an opportunity for us. I’m thinking again right from the beginning with Ubuntu with Canonical was that I wanted to be sure that I drove the friction and the cost of building an open source, consuming open source down, even in the late ‘90s, early 2000, I felt that it was really important for the true benefits of open source to come to the widest possible audience.

There were people in the ecosystem, working on driving that cost down, rather than essentially working on their short-term monopolies, or other sort of positions of power that might bubble up in open source in order to behave like, you know, the old school power players of the tech ‘90s.

So we are very committed to driving down the cost of infrastructure that’s open source, driving down the cost of operating that infrastructure.

That I think puts us in stock contrast with where Red Hat was, and increasingly where I think IBM would have to take Red Hat because they’re going to have to earn the money back to pay for the premium that they’ve put on top of Red Hat already high evaluation.

I think that bodes well, we’ve already seen some indication of that.

Customer Segments

Michael Schwartz: An operating system is a core infrastructure, everyone could be your customer. How do you segment the market from a commercial perspective?

Mark Shuttleworth: Internally, within the organization, we think about places where people are working in aggregate, supplied type infrastructure, where you are really blurring the lines between a single host, or single piece of infrastructure, and the whole.

And places are at the edge, where essentially everything is a single point of failure.

The operating regimes of those are quite different, the kinds of things that people are trying to do in those places is a quite different echo of each other, but they are quite different, and economics of those places are quite different.

If there is a primary segmentation, it’s along those lines.

The economics of cloud need to be shaped in a way that makes sense for cloud, the economics of appliances and devices need to be shaped in a way that makes sense for appliances and devices. If you zoom out, you can see a lot of common themes.

In both of those places, we’re thinking about how to help people put the right software in the right place, with the right version, at the right time, but the mechanisms and the economics are completely different, and reality has to line up with them.

Who Does Canonical Sell To

Michael Schwartz: So when your market is everybody, who do you sell to? Like, how do you actually figure out where is the next fuel is going to come from?

Mark Shuttleworth: Well, open source serves well to build a base of people who understand what they’re going to get when they work with you.

In our case, that’s sometimes a little less obvious because people’s relationship with the operating system is a little indirect.

They focused on an application, they focused on a project, they focused on the workload. It really only comes clear when they had been working with infrastructure or operating systems for a very, very long time, because then with a benefit of scale and time, you find yourself dealing with institutional type problems, with all the different versions of Ubuntu out there: How do I understand whether or not they’re compliant, whether or not they are secure, how do I manage them at scale, or how do I keep them compliant.

Those are not the sorts of questions that people are asking on day one.

There is sort of questions that individual teams will ask, that sort of question gets only asked once you’ve been consumed at some scale, across an entire organization.

But Ubuntu is very much in that position today, and so we’re usually able to find in almost any large organization that there is a substantial amount of usage of Ubuntu, and then show the organization how their relationship with that platform gets better in working with Canonical.

Breakdown of Revenues

Michael Schwartz: And that leads into my next question, which is DMB was showing around 130 million in revenue for, I think it was a year 2017. I’m sure you’re doing more now.

Can you shed some light on the breakdown of revenue? Is it mostly licensed, is it subscription? And does Canonical have a whole range of services and products, like is there an 80/20 rule, where 80% of the revenue is coming from 20% of the products?

Mark Shuttleworth: We do a mix of things, and that’s deliberate, you know.

We’re quite willing to do non-recurring engagements because, in many cases, we can help people with, for example, their startups or entrepreneurs, making an IoT device, or businesses building clouds, and so on.

We can accelerate their faster productivity because we have a whole pile of knowledge that we can call on, that they don’t have.

It would be much more expensive and take a lot longer, and be a lot less predictable if every one of those businesses needed to kind of do that pitch-scraping work for themselves.

So we’re quite happy to dig in and do work that people would think of as kind of consulting type engagements.

I know that that’s not considered sexy in Silicon Valley, but it’s an enormous benefit to customers, who otherwise effectively have to figure out how to staff something that they don’t understand.

The way we frame that is that our job is to get a business into a position where it’s very clear how they continue to operate efficiently in many cases that means doing a bunch of sort of heavy lift upfront with that business, which is not a subscription, not a service, not licensing, you know, none of the typical things that Silicon Valley likes.

However, if I come back to the original point, our core goal is to drive down the cost of consuming open source.

In any way we can do that is if we share that cost across many, many players. So subscription and licensing type products really achieve that. In the end we, make a much more cost-effective platform by sharing the cost of all the things that people end up caring about.

They may not really understand that when they start, but they end up caring a lot about those big-picture things over time.

And by licensing the product, licensing and running services that are recurring revenue services, we are really essentially reducing the cost to everybody of those critical functions.

Values Proposition

Michael Schwartz: What would you say is the core value proposition of Ubuntu, or of Canonical’s commercial offering?

Mark Shuttleworth: Managing open source, engaging with open source at scale.

If you look at the generations of open source, in the first generation you had open source components. You had a great compiler that a small community was building on that was interesting. You had tools, a fork there, a spoon there, a knife there – you didn’t really have a whole.

So companies like Cygnus, that were closely involved in those individual tools, those were a sort of poster children, or the figureheads for open source.

Then with the emergence of Linux, it’s sort of moved up a layer, and the idea of ours was a sort of a base-operating system, people thought of a company like Red Hat is providing an alternative to something like Windows.

Today I think we’re in a very different world.

Today, if I look at GitHub, you can’t really explain GitHub, and what’s available to a business on GitHub, through the lens of anything that you’ve ever seen, from the Oracle’s and IBM’s of the world – you just can’t. There’s no analog.

There is an analog for Raleigh, it’s Windows or Solaris. But there’s no analog for the real benefits of embracing open source as sort of an open source first type policy.

And if I look at our customers, they tend to be companies that have moved fastest to say, “I want the real open source. I want the real benefits of open source in my business. I want those everywhere in my business.”

The first waves, they needed to be closely associated with a business, people wanted to look at open source, and make it feel like it came into a shrink-wrap box from a company that they could relate to in the way they’re related to Microsoft, to Sun, or to Oracle.

They wanted obviously a stronger sense of control in a relationship, and they wanted better economics, but fundamentally they still wanted that idea of a product from a company.

You don’t get that if you say, “I’m opening my business up to GitHub.” You have to be willing to figure out how to be productive, and willing to say, “I’m opening my business up to GitHub” – that’s the kind of relationship we end up having with organizations.

Working with us, they are able to say, yes, we’re not consuming Linux at a bigger scale more cost-effectively than we were when we were working with Red Hat.

But more importantly, we are now actually accelerating our entire development applications operation because we’re opening ourselves up to GitHub.

And the way Canonical works with us that is attainable, that we understand how we can make that work.

That’s why I’m excited to do it.

It means that people who do put time and effort into things on GitHub can find a way, either to get more uses of that, or to get a better return on that, depending on their particular interest.

Sales and Marketing

Michael Schwartz: Open source companies have a strange relationship with sales and marketing. Customers normally start using the software, and then they contact the vendor as you mentioned when they get to a certain scale, but can you talk about Canonical’s approach to sales and marketing and how it evolved over the years?

Mark Shuttleworth: The key thing for me is view enterprises customers, not as single things – because they are not.

An organization is a complex thing made up of lots of different functions and opinions and teams, and so on. To move stuff forward, there needs to be some sort of consensus, especially at a platform type top-level.

There needs to be some sort of consensus across that diversity that you are moving in the right direction. So, to my mind, it’s important to be having simultaneously multiple different relationships and conversations with people in an organization that is a prospect or a customer.

There are some of those relationships that are best done, completely transparently as engineer to engineer, open source code first contribution matters type engagements.

And we are quite unusual in encouraging our core engineers to speak with customers, and encouraging our customers to speak with core engineers, because it strengthens that kind of communication.

But it’s also important to be able to sit down with other people in that organization and have conversations that make sense to them about things that they care about. I think the challenge comes if you cross those wires, if you think that you’re going to run a marketing campaign to target developers, then you may be running the risk of using the wrong language, prioritizing the wrong things, emphasizing the wrong stuff.

To my mind, developers love Canonical and Ubuntu because we’re pretty focused on finding ways to help developers be more productive, go faster, experience less frustration and friction when they’re dealing with that vast, open-ended fire hose of open source.

There are a different set of concerns that we have to deal with when we engage with the rest of the business, and so to the extent that we invest in sales and marketing, we certainly do, it’s to make that more rounded communication possible.

I think it is important for every open source entrepreneur to understand that they need to be able to speak multiple languages. It’s the same message, but it’s essentially framed in different languages, to different parts of an enterprise.

Who To Partner With?

Michael Schwartz: Canonical has a deep technology partner network. It seems like everyone wants to partner with the makers of Ubuntu. How do you prioritize in which partnerships to invest?

Mark Shuttleworth: I think this is actually one of the areas where I made a lot of mistakes early on, because as you say, there is an enormous number of companies that intersect with Ubuntu in one way or the other.

And they do often want to engage and talk about a partnership of one form or another.

And I found that we were wasting a lot of resources in trying to conduct too many of those conversations at the same time, when, in fact, the best thing we could do for many of those businesses was to enable them to go faster with Ubuntu, and they didn’t need to be talking to us to do that.

So the easiest way to kind of resolve that is to set a threshold of value, mutual value, on a potential relationship.

We’ve done that essentially. If there is no clear path to a certain threshold of revenue to Canonical from a partnership, then there isn’t the basis for investing in the conversation.

There’s almost certainly appetite for that conversation because they’re using Ubuntu, but when you sort of really dig into it, if neither side can see a clear path to a certain threshold of business they’re going to do together, then you better off, leaving your engineers correspond through the bug tracker.

So today I think we have a much clearer view on the relationships that we are interested in. Because we’re a platform and we are used in so many different places and so many ways, I can’t say that there is a particular game plan or strategy to that, it’s simply the idea that very early in the conversation, we’ll say, “Well, what’s a path to doing a certain amount of business together?”

And if there is no clear answer to that, then the way forward is pretty clear – it’s open source, you know how to use it, you’re here because that’s true, but if neither of us can see a clear way to grow faster together, than “let’s leave it as it is.”

What Defines The Best Partnerships?

Michael Schwartz: What have been some of the most successful partnerships so far?

Mark Shuttleworth: The best partnerships come where people need a platform because they’re doing something other than a platform.

So, an example of that would be somebody who’s shipping appliances, they are selling something that does some very specific, people are looking for that function.

They need an operating system, and we are the preferred operating system. If their engineers have a say, and increasingly engineers do have a say, then businessmen know that to succeed, they need to go faster and faster, and they need their engineers to be happy and productive.

So since we focused a lot on keeping the engineers happy and productive, we’re typically the preferred platform for people in that sort of space.

And again, we’re pretty focused on driving down the cost of the platform, making it cost-effective for people to build services on top of Ubuntu, ship them, be able to answer all the tech platform questions that people have: Is it certified on this hardware, where can I get support, how long till I get support, is it certified, for these purposes is it certified in these countries, who’s going to handle this kind of call, who’s going to handle that kind of call, what do we do in the circumstances.

So more complexities than most businesses want to deal with internally when it isn’t their business effectively.

Our best partnerships come where people are very clear in their minds that they need a platform. Also clear in their minds that that’s not their primary business.

A secondary kind of layer would be places where people understand that Ubuntu is effectively the reference way to do something.

In a field of AI, for example, now it’s very clear most people doing that are doing it on Ubuntu, and they all go faster as a result. There is just much less friction, and we accelerate that, we facilitate that, we make specific types of investments that essentially you get rid of friction between the various groups that are competing and cooperating in AI.

The same is true in robotics, the same is true in all kinds of fields that are important to people. None of those in fact are competing around the platform that they’re using. So they don’t really mind if they end up sharing a platform.

If anything, it is reassuring to their customers, they do not want to be wired in that regard. So I guess the heart of that is, there’s a clear distinction between what people are selling and what we’re selling. That makes for a much more natural partnership.

When folks on the other side of the table are conflicted about what they want to sell, then usually the conversation gets complicated.

Our part in that I think also is just unconflicted. The temptation is to sort of get into everybody else’s business, and we don’t. I like partnering with smaller companies who are good at something, in finding ways that the relationship between us effectively is healthy for them.

I think it’s really important when you are in a position to be an aggregator that you don’t forget what it took to create the things that you are aggregating.

So I think we’re unusually respectful of what it takes to be an innovator or an entrepreneur in open source, and that makes it certainly easier to partner.

View On Licenses To Prevent Saasquatters

Michael Schwartz: Just switching gears a little bit to more ecosystem stuff.

There’s a lot of discussion in the community about how to define new open source licenses that prevent SaaSquatting, or a large SaaS company uses open source technology, and either doesn’t contribute or even undermines the company that’s developing that software.

When I interviewed Jay Kreps from Confluent, he mentioned that open source licenses were created at a time before large SaaS companies were using open source to sort of move into this infrastructure layer. Do you think the community needs to develop new open source licenses to mitigate this type of exploitation?

Mark Shuttleworth: Well, you know, when it comes to the rules and regulations and terms of engagement, and so on, I think there’s one kind of perpetual rule, which is the old “treat others the way you’d like to be treated”, especially if the roles were reversed. I think that’s a universal story, and that’s been the case for a long time.

Beyond that, I’m not that much into sort of commandments written in stone, they don’t tend to last, the world changes, the dynamics change.

And exploring, innovating, testing, finding new ways to organize – those are all normal.

We have social norms and conventions, ways to run society, ways to run businesses, regulatory, and frameworks, and so on. Today they reflect our best understanding of what works. In that light, people exploring different approaches for licensing open source is normal.

Remember, we focused on the whole spectrum of what’s on GitHub. Our engagement with a bank, for example, is about helping them consume more of that diversity. So no one license is going to end up being the answer to all of the questions.

Again, it’s not like any of our users can be in a position where they say, “Look, we’re only going to deal with stuff on the GPLv2 or Apache” – this just doesn’t work that way.

The question really is, how can we get the benefit of all of the open source out there, so we have to work well with all the people who are innovating, both in code but also in licenses.

So it doesn’t work for me to be super ideological about the one license that’s best for everybody.

As I look at the current angst, written debate around open source licensing, I think there’s three groups. There’s the people producing open source, typically smaller, typically innovative, typically focused on creating something new. There are aggregators, we call them the SaaSquatters, and then there are also the buyers, they are also the enterprises.

Then, stepping back, I’d say, we are only at the beginning of that debate, so as a consequence, what you’re seeing is 1.0 type thinking from all of those players.

This shallow thinking and the arguments that I’ve seen from all sides, the cloud company’s arguments are little bit like Mary Antoinette, you know, “Oh, let them eat cake.”

This should be fine, they’ve set the business model problems, you know. That belies the fact that they really do depend on innovators to innovate, and it isn’t them. They do a lot of innovation, but it’s not this kind of innovation.

Conversely, there’s also folks, super upset at the idea that other people making money off their stuff are missing some obvious points that they benefit from consumption, then from engagement, that lose that if they weren’t willing to make a trade of some form.

And then you have the buyers, the people who ultimately pay the bills. Who also I think they’re a little behind the curve in terms of whether value is really coming from, and how to engage with both those aggregated type players and the underlying innovators.

I’m not particularly fast about where we are at right now. I think it’s normal for pendulums to swing, the pendulum is swinging in one direction now – that’s exercising people’s minds, it’s driving debate. I’m pretty sure it’ll all work itself out.

Challenges For Open Source Startups

Michael Schwartz: Besides licensing, what are the biggest challenges facing companies that want to make an open source software distribution core to their business?

Mark Shuttleworth: I think it’s clear that open source on its own isn’t enough.

And I think that’s because the sorts of things that people are trying to achieve with open source, or the sorts of problems, where people want to see open source play a role, have mushroomed into the full spectrum of problems and opportunities that are out there.

There was a time when interesting software could be written by one person or two people – that is still true.

I mean, it’s still kind of amazing how somebody will think of something and produce it – I love that, that sort of learn, think or invent, I love that. But that approach is completely not relevant when you’re looking at producing something like Kubernetes.

It’s completely not relevant. There is no informal couple of people or one person that can do that.

And I think a lot of the stress in the conversation comes from people who have had one experience of open source, and therefore assumed that they understand how it works or how it should work, and then they’re applying that to circumstances, where those ideas or approaches just flat-out would not work.

Compound that with the fact of course people have interests.

They’re both, either deliberately, or somewhat naively blind to the things they might think that are really convenient truth. Convenient because of their interest.

There isn’t going to be one approach that essentially enables open source to be relevant across the full spectrum of technology, because the full spectrum of technology is a very broad spectrum.

And so people yelling at each other and saying, “You don’t understand.” is probably mostly a symptom of the fact that people are coming from lots of different backgrounds, and making naive assumptions about what it’s like in the other person’s shoes.

How To Balance Corporate And Open Source Interests

Michael Schwartz: The raison d’être of a for-profit company is to make money, and to make a return for investors, but pure-play open source software vendors also have a contract with the community. Is there a right way to balance these objectives?

Mark Shuttleworth: I think it’s important for people to understand what makes someone else tick.

As soon as you start telling other people how they should behave, and specifically telling other people that they should behave the way that suits you, or the way that you behave, you’re probably missing the opportunity to get the benefit of having diverse perspectives.

And I think it’s really important for people participating in a community to have some empathy for the people for whom the project is their lifeblood. That’s super important.

And often in the Ubuntu community, it’s being valuable to remind people of the fact that we are a community because we have different interests and different needs, and figuring out how to make those things work is important, tend to push back quite hard on the idea that the company must serve the community.

I think it’s important for both groups to understand mutual interests. I love that we make opportunity in Ubuntu for people who have completely different interests to Canonical’s.

It’s an enormous amount of stuff that we do that they can free ride on effectively, which lets them explore interesting things that are important to them for whatever reason. It could be commercial, it could be personal, it could be scientific.
And I’m happy to make that space. I push back pretty hard on anybody who says they shouldn’t be spaced for Canonical.

And I generally try to remind different groups inside the Ubuntu community of the fact that they can’t expect everybody to act exactly the same way. Most often I see that sort of argument from people who have entirely external ways to support themselves.

So very large companies that control access to enterprise accounts can make money using open source in those accounts effectively, but they certainly don’t want anybody else coming into those accounts because their margins come from account control effectively.

So a lot of the foundations, where we see large companies essentially standing up foundations is really predicated on the fact that while they want to benefit from true community participation, and that they want to benefit from innovators, they don’t want to see either of those groups in their accounts.

And they’d like to sort of create a fig leaf that is strictly non-commercial, that those accounts can’t go and ask for certain things from – all of that’s normal, where in an evolving marketplace, I find just as a leader, it helps to remind people of the fact that the diversity of interests is what makes an interesting community.

Canonical 20 Years From Now?

Michael Schwartz: Where do you see Canonical in 20 years?

Mark Shuttleworth: 20 years? That’s super interesting.

If I look back 15, it’s been 15 years, in a sense, just an extraordinary amount has changed.

I wouldn’t have predicted 15 years ago that we’d be a key platform on the Mainframe, and on the Raspberry Pi. I wouldn’t have predicted the Raspberry Pi. And I think that’s part of what I love about open source, it’s that people end up doing things with it, that the creators of the open source didn’t imagine.

It is really hard to do that with proprietary software, because sooner or later you’ll run into something that it’s just a small little impediment but you can’t do anything about it.

But something’s really haven’t changed – it is about enabling people to go faster with open source, to drive down the cost of open source, drive down the friction of open source.

I don’t see any other way of organizing software that seems poised to beat open source.

I don’t see anything on the horizon that looks like a discontinuity in that flow, pretty certain that Canonical offers a better way to engage with the entirety of open source for business.

If you are a bank, and you want to engage with open source, with a next generation, with a next wave, and we’re already well-up on the adoption curve. Early adopters are very comfortable with Ubuntu and Canonical, and it’s now on the sort of a faster rising part of the curve.

Maybe there’ll be some other organization that figures out a better way to do that, and that would be exciting, that would be interesting.

But at the moment I think we are well-positioned to be the company that enables people to consume, and integrate, and operate open source across the full spectrum, across all the clouds, and architectures, and devices, and things like that, better and more cost-effectively.

It’s hard for me to predict what will happen at the application lab because I’m not an inventor of applications, I’m not competing with people who make databases, or AI, computer vision recognition systems, or anything like that.

There’s an enormous amount of innovation that happens around us, which is kind of a privilege to watch that I don’t have to worry about guessing too much, you know, who’s going to invent what, because as long as they need a platform, and as long as they want that platform on sort of a reasonable and efficient commercial terms, with a long-term commitment, there’s a role for us to play.

Advice For New Open Source Entrepreneurs

Michael Schwartz: Last question, any advice for new entrepreneurs who are launching a business around open source software?

Mark Shuttleworth: There’s a real sort of double challenge in starting a tech operation that is open source.

Starting a tech operation’s always hard because you want to do something new, and that’s surprisingly difficult.

Like, you genuinely have to do something different if you want to be successful, from a technology point of view, and most of the people who would have that kind of open source view, there’s a technology angle to it, that’s something new that they want to do. And it’s hard enough getting that right.

With open source, you need to think about the fact that you’re enabling your own competition, as the blunt truth of it. You’re enabling people to compete with you, but the benefit of all the things that you’ve done, and that can be both financially and emotionally very daunting.

But at the end of the day, I don’t see any other model for software, which is spreading as fast across the world of the kind of categories of software out there today.

If you’re not going to be open source, you’re almost certainly going to be niche.

That may be satisfying for you, but I doubt it.

For most people, I think they want to find a category, and it really is going to be open source that will define a category. I’m not too worried about the non open source work, or the sort of wrapped around open source work that we see in large aggregators. Because, in a sense, by definition, they’re niche, they can only ever engage with people in their pond, maybe a big pond, but the trick is where the boundaries are.

For people who essentially want to have the whole world as an audience or a market, I think open source is an important component. It’s very, very hard, but I do think it’s the only way.

Michael Schwartz: Mark Shuttleworth, cosmonaut, CEO, Founder, Capetonian – thank you so much for joining us today.

Mark Shuttleworth: It’s been a pleasure.

Michael Schwartz: Special thanks to Claire from Canonical for helping us get us Mark’s calendar.

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

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

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

Follow us on Twitter, our handle is @fosspodcast.

Next week we’re heading back to Berlin, Germany, to talk in person with Jakob Freund, Founder and CEO of Camunda.

Until then, thanks for listening.

Episode 13: Confluent – Apache Kafka Streaming Platform with Jay Kreps

Jay Kreps is the Co-founder and CEO of Confluent, an open source real-time data streaming platform powered by Apache Kafka. Jay is the author of numerous open source projects, including Apache Kafka and Apache Samza. In this episode, Jay discusses creating a hybrid open source offering and usage-based subscription models.



Michael Schwartz: Welcome to episode 13 of Open Source Underdogs, the podcast where we help open source software entrepreneurs metamorphize their business models.

Jay Kreps is a Co-Founder and CEO of Confluent, the company behind Apache Kafka, a real-time stream processing platform, currently used by 35% of the Fortune 500.

This episode is being recorded remotely because Jay is based in Silicon Valley. Jay, thank you so much for joining us today.

Jay Kreps: Thanks for having me.

Michael Schwartz: So it’s not every day that the company you’re working for agrees to let you start a company to work full-time on a project you started while working for them – how’d this come about?

Origins Of Confluent

Jay Kreps: Yeah, that’s a great question. There was actually a whole kind of evolution of the infrastructure stack at LinkedIn, where I had worked.

We rebuilt a lot of the database layers that served the kind of live site, and we had built custom stores, searching for people, searching for the infrastructure, and for social graph that shows how you’re connected to people.

It was kind of time in the world where all the infrastructure was moving from single-server databases and systems to these distributed systems that could scale horizontally, and that was incredibly important for a social network like LinkedIn, because it had to scale, and sometimes faster even than the number of users.

In some ways, it scaled almost with the square of the users because you have all their connections, interactions between them, and that kind of grows faster than just the people joining.

We were really trying to figure out how can you scale the social network, and how can you do it in a way that’s cost-efficient, and how can you not just make it able to handle the data size but actually make it something where you can have hundreds or thousands entrepreneurs that kind of work against these platforms productively, how can it all kind of interrelate.

And so a genesis of Kafka was really that environment, we had all these different stores, we had all these big aspirations for how we wanted to use what was happening kind of in real time and feeding back into the user experience, how we wanted to connect all these different systems, in some sense how it all played together.

And there was really no solution to that problem that we felt was in a well-thought-out, or could scale in that way.

So we really started to think about like, “hey, what was missing in this stack?” And we came to some interesting observations, like a lot of the traditional data processing technology is something that almost comes out of the mainframe.

Kind of at the end of the day, you load everything up into some big data warehouse, or your cluster, and then you run these big processing jobs that come and spit out results hours later, and we thought, you know, it doesn’t really make sense.

Like for a big, global digital business, all your data is continuous, and when you say, “oh, we run all our processing at the end of the day.” It’s not even clear like, at the end of what day?

So we kind of thought, “hey, there could be a model for this,” where instead of taking all this data and bring it all together once 24 hours later, you’d just do it all the time. Kind of model everything that was kind of happening as a kind of a continuous stream of data, and allow a real-time application that we continually process that as it occurs.

And if you did that, you could really feed that back, so that you can have news feeds that updates right away. The interaction could be much richer and more real-time. And this could be kind of the basis for connecting all these different systems, for connecting all these different applications that we would connect around these streams of data.

So we looked at the academic literature, and there’s been some stuff in this area, but it kind of fizzled out, and then we looked at kind of the commercial space, and there really hadn’t been much, and it was a kind of the old messaging systems and other layers, but nothing really good in the area and the way the databases had been developed a lot of theory and thought into them.

That was the origin of it. We started building, we spent about 5 years building Kafka, and scaling it, so it would really handle at LinkedIn: All the activity, okay, what are the actions people are doing, what’s happening right now, all the changes coming into databases – it could really be that kind of central nervous system that connects everything.

We open sourced it at that time, and it ended up getting really popular in Silicon Valley.

A lot of the big tech companies: The Pinterests, and Ubers, and Netflix’s, really took this and built around it, as really a core part of their platform.

As that happened, we really started to come into contact with a broader world. I mean, I have only really worked in Silicon Valley tech companies, so I didn’t really know a lot about how a bank is built and operates, or a big retailer’s built and operates.

But as we started to talk to these companies, we got a sense that the applications for this could be much bigger. Even than what’s happening so far. That this could be the central thing that they kind of all built around.

When we realized that, we kind of thought, hey, what do you need to do to make that happen. Because a lot of these companies just couldn’t adopt what we had as kind of, “hey, download this from Github and go put it into practice.”

They needed a lot more.

So we realized, look, there would have to be some company that we could go fund development on this, turning it into a product, turning it into a service, and take it out into the world.

When we realized that, we put some thought into how we do it. We told LinkedIn that we would be leaving, it was actually a really nice thing. Rather than being unhappy about it, they actually offered to kind of invest and help us on our way.

So, in addition to kind of raising majority of our funding is from traditional venture capitals, we took a little bit of investment from LinkedIn, which kind of helped us get started.

Michael Schwartz: It’s amazing. You don’t hear it very often that company is so supportive, but I guess they knew firsthand how powerful it was.

Jay Kreps: Yeah, it was actually an interesting part of their culture. That they believed in kind of entrepreneurship, and they believed that in the modern world – you don’t come and work someplace forever. I’d been there for seven years. I was there really from when it was pretty small to when it was quite large.

And then they believed in kind of helping people, you know, as time comes to go do the next thing. That was kind of the cultural values that I thought was pretty cool, that they actually acted on that, that they were willing to kind of back it up when push comes to shove.

Project To Company

Michael Schwartz: It’s one thing to have an open source project with lots of adoption and excitement, and another thing to start a business that generates millions in revenues.

So the company started in 2014, and I read a press release, it said that the first commercial product was launched in May of 2016 – can you talk a little bit about the experience of going from an open source project to a commercial offering?

Jay Kreps: It’s actually an interesting thing, there was actually two main ways of commercializing open source. I think for most open source projects, they don’t really need a company, and they actually won’t really support a company in an easy way.

If you go to GitHub, there’s probably some millions of repositories there, I think most of those would not succeed as a stand-alone company. You kind of need something, where it’s popular enough, and there’s enough depth to the problem that people kind of want ongoing work and effort and support and services.

It’s worked pretty well for these core data systems and platforms, it is not the case that it actually works for every kind of little library.

We felt strongly that there was an opportunity in the area we were in, even though there wasn’t really an existing example of any kind of open source company in that space. Because what we were doing is data system that’s not a traditional database.

The first debate was really whether we wanted to start with a posted service in the public cloud, or whether we wanted to start with a software offering that people could run in their own data centers, but that they would have to run. So would we do something that was fully managed, or would we do something that was more of a software product.

We actually thought a lot about this, we came out of the world of really running the software at LinkedIn. Like, we built it and we also operated it. It was pretty attractive to build an as-a-service offering.

Eventually, when thinking about this, we realized you have to do both. And it’s just a question of how you sequence.

We ended up starting with the software offering because we realized for a lot of companies, that’s kind of where they were, and that they were kind of already adopting the open source – that was a nice transition to be able to use the commercial features, if that was useful.

So we did that, and about a year ago, we released our as-a-service offering that’s in the public cloud. For the software offering, we kind of targeted a kind of an open core model, where there are set better price features beyond the open source, and you get also support across all of it.

For the cloud offering, it’s pretty much the same thing, you actually get it run for you, so you don’t have to develop the expertise and stuff to do that.

Open Core V. Tools

Michael Schwartz: When I was looking at some of the diagrams of the Confluent platform, I was wondering if it was more of a tools business model similar to Cloudy, or if it was open core. Is it sort of the same thing to you, or do you differentiate a little bit between those?

Jay Kreps: I think one question that, at least in my mind, has been answered is – you’re building a business around open source, do you need to have any kind of the commercial IPS as part of the offer.

Do you have any software that’s not open source, or is it better to do a pure open source offering?

I think defining it as it has been is definitely better, to have some kind of commercial offering that isn’t purely open source, and you want to find a way to do that doesn’t kill all the attractiveness of an open source platform.

The whole reason people want these open platforms, is there’s such an amazing ecosystem around them, there’s no lock-in; those are the huge advantages.

So you don’t want to ruin that as you think about how to commercialize it, and you don’t want to poison the community. You really want to support, enrich the open source community, rather than stifle it.

To me, that’s the finding that I don’t differentiate much between kind of open core or proprietary tools around the side of this – that’s all. You’re looking for a commercial offering that kind of supports the open source.


Michael Schwartz: Kafka is Apache License because it’s Apache project, but how did you license the other pieces of the Confluent platform?

Jay Kreps: Yes, we do both. We have an open source part of the offering, for example, KSQL is a layer where you can take the streams of data coming into Kafka, and you can do SQL queries on top of them. And that’s open source, so you can download it and use it.

For a lot of the management, or monitoring, or operational features, that can allow you to connect up between data centers or run the stuff at scale. We built those as commercial software, which has a proprietary license that’s part of our offering.

And the way that’s sold is you buy their service. You’re basically paying for your use of the service, and we kind of muter that use by the data that flows through it or that’s stored.

And if you buy the software, we do that as a subscription that is priced by the number of nodes that the software is on.

Both of those are roughly usage-based models that are subscriptions. And I think that’s actually a great model for companies like us, like it means our incentive is to make sure you’re getting value out of the software that you’re using it, and that you’re getting value out of us. And that you are able to use it more than it grows as a platform within the company, more applications are able to come on and take advantage of it.


Michael Schwartz: Were there any challenges around figuring out what item you’re going to actually get on, what was the right pricing model for that? Did you get it right initially, or did you have to adjust it a couple times?

Jay Kreps: Some of the things we got right and some we didn’t.

It’s interesting that you said that, so yes, for these hybrid offerings, where it’s open source but there’s also commercial features, I think they have an element of a kind of a freemium offering. That’s actually really common outside of open source, even.

I come from LinkedIn previously, and parts of LinkedIn’s business had that model, where they had basically a free offering which is probably most people’s experience of linkedin.com, and then you can get a professional account.

And then they have really a full enterprise software product for sales and recruiting that’s totally different from the main site and experiences geared towards users and those demands. It’s very much kind of a freemium model, where you can come and get a fair amount of value, even if you don’t pay.

For many of the people who are, they can get even more value if they can upgrade to one of those tiers and they can target different users.

So, yeah, you have tension in any of those models, because if you gave everything away for free, your users would be the happiest, but you also would have no business.

If you kind of kept everything back, you would have more to sell, but actually that whole basis of users, and that whole set of people who are getting this and building around it, and kind of growing it into something where they would get value from the commercial features, wouldn’t exist.

I think it’s actually a bit tricky to draw that line, but it’s actually very powerful for companies that can because they are able to basically create a lot of value in the world. And even if they’re not capturing all of it, they can capture quite a lot.

In open source, some of these infrastructure layers are so powerful that even if you’re only capturing 10 or 20% of the value you’re creating, that is still quite substantial.

I think that’s actually in many ways the hallmark of a lot of these software-driven businesses, it is very much like that.

If you look at Facebook, or any of these kind of internet services, they have similar dynamic where, in some sense if you think about the raw time people spend on them, they don’t make that much money in comparison, but the scale is so vast that they are still making a lot of money in absolute terms.

Range Of Customers

Michael Schwartz: What are the ranges of customers who convert into Confluent platform customers?

Jay Kreps: Yeah, we’ve got companies of all kinds.

Huge car companies that are doing these amazing connected car projects, where they are connecting all the cars that they sell to the internet, and they are adding all these software features around that, and internet services, they kind of have power stuff in the cars.

Big banks that are kind of rebuilding all their core infrastructure, and trading platforms, and risk systems, and security, and fraud analytics, big retailers that are doing kind of real-time inventory management, so really across the board. And we’ve seen that with kind of small companies to some of the largest companies in the world.

Definitely, it’s kind of time to talk about a commercial offering is when people are getting real value. I think one of the things that was wrong with a lot of the commercial infrastructure platforms is that when a new platform comes around and you evaluate it, you end up quite tied to the platform overtime.

So for something that’s new and kind of unproven and proprietary, you can be hugely tied to it, and it’s not really taking off in the world yet. So you saw so many of those platforms going to fail to ever achieve escape velocity.

And I think open source really solves that for these new platforms. People can do development against that, they can download it, do development against it, you really understand how it works, put it into place for less important applications – all without really spending any money, so the risk is pretty low.

And then, as it becomes something that’s generating a lot of value for them, there can be offerings that would make a lot of sense where they’re interested in paying more to get more.

A lot of this kind of failure to thrive that you saw in so many commercial infrastructure platforms, because this wasn’t just to work the lock-ins and embeddings, so they’ve got a small vendor, it’s really overcome by open source, and I think that’s why you see so many of the popular infrastructure of all types are open in that way.

Customer Segments

Michael Schwartz: So in your customer base, do you segment at all?

Jay Kreps: There are two dimensions that matter, small companies to large companies, and less technically sophisticated to more technically sophisticated.

Of course, there are companies in all of those segments that use the product in different ways, and their kind of needs and preferences are different.

If you think about the small, technically sophisticated companies, I would say that’s the Silicon Valley, but also New York, and parts of Europe, a tech startup scene.

What they want is a hosted service, you know, they don’t want to buy a software, they don’t want to run stuff, they just want to be able to use these services dynamically, pay for what they use and go.

Large technically sophisticated companies, they have substantial on-premise blueprints, they need something that spans both environments.

They need to be able to run the software and their data centers, but also in the cloud, and connect all that up and stream data back and forth, and kind of get something that works across all the environments there.

Let’s say, small non-technical companies, we don’t end up working with them that much just because they don’t really need what we are doing.

How To Prevent Saasquatters

Michael Schwartz: Amazon has a service choosing Kafka, you’ve probably seen MongoDB and Redis have adjusted their license to prevent large cloud providers from competing with them, in a way that doesn’t support the community.

Have you thought about perhaps forking Kafka and providing it under a different license to enable you to capture more value from some of the large cloud providers who might be deploying it and benefiting from it without really contributing back a fair amount?

Jay Kreps: Yeah, it’s definitely been an issue, where the public cloud is so new.

The kind of the dynamics of how you manage an offering, there are still merging, a lot of the assumptions that went into how open source is licensed. They really predict that, they come from a world where the way software was delivered was, it was shipped to you.

Obviously, that’s been untrue for the kind of cloud applications, where it’s like a UI, Apex, Salesforce for a while, but the new thing is that this kind of infrastructure-as-a-service ability to get a database to build these kinds of back-end infrastructure pieces, which is typically the domain of open source, to be able to get that as a service.

Open source licenses haven’t come to maturity in that time, so I think for a lot of these companies, they are kind of going through a struggle, trying to figure out what’s the right balance. How much should be made freely available to anyone who wants it, even if they want to create a competing service and not contribute, and how much should we not do that.

I think the balance people mostly want is actually fair for your customers, to kind of take the software and not pay. That’s kind of the deal that I think you want with open source. You want people to be free from lock-in to the vendor, and that’s a big part of the value.

It’s unclear that, you know, you want to basically fund a ton of R&D for Amazon, who should be able to afford to contribute as well if they want to have an offering like this.

I think people are trying to figure out the right way to adapt to that and do it in a way that’s community-friendly, and that accomplishes the goals of a company and actually just allows the communities to thrive. And I don’t think there’s any kind of final answer to how to do it, not the one that we know yet, but it’ll be interesting to see how it evolves.

Value Prop

Michael Schwartz: What’s the value proposition for Confluent customers? Why do they use the Confluent platform versus a platform of one of your competitors, or just the open source, I guess?

Jay Kreps: There’s a couple things that they’re looking for.

I mean, a big part of that is, how do you take one of these big, scalable distributed platforms and really make it production-ready, and really be able to operate it at scale, and be able to develop on top of that.

Both for our cloud offering and our software offering, that’s a lot of what we’re helping people do is really make it real. So when we work with companies, everything we do with them is really structured around that, we have commercial features, we have open source features, we have support, we have consulting, just to advise people on how to do stuff and to help them get set up, we have training to help them learn how to do that.

All those that’s really just aimed at this – “hey, how can we take a company that doesn’t have this technology, how can we get them started on it, and then how can we make their initial applications successful?”

And then how can we turn it into really a platform that more and more applications can be built on site becomes this kind of fundamental, central nervous system that connects all their stuff. So all of our offerings are actually in that value proposition.

So very much, how can we get from point A, where we don’t have this capability, to point B, to point C, to point D, where it’s this amazing capacity that we build around?

That is what we really help companies do at a really high level. And the way we do that is obviously through all these mechanisms.

So if you’re getting it as a service, then you have to kind of build all the expertise in-house. If you are getting the software, then it makes the people who are standing this up, they are operating it a lot more efficient. There’s a lot less that they would have to build in-house to do that.

Sales and Marketing

Michael Schwartz: What’s the primary channel for getting new customers? Do they find the open source and then they call you, or what’s a typical sales cycle look like?

Jay Kreps: Yeah, that’s exactly right.

The problem that open source solves from a marketing point of view, for infrastructure platforms is basically that if you think about these kind of big complex, distributed layers in a company, you don’t put them in or take them out very often.

You really want it to be the case that people are aware of what you do, they’re aware of the value, in a sense you are a kind of a default choice and solution. And that they kind of call you when they’re thinking about doing some change there.

So you want and kind of get a market speak would be called an “inbound sales” mode, and you want that to be as much of your funnel as possible.

If you try to do it the other way, where you kind of go door-to-door, looking for people who might want to make this change in educating them about what you do, it’s actually pretty expensive, because you’ll find that even if you find a lot of people who are interested, it’s just not the right time, and the right time may not be for some years.

So you end up with these enormous cell cycles and a really high sales cost actually, get the initial deal done, and then they still have to grow the platform to scale internally.

By working in an open source model, you can come to turn that around, where they kind of compete, they can take the open source, they can use it, as they’re getting value out of it and thinking about, “hey, we are taking some production application to you.’

That’s when they may be interested in talking to you and understanding the value proposition you have. That’s the advantage, as from a commercial point of view, to have an open source offering.

Michael Schwartz: I saw a press release from 2016 that you brought on director of marketing and a director of sales. What’s been the impact of formalizing the sales and marketing functions?

Jay Kreps: To scale, go-to-market activities, you obviously knew that. So we have a full management team that covers everything you’d expect from Chief Revenue Officer, Chief Marketing Officer.

You kind of need the full set of disciplines that you would expect to be able to actually scale the good market activity, and that’s been super important for us.


Michael Schwartz: Have you been working with channel partners, and what role have a channel or distribution partners played for developing the sales channels?

Jay Kreps: If you think about we do, what we’re all about taking these streams of data in a company in and being able to connect everything up, and so there’s a bunch of ways that we work with partner companies.

One is that with technology, we can just plug in, so that they can get these streams of data, analytics layers, security layers, and databases, all the different types of things that might either be a source or a sink for these streams of data.

The other way that we work with partners is SIS, so people would come and help companies do development. They often specialize in industry verticals and they really know the big projects in a company.

And so they can kind of help take a new, exciting technology, like our platform, and they help to apply it in these companies, to the problems that are kind of top-of-mind in that industry, which may be very, very industry-specific.

There’s a ton of value in that, and it helps to get leverage and scale. Then we partner also with cloud providers in different ways in selling our cloud offer, so all of those are important ways that the partnership can help drive the business.

Building The Team

Michael Schwartz: What’s your philosophy about building the team – do you try and keep everyone geographically close, and how do you find people and what are you looking for?

Jay Kreps: That’s a great question. I think ultimately for a company like this, company IS the team. There’s no other big asset that the company has.

There’s no factories and machines that you bought – it’s really just a group of people who are really passionate about making something happen in the world.

So all the energy has to go into making that set of people, the right people, and make sure that they’re motivated, and that teams can all work together.

In the terms of geographic separation or consolidation, in a kind of distributed model we have offices in Palo Alto, in London, in Munich, in Paris, in other parts of the US, but we actually take them on remote places as well.

On the engineering side and the sale side, we often go into territories with sales people who are in their territory. We found that works really well. You have to build the company to support it and to work that way, but it allows you access to the best people in the world.

And one of the advantages we have is people all over the world, who are really passionate about what we’re doing, you know, want to be part of it, but they don’t want to move to the Bay Area for lots of reasons.

So, fundamentally, the choice you’re making if you’re building a company is, either I want the best people in the world, or I want the best people that are within an hour drive of my office. And there is a difference between those two things.

There’s a lot of value in having people kind of all in the same building, but there’s a lot of value in having the best people in the world too, and so we chose the latter, and I don’t think we looked back on it.

Open V. Commercial Features

Michael Schwartz: So, there’s a million features you probably want to build for both open source and the commercial. How do you prioritize the work in terms of what goes into open source and what goes into commercial? And how much effort do you spend on each?

Jay Kreps: I mean, we have kind of a vision in the space, so I guess a lot of what we do is oriented around that.

Our vision is really that you could have something very much like what databases have been for static tables of data, you can have that for these continuous streams, so you could really build the company around this stream of events of what’s happening.

All of our efforts are kind of oriented around making it happen, so we are, either building up the stack and trying to add these sequel layers and interfaces, to make it really easy to work with the streams, or we are building core infrastructures that allow us to scale better across data centers and provide more fault tolerance, scalability and redundancy.

We’re building a kind of cloud and operational tool sets that make it easy to get the stuff, or run it in your own data centers. All those are really just organized around that same mission.

In terms of what’s commercial and what’s not, we targeted an operational value proposition, like I said. So the feature is going to fall in that bucket. We usually say – “hey, is this something that would make a compelling commercial feature?” – and if not, we make it open source.

Michael Schwartz: Maybe just to push you on that a little bit, there’s probably a hundred in both categories. How do you decide how much to invest in open source vs. commercial?

Jay Kreps: We don’t actually target our percent. I would say our percent of open source development is still quite high.

It’s not because we’ve managed to a particular percent. What we look at is like, “hey, for these commercial features, what do we need to do to make them really compelling?”

And then in terms of our overall opportunity, what do we have to do to get there?

When we think about what makes it good open source features, it’s the layers that people are building against, that their applications are going to be committed to.

That I think people actually don’t want.

They don’t want to be tied down, they don’t want to be locked in. So there are things that are inherently part of the open source development.

Should we really think about it that way? You know, we want to make sure we have a good commercial feature set that is worth paying for, but we don’t really target the percentage of a developer’s hours, one way or the other.

Closing Advice

Michael Schwartz: Do you have any closing advice for those entrepreneurs who are just getting started in open source?

Jay Kreps: I think the open source businesses work well when there’s kind of some depth to the problem, and where you’re really building the platform that other things will build around.

I think that computer industry just loves open standards of all kinds, x86, the operating system layers – all of these things have created these platforms in ecosystems that people could build around in it. It’s turned out that open source is a great way of building that kind of platform.

So the internet maybe it’s built around the TCP/IP, but not everything can be a protocol. X86, I don’t even know the right way to describe what it is, but not everything is in instruction set. For everything else, I think that we found that the best way to build kind of an open platform is open source.

That tends to have the best ecosystem, it tends to have all the right feature set over time – those are the areas where I think it makes sense.

I think when people target some kind of point wise solution or application that’s kind of limited in scope and not really a platform in any way, I actually think open source tends to not win out in those domains.

When people talk about something that’s going to be a platform, many applications or systems will be built around that will have an ecosystem of other tools, and they’re great with it, that’s where open source seems to dominate.

So I would look for those opportunities, and I would look for an area, where there’s going to be enough value that the important thing is to become kind of ubiquitous, and even though you may not capture all the value as a company, you can still be incredibly successful.

And I think if you pick those areas, that’s kind of where I think open source companies can really thrive. And then of course, all the difficulties of building a company still apply. All the hard things you have to do, it doesn’t get you out of any of those.

But it does solve some of those problems in good market that I described – how you find customers, how and what you sell to them, and so on. I think that can be really helpful.

Michael Schwartz: Jay, thank you so much for sharing your thoughts on this.

Jay Kreps: Yeah, my pleasure. It was wonderful to talk.

Michael Schwartz: That’s it for episode 13. Special thanks to the Confluent team for helping us coordinate with Jay.

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

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

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

Follow us on Twitter, our handle is @fosspodcast.

Next week we’re publishing one of the interviews we’ve been looking forward to since the start of this project Mark Shuttleworth, Founder and CEO of Canonical. The company behind Ubuntu Linux – don’t miss it.

Until then, thanks for listening.

Episode 12: Sensu – Full-Stack Monitoring Platform with Sean Porter

Sean Porter is the Co-Founder, CTO, and author of Sensu, an open source infrastructure and application monitoring solution. Sensu’s customers include Netflix, Uber, General Electric, and the Associated Press. In this episode, Sean discusses the challenges of managing two distributions of the Sensu code, and their journey to raising Series A funding.



Michael Schwartz: Welcome to episode 12 of Open Source Underdogs, the podcast where we monitor the business world for new and exciting open source business models.

Sean Porter is the creator of Sensu, and is a Co-Founder and CTO of Sensu Inc.

Sensu is an open source monitoring solution that watches your organization servers, services, and applications.

It has a huge community of contributors, it’s used by thousands of companies. Sean, thank you so much for joining us today.

Sean Porter: Thank you for having me.

Origin Story

Michael Schwartz: Tell us about yourself – how did you arrive at Sensu?

Sean Porter:My background, my education is in Information Systems Technology, I started my career actually working in an IT shop for insurance business.

And from there, I just kind of got a feel for open source technologies, and eventually found myself at a local Vancouver, Canada startup running perfume.com and cricket.com.

I actually migrated their services on to AWS, back in 2008, and that gave me my first taste of good medicine.

From there, I kind of started to dabble in my own businesses, I was really focused around services and open source software, and system administration. And then, eventually, I went through the cycle of joining a company, another startup, getting some more experience, then going to try my own thing, doing consultancy.

Eventually, I arrived at a company called Sonian, back in, like, 2010-2011. That was at Boston. They are eDiscovery email archiving business, and they were running on multiple clouds at the time. My team of, I think at the time, we’ve had a few thousands of EC2 instances and IBM SmartCloud VMs, and a whole mess of things.

We are managing that, and we’re fighting a lot of fires and are monitoring, and our signaling systems were just having too many problems in this newfound world, with a femoral infrastructure, and things of that sort.

We kind of looked on the landscape of how can we prove our monitoring, how can we improve our telemetry collection, so that we can cut down on this noise, and get a little bit more sleep, and get back to improving how we deliver software.

And there really wasn’t much out there at the time that solved for our problems, so really my friend, Justin Kolberg and I, we worked on an idea that I had on the weekend.

We really just threw together a very simple piece of software that would run service checks and collect metrics. We used a pub/sub model, similar to some of the applications that we had at Sonian, and we deployed successfully onto this public cloud.

We just kind of modeled it after that software, and then we tested it out, and lo and behold, it actually worked quite well. The signal-to-noise ratio improves, and management at Sonian gave me two months of company time to further work on this tool, and really AB tested it against our existing technology stack.

It just really stuck and picked up some steam, and then got them to “let me slap the MIT license on it”, and give it a name, and that’s the origin story of Sensu, the open source monitoring tool.

Michael Schwartz: Is Sonian still using it today?

Sean Porter: It is, yeah. Sonian, think it was two years ago, around that time, got acquired by Barracuda. And it was funny, because Barracuda was also a user of Sensu, so it just like added to the amount of Sensu used there, so yeah, absolutely, they are still users today.

Customer Segments

Michael Schwartz: That’s sort of related to my next question, which is, what types of customers are using Sensu? I saw it’s thousands of companies, but do you categorize or segment the types of customers at all?

Sean Porter: Well, I mean, the way that we look at our customer base kind of falls into two funnels or two buckets.

On our website, we have the ability to come in, you can get information on the documentation on the open source product, and you can use Sensu Core.

Most of majority people come in that way.

Some from the get-go will see that we have an enterprise version, and they’ll see that there’s a few features that differentiate it from the open source version.

They’ll self-select, self-service themselves there, so they’ll put in their credit card details, they’ll get credentials for the enterprise version, they will download it and use it.

Then, there’s the other side, which is more traditional, enterprise sales cycle, those businesses, larger corporations that will take at least 90 days before they’ll make purchasing, or even just an open source adoption path.

So, those ones, they typically fall into that other category, which requires almost professional services, customer reliability support there, and that’s kind of like whole other segment for us. You see a lot of fintech, a lot of large e-commerce business that falls into that category.

Value Proposition

Michael Schwartz: What’s the value proposition, especially for Sensu Enterprise versus some of the other solutions out there?

Sean Porter: Sensu, as a tool, has always been about flexibility and integrating.

So when you got these larger organizations that are just starting out there, at the beginning of their DevOps transformations, and they’re really looking at changing some of their own processes and changing some of the tool link to support that, they have to make big decisions, but Sensu was always about integrating with all those other tools, creating a full ecosystem.

I think that’s always been one of the Sensu’s competitive advantages in that you can choose your own time-series database to store your data, and Sensu really doesn’t care about that. You can choose your different mechanisms for notifications and alerting. Sensu doesn’t really care about that.

I think that is very attractive for a lot of organizations. And then enterprise just builds more on top of that, by giving more of a batteries included experience.

We kind of differentiate there on the integration side, it gives you more packaged there, and they’re fully supported, so I can just drop Sensu in. And then, I can effectively turn on the integrations for the other technologies I use in my organization.

Open V. Enterprise

Michael Schwartz: Is it fair to say that Sensu is pursuing an open core business model?

Sean Porter: Yeah. That is our business model.

Michael Schwartz: And how do you decide what features go into core versus what goes into enterprise? How do you prioritize?

Sean Porter: Up to this point, a lot of that has been on the integration side, so integrations that are from our enterprising technologies, a good example of that is just, ServiceNow. We have Enterprise Integration for ServiceNow. There isn’t a community version or variance of that integration, the community just hasn’t had a need for it, so they haven’t created it themselves.

I think that is one example of integration, and then, on the other side, which I think is more important is around the mission model, wiring up, like the Role-Based Access Control model, with your existing directory services.

So, organizations of certain size, they need to have a directory service for authentication and authorization, just for the number of people that work at the organization, and as well as just like features around collaboration and workflow, providing value in that certain form.

Managing Two Distributions

Michael Schwartz: How do you accomplish the two distributions – are there different bits or different packages for the Enterprise? And do you do license enforcement? How do you sort of manage having two different distributions?

Sean Porter: It’s what we do today, and what we’re planning to do. And I’ll talk about both, because I think it is interesting.

Up to this point, we’ve had separate packages for the open core backend and the Enterprise backend. And really, they’re interchangeable.

You can shut down the open core services and uninstall these packages, and then you can install Enterprise, and stand it up, and it’ll simply just run the same configuration.

So, it makes it easy for users to try the Enterprise version, and then if they choose that, it doesn’t bring the value they need, they can go back to the open core.

Really, the licensing enforcement around that is the honor system. People, they come in, they sign up, and then they get a license that gives them the ability to monitor so many devices. And then, it’s up to them to really just be good citizens.

If they need any more seeds, or whatever, that they come back, and they up their license. Of course, there’s still interaction points, with support that we can see how many devices they are monitoring, and align that up with their license. We can just be like, “Hey, just so you know, you’ve exceeded your license, you should probably give us more money.”

So, that’s kind of what we do today, I mean, it’s worked well enough. I think it was a small business that was growing rapidly. I think it was the right solution for us at the time, but now, we’ve gone through the work over the last 18 months, 19 months of creating the next generation of the Sensu software. And we’ve rethought how we want to do the open core model, and how we want to package it, and how we want to license it.

We are actually releasing the general availability release at the end of this month for the new version Sensu Go. It’s a single binary that we provide in our upstream packages, and that binary includes the Enterprise features that are feature flags, and require a license file to unlock.

So, when even open source users are consuming the software from are repositories, they are getting the Enterprise version, at least that code is there, it’s simply not unlocked. If they use it, they’re using the open core feature set.

If they choose not to go that path, and not to use our official packages and not to use official binaries, the tooling is out there for them to build the fully 100% open core period of that.

So, this is something completely new for us, and quite honestly, it is an experiment. Maybe we can record another episode a year from now to see how it all worked out – that’s kind of the plan right now, and we’re going to really see how that works over the coming months.

Range Of Customer Interactions

Michael Schwartz: Can you talk about the range of how you work with customers? Do customers really ask you a lot of questions, or what do the customer relationships look like? Or the range of customer relationships you see?

Sean Porter: Yeah, it’s interesting that you mentioned range because I think it’s quite a large, wide spectrum.

I mean, one, you have people that download the open core, they use it, they upgrade self-service to Enterprise, and we never hear a thing from them. They just use the software successfully.

And then there’s one step further, which is, they might just have a very specific question like, “Hey, I’m monitoring over 10,000 servers – how should I be configuring this feature, or this particular parameter of my installation.

Then, the other end of the spectrum, which I think falls in the category of like the Enterprise customers, they are looking for a lot more involvement. They are like, “Okay, teach us how to use Sensu.” So, we do training for them. “Okay, help us do our production deployment like a POC.”

Here is this effectively a statement of work, let’s go through this and deliver all of these things for you. And then, on an ongoing basis, whenever they run into a problem, they come to us first.

I think in terms of having a successful business, doing good customer success is like critical to Sensu’s business, in terms of generating revenue. Because when you look at our customer list, majority of our revenues comes from that latter category, that end of the spectrum that requires higher touch.


Michael Schwartz: How’s it been getting renewals? I guess your license should drive the renewals automatically, but have you had any challenges around getting customers to renew?

Sean Porter: Oddly enough, no. Our churn rate is near 0%, which proves that Sensu is extremely sticky.

I think because Sensu is all about integrating with everything, and it kind of becomes as a backbone of your monitoring and telemetry solution, that, once they adopt it and put it into place, there are fewer or no things that could possibly replace it.

And because of that, once they are paying customers, when the time comes to renew, they simply renew, or they realize that their license isn’t good enough for the number of devices, and they up it.

That’s something that I’m happy to be surprised by.


Michael Schwartz: One of the questions I’m always curious about is, how hard was it to figure out the right way to price the platform? And did you have to pivot at all on pricing, or were their challenges in figuring it out?

Sean Porter: First, I’ll say, we’re still figuring it out. And I think we’ll always be figuring it out. As the feature set kind of evolved and grew, we had more options in terms of how we’re going to price it.

I think for the longest time, we’ve kind of had to just use the Crunch, that is the monitoring device, and obviously, that doesn’t really work with today’s infrastructure and applications. Because that number is constantly changing, and we just kind of again lean on our other crutch, which is the honor system, where you say, “Pay for license, for like, the mid watermark of your infrastructure.”

If majority of the day you have a thousand machines, get a license for a thousand machines.

But as the product has evolved, and the feature-set evolves, we’re now given more options in terms of how we can price. We can price around buckets of features.

You know, ones that might only make sense for organizations of certain size, obviously, we can then charge more for that package, and we’re continuing to evolve on this.

I think, even at the very beginning, when we look back, when we were a company, and we had, like, two full-time people working on this project, we made a sale to a US Bank, for perpetual license. And it had a whole bunch of zeros in it, we were like, “This is amazing!”

But then the reality set in that now we just sold our perpetual license, now we have to focus around support around that particular customer, in terms of generating for the revenue.

I think that’s just kind of one of the learning steps that you go through as a small business, building around the open core model, and then, coming to the realization that you will always be changing your pricing model, you’ll always be changing your feature set.


Michael Schwartz: Yeah, at Gluu, every time we thought we had it figured out, it’d be like another couple of months, and we’d tweak it a little bit. I think we are still tweaking it actually.

Sean Porter: Same thing goes for like messaging it on your website, you’ve like, “We’ve done it! We have the best way to talk about our product, and then, like, two months later, you are like, “What do we do?”

Michael Schwartz: Yeah, I agree. Question about channels, you’re still relatively new company, and channels take a long time to develop, but how has your experience been with developing channel partners, and where do you see that going in the future?

Sean Porter: I mean, in terms of partnerships in general, from the get go, we focused on very loose partner relationships, to try to drive sales that way.

Since it was designed to work in an environment with configuration management, so having good relationships with companies like Chef, and Puppet, and Ansible, more like technology partnerships that just kind of made sense from like a Tool Ecosystem point of view.

So, as companies were adopting, Chef or Puppet, they needed a monitoring tool that could
work as fast as their automation tooling could. So, that was part of like initial BuzzDev and partnership efforts to align with that.

And then, as time progressed, we came more global in terms of our user base and our customer base, so we needed more outreach overseas, so we have some partnerships with companies, like, one is called Amazic, and the other one is called Becon. They are both in Germany and UK. Just to give us boots-on-the-ground overseas as well as just another form of, like, a sales funnel through these partnerships.

And then, of course, we’re still trying to figure out what does a reseller look like, what do OEMs look like for Sensu. I think we have a lot of work to do in that regard, but, overall, like partnerships with other companies have been a good source of generating customers.


Michael Schwartz: Where is Sensu with regard to sales and marketing?

Sean Porter: Majority of our sales are in-bound, a lot of people just landing on the website, or you know, seeing some of our talks at events kind of thing, and seeing Sensu in action, or word of mouth, and then they’re coming in and starting conversations with us.

We’ve just been working on scaling our sales organization to just deal with that amount of leads, but we are trying to evolve and create the marketing and sales machinery, to be able to generate more leads, and to start to be able to do more outreach, more outbound sales, but all that still in flight and constantly changing.

The most challenging problem to solve right now is messaging Sensu, getting Sensu in front of more eyes, and then working on converting those very raw leads into proper sales leads.

Raising Series A

Michael Schwartz: Can you describe the process for raising your series A?

Sean Porter: I think for to make Sensu all started, at the very beginning, we were a company called Heavy Water Operations, we were a DevOps consultancy, a small team, and then we made the choice to kind of pivot to Sensu, but before doing that, we actually tried to create another product, but we really couldn’t get enough traction there.

It was around software delivery pipelines, like CICD stuff, and it really wasn’t working for us.

But on the side, we always had a lot of business around Sensu. And my partner, Caleb and I, we had the idea to just package it up, and then create an Enterprise version. We were actually able to sell it, and we actually got that large perpetual license and a bunch of other good sales close on that.

We were basically able to validate the fit, and the fact that organizations were hungry for a paid version of Sensu, so we knew we had something, and that’s when we pivoted to Sensu full-time.

We were showing all the right signals as we were growing at a good pace.

The one thing we didn’t have a problem with was hiring talents, our team grew quite quickly, and it was time to raise our series A. We gave ourselves three months.

My partner Caleb and I, we did a typical road show, we traveled around, just getting some face time with a few VCs.

I think a month later, only four to five weeks later, it was time to take a deal. We raised a series A with Battery Ventures and Foundry re-upped again, as well as our Angel Investors.

I think we probably waited too long to start that process, really we should have started to work to raise our Series A sooner, but in the end, we ended up with a very favorable round for the company.

I think giving ourselves more time so that you don’t have the pressures of running out of money is always a good idea. I think, in hindsight, yes, we would have started to raise Series A.


Michael Schwartz: Do you think you could have bootstrapped it?

Sean Porter: I think so. I think we could have bootstrapped it. Everything’s always easier looking back.

If I could go back in time and do things differently, I would go back to probably 2012. I would just do Sensu full-time then, and really focus on just bootstrapping it, just staying super lean, and I think it would have been fine.


Michael Schwartz: Was the team mostly people who were local, or were they people who were active in the community, like, where do you actually find the team?

Sean Porter: It was a complete mix.

People who I’d worked with previously, or we had known in the community, and then there was a good number of people who haven’t even used Sensu before, which I thought was really interesting.

When time came to choose and grow our initial team, it was like, “Okay, who do we know in the Sensu community that has contributed, that knows about Sensu, the value that it brings?” We immediately went out and connected with those people.

As expected, it didn’t take much to get them to join and come on board which is really cool.

As a completely 100% remote company, we do have an office or studio in Portland, but no one works there, all forty of us are all over North America. It really made it easy to find engineers and sales folks all over the place that just really believed in the product and understood the value that it brought.

Michael Schwartz: All in the US – anybody overseas?

Sean Porter: Majority of our engineering team is actually in Canada.

What’s interesting, when you’re fully remote company, and then I’m actually Canadian, I’m up in the city called Kamloops, BC, Canada, we are fully remote, and we have a Canadian subsidiary, but when you offer competitive salaries that are also well above usual Canadian market norms, you attract very talented engineers in Canada. I think because of that, we ended up with a number of Canadians on our engineering team.

Biggest Open Source Challenges?

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

Sean Porter: I think the biggest challenge is your market, your market segment is crowded, how do you differentiate yourself from everyone else in that space.

And then, how do you package a version of your software that you can generate revenue for, or how do you become a software as a service provider that can get amazoned out. I think those are the biggest challenges.

How do you provide value on top of the open core, where people are going to pay money for?

Or, how are you going to do something so unique, from a software service point of view, that somebody else, larger than you, can just zap you out of existence, by running your own software more effectively than you?

I think those are the biggest challenges, and I think those ones are kind of the obvious one.

License To Prevent Saasquatters

Michael Schwartz: Are you worried about that for Sensu?

Sean Porter: The only case where it could affect us is if we chose to run a SaaS version of Sensu.

If we start to generate a more of a revenue from that, I think then we could become at risk of having that part of our business, having the rug pulled out from underneath us, if a cloud provider decided to run a Sensu SaaS. I

think then we would be at risk of losing part of our business, or at least a revenue stream.

To SaaS Or Not To SaaS

Michael Schwartz: How often in the last 4 years or so, have you considered launching a SaaS Sensu?

Sean Porter: I think constantly. My background is in operations, and I understand what it takes to operate a hosted service and the cost associated with it.

Every time I’m, “Uh, we should totally do a Sensu SaaS!” That would be really wicked, it would help people adopt Sensu, people start using it, lowers the barrier to entry considerably, but then the cost associated with operating that, the margin for generating revenue around that.

I feel like it’s a whole other separate business than what we’re focused on right now, which is how do we make Sensu easier to use so that it can be deployed on prem without problem.

We simply just avoid the cost of operating the hosted service. We will continue to ask ourselves the question, “Do we run a SaaS every Monday morning?” And as it comes down the line, maybe one day we’ll say, “It’s time. Let’s do it.”

I think if we were to do the SaaS thing, or at least, build the company around it, we would have raised specifically to tackle that. We would build a different team, a different company in order to do that over the last two years. One thing I would like to point out is that we have gone on 1.x on Sensu for a number of years now.

Sensu Go is the next gen one, so if we did build SaaS, it would be around our new technology.
If we were to do a SaaS, we’d start after that goes fully GA, which is at the end of this month.

Long-term Plans

Michael Schwartz: What does a long-term look like for Sensu?

Sean Porter: In terms of the technology that we are looking, 5-10 years ahead, just trying to say, “Okay, what are the general trends for the early adopters now?” Because that’s going to signal where the big ships are eventually going to turn to. So, just making sure that Sensu, from a technology perspective, is aligned with that future.

I think we’re thinking more ahead in terms of the business and the products, it’s much more short-term, seeing what works and what doesn’t, and then making those changes as quickly as we can, experimenting – in that term, we are just talking like a few years. I just want to see company to continue on the growth rate bet.

It has been experiencing adoption rate. If we stick to that, I think Sensu has a very bright future, and I see Sensu running on technology infrastructure and applications a decade from now.

Closing Advice For Entrepreneurs

Michael Schwartz: Do you have any advice for the entrepreneurs who are thinking about developing a business around the open source product?

Sean Porter: I think the most important thing is to first test, in terms of building your career or a company around open source is to see what sort of people gravitate to the thing that you’ve created or the idea that you have, and to see what those people can do with it.

I think it’s an early indication of when you’ve hit on something that brings value to people’s lives.

If other people, strangers, are willing to download your project and run it on infrastructure that runs a company that pays the most salary, I think there’s nothing better than that. It’s pretty awesome.

And to see if they start to kind of coalesce into community. I think if you got the community around your project, it’s time for you to pour more of your heart and soul into that thing. If you’re not seeing that happen, maybe it doesn’t make sense to focus all of your energies on that, and try something else.

I would say, don’t rush to raise venture capital around your open source project.

See if you can bootstrap, see if you can get more traction without it, see if you can do it when you’re a little bit more scrappy, when you can just focus on the technology, on the open source product, and less so on building a company and organization around it. I think you will be better off for doing it.

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

Sean Porter: Thank you for having me. I hope that your listeners on this episode have used to it.

Special thanks to the Sensu team for arranging the interview.

Transcription and episode audio can be found on opensourceunderdogs.com

Music from Broke For Free Chris Zabriskie and Lee Rosevere.

Production assistance and transcription by Natalie Lowe.

Operational support from William Lowe.

If you enjoyed this podcast, you can say thanks by tweeting it out. Our podcast Twitter handle is @fosspodcast.

You can find out more about Sensu at Sensu.io.

Until next time, thanks for listening.

Episode 11: data Artisans – Apache Flink Stream Processing with Kostas Tzoumas

Kostas Tzoumas is the Co-founder and CEO of Berlin-based data Artisans, the leading company behind Apache Flink, an open source stream processing framework that merges event-driven applications and real-time analytics. In this episode, Kostas discusses how Flink went from university research, to open source project, and finally to a commercial enterprise.

Update: In February 2019 data Artisans changed their name to Ververica.



Michael Schwartz: Welcome to episode 11 of Open Source Underdogs, the podcast where we try to process all the incoming information about open source business models.

Kostas Tzoumas is a CEO and one of the founders of data Artisans, a company who commercialized Apache Flink. Flink enables developers to query big data in real time, as it’s being created.

I’m recording this episode in data Artisans’ Berlin office. Kostas, thank you for joining us today.

Kostas Tzoumas: I’m happy to be here.

Michael Schwartz: Kostas, tell us about yourself – what’s your background before you got involved with data Artisans?

Kostas Tzoumas: So my background is in computer science. I started in computer science, I did a PhD in database systems, and then I moved here in Berlin to do research on big data. And this is actually where the whole idea of Apache Flink and data Artisans as a company came through, through the research work doing at the university here in Berlin.

What Is Stateful Stream Processing

Michael Schwartz: Keeping in mind that our audience is general interest/business, could you tell us a little bit about what Stateful Stream Processing means and specifically what is Apache Flink?

Kostas Tzoumas: I would say Stateful Stream Processing is a fancy technical word for something super simple. And the whole premise is the following: If you think of data, the way that data is usually generated is continuously.

So think of a clickstream. A clickstream is basically capturing the clicks, and the things that we do on websites or apps or whatever. Or think of sensors in the natural world, measuring something and awaiting data. Or think of financial transactions.

The way that data is born in the outset is always one event at a time. It is a continuous stream of events – that is what streaming means.

And the main idea behind stream processing and Stateful Stream Processing is to embrace this fact, and instead of trying to land the data first to some place, and then process them, and then do analytics on them, it is to do the analytics while the data is flowing. That is basically Stateful Stream Processing.

“Stateful” means that the computation itself is my worry, so stateful is really just a word for doing more than something trivial if you will, so analytics on the data, building applications on these streams of data that do, for example, things like fraud detection. For example, we are working with banks that are getting a continuous stream of credit card transactions, and they’re trying to classify whether the transaction is real or fraudulent.

The state in this case refers to the model. It can be a machine-learning model that determines whether a transaction is false or not. It can do things like real-time personalization, real-time recommendations.

So, for example, as people are buying things in any commercial, for as people are looking up things, hovering over something then you can continuously adjust the model that recommends new things to your customers.

One example is that we have been working together with Alibaba for quite a while, and they have built the service and recommender engine, based on this concept of using the real-time information for personalization and recommendations.

Other relevant work there is what Netflix has done with Apache Flink, taking into account what we are doing real-time on Netflix to personalize the website and recommend movies and series to you.

What Is Flink?

Michael Schwartz: Tell me a little bit about Apache Flink.

Kostas Tzoumas: It has a very interesting history.

I think the first line of call was written by my co-founder, maybe 9, 10 years ago, it started basically as a platform, that was when the whole idea of big data and distributed data processors, like Hadoop, was starting out. And the idea was to do that in real time, so massively distributed data brochures that came out were very batch processing-oriented, meaning that you would get a lot of data that you would process, that you would wait for a few hours, and then you would get an answer.

And the idea was to do that continuously and do that in real time.

As I said, it started out as a research project here at the Technical University of Berlin, then the team open sourced it so we donated it to the Apache software foundation.

That is when we came up with the name Apache Flink. So “flink” is a German word for agile or fast. And then a very fitting logo for this was a squirrel, which is very popular in Germany, it’s an animal that can move very fast.

And from then on it has been basically several years of the project, growing massively in an open source community, so it is by now one of the biggest projects in big data because it is being used in production by most of the tech companies in the world and also enterprise.

Origin Of data Artisans

Michael Schwartz: How did data Artisans get started?

Kostas Tzoumas: That I would say follows really the Flink history.

So the team that built the project at the university, at some point we decided that the best way to accomplish the mission that we were having, which was to really bring the technology out in the world and have everybody use it – this was best accomplished by starting a company rather by doing academic research.

So when we started data Artisans about 4 years ago, we had a very simple goal, which was to make it possible for everyone to use stream processing with Apache Flink.

How To Go From Project To Funding?

Michael Schwartz: It seems like the funding and the company almost got started at the same time – how did that happen?

Kostas Tzoumas: I would say that clearly, from the beginning, we were always positioned as a company based on the open source, so what we had was a great technology, a great open source community.

This is a model that has been proven to some extent by some companies, and to some other extent it is still being proven. There are a lot of companies that follow this model, so they have an open source foundation and build a business based on that.

This has always been our premise. We were always looking for investors that will subscribe to this sort of long-term.

Open Source vs. Enterprise Features

Michael Schwartz: How do you decide which features go into Apache Flink and which features become data Artisans features?

Kostas Tzoumas: With data Artisans we have always been following a very long-term approach.

In the first few years of the company, we were basically doing everything in open source, 100% in open source. Monetization was not the focus, the focus of the company was to grow the open source community, to help the open source community, we were doing a lot of work together with companies that have used Flink, with the goal of adoption. At some point, this worked out for us.

At this point, Flink is the engine of choice for every company that wants to do any kind of serious stream processing. It was the point that, also with data Artisans, we decided to move on to the next step, which is to build a business and monetize the business.

The way we did that is what people are referring to as the open core model, so we have a product, it’s called the data Artisans Platform. It encapsulates Apache Flink, and also adds additional features on top of that, and we offer that together with enterprise support.

There have been two features that we have added on top of Apache Flink that are contained in our product. The first one we released over a year ago, and that is a way to basically manage the deployment of stream processing applications and production. It makes it easy for enterprises to operationalize Apache Flink.

The idea is that we should be able to experiment quite a bit with open source. But then, if you’re an enterprise and needs additional help and additional tools to bring it into production, to connect it with all the other infrastructure. You have like login, matrix, etc, and to really build an internal platform to use – that is where our offer kicks in.

Then the second feature is part of data Artisans platform we released in September. It’s called the data Artisans Streaming Ledger, and it is effectively a way to do ACID transactions on streaming data.

To your question, how do we decide whether something is open source or closed source – I think it’s a fine balance.

We are always taking the long view. We are not maintaining an internal version of Flink, we’re shipping standard Apache Flink.

At the same time we appreciate – and I think by now open source communities appreciate as well – that a healthy business behind the open source framework is something that is also good for the development of the project.

Really the value proposition is that you get a turnkey solution, you don’t have to build stuff around the edges yourself but you get a turnkey solution that has been built, by the creators of Flink. It has been tested by us, it’s been supported by us. And we can basically help you on your journey to adopt, productionize, and use stable Apache Flink production.


Michael Schwartz: So how do you license that? Is there a different license for let’s say the non-core features?

Kostas Tzoumas: Apache Flink is Apache license, obviously. Our product is as a whole closer, it comes with a license, and we offer that in basically two editions.

In one we call the Stream Edition, which contains Apache Flink, application manager. And if you have components, then the other one also contains a streaming ledger, the ability to do ACID transactions. We call that the River Edition.

Other Revenue Streams

Michael Schwartz: Are there any other revenue streams like services or trainings?

Kostas Tzoumas: Yes, we do offer services to customers, and we also have training for Apache Flink, which we do both in the form of on-site training to customers, and also recently we organize public trainings in several cities.

Michael Schwartz: But in terms of a percentage of revenue on licenses – is it more than 90%?

Kostas Tzoumas: We are pretty focused on licenses as a company. I think we better wait to make a revenue, selling a product rather than selling time – it scales much better.

Customer Segments

Michael Schwartz: So, who are the current customers – do you segment them in any way, for example by sector or by functional application?

Kostas Tzoumas: Product is very horizontal. Obviously, the open source community is completely global, and I would not say it’s segmented in any way, so we have use cases from all industries.

As a business, we see a lot of early commercial adoption in the financial services sector – so investment banking, insurance companies, and so on.

That’s not to say that these are the only customers that we serve, but we do see a good amount of commercial adoption.

Contributions From Large Companies

Michael Schwartz: Are those larger cloud companies contributing? Are they buying support, or are they contributing in other ways to the project or to data Artisans?

Kostas Tzoumas: Netflix is a user of the open source framework. Same goes for companies like Uber, Lyft, so the larger, new tech companies.

So in tech companies, they usually have a different mentality, to make sense for them would be to hire talent and build a lot of things internally. But they do contribute in other very, very meaningful ways to the open source communities.

For example, specifically with Netflix, built largely on AWS, and they have tested Flink on AWS, on a scale that pretty much nobody else has. So they really made Flink extremely stable at that scale with AWS, which is a benefit to every other potential user or data Artisans customer that wants to run on AWS.

Concerns About SaaSquatters

Michael Schwartz: You might have been following some of the license changes by other open source companies to prevent monetization of the open source by large cloud providers in a way where they’re not contributing their fair share to the open source.

Are you concerned that an Amazon or Google might take Apache Flink and build the features that you consider enterprise and compete with you?

Kostas Tzoumas: I mean, this is definitely something that might happen, as Flink is getting more and more popular.

Amazon and Google already have offerings around Apache Flink, in their free services, on Amazon EMR.

Does this concern me – yes, it concerns me.

I would very much like to be in a world where all of these players would play specifically and contribute back to the open source community.

However, I take an optimistic approach to this, so this also proves the popularity of the platform. We are in a market that is growing every day.

We see completely new applications coming in every day. I’m less concerned right now about how we’re going to slice the pie, but how everyone in the industry is going to work together to bring the message out, the message about streaming data, and to make the pie even larger.

It’s just the market is growing very, very fast.

What’s Next?

Michael Schwartz: Where do you think you need to go from here? What new products and services are in the planning phases?

Kostas Tzoumas: I think we are just in the beginning.

We see stream processing as a new paradigm for data computation. It just changes the way that you look at data.

Instead of landing the data somewhere, and then finding a query, and then getting an answer, you have a query that is running always. And as this data is coming in, you always have the most updated answer. And we just see more and more and more applications coming in every day.

When we were starting out, the main use case for streaming data was to do real-time analytics, and usually to kind of do an approximate analytics in real time, while you wait for the correct answer to come up later.

Then we saw a lot of applications that we would classify more as applications rather than as analytics. Things like fraud systems as I mentioned before, or billing systems, and things like that.

So actually running the business – not measuring what is going on – with the new functionality that we brought in our product, the streaming ledger, we are now able to cover use cases that before could only be covered with relational database systems; use case and applications that need basic transactions.

We see a lot of movement in a Flink community, trying to bridge the gap between the batch processing and stream processing.

Batch processing is really a subset of stream processing. Batch computation is a stream that just so happens to have a beginning and an end – so you can do that as well.

So we’re just seeing new applications coming in every day. And the way we are approaching this is, we are trying to create the tools to make this accessible to the Enterprise.

So every company that, let’s say, does not have the ability that, sort of Netflix or Uber have – to hire dedicated developers and build everything on their own – we have positioned ourselves as being the vendor that can enable them to be at the same place that Uber, Netflix, and Alibaba is, but without having to roll their own system.

So we’re learning from the community of our products.

Range Of Customer Interactions

Michael Schwartz: What’s the range of different customer relationships you have? So some customers maybe give a very direct support relationship, some customers maybe they never call you – so what’s sort of the range of customer interactions that you have?

Kostas Tzoumas: Right now, in the state that we are in our business, we strive to have a direct relationship with every customer.

So everything we do is direct sales, or most that we do is direct. And we strive to have a very direct and a very deep relationship with a customer, working together with our engineering teams, like really being a partner for them.

Sales Process

Michael Schwartz: How do customers find you?

Kostas Tzoumas:The open source platform is famous, that’s where people find us. It’s all inbound, we don’t cold call anyone.

And from that point on, for us, it is a typical Enterprise sales, because we work with very large enterprises, large deployments, typical Enterprise sales process.


Michael Schwartz: Pricing is really a challenge for everybody, every industry. Can you talk a little bit about what were some of the challenges around pricing?

Kostas Tzoumas: As you say, it’s hard.

First of all, I think pricing works when it captures utility, so the customer must be happy to pay more as they get a lot more value out of it. I think this is one parameter. And the other parameter is keeping it simple, because nobody wants to solve a differential equation to figure out the price.

Balancing this too is always I think an arc, and I’m not going to say that we have done something completely different there.

Michael Schwartz: Have you had to tweak the offering a little bit since you get started as a being trial and error?

Kostas Tzoumas: Always, yes, we had to do that.

I think there’s no other way, you have to communicate with the market, see what the customer wants, see what resonates with a customer and then adopt.

Michael Schwartz: Isn’t that tricky in Enterprise sales, where there’s a longer sales process, and it’s not like you can do A/B testing, and sell your data Artisans platform for one price, and then sell it for another price?

What’s the time frame for you making those types of pivots?

Kostas Tzoumas: It is, and I don’t want to say we ended up doing any kind of pivot.

Our initial thesis there was well-received, we had to do minor tweaks. We also know the way that this kind of Enterprise customer products or price in the market is pretty uniform. Most of the companies show very similar broad concepts, so there’s also that experience to tap into.

It’s also valuable because from a procurement department, what they want to see is something they have seen before and understand and give a processing rather than fancy a new idea that someone thought of.


Michael Schwartz: Can you talk a little bit about channels? I know that data Artisans is still pretty new, but have channel partners played a role, and where do you see the partner program going?

Kostas Tzoumas: I’m a big fan of being focused. For me, building a company has a lot to do about saying a lot of “No’s,” and making a few bets.

When we started out the company, we focused 100% on open source.

At the time, that was an unpopular choice for many who were telling me, “You have to build a business, it’s not about the open source.”

If you try to do too many things at the same time, you end up being kind of medium good at many things, and nobody wants that.

So, for me, the first challenge was to achieve critical mass in the open source community.

The next sort of journey we are going on now is to prove that data Artisans is a business, and then after that comes scaling.

Right now, we’re working with a number of partners, but in an exploratory way, and when it makes sense to get a direct customer.

Pretty soon, we will start making a more formal partnering program, but we haven’t done this yet.


Michael Schwartz: How do you distinguish your offering from the competitor’s?

Kostas Tzoumas: What is core to us is that we are basically the people that created Apache Flink, originally internally in the company we are the experts on the framework.

We are the ones who can support the customer best. And by participating in the open source community and by working together with all of these large tech companies that are using Flink, even if there’s another customer, we are learning so much, and we’re bringing all of this institutional knowledge to our customer. We are really the absolute experts on Apache Flink.

There are of course other alternative frameworks from Apache Flink, and they are distinguished by, if you really look at the market today, Flink is ahead of its competitors in stream processing for a number of years in development. Both in terms of feature shared and the functionality of the new framework, but also in terms of to how much extent has the framework had been tested and hardened at a very large scale.

Ten-Year Vision

Michael Schwartz: Where do you see data Artisans in 10 years?

Kostas Tzoumas: The market is growing very, very fast. This is a new paradigm for data.

Companies are realizing the benefits that embracing this paradigm can give them, but I think we are really in the early days of the market.

Challenges For Open Source Startups

Michael Schwartz: So you’ve had quite the experience building an open source community and an open source company – what do you think are the challenges facing new founders of open source companies?

Kostas Tzoumas: A lot of companies, before we started Artisans, had done a lot of the groundwork – for example, the Hadoop companies Cloudera, and so on. They had proven to the market, they had convinced the market, that open source is a good thing.

For example, we in data Artisans have never had to sell and to convince a bank that open source is a bad thing – that’s a huge step.

I also think that developer communities are also becoming a lot more business savvy. Developer communities are also realizing that having a financially successful business, backing up the open source projects, just means better results for the open source projects.

I think for us, data Artisans, and for new founders, that a lot of work has been done – but it doesn’t mean that this has been proven.

There are very few companies in the world that have successfully IPO’d, and have been public for a while, or have been financially successful with open source. But a lot of this road, I think, has been paved.

I think one challenge for the new founders is the licensing challenge that you mentioned before.

Basically, how can you avoid sort of parasitic behavior in the community. So, companies just grabbing the open source, offering it commercially, but not contributing anything back – I think this is an active discussion right now in the open source community.

I’m interested to see how it goes from an academic point of view more, because for us, we are part of the Apache Foundation – Flink is Apache licensed, and it will stay like that. But the movement in this space for me is interesting.

Advice On VC Process

Michael Schwartz: Any tips about the VC process and working with VCs might be helpful to other entrepreneurs?

Kostas Tzoumas: Yeah, I think this is a challenge in every company. I don’t think this is particular for open source companies.

I’m not going to pretend that I’m the one who is in a position to give advice at this point. But even if it kind of sounds like a platitude, what I have seen is that the person matters a lot, so the particular partner that you work with is paramount – and perhaps even more important than the firm.

Closing Advice For Entrepreneurs

Michael Schwartz: So one last question – do you have any personal advice for the entrepreneurial person who is about to start a company?

Kostas Tzoumas: It’s hard. I think first of all what I have seen is that the motivation should not be the money.

Money has not made any successful entrepreneur who was motivated by money, and to do all the hard work, and to stay up all night, and to go through all this stress, you really need to believe in your mission and refine your mission.

And then the other thing I learned from others that came before me and mentored me was exactly the importance of being focused.

So when you’re starting a company, and you’re building a company, it’s not obvious what you have to do. Especially for me, that’s my first time doing that.

So it’s never obvious what you have to do. And, you know, you see all of these things and you always think – hey, I should be doing a little bit of that. I should go to that conference, and that conference also looks good. Or, maybe we should be building a product now and targeting that market, because oh, there’s another community coming in that’s targeting that market.

So, you can very easily get lost.

What I think has proven very, very useful for me is the importance of focus. So the definition of a startup is limiting resources and maximizing the impact of these resources.

So the question should not be, what is the possible spectrum of things that we can do, but whether there’s 1, 2, 3 maximum things that we can do to maximize our impact in this world, without resources right now.

So focus on one thing and become extremely good at this. This is the advice that I have gotten, and it’s served me very well.

Michael Schwartz: Kostas, thanks so much for your candorous responses, and thank you for being on the show.

Kostas Tzoumas: Thank you so much.

Michael Schwartz: Special thanks to the data Artisans team for reaching out to us. 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.

We have a packed schedule for 2019. Next time we’ll be talking with Sean Porter, Founder of Sensu – he has some great insights, so don’t miss it.

Until then thanks for listening.

Episode 10: Nextcloud – File Sharing Platform with Frank Karlitschek

Frank Karlitschek is the Founder and Managing Director of Nextcloud, an open source file sharing and communication platform. NextCloud provides cloud, virtual desktop, and application hosting services for a range of organizations that include healthcare, education, finance, and government. In this episode, Frank discusses the value of Nextcloud’s community contributors and why he believes transparency the best competitive differentiator.



Michael Schwartz: Welcome to episode 10 of Open Source Underdogs, the podcast where we discover new recipes for open source business models from around the world.

Frank Karlitschek is a free software developer, entrepreneur, and privacy activist. He is the founder of Nextcloud, which is self-funded and employee-owned. For those of you who don’t know, Nextcloud has been incredible success story with over a thousand contributors, and 50,000 plus commits.

Frank is a true open source hero and inspiration. Frank, thank you so much for joining us today.

Frank Karlitschek: Thanks a lot for having me.

Michael Schwartz: So tell us about yourself, how’d you get involved with free software?

Frank Karlitschek: It happened like over 20 years ago, I think it was around like ‘96/ 97, I think ’96, a friend of mine showed me a desktop running open source at a time, with KDE desktop, KDE 1.0 better or something, I don’t remember, and I looked at it and I was, “Oh, that’s nice. It’s all free software, it’s all done by the communities around the world.”

There’s no real company around, it’s all self-organized, it looks so much better than Windows 95 at a time, I thought, and of course, I said like, “next year this will of course conquer the desktop.”

Then I went to work in the KDE community, for the Linux desktop for a long, long time, but yeah, things changed over time.

Why Not Dual License

Michael Schwartz: Nextcloud has an interesting history, it’s a reboot of a previous company in a project called ownCloud.

In your 2016 blog, you mentioned a few changes for contributors, including no dual licensing, no requirement to sign a contributor license agreement, trademark held by a foundation, and making development planning a public process.

Can you talk a little bit why each of these considerations were so important? Let’s start with no dual licensing – what do you mean by that? Doesn’t Nextcloud currently have Enterprise features too?

Frank Karlitschek: Yeah, that’s a very big question. Where should I start?

So the thing is that the Nextcloud community and also a lot of the people in the Nextcloud company, they have history in the former projects that they also founded, but then that wasn’t that successful at the end.

So because of the history, we decided to do some changes, and as you mentioned, lots of those decisions were influenced by mistakes or problems that happened before the former project.

So you mentioned the dual licensing, I mean, maybe I should explain what it means. Open source software is available under free software license, obviously, otherwise, it’s not an open source project or a free software project.

The concept of dual licensing is that there is also a second license. If you want to use the software, then you can basically choose between two licenses. And the concept of dual licenses usually means that you have a free software license, the second license is usually not free software.

It’s like a proprietary license usually which means that you have additional rights, you can do more things that you can’t do with open source license. But to get these rights, you have to pay.

It’s usually a business model from companies who say, “hey you can use this free software version. Or you can use this other version, but for that, you have to pay.” This sometimes gives the user the benefit that they don’t have to follow some of the restrictions of the free software project, or free software project as Nextcloud, it means that you can use it for free.

You can change it obviously, but if you change it, you have to contribute those changes back to the community. And if you don’t want to do that, you can pay other companies, not like us, to not have this responsibility.

But we don’t really like this concept, so the Nextcloud community has a strong opinion that everything should be open source and free software, and we don’t really like these proprietary licenses – we don’t do this at all.

More On Dual License

Michael Schwartz: I see. You know, when you mentioned in ownCloud, contributors had to sign a contributor license, I found that somewhat unusual. I’d actually never heard of that before – do you know why they implemented that change, and why did you want to get rid of it too?

Frank Karlitschek: This is something I should have mentioned, you can only do this dual licensing if you have to complete ownership of the code. If the company owns the code, then the company can release it in a different license, and if you want to do the dual licenses, you have to own the code.

So this means that every contributor has to give the ownership of the code to the company, and this is usually done via contract.

If it’s the contributor license agreement, every contributor has to sign it, and then the company owns the code, and then they can do this dual licenses thing. As I mentioned, I’m not a big fan of that, I don’t think we should force contributors to sign a contract to give away the rights on their contribution.

I’m a bigger fan of a community, where this is not needed. For example, the Linux community, in the Linux Kernel you don’t have to do that, you can send the patch and the patch is of course available under competitive license, like a GPL.

And then it will be part of the software, but you don’t have to transfer the ownership to – I don’t know, the Linux foundation, or retailer, or someone. I find this weird. And it is also at open source project, like Gnome and KDE that do it the same way, and Nextcloud also does it that way.

We don’t require any contract or transfer of ownership from the contributors, that’s something that happened in the past with ownCloud, as you mentioned, we don’t do this and we don’t like that.

Why ownCloud Wanted a CLA

Michael Schwartz: So ownCloud took venture money, and then the company introduced on the advice of VCs, a dual licensing model, and at that point, the contributor license agreement was necessary.

Frank Karlitschek: Yes. The thing is, if you are an investor, then of course you invest in something that you want to sell later to make a profit, you want to sell it to a high price of course. And to do that, you need to have as much intellectual property as possible to justify this high price.

It’s really good if the company can say, “Oh, we own all the code, we own all the contributions.” But in the Nextcloud, we don’t want to sell the company, so we don’t care.

How To Use A Foundation To Protect the Community

Michael Schwartz: One of the things you mentioned was starting a foundation that owns a trademark – did you do that at Nextcloud?

Frank Karlitschek: Yeah, that is in progress. This is something that we still have to figure out how to do it correctly from a legal perspective. It will be a Germany e.V probably for practicality reasons, and this foundation will own for example trademark, and then can license the trademark to the company.

This is a bit a safety net, so if there’s any issue with the company, then the foundation could revoke this trademark grant and give it to someone else.

Also, something that I learned from the past, I think the community needs to be protected from the success or no success of the company.

Open Development Process

Michael Schwartz: Have you made the planning process more public? That was one of the goals also. I know that at Gluu, we prioritize features, a lot is based upon paying customers, but how do you actually make the process public but also run the business and give your customers the features they want?

Frank Karlitschek: We use GitHub a lot, it’s a bit controversial sometimes because now it is owned by Microsoft, but GitHub is like the place for us where everything happens.

Obviously all the code is there, but also we use the issues, the tax, and also the issues of feature planning, and there’s like some nice project management, there’s planning features on GitHub nowadays, we use it for all the planning.

So you can go there, and you can see the milestones, and you can see the texts assigned to issues, what version is planned, and so on. This is pretty transparent, and everybody can give feedback, a lot of people who communicate can give feedback.

We are a company, we also have customers, and the customers have opinions, what they need, so we listen to our customers, and if they want to have a feature, then we do it. But if we decide that we do it, we also put it on GitHub, it will be part of the planning and everybody can give feedback.

I think our contributing to a community is growing really nicely and I didn’t hear a lot of complaints, actually I hear the opposite, more and more people are joining Nextcloud every day. So I think this works out quite okay.

Role Of VC In Open Source

Michael Schwartz: Sometimes I warn entrepreneurs that VC money can actually kill you. It can help you but it can also kill you. You mentioned in one of the articles that you said, “With venture capital, you have to limit yourself to doing things investors can understand, rather than what users and customers ask. Is ownCloud a cautionary tale of how VC can go wrong?

Frank Karlitschek: First of all, I want to clarify that I don’t really have a fundamental problem with venture capital, it’s a fine model if everybody understands what it means.

I think it’s really difficult, I wouldn’t say impossible, but it is really difficult to do it together with an open source project. Because an open source community has a different understanding, different goals than a VC might have.

This is a challenge, and we don’t do this anymore. One of the issues was that we had to do something that VC understands. A good example of the past was that we had to decide which market we are in.

So, at the time, Gartner created or defined the enterprise file sync and sharing market, and ownCloud at a time was like, “Okay, do you need the enterprise file sync and share?” – that’s good.

But then our community decided to add other things, for example, implement a nice calendar and email integration, and contacts, and all kind of communication features, and chatting, and so on.

And if you talk to Gartner, they’ll say, “Well, this is not enterprise file sync and share, you can’t do that.” They are confused, you’re not doing it right, you don’t have this product market fit. I don’t really care, because we want to do what our users want and what our customers want. I don’t really care if you fit a specific box.

And it’s actually funny that nowadays Gartner changed the market from Enterprise file sharing and shared it to a collaboration platform. So actually the new definition is very similar to what we are doing, we’re doing communication and collaboration software.

So we are basically doing something before Gartner defines a name for it.

Initial Startup Changes

Michael Schwartz: Without VC money, how did you fund Nextcloud when you got started?

Frank Karlitschek: The first few weeks and months were of course a big risk because we didn’t have any customers obviously, but very quickly after a few months, we got a few very big ones.

After six months or something, it was very profitable, because we were very lucky to get a few very big ones. It was a bit of a gamble of course. If you want to found a company, you are not really sure how it would go, but, yeah, this is how it worked out.

In the first few weeks, it was of course tricky, because I mean, we didn’t start from zero, we started with 12 people already, so the first few weeks it was a challenge. But as I said, we were really happy that we got some customers very fast.

Customer Segments

Michael Schwartz: How do you say segments the customers – do they fall into any categories?

Frank Karlitschek: Every customer we have cares about security, and privacy, and on-premise, and things like that, but they come from totally different backgrounds.

We have lots of universities, we have classic enterprises, like manufacturing and people who really care about espionage and want to protect intellectual property. We have customers from the public sector.

For example, a German government is a big customer, so they use it for all the people in the German federal administration, then we have tax service providers who want to offer a service based on Nextcloud, so that’s totally different, but they all care about on-premise cloud basically. This is a thing that is same for everybody.

Customer Events and Input

Michael Schwartz: How do you interact with customers?

Frank Karlitschek: We do a lot of different things. I mean, we have the usual meetings and phone calls and workshops, but we also do events like an Enterprise Day.

It started two years ago, and then last year, and this year it was in Berlin that we had a lot of people coming together for this day and discussing Nextcloud and Enterprise – it was so successful that we do this, at least, two times a year now, so the next one will be in early 2019.

That is an event where they can sit together all day and discuss things with the developers directly, then we’ll do something like a Customer Product Advisory Board. This is something that will be announced in a few days.

This is a way that bigger customers can directly together with us discuss a roadmap, so they want to have like more influence, and we have a forum for that. In general, I think we are a very, very open, transparent organization. I mean, every customer can look at GitHub and see all the things and what is going on in the planning.

So I think we have really a lot of good ways to interact with customers.

Types Of Customer Interaction

Michael Schwartz: It’s such a big community, and you can’t have a personal relationship with all the organizations that use Nextcloud – how do you sort of make that balance?

Frank Karlitschek: The thing is we really want to create a really good and stable product, so every time someone responds with a serious issue with us, we fix it, it doesn’t really matter if it’s a paying customer, someone from the community.

I mean there are open source projects or companies who say, “We don’t really care about the community at all, we only care about paying customers.” But we also care about the community because at the end it makes our product better, which helps everybody.

Of course, we provide some kind of premium support for all paying customers, that is why they’re paying us. They actually have a phone number that they can call and direct email communication, and access to like a knowledge base and some other things. This is the premium enterprise support that they are paying for. But, overall, I think we really care about a stable product.

If the community also reports on GitHub a serious issue, we fix it in the same way.


Michael Schwartz: Can you talk a little bit about how you’re building the team? What are your thoughts about location of team members, and how do you find people who become part of the team?

Frank Karlitschek: This is something that’s surprisingly easy for us, because as you mentioned the community, so we have a lot of people that are active on GitHub.

So, if I’m looking for another developer, it’s really easy because I can look into the existing contributor community, and I find the right person. And I usually approach the person, and say, “Hey, what are you doing as a hobby at the moment? Do you want to get paid to do the same?”

So, finding a good developer is pretty easy for us, and also like in other areas, like marketing and sales – it’s far easier because next level is quite well-known, and a lot of people use it already, and this all works out quite well.

Of course it requires that you work with a distributor team because when people are hired, they are not all in Stuttgart or Berlin, so we really redistribute it. So, actually lately, I looked into our employee list, and we have employees like in 9 countries at the moment.

And this requires that all the processes and everything we do have to work with a distributor team, but to be honest, this is a requirement anyway for all community, because our communities are also distributed.

As long as you have the process and the tools to work like with people sitting in home offices and other places on this planet, then it’s quite nice. So I’m really happy with our team.


Michael Schwartz: Are you offering 24/7 support?

Frank Karlitschek: Yes, we do. An important thing regarding support is that we don’t really have a support team, like other companies that have instigated support team.

Our support is directly done by the engineers, which makes our customers really happy because there is directly someone on the phone who actually understands what you’re talking about, which is not always the case with other support organizations. And this also helps our engineers to understand customer requirements better. It’s a win-win.

Of course, if you work with engineers directly, they are more expensive than, I don’t know, random phone support persons somewhere, but this is what our customers are paying for, they really get like the best possible support.


Michael Schwartz: Do you feel like the support revenue is capturing the value that customers are seeing from the software?

Frank Karlitschek: I need to clarify something. When we talked about support minutes ago, but we don’t really sell support, we sell a subscription. It’s called Enterprise subscription, it’s very similar to what you buy from Red Hat and SUSE, and other open source organizations, and part of this subscription is support, but there’s more in the subscription.

For example, you also get help from us with scalability of the instance, with security, how we can do security reviews, you get the roadmap as we discussed before, you get maybe like special packages for your Kubernetes cluster, or whatever special requirements you have, and so on. You get a little bit more than just support.

What we are basically selling is maybe like an insurance.

So if you run like Nextcloud in your organization, with like a thousand people, and it’s basically mission-critical, it’s really a big problem if your service doesn’t work anymore. Then you can get from us like a subscription, and it’s basically like an insurance so that you can make sure that it never fails.

We deliver everything to you to guarantee that it never fails, and part of it is support but it is small rounded.


Michael Schwartz: How about renewals? How’s your experience been with actually customers renewing?

Frank Karlitschek: We are quite young, two-and-a-half year old, we don’t have a ton of experience with renewals at the moment, but I think so far, we had like two customers who didn’t renew. And the rest, like hundreds, they renewed it. So it just seems to work out quite well.

It’s funny, the feedback that we got from the two customers who didn’t renew the subscription, they said, “Look, your software is so good, it never fails – we don’t need your help. “ which is in a way great, I mean, good that Nextcloud is so stable, but of course it would be nice to have another subscription.

Overall, like 98% of the customers, they have their subscriptions renewed every year.


Michael Schwartz: So the company is still new, but partners played an important role in the development of Nextcloud?

Frank Karlitschek: Partners are important, the different kinds of partnerships of course. I mean, we have more the resellers and the system integrators who basically is the organization that will take Nextcloud, sell it to the market and implement it, customize it, and so on.

This is very important because we are a software company, we are not a system integrator organization and we don’t want to become one.

For that, we need partnerships. This works out quite well, I mean it’s still early. I can say that we get a lot of requests from companies who want to help us – actually reselling those subscriptions through them is something that also happens, but I expect it becomes a lot more in the future.

And then we also have technology partnerships. The thing is that Nextcloud is software that can synchronize files, do communication and collaboration, and other things.

It means that you should integrate it into other software that runs in your organization, like backup or storage, monitoring, or identity management as Gluu for example, so I know that Gluu is connected for example for Nextcloud, and this is a great technology partnership. We have lots of them and I really like this a lot.

It makes everybody stronger, and I think more open source companies and organizations should like integrate into each other.

Why Not Cloud?

Michael Schwartz: Eliot Horowitz in one of the previous episode, stressed how critical it was for open source companies to have a cloud offering, certainly the value proposition of Nextcloud is on-premise, control your privacy, control your data, but I bet there are a lot of customers out there who would love a cloud version. And there may be some advantages to operating a cloud service and insights that you might get in using your software.

And there’s a lot of friction these days between large cloud providers and the open source software that they’re using and not always contributing back to proportionally – you must have the given some thought to launching a Nextcloud cloud offering – what are your thoughts about that?

Frank Karlitschek: Of course, when I say that Nextcloud is on-premise software, it doesn’t necessarily mean that every customer needs to own hosting center in the base.

Some customers, they want to host it like somewhere else. This is usually in our case done by partners. So it might be existing partners of the customer, or they maybe work together with like a service provider somewhere. Or we can recommend a service provider who hosts like Nextcloud for them. This is usually the way that it works.

We as Nextcloud most likely will never become a hosted service provider for several reasons.

First thing is that it might become a distraction for us. So as an organization, you have to focus, if you’re like an on-premise and off-premise organization at the same time, it’s difficult to focus. Then also of course our whole strategy, our whole mission, is to decentralize cloud hosting, and if you become like the main Nextcloud host, then, yeah, it’s just the opposite of what we want.

Also a thing for customers that is not great, because as a customer if you are happy with just like a random hosted version, like Nextcloud, and since it’s hosted by Nextcloud, then I don’t see a lot of value there. Because if they’re happy with that, they can also go to Box, Dropbox, or Google because it’s very similar.

If a service provider, or a partner hosts Nextcloud specifically for them, then this is typically something that has some customization for the use case of the customer, or some integration with some co-existing software they have. Maybe to have like an existing identity management like Gluu or something else, then this partner will integrate with Gluu, or integrate like specific cloud or backup or monitoring or auditing requirement, so they can actually do this together with the customer.

But if you would become like a one-size-fits-all generic Nextcloud host, then this can’t be done, there’s no way for the customer, they can just go to box.com and get something similar.

Is It Okay For Hosting Companies Not To Contribute?

Michael Schwartz: Are you worried about, let’s say, a large cloud provider maybe an Amazon or somebody else, making a ton of money off your software, but maybe not contributing anything back?

Frank Karlitschek: Yeah. I know that discussion at the moment in this area.

Other open source companies and projects who have an issue with that, I mean, what kind of contribution are you talking about, because if it’s like a code contribution, this is something that they have to do because it is HPL license, so if someone would take Nextcloud and do like modifications, or improvements, they actually have to contribute back or at least release patches or the software, so I don’t think that’s a big issue.

Of course, someone could take Nextcloud and host it out of our subscription without our support contracts.

This already happens, a lot of service providers do this already without paying us – I think it’s fine. It’s just helps to spread the message, it helps the Nextcloud get more users. As long as there are enough customers and partners who work directly together with us, I’m happy with it.

Actually we promote it. If you go to nextcloud.com/providers, you’ll see a long list of service providers who offer Nextcloud hosting, and lots of them don’t pay us.

I mean, some of them are actually partners, they work together with us and they contribute back, like code, money, and other things. But from lots of them, we get nothing.

But I think it’s okay, I mean, it’s a free software, it’s okay – you can do what you want.

Challenges For Founders Of Open Source

Michael Schwartz: So what are the biggest challenges facing the founders of new open source companies today?

Frank Karlitschek: Oh, there are so many.

I’m a product guy, so first of all, I think you need a compelling nice product. If you have a nice idea and something like a nice product, then of course, the next challenge is to create a community around it because without a community, you are way too small.

And this is same for a lot of tech startups nowadays. If you have a great idea and you develop a product, it’s really hard for you to compete against the big guys. And an open source community can help with that, because then you are not only like 40 people, like Nextcloud, but you are suddenly 1000 people. And then you can actually compete with the big guys.

The next step for me would be to build an open source community, and you have to figure out your new business model. I think this is something that you have to do.

I mean, if you don’t do open source and don’t have a community, then you can sell software licenses, which might be easier to sell, but as I mentioned before, I don’t think you can be successful with that because then you’re just too small. You have to stand on the shoulders of giants, you have to work together with the community, and you have to figure out an open source business model.

I really enjoyed listening to the interviews of your podcasts, your former interviews of other founders of open source projects and companies. There is so much insight in this area. We decided to adopt the Red Hat and the SUSA business models with enterprise subscriptions, but I’m sure there are many other ways to do this.

I want to encourage everybody to listen to all of episodes of your podcasts, there’s a lot of insight, with all these questions in it.

Michael Schwartz: Thanks a lot, that’s why we’re at it. That’s why we are asking you the hard questions.

Is NextCloud an Underdog?

Michael Schwartz:Do you think Nextcloud is an Underdog?

Frank Karlitschek: Depends, I mean, with all these questions, how you define a market. If you look at the open source, self-hosted, file synching and share, than we are probably most likely the biggest, so we are not an underdog.

But, of course, if we compare ourselves to like Dropbox, Google and iCloud and box.com, then we are tiny. We are a huge, huge underdog, so really small. They probably don’t even know us, we are just too small.

Yeah, it depends on how you look at it. I mean, we had some nice growths in the last few years, but yeah, if we really want to compete against the big guys, then the biggest challenges are in front of us, not behind us.

NextCloud In 10 Years

Michael Schwartz: Where do you see the Nextcloud in the next 10 years?

Frank Karlitschek: I really hope that we can somehow decentralize the internet and the cloud. Again, I’m really, really afraid of a situation where all the files on this planet are like hosts, like cloud companies – I don’t think that’s healthy and a good situation, so I really hope that Nextcloud can contribute to a world where everything is a little bit more decentralized, self-hosted, and on-promise.

I mean, it would be awesome if you could like help with that and become a significant player. If you like present the data of people on the planet or host it on a decentralized federated Nextcloud instances, it would be a great. This is what we want to achieve.

Advice For Startups

Michael Schwartz: Do you have any closing advice for the next generation of open source entrepreneurs?

Frank Karlitschek: In general, I would say that being open in your communication, in your planning, and working together with companies and communities – that is really key.

I talk with other entrepreneurs and open source, and outside of open source base, and sometimes I hear thoughts that they think they have to have a special idea, they have to be secret and they have to be protective about their planning and ideas because they think that what they have is unique, it is a unique vision that no one else has – I don’t really believe in that.

I think if you try to protect your secret, and your organization, and your little room, then you’ll fail. I think you have to be open, and talk about it, and get more people excited, and build a community and a customer base, then this is the only way.

So my advice would be to be as open and transparent as possible, don’t be afraid of competition. Try to beat your competition with openness and transparency, not the other way around.

Michael Schwartz: Frank, thanks so much for your time today.

Frank Karlitschek: Thanks a lot.

Michael Schwartz: Special thanks to the Nextcloud team for hosting the meeting in Stuttgart.

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

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

Production assistance from Natalie Lowe. Operational Support from William Lowe.

If you’re really liking episode, please post a link to it on social media.

Tune in next week to hear the story behind Apache Flink, with Founder Kostas Tzoumas. It’s a big data company that emerged from the Berlin academic scene to become one of the leaders in the industry.

Until next time, thanks for listening.

Episode 9: Rocket.Chat – Open Source Enterprise Team Chat with Gabriel Engel

Gabriel Engel is the Founder and CEO of Rocket.Chat, one of the most popular open source chat platforms on the Internet. Rocket.Chat is used for secure team communication by companies and individuals from a variety of sectors ranging from education and technology, to financial, non-profit, governmental and public services.



Michael Schwartz: Welcome to Open Source Underdogs, the podcast where we find the founders of open source software companies and hold them up for their business model insights.

Today my guest is Gabriel Engel, Founder and CEO of Rocket.Chat.

With almost 500 contributors on GitHub and 50,000 monthly downloads, Rocket.Chat is one of the most enthusiastic open source communities around.

We’ve been using Rocket.Chat at Gluu for a while, and we love it. Who needs Skype or Slack?!

You might hear some clinking in the background – this podcast was recorded at the 2018 All Things Open Conference.
So without further ado, here we go. Gabriel, thanks so much for joining us today.

Gabriel Engel: Thanks for having me.

Origin Story

Michael Schwartz: Can you tell us just to get started a little bit about how Rocket.Chat got founded and what did you do before Rocket.Chat?

Gabriel Engel: Yes, of course. It started actually on a website of another company that I was running before, and it came because of the demands of our customers.

We were designing or developing CRM tools and business management tools for a small and medium enterprise, and they were always asking a way that they could talk to their customers on the website and have those little widgets. And at the same time, the people that would be talking to the customers, wanted to talk among themselves.

So we looked at what was available, and we’d either had software where it was designed for help desk, where you can only talk to your customer, but if you want to talk to a colleague, you have to jump into something else and then talk to your colleague. And all those were really hard to integrate to a CRM tool to gather data in the context of the conversation that the data would be displayed.

Maybe we were a bit naïve, but we decided we could do one ourselves since we didn’t find any. And then we ended up developing it. We published as open source because we really liked what we built, and we thought since this was the first time that we built something real, it’s time that someone could help us improve find all the the mistakes that we’ve done, trying to build such a software.

And when we published it, in 24 hours, there was already 30,000 downloads, and people were thinking it was awesome, giving us amazing feedback, then we decided to pivot and focus on that product.

Michael Schwartz: How did you get into the software business?

Gabriel Engel: In my childhood, my father had a software business, so I grew up going to the office with him and playing around the developers and learning how to develop.

I think the first thing I tried to do was just like a menu so I could run all my games from UI – that was the time before Windows when you had to run all your games from the command line, and I wanted to have UI to select my games or develop a little software so I could have a list of my games.

I guess I grew up developing.

Michael Schwartz: Born coding.

Gabriel Engel: Born coding. And that’s why I didn’t even do coding – in Computer Science university I went to do business management because I kind of naively thought that I knew enough of developing already, and that I wanted to learn the business side of things.


Michael Schwartz: Who are the customers of Rocket.Chat today?

Gabriel Engel: It’s a very broad spectrum, we have companies, like a Deutsche Bahn in Germany, which is like they run all the trains and the public transport in Germany, like 300,000 people.

We have banks in Brazil and US, we have hospitals. There’s always two, three guys that want to run and customize their collaboration platform, and we have a lot – which I find very interesting – a lot of startups which are running Rocket.Chat, not as an internal communication tool, but as an add-on for their own product.

So every time they design a product around a service, and they want their customers to be able to talk to each other, they get a white label version of Rocket.Chat, integrate the user base, and then become the chat part of that solution. We single signed-on all this behind.

Customer Segments

Michael Schwartz: Do you segment the customers’ markets at all, like vertically, or by use of the product?

Gabriel Engel: We are starting to, mainly because we found that actually helps the users to understand, to see their own challenges, so we’re producing a new part of the website, we have different solutions for different types of customers, because now we learn what they are looking for in the software.

Until now, it was a lot of work for us to talk to them and then explain how they could use our tool for that specific use case, so you want to put more of the use cases on the website.

Also we’ve already seen that the older toolkits were so different, even on the setup wizards. We are asking for the size of the company and the industry they’re working on so we can actually customize the setup, based on the usage and the size of the organization.

Michael Schwartz: Do you see any commonality among the types of customers who want to operate their own communication platform?

Gabriel Engel: Well, yes.

Usually, there is some specific industries where we have more value, like financial sector, usually they put a high value on privacy.

Some high-tech industries, like Intel or HTC. HTC is not one of our customers. For Intel, we are running protocols, so I think they put a high value on what engineers are talking, and they don’t want anyone else outside that organization to have access to that conversation, a healthcare – there is a range of organization where privacy is high value.

Balancing Community Versus Enterprise

Michael Schwartz: So, there’s a huge open source community for Rocket.Chat, and Gluu’s also a Rocket.Chat community – how do you balance serving customers and serving the open source community?

Gabriel Engel: The open source community for us is pretty much everything, and the company would not exist without the community.

It was the community that gave us not just the visibility of the project, by using and talking about and helping to share and promote, but also so many of the features were developed by the community.

One of the things that I tried to learn earlier, and I went to visit the guys in MongoDB and Elasticsearch, talking to the VP of product and the commercial guys, “How do you balance between what you charge for and what you keep free in a community edition?” And they were always talking like, “You’re going to see quite clearly things that large enterprises are looking for, what they need, and are willing to pay for it.”

We found out that with few banks and larger organizations where it’s free, that it is not a good price for them because then you don’t have an SLA, you don’t have someone to call when things go wrong.

They wanted to pay, and there was a few features which many large organizations wanted, like being able to do a complete auditing on the message, or all the employees, or track some of the conversations for a regulatory reasons, where you have to have a history of the conversation of the sales people with the clients, and so on. And they wanted those features, the community didn’t even care.

Usually, it’s one smaller community, they are talking to each other, they’d rather not have that feature – so it was clear, “Okay this is a feature that we can charge for. The community is not interested, but organizations are willing to pay for, and they want to have a price value.”

That was the way we balance what are the big guys asking that the small or medium-sized companies are not asking for, so we can put that in the enterprise version and charge for it.

Customer Interaction

Michael Schwartz: How do you interact with customers?

You mentioned that larger customers get an SLA, community maybe has forums, you are a chat company so maybe you offer chat – but can you talk a little bit about the range of customer interactions that you can have based upon the business model?

Gabriel Engel: I guess one thing that is our favorite from the beginning, from being a chat company, is that we gather all our community on our own chat platform.

I like sometimes to talk about – like, it is loop, where people would come to the chat to talk to us, the community was using it to self-organize. And if there was any feature that was missing, or making it harder for us to organize and collaborate, we would fix the tool that was making us get better organized and collaborate better.

So it’s almost like this feedback loop of improving the tool, getting more organized to improve the tool. And that was a key part, first eating our own dog food.

And we’ve seen other projects, where they were using a different platform to communicate with the community than the product itself, which first didn’t make much sense.

We soon realized that chat is great for real-time communication, but still sometimes people would miss the fact of having sometimes a forum, to have some of the conversation in a way that you could be referenced is slightly better, so we ended up creating a forum lately this year.

And we still have some email support that we created mainly for the enterprise, but we decided that we would allow even the community if they needed to send an email, going to the same Q, just different SLA.

When our support people have a spare time, they would get Q from the other communities and would try to answer those. Mainly on the chat we have a support channel, and channels for each of the components, so people can go there and talk to the developers.

And the forum sometimes, it’s just for discussion about a feature, or like a change, they want more people to be able to write more and take more time to gather input and an opinion. And email sometimes, it’s just mainly because of some people if they want to open a ticket, to send an email to our support team.

Revenue Streams

Michael Schwartz: Can you just broadly define what are the revenue streams for Rocket.Chat, like what do you actually sell?

Gabriel Engel: We’ve started with what was the easiest one, which is a SaaS version of Rocket.Chat.

So we have this cloud components, the Rocket.Chat is a service that is a starting point, but we don’t think this is going to be the main revenue generator because this is mainly just a way to get people to try Rocket.Chat, to experience or/and have a minimum revenue for entrance to join the network. So this was the initial one.

The second then is this support model contract with a few features for the larger and medium enterprise, which then, it’s is growing and is becoming quickly our main revenue service.

And the third one that we are launching is the marketplace, where we are going to be publishing our plug-ins and integrations free, but we are going to allow people to publish with a license for charging people, based on a user account or server account, their own public plug-ins, and integrations, and extensions.

In a way, when I think back, I always said we based our revenue model into WordPress, Automattic. So they have a SaaS version, they have a marketplace for plug-ins and extensions, and they have a support brand for large corporations.

So we inspired our business model in WordPress. We like to say we are the WordPress of chats.

Michael Schwartz: Do you think you’ll launch your own commercial plug-ins?

Gabriel Engel: We want to turn some of the features that we developed for enterprise, to be turned into plug-ins, mainly because we think we need to keep a single-code base, we don’t want to have different code bases for enterprise or for community.

What we want to do is, when you buy the enterprise support, you’re going to get the license for a few of the plug-ins that are on the marketplace.

For example, this auditing tool for messages, it’s going to be a plug-in. This way, you reduce the barrier for someone to migrate from the community to start paying you something. You want to have like a very low entry point.

So I just want this little feature for the enterprise, then you can just buy that later feature for a very small amount. And then if you want more features of the enterprise, you can keep installing and installing them. And maybe if you don’t use one of them, you can uninstall that feature, and that would affect your monthly plan.

So in the future, it’s going to be all plug-in, sometimes free, sometimes commercial.

Value Proposition

Michael Schwartz: It’s a competitive market. Everyone knows Slack, there is Mattermost, whom we interviewed last season. What’s the value proposition for Rocket.Chat, while your customers downloading, installing, and adopting Rocket.Chat?

Gabriel Engel: We designed the whole system to be more than just an app for collaboration, we designed it to be a messaging platform that you can integrate into different entry points, and be a hub.

So Rocket.Chat, we can already integrate, even with your Facebook page, with your WhatsApp for business profile, your telegram business account – you can have all these entry points to talk to the customers.

We designed API, the bots, also could be a first to talk to your customers on the platform, talk to your people. And we designed it in a way where you can turn a platform easier to make it a white label, as well as your company, it’s really on Messaging Collaboration Platform, we are deploying the federation protocol, so Rocket.Chat service can talk to each others, or each organization can share channels with other organizations. Each one running their own server, but having a federation protocol to be able to talk to each other.

So we are seen more of an engine for communication than just the app, but it comes out of the box with the features and the UI that you already expect from Slack, but then that’s just the beginning.

You can take that a lot further and connect with everything you want, even email as well, connect and receive email messages inside Rocket.Chat.

Unexpected Applications

Michael Schwartz: Have any of the deployments of Rocket.Chat surprised you, maybe when you’re saying people used the platform for something you hadn’t anticipated?

Gabriel Engel: Yes, there’s a few, like dating websites.

Looking back, it’s quite obvious, but some people created Rocket.Chat for hospitals, where they changed the channel model, where each patient becomes a channel, so the doctors and the nurses inside that channel and even the X-ray machines posting the exam results in that channel.

They just changed the focus.

And then we’re seeing the Rocket.Chat for universities, where each class then becomes the channel. There is some interesting change where people get the platform, but they adapt that specific industry and put their, whatever is the main focus of that, whether it’s patient-centric or student-centric, into the organized flow of information. I think that’s very powerful.

Challenges of Entrepreneurship

Michael Schwartz: So entrepreneurship is more challenging than most entrepreneurs realize that when they got into it. What have been some of the challenges of entrepreneurship for you and starting the company?

Gabriel Engel: So I guess in the beginning, we were very limited on resources, we were just a small company and we were making ends meet.

It was really hard, and then it took until the project got some momentum for investors to come to talk to us, and then come and start offering, that they wanted to invest. That was an amazing experience, being actually chased by investors that wanted to participate.

Then we got into this new phase, where we had enough capital to do our plans and to grow and invest in a project fast, but then there were different challenges, like how you hire the right people when you want to grow that fast, to hire that many people in a short period of time, but you keep the DNA of your company and to keep the people you are working with the same.

We had some interesting experiences, we hired a lot of people and some people would end up not fitting, and then you have the experience of having to let them go. And sometimes they’re good professionals, but they just do not fit the culture in the way you want your company to be.

Then you start learning how to hire, and even moving from a five-person company, where you are the center of everything and it’s easy to know what everybody’s doing, and everybody relies on you for decisions, and then when you go to 40 people – that transition is harder than I was expecting. Because normally everybody was just waiting for my decision, and then delegating, it’s harder.

That’s been one of my learning this year, it’s how to delegate. And delegate is not just tell people to do something, you have to teach them your decision-thinking and matrix so they can feel comfortable that they are not asking you but they know what the goal of the company is, how the company should make the decision, what are the values or what is important – it is harder than it looks and than I expected.

Should I Start That Business

Michael Schwartz: If you are talking to a young entrepreneur, are you going to recommend them to start a company?

Gabriel Engel: Unless they’re following something, a problem that they really love to solve, and they’re not seeing anyone solving it, and it’s something that they feel really, really excited about, then I would recommend them they start a company to do that.

But if they’re starting a business just because they think it’s cool to start a business, I would say don’t do it.

Because you’re going to need more than just the, “Oh, it’s nice to be able to keep with the challenges, you need something that you really love to get you through the hardest moments.”

So, yeah, it really depends on how much you love the problem that you are solving, rather than just thinking that is cool.

Challenges Of Brazil

Michael Schwartz: You are from Brazil – are there any challenges specific to Brazil that you’ve encountered or maybe just starting…?

Gabriel Engel: What is not a challenge in Brazil?

We have a saying in Brazil: “Brazil is not for amateurs.” Because everything can get rather complicated, even to start a business in Brazil.

I remember, in the UK, it took me 20 minutes on a website to open my own company when I was living there. And then I had everything in the mail the next day, and I had the company running.

In Brazil, it can take up to three months just to open the business, and you have to hire an accountant, it’s so much paperwork just to get the business there. To close it – it’s even a worse story.

Sometimes they say, “In Brazil, you open a company but you never close it.” So think twice when you’re opening a business. In Brazil, the labor laws make it a lot harder to get the type of a relationship with your developers that people are used to here in US or other countries.

In Brazil, the timekeeping of the developers, they have to do those clock – how they call it?

Michael Schwartz: Time cards or punch cards.

Gabriel Engel: Yeah, punch cards, which really is not what I expect on a startup, when our developers are stressed and we need to asked them to do punch cards.

I had that experience once, my accountant told me, “oh, you need to do the punch cards, you need to do the punch cards.” Then I asked my developers to do that, and it completely changed the relationship, they started to treat the company as a job rather than something that they were engaged in because they think, “okay, they are controlling me, so I’m just going to do my X hours a day, and leave in the middle of doing it.”

Because you have to do a punch card and leave, so we ended up deciding just to take the risk, saying we’re not the type of a company that will do punch cards. We’ll just ignore that part of the law.

And there’s a few other things about the amount of holidays that you need to get, how you take your holidays – everything is really restricted and not designed for a tech company. So you either ignore or you have a really strange relationship with your developers.

Geographic Distribution

Michael Schwartz: What’s the distribution of Rocket.Chat customers? I imagine it’s very global, but where do you see the concentrations?

Gabriel Engel: There is a concentration relatively in US, 30% of the users are in US, then Europe is another 30%, but it’s spread, like Germany is the top country, then UK, and France.

I think Germany has about 13% of the customers, and Brazil is only 1.8%. In Brazil, most people don’t even know that the company was founded by Brazilians. And there is a lot of like in India and China, spread all over.

But it’s almost evenly spread based on the size of the economy of each country. It’s interesting.


Michael Schwartz: How about partnerships? Do you have any channels who either integrate the product, or how’s it going with developing like partnerships and channel partners?

Gabriel Engel: What we started to do this year is try to get to the larger customers and enterprise, to channel partners, where they hold a relationship with those customers to resell our license and support, so they can do the implementation work, they can do customizations, because we felt that when we were trying to do this ourselves, it was taking too much time of our developers away from the projects.

It’s tempting because it’s kind of an easy money, and because the work is there, they have the budget, they want to pay you, but we found out that at the end that we were getting our developers to do all this work, and the project wasn’t developing enough because we were having to do specific projects for customers.

So we decided, “Let’s train partners around the world to do this.” You have a larger community that is economically healthy, you have more people selling and talking and doing a better job than we could remotely. And you could focus on the projects to help them sell more.

Then we found out that there were more productive arrangements. So now we do have channel partners that resell when we’re looking for more, and that’s how we think about going to expand to resellers and channel partners.


Michael Schwartz: What’s the sales strategy? Do you think that companies mostly find you and reach out to you? How does it work from I guess beginning to end of the sales process?

Gabriel Engel: Yeah. So far we are really reactive.

People were finding us, and then even larger corporations – we’d get a phone call or an email from, for instance, like Intel, the guys would actually say, “Oh, we’ve been trying Rocket.Chat for two months, and we want now to move to the next step and have the Enterprise Edition. We already decided – how can you proceed?”

It makes you think two things, like how open source is amazing, and the company is already trying and it has come to you on a late stage of the selling cycle, but also we found out how many people didn’t find, that were not participating, they didn’t even know that they were in this bid they were looking for.

So we are only this quarter hiring sales teams to start engaging with customers, trying to understand what their needs are and offer a solution to them.

But before we were really reactive, people were trying Rocket.Chat and then would come to us, asking for Enterprise and an SLA.

Now, we are organizing ourselves to start to promote the Enterprise version of SLA, and even looking to some customers that are leaving HipChat because Atlassian has killed the project. So actively trying to go, like, do those companies show that they have a good path to migration from HipChat to the Rocket.Chat.


Michael Schwartz: You mentioned license before an Enterprise versus Community Edition, but you said there was only one edition.

Gabriel Engel: The source code is the same.

The only part is because the marketplace still cannot install all the components that we want, so the Enterprise Edition, we compiled the Community Edition and we just added some those plug-ins that we cannot distribute via the marketplace yet.

It’s a temporary fix to a technical challenge that we’re having on how to distribute Enterprise features to the marketplace when it’s not finished yet.

License Enforcement

Michael Schwartz: So there’s different bits, the base code is the same, but there’s the Enterprise different bits. Are you just controlling access to the bits or is there some type of license enforcement in that, too?

Gabriel Engel: There is a license that we generate that activates that component based on the number of users. It’s still early days, we’re playing with it, how are we going to be doing it, it’s on a git repository.

Nevertheless, that’s part of the plug-ins. But in this initial phase, we designed – because we wanted even other people to be able to put a license and then copy the model.

We were very inspired on how Atlassian did their own marketplace, where there are so many other companies selling plugins for Jira. And Tempo, for instance, is one of the massive plugins used by almost all Jira customers.

We thought, okay, if we were going to bring those guys to develop plugins for Rocket.Chat, we need to give them the same type of functionality, where we can generate their license that they can apply when installing the plug-ins.

We started getting, inspired by Atlassian, trying to copy how they work, and then we’ll see if our community shows and have a different demand that we can adapt to it. From the start, we decided to get inspired by something that is already working well.

Test Marketing

Michael Schwartz: Are there any other types of partnerships that you think have been helpful in developing the business?

Gabriel Engel: Yes, we have sometimes, even for a way to expose the product, we have offered Rocket.Chat as a service for a few communities and organizations to organize themselves, in a way the people in that community can see the tool to the value, and then learn more about our platform.

Some of those organizations are the ones that gave you the most valuable feedbacks because they value what they’re getting for us for free, because we’re not just giving a CloudBerry, and hosting, and deployment, and externalization for free.

So the way they would like to repay us is by giving us quality feedback, and getting engagement from the community to use the platform and give feedback. This have helped a lot in the building of the product and improving of the product to engage in this developing communities and business communities.

Open Source Development

Michael Schwartz: What are your thoughts about how the open source development methodology has helped the product?

Gabriel Engel: Definitely one thing that people talk about is how you need to be close to your customer, and open source makes that part a lot easier to be close to your customer when they are really using something that your developers are your initial main customers, because they’re going to be opening issues, they’re going to be talking a lot on the chat, and even opening pool requests.

So for the beginning, we have so many pool requests opened by the community, and that was even a lot more than we expected, and even from what some other projects expected.

I talk to other leads of open source projects, and sometimes they would ask me like, “Why do you guys get so much collaboration? There are many people actually helping you develop the product.”

And my opinion was like, first, we are really open to pool request, we always try help that the request gets approved. We go an extra mile to really try to have the developer fix the code, to get it into our code base, if it’s a feature that we think it’s nice and that our community will benefit from it.

But also because when people are using the tool so much, and if it’s something that is annoying, they are willing to collaborate and develop that. But it has completely shaped the project.

Some of our largest features were developed by companies using Rocket.Chat.

For instance, the global search that we added that can be powered by Solar, or Elasticsearch, or other full-text search databases, was developed by the community, specifically by Deutsche Bahn because they wanted to use that, and then they called back because for them Rocket.Chat is a tool that they use, rather than a product that they want to sell.

We have many of the largest features developed by the community, and then sent back to us by pool request, so it totally shaped us, made us get close to our customers, and made the customers being able to help shape the product in ways that we didn’t think before.

Current Progress

Michael Schwartz: How do you feel about where you are right now?

Gabriel Engel: Right now, we are transitioning.

In 2017, our focus was very much on growing the project features, growing the user base, and having a healthy community. And then in 2018, we started to focus on monetizing the tool.

Now, we are seeing the results of that, we are growing companies that have Enterprise features and support, we are growing this marketplace – that is one of our dreams from the beginning, to have more people publishing apps there, and we are starting to see people now publishing apps on the marketplace.

It’s an exciting moment where we see the revenue part of the projects starting to work out as we planned. In all, that is a very crucial moment in our organization where you finally have to turn on the money-making part.

And when it works, it’s quite an exciting moment.

Final Advice

Michael Schwartz: Do you have any advice to help entrepreneurs who have decided to take the plunge?

Gabriel Engel: I guess open source was always the community is your most valuable asset. They are the ones that are going to help you to get market fits, show you what features are important, what they’re missing on the product, and giving you feedback.

And if they feel engaged with the product, they will defend you, say good things about you, and feel that they partially own what you are building, so we think that the community is the most valuable asset of a project because they help build the product.

Respect them and listen to them – it’s the main point.

The second is, when you’re going to the revenue part and building a way that you can charge the right people, and understand that sometimes smaller companies or other organizations, they will be contributing to the product not financially, but with time, development and their feedback. And understand what organizations that are going to use your product are not just willing to pay but want to pay, because they want to have a commercial relationship with you, and balance, and then build the features on the paying part for those guys.

Just value your community and charge people who want to pay.

Michael Schwartz: Great. Well, Gabriel, thank you so much for your time, congratulations on Rocket.Chat, and best of luck.

Gabriel Engel: Thank you so much.

Michael Schwartz: Thanks for tuning in to season 2.

We’re starting the international portion of our journey, and we’ll be talking to startups in Germany, the UK, South Africa, and Israel.

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

Special thanks to the Linux Kernel for co-sponsoring this podcast.
Music from Broke For Free by Chris Zabriskie and Lee Rosevere.

Production assistance from Natalie Lowe. Operational support from William Lowe. Thanks to Rocket.Chat for sending Gabriel to the All Things Open conference.

If you want to support this podcast, please leave a review – that really helps us get the word out.

We’ll be pushing episodes more frequently now so make sure you keep checking back.

Until next time – thanks for listening.

Episode 8: SaltStack – Event-Driven Automation with Thomas Hatch

Thomas Hatch is the Co-founder and CTO of SaltStack, an event-driven automation platform that delivers threat-aware security compliance, fast and scalable control of any cloud, and configuration management for heterogeneous application environments and data center infrastructure. In this episode, Thomas describes how SaltStack has built tools and point solutions to monetize a very flexible open source platform for orchestration and configuration.


Michael Schwartz: Welcome to Open Source Underdogs, the podcast where we talk to the people who make open source companies get up and go.

Today my guest is Thomas Hatch, CTO and Co-Founder of SaltStack.

The SaltStack automation platform delivers threat-aware security compliance, fast and scalable control of any cloud and configuration management for heterogeneous application environments and data center infrastructure.

This is one of their first remote interviews, and I forgot to get hellos and goodbyes, so we’re just going to dive right in with the first question. Here we go.


Tom, can you share with our listeners the journey that led you to start SaltStack, and why using the open source development methodology was important to you?

Thomas Hatch: To be honest, when I started writing Salt, my aspirations weren’t quite as high as they are now. I started writing Salt in my basement to pretty much solve a problem.

I’ve written a lot of other pieces of software that were proprietary owned, and owned by companies that I work for, but always as an internal tool, and I was kind of sick of having to rewrite it.

And so I thought, well, I’ll just write it this time and make it open source and clear it with this company that I’m going to make it open source. And after about ten months or so, people were using it. So I started looking at it saying, “I should try and make a business out of this.”

I mean, like you were saying about business models, it started off that journey, that journey of trying to figure out what are the optimal ways to be profitable, with an open source software platform.

Initial Struggles

Michael Schwartz: How do you survive those first two years?

Thomas Hatch: Well, back in 2011, I mean, that’s when I started writing the project to my basement, I still had a job, and at that point, it was me, spending my nights writing Salt, and my employer didn’t mind because they were using Salt internally, but it also made it a great test bed.

That company went out of business not because of their infrastructure, but went out of business at the end of 2011.Yeah, I mean, I still remember, I was in my basement, and I get the “hey, we are out of the business” phone call.

And I went upstairs, and I tell my wife, “hey, do you think I should make a business with this Salt thing, people are starting to use it?”

And she looked at me and said, “don’t you dare do anything but start a business! I don’t want to listen to you moan for the rest of our lives together about how you missed your big chance.”

So, then, we had a fair amount of money in savings and we pretty much burnt through that, through 2012, and we were honestly running pretty low on cash when we got our first seed money in the door, but yeah, I mean, that was basically it, that and a few consulting jobs.

Initial Community

Michael Schwartz: That’s amazing! Congratulations. What was the community like in, let’s say 2013, when you raised that seed funding, like how large was the community at that point?

Thomas Hatch: We had received contributions from maybe 400 people, community had grown pretty quickly through 2012. We had quite a few pretty large users. So some of the flagship users that we still have we’ve gained back then, like LinkedIn for instance.

Open Core

Michael Schwartz: I was watching the 2016 keynote that’s on YouTube, and in that keynote you mentioned you’re not a fan of open core. Have your thoughts changed at all on this topic?

Thomas Hatch: Well, I’d like to say that my thoughts have evolved a lot over the years. In the early days, my thinking was let’s just make a ton of open source software and figure it out.

But at the same time, I did want to avoid an open core issue because when you go with open core, it stifles the innovation that can happen inside of your community.

I really wanted to avoid stifling innovation, but at the same time, we ran into a problem which is pretty typical I think of a lot of open source software companies is that, we’re out there and we’re selling services and support, but once we solve the problem for our customer, they don’t really need us anymore.

I mean, we go back to the early, early years, and that was a lot of what we’re running into. So we decided to start working on an Enterprise product. I specifically architected the Enterprise product so that it was a separate piece of software.

The actual definition of open core is hotly-debated, I definitely argued that we are not open core, but every now and then someone comes out of the woodwork and accuses us of being such.

The way that I look at it is that open core means that you have one piece of software that is augmented with proprietary software directly in that codebase. What I wanted to do is create a separate piece of software that could sit above Salt and value.

One of the things that I find challenging with that was that, right off the bat, developing proprietary software is very different from developing open source software.

And I think that that’s one of the major problems that a lot of open source companies run into.

They say, “okay, we’ve been really successful, making a piece of open source software that people love, and we can make a proprietary one, but the way that software was developed is so dramatically different from open software.”

So we struggled a lot admittedly early on in making that piece of proprietary software. And then we hit another wall that, again, in retrospect, I think it’s a common wall for people to hit from business and monetization perspective, especially with add-on software.

It was that the proprietary software that we had just ended up, mostly at the beginning it just expressed what we already did with open source software.

So we found it was really hard to create differentiation. It was especially difficult to create that differentiation because Salt does a lot of things. I mean, it’s an incredibly powerful platform. So, then, we struggled with that.

A lot of where my head is at today, it’s actually along the lines of what I like to refer to as “peripheral engagement.”

So when we come back and we look at our core users of Salt, their needs are typically your DevOps professionals, SRE professionals, people who are very technical and low-level in being able to use the automation platform.

But then the power that we found from a sales perspective and a monetization perspective is to make sure that our Enterprise products are geared towards the needs, not of that core team as much, but more towards the groups that are slightly peripheral to that core team.

And it helps that core team, and then they are able then to expose the power of what they’ve built with Salt to these other teams.

So, right now, a lot of our success has come through our Enterprise software, exposing the functionality of Salt over to, say a NOC environment, or your IT maintenance teams, which makes just that day-to-day maintenance significantly easier.

And then we’re also in the process now, because we’ve seen some success there, we’re in the process now of creating a new security, a SecOps piece. And we’re really excited that’s going to come out, our Enterprise software first quarter of next year. And we’ve already got a lot of companies lining up to purchase this in their infrastructure.

And, again, it turned into the situation where we’ve got a powerful, open source foundation that is widely used.

That open source foundation needs to cover certain use cases that are broad in nature and are platform in nature.

And open source communities are really good at developing those, but we find over and over again that there are certain areas of software development, where open source communities, to be frank, don’t seem to be quite – I mean, I’m going to get burned for saying this, for saying anything disparaging about the effectiveness of open source communities and software development – but there are certain areas where open source communities seem to have difficulty building software that gets wide, mainstream traction despite the quality of the software that comes out.

And those are areas where open source through the years just hasn’t been able to penetrate.

One of my favorite examples there is the “year-of-the-open-source-desktop.” I mean, I’m running KTE, sure, of course, but Linux desktop hasn’t penetrated the masses whereas the Kernel has.

So you end up being able to kind of step back and say there are things that an open source community express as well, if we can build the targeted solutions, that solve business problems that aren’t going to be solved as easily in a pure open source environment. Then that is a way to market, and the way to augment your position.

Open V. Commercial

Michael Schwartz: How do you decide which software to make commercial?

Thomas Hatch: So early on, it was kind of, well, where does it belong? You’ve got an Enterprise platform, if it belongs in the Enterprise platform, it’s commercial. Otherwise, it goes in the Open.

At this point, it’s shifted a little bit. I mean, that’s still part of that philosophy, but it’s shifted in, proprietary is that which is tied to the solution that is being expressed in the proprietary software.

Actually, that core answer still really holds true. If that functionality belongs on the Salt agent, it’s got to be open source. If that functionality belongs on the master, it’s generally going to be open source. If hat functionality belongs in the Enterprise piece, it’s going to be proprietary.

Resource Allocation

Michael Schwartz: So how do you prioritize, with regard to like resource allocation, everyone’s resource-constrained, you know, you can’t develop everything you’d like to develop, but how do you decide how much to invest in a Commercial versus the open source?

Thomas Hatch: A lot of that has to do with really just hitting our goals. We have that blogmenting who’s working on what quite a bit.

We’ve got a few people who stay Open all the time, and we’ve got a number of people that stay Enterprise all the time, and we’ve got a few people that kind of bleed between teams.

It’s basically, Hey, we’ve got to get X, Y, Z then to meet our protocols of the Open, and we’re a little ahead on the Enterprise side. Then, we’ll shift him over and vice-versa.

It really depends on, frankly, sprint-by-sprint basis on where those needs are. It’s just this constant balancing.

Commercial & Open Source?

Michael Schwartz: Do Commercial features ever move into open source?

Thomas Hatch: Oh, definitely. It’s one of the interesting things too.

As I come back and look at it, occasionally there’s some component libraries that we make for the Enterprise piece that we move into the Open.

One of the things about having a separate codebase like we do, for the Enterprise platform, is that things that belong in that Enterprise platform, again, by their nature are more likely to stay proprietary, but in the places where there is some lead over.

So occasionally we’ll end up writing something that – actually, let me just kind of walk you through a life cycle of this.

So Salt’s pluggable, crazy pluggable, and so we’ll write plugins that are going to be running on the minion that need to be deployed by the Enterprise products. So they can, you know, do its work.

And, oftentimes, those plug-ins are very specific. So we don’t hide the code, but we don’t add them directly into the Open source product because their functionality is directly tied to the use case that’s being expressed in our Enterprise product.

But occasionally, those plug-ins are of such a value that they are generic, in which case, we end up putting them in the Open and the proprietary software at the same time, so that the proprietary software can then send those plug-ins out, really as a back port, to older versions, until our entire customer base migrated to a version where that’s just baked in.

It’s not always this philosophy of, “I’m going to make a piece of proprietary software, and it’s got a timeline until it becomes Open.”

That is something that I think that we’ll probably be adopting as some of our proprietary software matures a little bit, and its install base matures. And we’re able to continually make the right business cases and the right alignment.

But yeah, that’s one of those things we feel that we need to walk into, as opposed to trying to pursue the future too much, too early on.

Is New Model Working?

Michael Schwartz: You mentioned before what I call the open source dilemma, which is, customers only buy support when they need help.

You’ve moved towards a licensed strategy, where certain features are licensed, and certain features are open – how do you feel about commercial adoption so far since moving to that strategy? Has it met your expectations?

Thomas Hatch: It has certainly improved. It has certainly met some of my expectations.

I mean, entering into that strategy, there were still things that I was skeptical about.

A lot of my goal for a long time inside of the company, we need to express a certain amount of functionality from our proprietary software, to be able to just get to the point, where we can start expressing these targeted solutions that I was talking about.

As we built out the targeted solutions more, the sales improved significantly. It’s been really interesting to watch because those solutions that are built out in an Enterprise software, that augment the automation platform that we have in the Open, does start to drive sales, and does start to drive a business model that is much more sustainable as we grow.

As opposed to, I mean, we still run into a number of open source companies that struggle making that sustainability curve, they still need to have a significant amount of their business consumed by professional services.

Customer Segments

Michael Schwartz: Do you segment your customers at all?

Thomas Hatch: Oh, definitely. Usually we segment them along solution verticals.

Instead of looking at them from industry perspective, and there’s certain industry overlap relative to solutions, we look at the very much so as to what are the problems that they’re trying to solve.

And we’ve got customers that are solving IoT problems, that, you know, if our automation said, “customer,” you would probably think, “well, I wouldn’t think that they’d be the kind of customer that would be solving the IoT problem.”

And vice versa. I mean, when we come back, when we look at one of our customers is a major cruise line, and they use Salt to manage devices on cruise ships. So we categorize them as an IoT customer.

Other customers will do things like as this typical network automation or application deployment, all those generally automation platform use cases that you run into.

So, yeah, that’s mostly how we separate them.

Customer Interaction

Michael Schwartz: How do you interact with customers?

Thomas Hatch: We’ve got numerous tiers that we can sell, everything from allowing somebody to get us on the phone within a few minutes, all the way down to, they’re going to open up a ticket, we promise to get back to them in the next, say, 72 hours. All depending on which tier of support they want to buy with their licenses.

You look at what you offer, then you look at what people use, and it doesn’t always line up quite as nicely as you hope when you create set offerings.

Customer Size

Michael Schwartz: Is your business skewed more towards large or small transactions?

Thomas Hatch: Our software, by its nature, it tends to be more applicable to larger, more complex problems, from a platform perspective.

From a solution perspective, it’s a lot easier for us to sell into those smaller and mid-market size companies.

And then, again, I completely agree there, I mean, that is your sustainable revenue.

But, yeah, that has been something that’s been interesting, because earlier on, the vast majority of our revenue came from really large installations.

Or they would come back and say “we just have to have a relationship with you, guys.” We are using Salt to manage hundreds of thousands of systems and, yeah, we just have to have a relationship. Even if they would go months, and not talk to us or reach out to us, we’re reaching out to just say, “hey, is everything okay?”

That still turned out to be a significant chant, again, early on. But, yeah, as we’ve evolved and as we’ve been able to embrace these solution expressions in a cleaner way from our proprietary software, that has attracted more of the smaller and mid-market customers.

How Has Offering Evolved?

Michael Schwartz: That sounds like your offering has changed. What’s working well, or what hasn’t worked well, or what do you think is missing?

Thomas Hatch: Oh, I mean, what I think is missing is, you know, just more software. Always trying to get more products, build them to be more robust, but yeah, I mean, like you expressed, it’s a journey, so a lot of my assumptions about things have changed over the years.

A lot of my assumptions about the role and mechanism of how development happen, that’s changed.

Again, if we look back at the customer base, how that’s changed, we still have a lot of strength and really big customers.

We’re used by quite a few major banks, insurance companies, big tech companies, but yeah, the things have changed for the better, I think, more recently over the last year, so that improved traction in the mid-market.

And our change, I would say is very much so towards our ability to begin to shift from a pure platform support sale to say, “you’ve got a really complicated platform. Our Enterprise piece can help you manage it.” To being able to say “you’ve got a target of pain point, and the entirety of the software that we deliver can help you solve that pain point.”

When we talk in terms of pain points directly, that is more directly applicable to those smaller and mid-market companies, whereas the big platform play makes more sense to the larger ones.

Reducing Revenue Lumpiness

Michael Schwartz: Can you imagine serving the smaller pain points is more scalable, in terms of building the revenue?

Thomas Hatch: Definitely. I mean, as you are probably aware, you get the big guys and it’s up and flow.

You have two months that are fantastic, and then you hold your breath for another month and a half until the next giant deal comes in, but once we’ve got more of those pain point solutions in, they’re significantly easier to support, they are significantly easier to sell, you get a more consistent sales cadence, our revenue still looks a little lumpy, but it’s not lumpy in a bad way, like it was two or three years ago.

It’s lumpy in a way of saying, hey, there’s frosting on the top of this cake.


Michael Schwartz: Have you worked much with channel partners?

Thomas Hatch: Oh, I think channels are very, very useful. They can be tricky.

In the early days, we started with professional services channels. And we did, we struggled a lot to get those going. But more recently, the picture and painting is that our model has evolved a lot for the last few years and it continues to evolve.

And as it’s continued to evolve to be more solution-oriented and less supporting a complex platform-oriented as far as that mixture, then channel partners have started to be much more lucrative for us.

It’s a lot easier for a channel partner to execute a sale that has a more simplified delivery, as opposed to going in and dealing with that whole complex platform sale.


Michael Schwartz: Where do you feel like you’re the most constrained, resource-constrained?

Thomas Hatch: I don’t know, everywhere? That is admittedly a very challenging question. I definitely feel resource-constrained in engineering, both on the Open and Enterprise side.

Probably the place where I feel like I’ve heard the most resource-wise over the years honestly has been marketing.

I think that’s one of the things that we struggled more with, and I think we’re struggling more, going back again to that platform versus solution thing.

As we’ve rolled out our solutions, it’s been a lot easier to market, as opposed to platform play. It’s hard to market – “hey, we can do anything, tell us what your problem is?”


Michael Schwartz: Do you think SaltStack’s an Underdog?

Thomas Hatch: We get pigeonholed by the market in certain places, and so we have a very powerful configuration management platform. So the market likes to put us with Puppet, and Chef, and Ansible.

When our customers come back to us, they say, “yes, we use your config management, but not in the same way that the other guys use it.”

So it’s hard to categorize this as an underdog because I think we’re an underdog in the sense of the market thinks we belong there.

But that’s not where we want to be, as much as – I mean, don’t get me wrong, config is very important and I would still argue that we’ve got the best config platform – but so much of our focus is around automating tasks that are outside of that classical config management use case.

I don’t see us as much of like an application, deployment and management company, which is what you see a lot more from the config management players.

I see it’s more of an infrastructure maintenance and building company, and then, event-driven company, and a security out of remediation company.

And in those areas, I don’t feel as much like we are an underdog. When we go in, from command and control, and an execution position, we don’t really have a lot of competition there.

We’ll get compared to some of the other open source players, and we just say, “yeah, but they don’t do X, Y, and Z.”

So the nature of our offering is so different, and the approach that we’re taking to managing infrastructure has so many differences in it that I generally get pretty frustrated when somebody comes and they say, “well, you know, I use Ansible instead of Salt because of X,Y,Z.”

And I’m like, “I don’t care. Most of my customers are using also Puppet, Chef, or Ansible.” For many of them, they’re using Salt to orchestrate and manage those tools.

It’s frustrating along those lines, because we’re kind of still pigeonholed in that area when we really shouldn’t be.

And one of the things that I am excited about is that some of these products that we’re working right now, I feel like they’re really going to help us break out of that better and expose our functionality better, and the reasons why what we do isn’t just, you know, a copy of Puppet.

Salt In 5 Years?

Michael Schwartz: Where do you see SaltStack in 5 years?

Thomas Hatch: Especially with the newer security offerings that we’re producing an offering now, as well as the expansion of a number of other solutions, our sale’s on a positive trajectory, moving us towards going public.

And, I mean, again, we’re still many years away from that. I’ll avoid making some public statement. Ten years, I sure hope we make it there in ten years.

That’s definitely the track that we’re on from a macro business perspective. Yeah, figuring out what the revenue models look like is something that I feel is increasingly part of our past. And our future is more of executing along those models and growing out the pieces that we’ve learned to work really well.

Going Public?

Michael Schwartz: Do you think that going public would assure the continuance of the open source mission, in a way that another exit strategy would not?

Thomas Hatch: So I should probably temper my earlier statement, I believe very strongly that you should manage a company towards building the company in such a way that it would be viable as a publicly traded company, and that you’re gearing your company towards growth and stability.

I certainly agree that taking a company public is not necessarily always the best option any more. The markets are much more complicated than they used to be.

I also want to, you know, caveat that by saying I believe that managing a company in such a way to go public, and managing it responsibly, is probably one of the best ways to, either be acquired by another company, or private equity, or whatever.

The right tact that I would take would be that I am managing towards the goal of making SaltStack into a company that can be viable in the public market. But I’m not going to close myself off to potential opportunities.

Final Advice

Michael Schwartz: What are the biggest challenges facing the founders of open source software companies?

Thomas Hatch: The open source business model is viable. I certainly don’t want to say anything to disparage that, but being able to build internal culture, and a management mindset, that deals with open source, and profits from open source, and functions in a stable and responsible way with respect to open source, is in and of itself one of the big challenges that you’re going to face.

It’s one thing to make a piece of open source software and get people to use it. It’s another thing to realize that you now have to build another thing on top of that open source.

Two, your sale cycle and your marketing cycle, these are going to be complicated. You’re not selling candy, so you’ve got to work hard to make sure that your sales teams and your marketing teams, and a lot of these people that are more token and dollar-driven are able to see the benefit that they are receiving from the open source.

Otherwise, you’re bringing these people from other areas and they can eat you alive, and end up sending you down bad paths. And that’s another one of those things that I see all the time.

The other thing to warn against is the extreme on the other end. It’s really easy from an open source developer perspective, and I was very much this way, to get caught up in the virtue of Open Source and the idealism of Open Source.

I certainly believe in the idealism of open source, but my views have changed from what I feel was used to be more of a blind trust in open source into more of views that are along the lines of saying that I understand how open source is important and viable inside of a complex economy, instead of just looking at it and saying, “If I build it, they will come.”


Michael Schwartz: Well, that’s it for episode 7. Thanks to Tom for answering all my tough questions.

Transcription and episode audio can be found on opensourceunderdogs.com

Special thanks to the Linux Journal for co-sponsoring this podcast to the All Things Open conference for helping us publicize the launch.

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

Production assistance from Natalie Lowe. Operational Support from William Lowe.

Thanks to the staff of SaltStack for scheduling support.

Next week, we are joined by Matt Mullenweg, Founder and CEO of Automatic, the company behind WordPress which needs no introduction.

Until then, thanks for tuning in.

Episode 7: MongoDB – Cross-Platform Document DB with Eliot Horowitz

Eliot Horowitz is the Co-founder and CTO of MongoDB. MongoDB is the fastest-growing database ecosystem, with over 30 million downloads, thousands of customers, and over 1,000 technology and service partners. In this episode, Eliot describes how Mongo uses a combination of cloud services and licensing to drive growth of their business.


Michael Schwartz: Welcome to Open Source Underdogs, the podcast where we interview founders of amazing open source software companies, and ask questions to help us lay people understand what makes the business tick.

Today I’m in Manhattan, with great views south of Times Square, chatting with Eliot Horowitz, Founder and CTO of MongoDB Inc.

MongoDB is a leading NoSQL database platform and has been downloaded over 40 million times, making it easily one of the most popular new persistence layers for modern web and mobile applications.

Eliot, thank you for joining us today, we’re excited to have you on the show.

Eliot Horowitz: Thanks for having me.


Michael Schwartz: Can you tell us about the origin story of MongoDB?

Eliot Horowitz: So we started building MongoDB about 11 years ago, and the origin story of Mongo really dovetales entirely well with sort of my background and software.

Every time before starting MongoDB that we got stuck on a really hard problem on some project, it almost always came back to database problems. Either the database wasn’t scalable enough, it wasn’t fast enough, the data model didn’t quite work.

And between Dwight Merriman, who is the other Co-Founder and I, in the decade before we started Mongo, we counted that we probably built about 12 custom databases to work around problems – whether there was a DoubleClick or ShopWiki, always working around databases just to get things done.

And so when we started MongoDB, our goal really was to build a database that we wanted.

And originally were thinking about trying to build, we had some other ideas for some projects and applications we wanted to build, and we very quickly realized that we were going to run into database problems.

And as we started designing the database we would want for that application, pretty quickly realized that we were way more interested in actually building the database than the application, and just started you know, alright well let’s build the database.

And so we started building the database about 11 years ago. Shipped the first version about 18 months later. Been on the journey ever since.

When To Start Company?

Michael Schwartz: That’s awesome. Was there an existing community before you started the company? Or, do you have any thoughts about when’s the right the right time, if you have a great open source project, to start to think about monetizing or making it a business?

Eliot Horowitz: So for Mongo, we started at the same time. It was the two of us and we just started writing the software.

And we did as a company, and it wasn’t actually entirely obvious to us on day one whether it should be open source or not. Frankly, because we really hadn’t thought about it very much.

You know, for the first year we were really just focused on building on building a software. And then once we were ready to start trying to see if people were interested in it, was very obvious to us at that point that no one was really going to be that interested in a proprietary database in 2009.

And so the obvious decision at that point was to make it open source, and then we started building a community around it. So, the other way, I don’t have a lot of particular experience the other way, you know, starting taking a project and then trying to commercialize it.

But the way that we did it, I really kind of enjoy, right. You have an idea, you think the idea really should be open source, so you start building a product you make it open source, and you work on building a community, and a group of people who are really excited about it.

And it was great even early on, you know before we were trying to monetize it. You know, we would hire a lot of people from the community, we’d get contributions, we look through them.

The ones who continuously delivered great contributions became some of our first engineers, some of them are still here today.

Why Are People Excited About The Mission?

Michael Schwartz: Why do you think people were excited about the mission of MongoDB?

Eliot Horowitz: So I don’t think our experience with databases was particularly unique. I don’t think there are many developers who are in love with their database.

You know, the number of developers who have said who have to fight with their databases, whether it’s because of the data model or to solve other problems. And so I think a database that really tried to directly address the three main problems really pretty interesting.

The three problems we had, really are very standard. Right, so those problems are the document model, or problems of the data model, right.

So we saw that with the document model. Whereas the document model is just a much more intuitive data model for most data.

People when they’re thinking about data, when they’re thinking about business objects that they’re writing with code, they don’t tend to want to break them down into tables and rows, they tend to want to store them as as they are in their code; as they are in the real world.

And that resonates with a lot of people because that’s how people think. People think in terms of structures. And if you look at every API in the modern world, they’re almost all in a JSON over HTTP, and why is that?

Well, the same reasons right, JSON is a pretty good format for representing data. And then you can take that JSON and store it directly in Mongo – that becomes pretty powerful.

You tie that with a query language that lets you actually index and query those JSON documents, you got something pretty compelling.

Then you take that and you add on distributed systems, so you solve a lot of the problems around high availability, and scalability that people have, and let you solve other really interesting problems like putting data in different places.

And then you take those two really great attributes, make it open source, make it accessible to run anywhere on any kind of platform, whether it’s in the cloud or in a private data center.

You know, it’s a pretty compelling product for most developers.


Michael Schwartz: Who are the customers who said – okay, this is great open source but we actually want to do business with this company, too?

Eliot Horowitz: So there’s a lot of history there as well.

So you start off early on, the people who decided to engage with us commercially, it was largely just around support.

Right, it was larger companies who were really interested in using Mongo, but was a very new technology and they basically were not going to put it into production without a support contract.

That was you know, eight, nine years ago. Things have evolved quite a bit since then.

So now we have a few different kinds of focus areas, I would say, and you can break it down roughly into two major camps.

One is sort of the Enterprises were largely still on premise, who are sort of deploying our Enterprise version which has sort of advanced security features and management features. That sort of one big cohort.

And the other big cohort is the people who are in the cloud, who are using our fully managed service that is MongoDB Atlas, who really want a fully-manned and turnkey database sort of experience in the cloud, so they can come in either with an API of the UI, and manage things really easily.

Deploy clusters, manage clusters, and have all that taken care of by us so they don’t have to worry about database infrastructure and can just build applications.

Customer Interaction

Michael Schwartz: You guys must have tons of customers, and it must be a challenge having relationships with all those customers. How do you interact with the different types of customers?

Eliot Horowitz: We have a large sales team and a large customer success team. But, I mean it’s really, our sales team has grown tremendously in the last five, six years, we’ve got a really great support team.

So that, you know, one of the things we really pride ourselves on is having a great customer support, so whenever anyone calls they can get you help really quickly.

A great customer success team to make sure that customers are happy, that they’re building the things that they need, that were making sure that we’re going in the right direction for them. That if there are any challenges that they’re having that we can address them quickly. I mean those teams are all in all scaling pretty aggressively.

Michael Schwartz: Are there any lower price points where maybe it’s hard to interact directly, where you’re looking to other types of relationships with people, more automated, online ways to sort of scale?i

Eliot Horowitz: In our Atlas product, right, the Atlas product goes anywhere from is a free tier to tiers that are $10 a month or $25 a month, but you know you’re not really having a direct personal relationships with everyone of your users because there’s way too many.

And that’s where we do a lot of automated systems – we’ve got online support forums. We use chat, we use a lot of chat software; usually back by real people, but there’s actually chat software to make that easier.

But a lot of what we’re focused on in the managed service space is how do we make the product really let people help themselves. You know, how do we do better and give you better, help you understand what you should do to help your database go faster.

So for example, index advisors. So we’ve got an index advisor, they’ll tell you – hey we’ve noticed that these queries are running slowly, maybe you should go ahead and add this index. And really trying to let users be incredibly successful without a lot of help.

Community Misunderstanding

Michael Schwartz: Is there any way you wish the community understood MongoDB better?

Eliot Horowitz: There’s a few particularly interesting challenges with Mongo.

One is that the data model is just such a different thing than what a lot of people are used to. And people really need to take the time early on, especially when they’re adopting it quickly, to make sure they really understand the right way to model data with Mongo, and not just to use the relational models they’re used to. That sort of a pretty big one.

The other big one is and I think a lot of early open source projects, or just even companies have this problem where people think you haven’t added a feature in the first 5 years after they’ve asked for it, that you’re never going to do it.

And it’s like no, it’s actually on the list, is actually really important and like maybe you know 7 years after you asked for it it’s going to come.

We had one a couple years ago or so, where someone said – hey this ticket has been open for eight years, so you’re never going to do it, right? And then a year later we did, and they’re like, wow, I really thought you were never going to do this.

It’s like, no, we’re just just taking our time.

And especially in the database space – databases are pretty big, complex pieces of software, and so some of these things just just take time.

Value Prop

Michael Schwartz: The value proposition for MongoDB – is that different from the Enterprise customers to, let’s say the smaller customers? Or how do you think about the value proposition?

Eliot Horowitz: Of the other core database? Or of the commercial offering?

Michael Schwartz: I guess of the commercial offering.

Eliot Horowitz: So the commercial offering is really, very different on the different sides.

So the Enterprise’s who are again largely, on-premises – it really comes down to a few different pieces. So one is support. The second is management.

So we provide, we have a lot of commercial management tools: For monitoring, backing up, automating clusters, for doing rolling deploys, for doing back up’s from production into staging.

All sorts of things around management, we have an integration with Kubernetes, in that space as well.

And we also have a lot of features in the security space. So things like, if you want encryption at rest, or field level auditing, or database level auditing of every single type of operation, those sorts of things are also in the Enterprise edition.

So that’s sort of a one way we differentiate on the Enterprise side. And then on the cloud side – it’s really about the managed service.

It’s really about if you want a fully managed service where you can just have a turn-key thing and say – I want a database. And okay hold on, if something goes wrong we’re going to fix it.
If there’s a hardware problem, we take care of it.

If you want to scale up, you just press two buttons in the UI and you’ve got more capacity. And if you want to move data centers, switch data centers, move cloud providers, add another cloud provider – It all becomes incredibly easy UI changes or API changes, and you don’t have to manage that infrastructure. Security’s managed, all the stuff is fully managed for you, in a really simple solution.

And then that tier, we also have extra security features as well, if you want even more security in a fully hosted environment.


Michael Schwartz: So two different segments really, Enterprise and Cloud, and two different value propositions. There’s a lot of databases out there even, JSON databases, what do you think makes Mongo unique?

Eliot Horowitz: So I think there’s a lot of databases that let you store JSON, which I think is very different than a JSON database.

And to me, really being a database that works well with documents, really comes down to having a really great query language that makes it really easy to work with documents.

And so it’s very easy to store JSON, right. You can easily just go store JSON in a BLOB field in any relational database, and you can do that for the last 20 years. But that’s not that helpful.

What you really want to be able to do is store a document in its natural form, right – so if you have a user, being able to store a user with a list of addresses, where each address is a document, and maybe you have tags on them, you can have like: Type work, or type home, or type of previous, and you have city, state, ZIP on every single one of those.

But then being able to actually index on that efficiently, and then query on that efficiently. So you can index on address.city, or address.city, address.state, right. You can actually like multiple types of multikey indexes. And then be able to sort and query on those things, and then be able to actual analytics on those things.

So you can say – okay I want to find the average age of people live in New York. Which means you have be able to look through the documents, figure out which documents are New York and then compute it, do some summations on those. And then do other sort of interesting things.

And so it really makes, one of the main things that makes Mongo different than everything else in stores, that lets you store JSON, is we’ve got a very powerful query language that lets you do all sorts of queries, with a very powerful indexes, that are very similar to indexes that people would see in a relational database.

So from a semantic standpoint they work almost the same.

But now you’ve got a very rich query language that lets you go inside of a document, aggregate things, analyze things, do real-time analytics on that data.

In addition, we let you do things like update documents in really interesting ways, So you can update as many fields as you want in a big document.

Let’s say you got an array of line items in an order.

You can actually go ahead and say update every line item, and update the price, multiplying it by you know point eight to give a discount, but only when this predicate on this line item is false. So you can say – take this order, find all the line items in that order that haven’t yet shipped, and give them a thank-you that user a 20% discount because the items are late.

Right, you can really use a query language to go in and understand and work with the documents in a way that you really can’t do with any other sort of database that lets you store JSON. And then you go ahead and take that, and put the distributed systems piece on top of it.

Which is the piece that lets you have a really high availability, both inside of a data center or across data centers. It gives you full elasticity so you can go from one shard to a thousand shards so you can store almost as much data as you want, and almost as many transactions per second as you want.

And then that also has other cool features like workload isolation, so you can actually have one Mongo cluster that serves both your transactional workloads and and your analytical workloads at the same cluster, because you can put different workloads on different machines.

And you could also use some of our more advanced features, which are these Global Clusters, so you can have different data that lives in different places.

So you can have some data that lives in the US, and some data lives in Europe, and some data that lives in Australia – all in one logical cluster.

But the physical data stays where you need it to, either to comply with laws where you have to say certain data can’t leave certain areas. Or just for latency reasons, right, so you want users in Australia to be close to their data so they can have a really great user experience.


Michael Schwartz: So on the Enterprise product – just maybe some brief thoughts about licensing.

Eliot Horowitz: So we made the interesting choice way-back-when of choosing the AGPL. Which is definitely not the most common open source license. And the reasons why we did that, you know there’s many of them, and now it’s definitely been a good thing for us.

One of the most obvious ways that open source companies want to, and should try and monetize, is by in a running a managed service. It’s an obviously great way for an open source company to make money.

I think most consumers of this kind of technology would prefer to consume it as a service these days.

So from a user standpoint it works great as well, but having open source is also great because they have some of that freedom if something does go wrong.

The challenge with that of course, is that you got cloud providers who can take that same open source software and make it a competing service. And so one of the great things with us is the AGPL makes that a lot trickier for these cloud providers.

So I think our choice of license definitely has helped us tremendously over last few years.


Michael Schwartz: Quick question about, I guess pricing – what was your feelings about the experience of trying to figure out what’s the right price?

Eliot Horowitz: I definitely say it’s not easy. Early on, I think we definitely probably undercharged significantly. Because we were like, hey this is open source, we’re trying to get people to pay for an open source thing, that’s kind of weird.

And so we were definitely sort of undervaluing the software we were providing, and the value of we were providing. In the cloud was a lot easier because they’re better comparisons.

So for the managed service it has been a lot easier to price that, and we’ve had much fewer issues there trying to figure out what the right price is.

Evolution Of Product

Michael Schwartz: Is what you’re selling today in the Enterprise space roughly like what you were selling when you got started?

Eliot Horowitz: In broad strokes, yes. If you think about it, the very first Enterprise things we were selling was just support.

Then we started adding in some Enterprise security features, then we started adding in management. Then added a lot more management at a lot more Enterprise security features.

More recently we started to expand that portfolio even more – we’ve got some new products in the charting space, in the BI, in the analytics space, that are also in that suite.

So we started building out that product suite a little bit further and put more products inside of that suite. So the biggest change the really probably been in the analytics space, and we’re putting some tools for Enterprises who have business analysts into that suite as well.


Michael Schwartz: Changing tracks a little bit. What are some of your thoughts about like building channels and distribution?

Eliot Horowitz: So early on, all of our go-to-market was really focused around just developer you know, developer advocacy.

We really didn’t know what we were doing for marketing or sales standpoint; we were just you know, a few people. So really, what we were doing is we were going to meetups and talking about why developers should use MongoDB, and going to hackathons, and talking to our friends.

And pretty quickly what happened was the people who were really excited about Mongo started talking themselves at conferences, and things of that nature. It was really just a grassroots developer adoption strategy.

I use the word strategy strongly, that’s all we knew. As we started getting bigger, we started hiring a sales team, doing direct sales, and going through those kinds of motions, and a marketing team that’s doing all sorts of other things. We also started doing our own events.

Because there is so much interest in learning about how to use MongoDB and what other people were doing. We started doing MongoDB events relatively early in our in our company’s history, have always been very successful for us.


Michael Schwartz: Are there any strategic alliances you’ve found that have been really helpful for you to build a company?

Eliot Horowitz: I would say there’s not one particular one. Obviously we have a lot of partnerships you know.

These days we do a lot of partnering with all the different cloud providers: Amazon, Google, and Microsoft, We partners with other technology companies who embed MongoDB in their products, or there’s a lot of synergy between what we do.

We partner with a lot of the consulting companies who are trying to get some of their clients to use more MongoDB to be more effective in what they do. So it’s a little bit of everything.

Definitely hasn’t been one partnership that you know, been way more worth than others.


Michael Schwartz: Do you ever feel like your company’s been constrained by resources?

Eliot Horowitz: I think it would be hard for anyone to say resources are never an issue. But I think we’ve been pretty lucky in our ability to sort of have a fair amount of capital even early on, to grow pretty quickly.

I’d say you know, where we could have grown faster, it largely is around understanding where we fit into the ecosystem and strategy, moving faster.

But frankly we’ve been able to move pretty fast and we’ve had a pretty good flow of resources even from the beginning.


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

Eliot Horowitz: I think the biggest challenge is understanding the right monetization strategy.

Alright – getting people excited to develop it, to use it, I think that’s actually, you know, people like open source, people get open source. You’ve got a great adoption life cycle, I think that makes a lot of sense.

The challenge really is trying to understand what things you want to make free versus what things you want to make paid.

And then around the service side – which I think the cloud service is by far one of the best strategies – is how to do that in a way, and do that in a way that is sort of both easy for your users to use and also has enough sort of, protection so you’re not fighting with the cloud providers on day one.


Michael Schwartz: It seems like having a hosted cloud offering, it’s a great way to monetize, but it’s also challenging because it requires a certain amount of capital and established operating procedures and policies.

If that weren’t an option, what other recommendations would you have about how to how to monetize?

Eliot Horowitz: Well I would definitely try pretty hard to go to the cloud services route.

I think on the capital side – because you can actually leverage cloud providers as well – so you can actually keep your initial capital needs pretty low.

But you do need to like, you know, learn how to operate the software as opposed to just running and writing the software.

Although I would also argue that your experience in running the software yourself, on behalf of your users, is going to make the software way better. You’re going to find all the little pitfalls, when you’re on the hook for issues, there’s going to be less issues, and managing it’s going to be easier anyway.

So I think that’s actually, I’d push people pretty hard to go that route.

If you’re not going that route, definitely the most successful ones are, I don’t know if I love the phrase but the open core model, where you’ve got some core that is open source, and then you have some features that are commercial around it.

But I think the hosted service route seems to be the direction most people want to go in.


Michael Schwartz: Do you think that the software needs to achieve a certain level of stability before you can really build a business around it?

Eliot Horowitz: It certainly has got to achieve a certain, enough stability that people are willing to use it in production.

If people aren’t willing to use in production, I think it’d be pretty hard to build the business around it, right. It’s got to be compelling enough that people want to use it and then good enough that people are willing to put it in important applications in production.


Michael Schwartz: Not just stability, but ease of upgrade?

Eliot Horowitz: We’ve spent an enormous amount of time making sure that it’s relatively easy to upgrade versions of Mongo.

We’ve been around long enough now that there are people who run relatively older versions, but we work very hard to make sure our users stay in the latest version, to make upgrades as seamless as possible – and we spend an enormous amount of time on it. But it pays itself back as it lets us move faster as well.

But we do spend a huge amount of time on that. We’ve got a huge amount of our testing infrastructure dedicated to understanding how the software can get upgrade from one version to the next, and then downgraded if there’s a problem. We try to automate all of that.

It’s such a huge problem if your users aren’t upgrading, or if it’s too hard to upgrade.


Michael Schwartz: We name this podcast Open Source Underdogs. Mongo’s been so successful, but – do you still consider yourself an underdog?

Eliot Horowitz: Sort of analogous to the question of “do you still consider yourself a startup or not”; and I think the answer is in some ways yes, in some ways no.

Obviously we are a public company now, we’ve got a lot of money, we’re over a thousand people. So the company’s pretty big.

On the other hand the people were competing with in the space, you know whether it’s Oracle, or Amazon, or Google, or Microsoft, are definitely considerably bigger than we are.

So are we a underdog?

Yes and no. Like we’re still small compared to them, but was also a pretty well-established company, and have a lot of good things going for us.

10 Years?

Michael Schwartz: Where do you see Mongo in 10 years?

Eliot Horowitz: The database space, the good thing about it is that it’s a pretty long-term space.

So if you look at our roadmap the number of things we want to add over the next 10 years – whether it’s in the core database, or the areas that we’re working around in the database, are enormous.

And the nice thing about what we’re trying to do here, and even if you look at some of the new products like MongoDB Stitch, everything we’re doing is really about making it easier for developers to work with data. Almost an infinite amount of things you can do there.

And the core database, you’ve got a ton of stuff, and then we’re doing things like Stitch, which is all about bringing a lot of those database features to where developers are today.

So for example – making it easier to use databases directly from mobile applications are web applications. Or making it easy to embed charts in a mobile applications, so you’ve got data sitting in a database and you expose a dashboard inside of an application, where someone can only see a subset of the data.

How do you make that easier?

So in ten years? You know, what I hope we’re doing is continuing to make it even easier for developers to make use of data.

At that point I’d love for most developers to be using MongoDB to store a lot of their data, and to be getting a ton of value out of it. Both on a transactional like, hey I’m using this every second for my application, and on the back end to say okay, how do I get insights from this data and do interesting things.

You know, I still think there are people out there who know they have to use a database, but they don’t want to because they’re scared of them and they’re kind of annoying.

And you know, our goal will be every developer just wants to use MongoDB because it makes their lives easier. And lets them focus on building great applications, and makes the data management, takes that out of the way.

Personal Advice

Michael Schwartz: Do you have any advice, on a personal level, for entrepreneurs for starting a company with open source?

Eliot Horowitz: I think the most important thing, whether it’s open source or not open source, frankly – is for you to get incredibly close to your users.

For many years after we started, I spent an enormous amount of time just working with users, whether they’re paying customers are not. On forums, on IRC.

I used to do these things where I’d just hang in the coffee shop and have people who would come and say, hey I’m going to be here for the next two hours, if you’re having trouble, you know, let me help.

And it was great both to help our early users be successful, but it was almost more valuable for me because I really understood what users were trying to do. I understood what their pain points were. Not just the obvious pain points, but the subtle pain points that made it go from a – ok this is an interesting product to now, okay, I actually really like this product.

And so, especially a technical person starting a technical project, there is nothing more valuable than really getting incredibly close to your users.

And I would push most of those people starting those projects to, don’t think about it as the first five or ten users, but you know how can you host the first 50 users, or 500 users, or first 5000 users.

And push yourself there more than other places. Because it’ll pay itself off very quickly.

Michael Schwartz: I know I got a lot of information out of this interview. So Eliot, thank you so much for sharing your your experience and your thoughts on open source. And best of luck with with MongoDB.

Eliot Horowitz: Thanks, you too.

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

Special thanks to the Linux Journal for co-sponsoring this podcast, to The All Things Open Conference for helping us publicize the launch.

Music from Broke for Free, by Chris Zabriskie and Lee Rosevere.

Production assistance from Natalie Lowe. Operational support from William Lowe.

Thanks for the staff of MongoDB – especially to the audio technicians who recorded this episode.

Next week we are joined by Tom Hatch, Founder and CEO of saltstack, one of the leading orchestration automation platforms.

Until then, thanks for listening.