Episode 57 – Tokenizing the FOSS Package Ecosystem, with Max Howell, Founder of Tea.xyz
Tokenizing the FOSS package ecosystem.
Tokenizing the FOSS package ecosystem.
James Watters, SVP, Products at Pivotal Software, is a veteran of the unix and open source software business. With a broad breadth of products, including Java Spring and many other essential tools for developers, Pivotal has built a business of enormous scale in record time.
Michael Schwartz: Hello, and welcome to Open Source Underdogs. I’m your host Mike Schwartz, and this is episode 40 with James Watters, SVP of Products at Pivotal.
Pivotal is probably best known for the success of Spring, the most popular way for developers to write Java applications, but they built a great business around the Pivotal platform, which enables large businesses to manage a unified, multi-cloud software infrastructure.
Pivotal is a little different than your typical open-source startup. Spun out of EMC and VMware in 2012, and IPO in 2018, and shortly before I recorded this episode in August of 2019, VMware announced the definitive agreement to acquire Pivotal, a combination that’s expected to close in 2020.
James makes the case that open source is winning because it’s innovative feature-rich and enterprise-ready. He has a deep understanding of both the technical and business mechanic that make open-source companies tech. I’m sure you’ll enjoy this interview, so without further ado, here we go.
Michael Schwartz: James, thank you so much for joining the podcast today.
James Watters: Great to be here, Mike. Hi.
Michael Schwartz: So, you were trying Pivotal in 2012 when it was formed, and for the listeners who don’t know the backstory, maybe you could just drive a little bit about how that came about, and perhaps about how it’s coming full circle to some extent.
James Watters: I was fortunate enough to join a open-source research and development team at VMware in 2010, working on an open-source project named Cloud Foundry, and we didn’t really know what it would become as a business. It ended up, they decided to spin that out along with another open-source project called Spring Source, or Spring, into its own company, and that was one of the foundational product elements of the company called Pivotal.
Michael Schwartz: What’s your current role with pivotal?
James Watters: I’ve done a lot of product work at Pivotal. I’m currently SVP of Strategy, focused on new parts of our product. I’ve been focused on things like streaming, container-as-a-service, function-as-a-service, all the emerging areas of our product.
Michael Schwartz: Just to give everyone a sense of the scale, could you give a rough estimate about how many product managers are Pivotal, and the total size of the product team?
James Watters: It’s pretty expensive. There’s hundreds and hundreds of engineers that work on the platform at Pivotal, and I would say 50 full-time product people working and supporting them.
Michael Schwartz: When you were at Sun a while back, you were a product manager of Solaris, which is a pretty epic assignment for those of us geeks who revere Solaris. Since then I’m wondering, could you comment about a little bit about how has been an open-source project manager evolved? Like, what’s different now?
James Watters: That’s a great question. The cycle time was so different on Solaris. And that was an 1100-person engineering team. And then, on the kind of customer-facing product front, I think we were under 10 people. It was very much engineering organization, product provided a bit of input and amplification of key customer themes. We worked on often multi-year release cycle.
In the new world of open-source, the community input comes so fast. It’s a different release cadence. Our core platform PCF at Pivotal, we released every quarter. And that was a big mindset change for me versus some of the older world at Sun. It was just how fast everyone expected you to respond. It’s not uncommon now to meet with a client. And in a matter of weeks, we will have a feature changer update shipped to them.
It’s a completely much more iterative world of continuous delivery, both at the platform as well as what we’re trying to inspire our customers to do for their end users. So, I think that’s dramatically changed since.
Michael Schwartz: If you’re not Sun, you are VMware Pivotal, but you are so much smaller. Do you have any suggestions for some of the little things that you can do, or that it open-source company might do around product management?
James Watters: I think that’s really opening a question, and I don’t want to speak conclusively on it, but I think what I’d say is, there’s kind of two ways of coming at it. And my specialty is always being understanding the enterprise organization that the product fits into.
There was a point in our journey, where we felt adding additional features around security would probably be neutral to the developer audience that was using the platform, but what actually bring like the chief security officer and her team deeper into the conversation.
Suddenly, we approached a few banks, and we said, “What if we could rebuild this entire platform infrastructure every day for security?” And we had a really brilliant product person at the time named Justin Smith, who let this initiative to articulate the idea of the much more ephemeral approach to the platform.
I think the reason I mention this is, you could have gone deeper on just developer experience, but by finding that other constituent in an enterprise that come to the negotiating table around why we’re giving money to this company, that really changed the game for us and a few clients, because the chief security officer was now also an advocate.
I think it’s challenging you doing open-source products because you might get a lot of feedback from your immediate community and immediate users. But in order to sell the products to a larger organization, you need to think about articulating investments to a broader set of constituents.
Michael Schwartz: You mentioned PCF for Pivotal, Cloud Foundry. For those who don’t know, maybe you could just tell us a little bit about what that is, or also walk us through some of the other product offerings at Pivotal.
James Watters: I’ve been fortunate enough, Palmer at VMware hired couple of Google engineers in 2009-10, to come build this platform out. It was really like what you might call the Cloud Native platform world today.
At the time, there was no such thing as container-as-a-service, and at the application level, there really was no micro-services, and continuous delivery was sort of a very radical idea of enterprise. It was sort of the first platform built with the container first design, built to enable continuous delivery of things that look more like micro-services than monolithic applications.
And kind of was the first investment in this Cloud Native space, in terms of application platform and culture, all coming together in a platform.
That was really what PCF did, and we were able to scale it from zero sales in 2012. Or the spin that was first contemplated to hundreds of millions of dollars in sales, and ultimately the background of a public company.
Michael Schwartz: Cloud Native is a broad horizontal market. Do you segment the market at all by vertical industry or use case?
James Watters: This is another thing around products. For me, products strategy is that I do think that vertical use cases are critical. I’ll give you two examples. In the banking world, there is a huge focus on Java, because it’s traditionally a Java-centric custom application world.
Banks were always willing to invest in the high-end applications that often was built by Java developers.
When I first started and till this day, banks are, I would say, the number one language in banking is Java. They are very security-centric, they operate in a highly-regulated world, and they tend to be very hybrid cloud. There’s very few banks that run public only.
They were a tremendous fit for the design of PCF, both from support for Spring Boot as well as its core security differentiation.
We absolutely thought of a lot about banking, insurance, regulated industries. Then, manufacturing and industrial was a little bit different space. There you had a lot of the IoT world, you had streaming data, you had a completely learning how to build software for the first time way of engaging, where industrial companies were just getting started on major software investments.
I definitely think about vertical segmentation. I think for anyone who’s contemplating a sort of customer first approach to product thinking, vertical segmentation is a good early model to take on.
Michael Schwartz: Pivotal has 73 projects in GitHub, and I’m sure that there’s more in private repositories – how do you decide which projects to open-source?
James Watters: I think, by and large, we tend to be an open first-style company, as I mentioned on the Andreessen Horowitz podcast awhile back, I am an advocate for sometimes keeping the UI, closed-source can be a simple way of differentiating between the pure-community efforts and the final enterprise products. But in general, we’ve tilted towards open source first.
That’s also been a key part of our relationships, like I mentioned, with certain banks.
A lot of the core security infrastructure of the platform was all kept open source, because the banks felt more comfortable consuming a platform that was opened first, even in those core areas.
Michael Schwartz: When you have a lot of projects, is it difficult to position the value proposition of the company?
James Watters: That’s a great question. If you think about how many projects you want to take on, like say, MongoDB is a fairly focused company. One core thing, Elastic are fairly focused company, but you get into the platform world, companies like HashiCorp are very successful at doing multiple projects. I think Pivotal is probably one of the broader breadth open source company is out there, certainly Red Hat has a pretty broad breadth. You hit a point where you become the platform provider of choice for their next generation of design, and actually the pressure comes to do more and more and more.
One of the biggest pressure points for us was always like, “Okay, we love this as an application platform. Now, provide us the whole universe of data services on the platform.” And so you have to achieve a certain critical mass to have the scale to invest like that.
But I do think that in enterprise segmentation, it’s powerful when you can start to have people accept the offerings you do have. And then, the biggest pressure is, “And now add this, so I can have one coherent approach. And I think that that’s something really important for open-source companies to think about it. Like, “Look at how Amazon operates. They are not a federation of hundreds of little hosting providers all coming together. They really have that sort of single point of interface to all of their abstractions.
I think that’s an interesting dynamic in the world right now. Open source is like, how broad you should go in your portfolio, do enterprise buyers favor that, is it better to be lower and single products – that’s something we discussed.
Michael Schwartz: With a lot of products, containers, Cloud Native services, it seems like it’s harder than ever to figure out how do you price. There’s more things you could gate on and the more elasticity is given, I know us, at my company Gluu, a lot of challenges because of CPU that depends upon the time of day. Can you talk about the evolution of pricing, and did you get it right initially, or did you have to make some tactical adjustments along the way?
James Watters: I think that’s a great question. I think it’s never easy or straightforward, we made a decision that we were going to go after the largest thousand companies in the world predominantly. We were going to supply a lot of technical resources to them, to ensure that they were successful with our product, and very much be an outcomes-focused company.
I think we intended to price at the higher end of the market, and that was a very deliberate choice. And I think as we’re growing now, we’re seeing more opportunity to start to segment the offer. To have a more transactional approach, we reintroduced the container-as-a-service product that didn’t have as many features as the full platform, but was something that people were ready to pay for more on a transactional basis.
I think that there is this tension between the desire to have a broader platform versus to be more transactional, and that very much comes back to customer segmentation. I would think of pricing in terms of how transactional you want to be, and then what the customer really expects out of you to make them successful.
Like, what does customer success really look like – it has to be at the core of your pricing model. If the prices are really low, and they’re not successful, that’s actually not on either of your interest.
Michael Schwartz: Does Pivotal actually have competitors?
James Watters: I don’t think that Pivotal has a company that is assembled just like us. We have some unique assets, one of the reasons we were successful in enterprises is, we have the number one way that enterprises build apps in the Spring Boot.
So, when it comes to like how enterprises are building applications in the Spring Boot, it’s probably easily the number one, and it might be over 50% market share of net new enterprise applications today.
There’s not another company that has that. We also had a very big git, and we were owned by kind of the Dell VMware family of companies ultimately. So, we’ve always been able to go to market with them, but we really still did have to earn our own way. But we could get introductions.
I think all of those
things came together in a way that allowed us to build a higher-end platform to
focus on the top 2000 companies in the world, and to go make them successful, and
to price and package accordingly.
I think one of the challenges right now for smaller open-source companies is, these cloud platforms that are open-source, they keep adding features that are pretty high rate. So, you may think that one day, you have a company, and the next day, that’s a feature of a cloud platform. And I think that’s attention.
Certainly, in the
service mesh world, you see disruption of kind of traditional networking and
API management, coming in the way that people are adopting a service mesh, etc.
Is that a company, is that a platform – I think that’s a very dynamic part of
the market right now. It’s pretty important, and I don’t talk about it too much,
but I really do enjoy working on open-source projects because they can have a
breadth of impact that’s pretty unimaginable to something that you have to
commit a sales transaction and for software before someone can use it.
We have an asset at Pivotal, Spring Starters, and they’re the number one way that people get started with a new job application. And that’s start.spring.io. You start a new job project there.
Every two seconds a developer on average is going there to kick off a new project.
And the top three countries for it are China, United States, and India, but these are the kind of impacts that open-source can have worldwide, deep into developer impact that you can never do with closed-source only, enterprise sale only products.
I think just the unimaginable breadth that open source can get you in ubiquity, that it can get you in the modern world is stunning. So, that’s what I’m humbled to work on. I think the challenge is then like, “Well, how do you make sure that the largest 5,000 organizations in the world are contributing to that?” And that’s where I do have a passion for enterprise monetization of open source, and finding ways of partnering with those organizations, and packaging, and pricing things, such they feel that there’s good value. And partnering with these open-source companies and making them their most meaningful platform.
I think I’ve got there two minds, number one, open source is super important just from a long-term impact the world, it’s harder to work on projects, they can have a bigger one than open source ones.
And then there is the challenge of like, “Well then, how do you build the economic model around that when it’s so ubiquitous to begin with? That’s the kind of challenge that I’m taking on, and I’m humble to be able to work on open source for enterprises for that reason.
Michael Schwartz: Do you think that certain types of software lend themselves to being open source?
James Watters: I would say that the developer workflow today – and that’s not my line but I like it – it starts with “Git clone.” And I think any saying, where a developer is initiating a project in this era, it better be either a really easy to use API, I think Stripe certainly has proven that, or, it better be something like start.spring.io. Or, git clone, something that a developer could just go grab in a permissionless kind of way.
And Adrian Cockroft at Netflix said that, back when he was at previous companies, there were these big architectural debates for months before a project would start. And that in Netflix you really implemented the running code talks. It’s all about running code. I think that that is the reason why open source is really powerful for anything having to do with developers.
And then, on the infrastructure level, open source has become the most profound way that large vendors collaborate. If you look what’s happening in the Kubernetes community, where you have every major public cloud contributing to Kubernetes, IBM acquiring Heptio to make major contributions to Kubernetes, in infrastructure, open source has the way that these, what you might have had standard bodies before, there’s sort of like a running code way that large vendors are collaborating. Both, in the end-user developer space as well as in the infrastructure space, open source had a huge impact.
But if you think those worlds are slightly different, the dynamics of start.spring.io, which is very end-developer focused versus the way that every public cloud is normalizing how they run Kubernetes are slightly different, they’re all open source but they have slightly different behaviors and attributes. And it’s kind of fascinating to see database companies like MongoDB a little bit different than the way that the Kubernetes community is operating.
Michael Schwartz: Do you think that customers actually care about open source? I mean, large enterprise customers?
James Watters: I think large enterprise customers absolutely have seen the tremendous benefits in just frankly the innovation velocity of open-source products. And I think the biggest change is that in the early days, open source was a cheaper version available for free of the enterprise products. That’s what I think it was especially hard to monetize.
If you’re just going to be the cheaper thing and the low-cost provider, and not the premium product, a lot of enterprises might look at that and say, “Hey, we’re an enterprise, we can afford to buy whatever we need. We just really want innovation leverage, like we want the best product.
But I think there’s a new whole category of products, or there’s only an open-source player that is creating it. Like PCF was the kind of first micro-services platform in the world for enterprises. And it was built a 100% open source. It was both the market leader in terms of features and the open play.
I think the open-source market is changed, where there is room to be both innovative, or the expectation is that they’re both innovative, higher-end, feature-rich as well as enterprise-ready – all of that is expected from open source today. I think that’s where the innovation is happening.
If you look – here’s an example – Amazon has a service Kinesis, which is how they were doing messaging, and it did a pipelines. And now they’ve switched that to a managed Kafka service. They had to do that because the innovation was really happening in the Kafka community in open source. Even on Amazon scale, they couldn’t keep up with it.
I really find that to be the best part of the market right now is that you can’t out-innovate the open-source players.
Michael Schwartz: It seems like there’s sort of a cyclicality between centralization and decentralization. For example, a couple years ago, everyone was at full tilt towards “Go to the cloud.”, and now, it’s almost like with Kubernetes and other technologies – is there any shift away towards maybe bringing more of this type of functionality in-house, and does that help a company like Pivotal?
James Watters: When I talked to CIOs about this, I tried to help them deconstruct the current cloud market, and what I told them is, “Public cloud is not one thing. It’s really three different zones of features that you need to think about. The first is the commodity layer, which is, “Hey, I’m just buying virtual machines, networking disc, the basics, and that’s kind of where public cloud started.
There, you can use a platform like Kubernetes, and run those system resources in similar ways, if not identical ways, across public-private, hybrid multi-cloud. So, I think Kubernetes has done a tremendous job of making those system resources normalized across all the clouds.
Then, I think there is this emerging space within the Cloud Native community around the open-source developer focused projects that run on Kubernetes, like Kafka, like Spring Boot, really like Pivotal’s platform. That’s where the developer innovations come. That’s like the open developer innovation community, that’s number two.
And the number three is, they selectively are these managed services like Google Spanner, Google Machine Learning, or you might be ahead of the market, where there might not be an open play there yet, where Spanner requires dedicated fiber networks between data centers to make the database magic work. So, there are areas we are the managed cloud or head.
Our perspective is that innovation in the core, where you are really arming your developers, continues to happen in open source. Commoditization can be achieved through technologies like Kubernetes running in a normalized way across clouds.
And then, technologies, like the Open Service Broker, relay to buy these managed things. Long story short, I think what’s happening is, the CIO’s are getting smarter about deconstructing cloud from this monolithic idea of “I go all in one cloud.” to like, “How do I selectively use what’s best about each cloud?” I think open source is playing a huge part of that.
Michael Schwartz: You touched on this a little bit before, about how open-source software maybe should be cheaper. I think that there is a sort of perception for some reason that even though you get more rights with the license that the software should be less money – do you think that that is changing, or is that something that is an industry we need to work on with customers?
James Watters: I’m a maybe a contrarian here, my dream was always a very open product that generated a lot of value that enterprises were excited to invest in the platform partnership in. And, essentially, I don’t think that open source should have to have cut rates levels of investment into research and development vs. closed source.
My contrarian nature there says, “If you really have the right relationships with these customers, they’re going to be just as happy giving an open-source provider money as they are giving Oracle money.” I mean, if anything, I think that open-source partnerships are valued in a more profound way in the modern enterprise that might be even happier to give you more money than Oracle.
I do think that that something is happening. That also comes back to how these open-source companies engage with these large enterprises, are they focused on them, do they understand their vertical needs, do they put security first, are they able to measure the outcomes that are achieved with their platforms?
Michael Schwartz: Last question. Do you have any advice for entrepreneurs who are starting new ventures based on open-source software?
James Watters: I think my advice would be, if you really develop a community around your open source, you’re one of the luckiest people in the world. That’s a tremendous gift. Save and invest in that community, but also spend some time understanding how that technology fits into the value chain, in the largest thousand companies in the world, and investments they are making in technology.
Try to balance the needs of the developer who’s approaching it from a ‘git clone, let’s get started’ perspective, as well as the more complex matrix or matrices of a large enterprise organization, and what they need across security, operating, certainty SLAs, etc. If you can get those two forces right, then I think you’ve got a remarkable opportunity. But I do think that monetization, and ultimately funding a great R&D team behind your open source project, takes a balance side towards both.
Michael Schwartz: James, thank you so much for taking your time today in this really pivotal moment in Pivotal’s trajectory.
James Watters: One last pivotal word joke.
Michael Schwartz: Thanks, James.
James Watters: Thank you, Mike.
Michael Schwartz: Thanks to the Pivotal team for making this happen.
Transcription and episode audio can be found on opensourceunderdogs.com.
Music from Broke For Free and Chris Zabriskie.
Audio editing by Ines Cetenji. Production assistance by Natalie Lowe. Operational support from William Lowe. Transcription by Marina Andjelkovic.
The Twitter handle is @fosspodcast.
Next week, we have Geoff Schmidt, Co-Founder and CEO of Apollo GraphQL.
Until then, thanks for listening.
Shannon Williams, Co-Founder and VP Sales of Rancher lays out how a great team with deep domain knowledge can actively identify a product market fit in a crowded space, and emerge a winner. It’s an inspiring story of a plan perfectly executed. This is a MUST LISTEN episode of Underdogs!
Michael Schwartz: Hello, and welcome to the Open Source Underdogs podcast. I’m your host Mike Schwartz, and this is episode 39, with Shannon Williams, Co-Founder and VP Sales of Rancher.
Let’s go for a minute into the land of hypothetical. If I can ask all 38 previous podcast guests a question, “Is monetizing support a good idea?”, I think there would have been virtual consensus that support doesn’t scale. Except, Rancher is perfectly executing a business plan to do just that.
I hope you’ll enjoy this episode. Tweet your comments at @fosspodcast, and we will asynchronously discuss in the Twitter sphere, but for now, here we go with the interview. Shannon, thank you so much for joining us today.
Shannon Williams: Thanks for having me, Mike. It’s exciting to be here. Looking forward to our conversation.
Michael Schwartz: Can you just fill us in a little bit about how Rancher got started and what was the mission?
Shannon Williams: We’ve been going now since 2014. In a lot of ways, it feels like we started before that, because my co-founder Sheng Liang, Will Chan and I, the three of us started another company called Cloud.com back in 2008. And, for all intents and purposes, we’ve been working together every day for 11 years now. That company was an early developer of open-source infrastructure-as-a-service software.
We built a product called CloudStack with the founding members of the OpenStack foundation. I had a really fun run there for about three years before being acquired by Citrix, and spending another three years at Citrix.
In our work on CloudStack, we learned a lot about, as you can imagine, managing infrastructure at scale, building out private clouds, helping a lot of large companies build public clouds. At the time, everything we were focused on was how do we deliver virtual machines to developers quickly from anywhere.
But over the course of working on a lot of private clouds, we noticed that we had a lot of conversations with people trying to figure out how to blend their on-premise infrastructure with this growing amount of cloud infrastructure.
One of our early customers was GoDaddy actually. They were looking at building a public cloud, and Darren Shepherd, our fourth co-founder of Rancher, was a Chief Architect there. We got to know Darren really well.
We started talking in 2014 about what could be done to bring together the on-premise infrastructure, the cloud infrastructure, into something that overlaid it all, and to really allow people to treat infrastructure like Cattle, like a disposable commodity. And Docker was just getting started, the concept of Containers was emerging, and we thought there was a really cool opportunity to look at leveraging that, to build out management tooling, infrastructure services, and kind of imagine the next generation of infrastructure management, which would hopefully enable people to do computing anywhere, with really consistent deployment experience, management experience, monitoring experience, all these types of things.
And so, Rancher was born. For almost 5 years now, we’ve been working on continuing that journey, how to build open-source products that are available to anyone, and really allow them to run workloads anywhere. So, that’s really where we came from.
Michael Schwartz: This market, it’s really diverse. There’s a lot of tools and tooling in this area. I’m wondering, what’s the exact value proposition for Rancher service?
Shannon Williams: Rancher is open-source software, we have a number of open-source projects but our most famous is called Rancher, and it really sits at the management playing around Kubernetes. Organizations use Rancher because they are deploying and managing more and more Kubernetes clusters.
Rancher provides distros of Kubernetes. We have one called RKE, which is a pretty typical, upstream distro, it’s really good for deployment, automation. Then, we have one that’s optimized for the Edge or other low-resource utilization called K3s.
We provide distros of Kubernetes to people that need to run Kubernetes, but Rancher itself actually sits above those distros, it’s the management client. What’s cool about it it’s really distro agnostic. It actually manages any Kubernetes. And by managing, what that means is an organization implements Rancher so that they can deploy and control, and then grant access to dozens or hundreds of Kubernetes clusters – some running in the clouds, some running as hosted services like GKE, and EKS, some running on premise, maybe on the Edge.
By bringing all those clusters together, what Rancher allows them to do is, dictate policy, control access, monitor availability, manage deployment of applications, manage catalogs, attach additional open-source services, like Prometheus for monitoring, or Fluentd for logging, or Istio for service match, and so, Rancher sits at that next. So, how do I manage Kubernetes everywhere according to my organization’s policies.
By doing that, it enables them to then really deliver their service reliably. For organizations, they think of Rancher as the Kubernetes platform, it’s Kubernetes as a service, it’s how they deploy apps and run anywhere.
Michael Schwartz: The Rancher GitHub repository has 14,000 forks, which is really a lot. But there’s only around 60 something developers, which I could see is probably primarily being the people in your organization – can you talk about the relationship between the open-source project and the activity there, and the SaaS service?
Shannon Williams: Just to be clear, we don’t offer a SaaS service. Rancher is open-source software only. We only provide open-source software that people use, but what we sell is support for those open-source projects.
On any given day, there’s about 30,000 teams around the world running Rancher. Those teams, they may be a smaller group that’s deploying it for one application. There’s maybe somebody doing a Dev lab, or test lab, but of those about 1%, about 300 enterprise customers, these are companies that deploy Rancher, and whatever they are running on it, it’s critical to their business.
They contract with us to provide enterprise-grade support for Rancher, RKE, K3s, and really their whole Kubernetes stack up and down. By providing that Enterprise-grade support, what they get from us is the confidence to run really important workloads on the open-source Rancher, but what they like is that we don’t have your classic open-core only model, we don’t sell version that’s different to them. They just pay an annual support subscription, and they use it.
A year later, if they are no longer using it, they are not paying an annual support subscription. They can keep using the software, but they would be using it again without support.
Our model is geared around helping organizations that need support, get the best possible support in the world for Rancher, Kubernetes, Prometheus, and Istio, and all the pieces of technology that we deliver to them.
Michael Schwartz: Has open-sourcing the code really made a meaningful contribution to the company?
Shannon Williams: It’s at the root of our success. By open-sourcing the code, we enabled a startup with relatively no name recognition obviously, to come into, in a lot of ways, it’s a very crowded market.
Think about the companies that are dealing with application management platform as-a-service. When we started, you can imagine Docker, Mesosphere, Red Hat, Pivotal, these companies were already out there. You know, Docker, in their sense with having released the Docker project, orchestration and building different types of management tools, and with enormously more funding than us, much, much, much bigger brand recognition teams.
We had to find a route to market with limited funds, we needed to let our product be our best piece of marketing, and so we took that approach. We believed in this for a long time. In our last company, we had a very similar approach. We made Rancher fully open source and free because we felt that it was the best way to get adoption, to plant seeds in organizations that would need this technology.
By putting it out there, we really bet on two things. We bet that people would like it, and that they would want to use it, but we also bet that this technology was crucial. And that at least a good chunk of people who use it would find value in getting support for it and find value in having SLAs that they can rely on for that application. And we’ve been thrilled. I mean, our company’s now almost 200 people, we’re more than doubling this year. In terms of revenue, it’s really worked out really well.
People really do love Rancher. It’s something that makes me really confident with the model as you have to believe in your engineers, you have to believe that products can be great. We also spend an enormous amount of investment of time working with our open-source community. We have a huge Slack community of thousands of users who come in with suggestions and ideas on how to make the product better. We get thousands of issues, and feature requests, and bugs filed by the community.
I don’t think we have more of a user community then of a contributor community. I love it because they come to us with real problems that need to be solved, and I identify them. Often, their use cases sometimes are pushing the boundaries that we may not see out of a Fortune 500 company that’s using Rancher. So, it all sort of pushes forward with the hopefully creating a great product for everyone.
Michael Schwartz: So, just to sort of dive a little deeper on that. If you made the software commercial tomorrow, do you think the 300 or so Enterprise customers, who are using the software, do they really care about it being open source? Or is it just a non-sequitur, or they just want the best software? So, if you made it commercial tomorrow, do you think that that would be bad from where you are today?
Shannon Williams: Yeah, I do. When I talk to organizations about our business model, they get really excited because there isn’t one of them which hasn’t been in a position of really limited leverage against their current vendors. Everybody has been staring at just massive renewal orders.
We closed, just this quarter, today is the end of our third quarter, and we closed three deals with organizations that are spending a lot with us, half a million a year in recurring revenue, for example, to support environments. And their frustration in some cases was platforms that they had built, PaaS platforms, where the cost had grown exponentially. And they just had no ability – even though these were all based on open-source, they weren’t themselves open source. I mean almost everything is based on something, open source at this point.
What people really like is, they like an open-source product, because they always have the option to leave it there, let it run, support it themselves, hire some engineers and figure it out. In the end, if you are running a proprietary tool, and you don’t pay, you have to yank it out of production. And that is impossible for most companies.
I think our business model, yes, some people would still buy a Rancher, and be fine with it, but I think a lot of the smartest CIO’s I talked to are really excited to see a company like us, that embraces open source for commercial purposes, provides really good support, and is committed to building open-source products. For us, it’s allowed us to grow faster than any other approach I’ve been able to come up with.
Michael Schwartz: Seems like Rancher made an epic pivot towards Kubernetes at some point, I guess, fairly recently – what did you learn from that process?
Shannon Williams: Well, the hardest part about getting into any market is making bets, and then figuring out where they come down. Rancher started about the same time as Kubernetes. Right around 2014, Kubernetes was starting at the same time we started our company.
At the time, we really thought Docker and their Swarm and stuff were probably more likely to win out. They had so much momentum. But it only took a year to realize that Kubernetes was actually really well-built piece of code.
So, when we first started working with them, we were kind of thinking we would be managing Swarm clusters and Mesos clusters, and then, even before we launched our 1.0, we decided to support Kubernetes, because it was a really good piece of software.
So, we released our 1.0, our first product to the market in 2016, Rancher 1.0, at the time, if I was talking to them, I would have said something like, “You know, it seems like different companies are choosing different orchestration approaches to containers because they need different things from them.”
Some people want to scale really big, like Twitter. So, they’re using Mesos, other people really focused on the developer experience, and they’re choosing Swarm. And it wasn’t really clear yet that one standard was going to emerge, but what we started to see was some stability issues with some of the other orchestrators that we saw as a manager. It was like, “Ah, these things aren’t stable as I would have expected them to be.” What we found is that Kubernetes is really reliable.
So, as we imagined our business, and trying to support these technologies and helping companies implement them, we felt like it was safe to bet on something reliable, and that did require pivot that moved away from messaging, and product development had gone into supporting, we built our own thing, we had Swarm, we had Mesos, we weren’t really sure what orchestration was going to take off. But as we got more comfortable with Kubernetes, and luckily, we started working on it early, it made it really easy for us to honestly commit to something we liked.
By that point, by 2017, we were all in on Kubernetes building on that. And since then, we already had a lot of people using it in our 1.0 product, we also had a really nice base installed, we didn’t just lose.
So, a lot of times, you have a pivot, and it means almost starting from scratch. But actually, we didn’t really lose hardly anyone because it was very much in line with the direction that most of our customers wanted to go as well. Even if they maybe chose a different orchestrator, they also saw the market going this way, so they were really, really appreciative that we gave them a path to get to Kubernetes off of maybe something else they had chosen when the market was still a lot less clear.
We found that that wasn’t nearly as big a problem. Now, what is hard in pivoting, especially, one of the things we built was our own orchestrator called Cattle, and one of the hardest things was actually convincing our own engineers that the Kubernetes was actually superior to what we had developed ourselves.
That’s a hard thing to do because no matter what, if you built something, you’d always love it. And at the same time, in an early market like we were in, lots of people loved the thing we built, a lot of people telling us, “Hey, we really like this Cattle. It’s really good and you should just keep improving that.”
But as an entrepreneur trying to build a business, you have to be really, really honest with yourself, and you have to really look at all the signals, not just the ones that maybe are giving you the positives you want to see.
All the signals told Sheng, and I, and Will, and Darren, that we needed to really focus our business on solving the problem that we thought most organizations were going to have. And that was, how to take Kubernetes to scale, how to bring together a really complex ecosystem around it, how to build a platform that would work.
That meant really having long conversations with our engineers, convincing them if they weren’t excited about this, that maybe there are other things they could work on in our team and finding the team focused on doing this.
It worked out great, but it was not trivial. We have a small team, I can only imagine when you see big companies today trying to pivot to Kubernetes, you’ve got years and years of customers install base, and how difficult that might be for them.
Michael Schwartz: Great. It takes a lot of leadership. Most sizable organizations are using Containers today, so if you can sell to anyone, it becomes sort of challenging, so who do you sell to? I’m wondering, do you segment the market at all?
Shannon Williams: One of the nice things about open source is, it has allowed us to, give an idea most, I would say the 300 Enterprise customers, like every quarter now we’re closing about 50 new customers. Every quarter we are closing, we look at what the source of those are. I would say 30 of the 50 came from open-source Rancher users.
They started with open source, they used it at a business-unit level, or line-of-business level, and it became important to them, and they needed support. Those deals, they are not very competitive, they’ve already kind of looked at Rancher, they have a relatively short sale cycle, they’ve done the proof-of-concept – we don’t have to go in and prove that Rancher is the right solution for them.
What we found is that we don’t really need to segment that. The product pricing was probably the most important thing to segment. We did find that with such a huge install base, one of the mistakes we couldn’t do is, we couldn’t support everyone for free, for a small amount of money. We needed to kind of keep a relatively medium-sized bar, to ensure that people who needed support had to make an investment to get it.
For example, we could have gone with a lot of SaaS models, $10 a month or something like that, but the reality is, infrastructure and Containers, Kubernetes – these are all really complex. The support is quite real. We provide a lot of advice, a lot of architectural help with these organizations doing it. So, there was a real risk that we would price the product so low, and that we would then be trying to do this for lots of companies with very different levels of technical skills.
I’d say, the closest thing we came to segmenting the market was providing a lot of free open-source support for people who are trying to figure it out themselves, but then, charging a reasonably significant fee to come in and get support. Our customers had to invest tens of thousands of dollars on an annual basis to get support with us.
By doing that, it allowed us to work with companies that really valued this. We’re investing their time and the money into making it successful. That was really the best qualifier. It allowed us to focus on teams that really could help us grow the business at the same time.
We’ve seen some industries become really big with Rancher, but it’s more just a sign of who uses Containers. It’s companies, and certainly the internet, and the technology industry, but there’s a lot of financial services, companies, fintech companies, biotech companies, universities, research organizations, we’re seeing adoption in government and military use cases. It’s really broad now.
Retail, Edge’s driving, all sorts of interesting use cases, oil and gas, all sorts of interesting use cases in manufacturing, automotive – just lots of cool things that people start to imagine, a model where Kubernetes becomes this grand unifying theory for computer, where it runs everywhere. It runs in their single node, base station, it runs out in the windmill farms, it runs in Chick-fil-A shops, it runs in factories, it runs on cruise ships, it runs in data centers, it runs in the cloud. It’s a really exciting time to be working on tech, I would definitely say that.
Michael Schwartz: Normally, it’s really hard to get pricing right. Did you have to pivot your pricing model a couple of times? Or how was your experience like, figuring out what are the right price points?
Shannon Williams: Oh, man, that is a good one. We learned a lot from our last company. I made every mistake you can make last time. This time, we definitely had to pivot a little bit to be quite sure what the right element was to scale on with the number of clusters, or containers, or nodes, or CPUs, or things like that, but we decided pretty early on that the size of the implementation was probably a good way to judge how the cost should change from a small deployment to a large deployment, the number of hosts and servers, things like that.
Actually, I would say we learned a lot, we’re fortunate, that were a lot of indicators from the market, as people talked to us I would say. Your first 10 – 20 customers give you a lot of feedback on pricing, whether you want it or not.
Usually, I think most people price to low, just by nature. We all want to just make it both amazing and cheap prices. Like, who wouldn’t love this thing? It’s the best and it’s the cheapest. But you have to be realistic about what it takes to fund a business, what it’s going to take to build a profit, and what you can do with those engineers you can hire, and then you have to convince people of the value. It can be tough.
I remember I walked away from a lot of deals in open source. I just said, “I’m sorry. I totally appreciate that you’re telling me you could use the software for free, so you couldn’t possibly pay me more than $10,000 or $20,000. But if I did that, I wouldn’t be able to build a business, I wouldn’t be able to write open-source software, and I wouldn’t be able to give you the level of support you demand from your other enterprise software vendors. So, I’m sorry, we can’t do business with you.”
And sometimes they come back, sometimes they don’t, but being willing to walk away from deals – for our business model, it is absolutely critical to have to be able to do it. Otherwise, again, the car I’m selling you is available for free. You can take the same car with the exact same features, you’re not paying for a special version, it doesn’t have a better horn or better tires –it’s the exact same car. What I’m offering you is the confidence of working with me on it, and the world’s best support for that technology. If you don’t value those things, then, we can’t come to any business relationship between us.
Michael Schwartz: Have you used partners to help you deliver to customers, especially globally? Or are there any other business partners that have been important for you to build a business?
Shannon Williams: Yes, yes, yes, yes. Over and over again – yes. The critical partners for us have been really two big buckets. We have found that the other companies who are building critical technology for teams adopting containers. It’s a company that’s called Portworx that builds a really nice storage, and a company Aqua that builds great security, Sysdig who creates monitoring, Gitlab who does really cool tools for CI and Git deployment – all really commonly chosen by our customers.
But partnering with those companies, companies that fit into the same solution stack, we have been able to do two things: we’ve been able to build a much more credible solution for our Enterprise customers. And we’ve been able to align messaging and go-to-market together, and take maybe a couple of other organizations who are our size, venture-funded startups, and take our stories, and show them to larger organizations together.
And we would’ve done this through, we’d run online meetups, where our partners come and present to our users about their technology, and how they work with Rancher, and how they work with Kubernetes. That gives us a lot more credibility, and helps those company succeed, which helps the market grow because the market is vibrant. So, we invest a lot in partnering. We’ve also partnered really closely with the cloud providers.
We work really closely with Amazon, Google, and Microsoft in the U.S., and large providers around the world, to ensure that their implementation of Kubernetes works really well with Rancher. And that’s been fundamentally critical, especially because what we see is we see a market where, if you are in the cloud, you are probably going to use the cloud providers Kubernetes.
So, we want to make sure that we’re not trying to convince you to use Rancher’s Kubernetes on Google, take Google’s Kubernetes engine, which is great. Let us provide you with the common frameworks, whether using Google’s in Google, and Amazon’s in Amazon, on premise and Edge, or different types, everything is consistent, everything is managed the same way, everything is deployed, monitored, upgraded consistently. And you have a platform that really is this UberCloud we set out to build in the beginning anyways.
Michael Schwartz: If a customer says that services aren’t enough, they want on-site engineers, they want sort of higher-level design consulting – do you do that as expert services, or do you work with delivery partners to do that?
Shannon Williams: We tend to work with delivery partners. We work really closely with both big and small delivery partners who had built expertise. In Rancher, we have a platinum partner program, which is made up of some amazing companies that have implemented Rancher for others multiple times, and really have deeper understanding often not just of our ecosystem.
So, companies like RoundTower, CloudOps, Readapt, Accenture. We work with quite a lot of the large multinational services companies. We work with different regions around the world. These companies, BoxBoat and other really good ones, these guys, they’re really staffed to provide ongoing services for organizations in a way that we’re not.
Like, we are great at coming in and giving you a ton of information about Rancher and helping your architect your Rancher deployment, but a lot of times, technology is only a chunk of the solution. The solution needs to include some transformation of how you do things, how you do DevOps, how to train all your developers around microservices, how they start thinking of some of these new service matches, and how they might get into solving business problems for your company.
We can point you in the right direction and help you with those things, but we’re very laser-focused on the Kubernetes platform. And these companies are much better than we are at providing the transformational experience around there. So, yeah, we very much partner, especially in those longer-term things.
What we have found as really critical is the actual investment of our own on customer success. I would say, one of the things that’s got a lot better as we’ve grown is, we’ve invested more and more in — I think it was like the first 90 days when an organization becomes a Rancher customer.
I think this is really important for open-source companies because if you are a SaaS provider and somebody’s using your product, you have a pretty good idea what they’re doing with it. But as an open-source software companies, especially ones that support that open-source software, organizations can have very different processes, they may have more or less mature implementations, they may or may not have built-in an HA deployment. And they’re coming to you to provide support. You really need to make sure they understand best practices, that you reviewed their deployments, you helped them understand how we recommend doing things.
We invest a lot more now in customer success than we did in the early days. When a customer comes on board, we really spend a lot of time going through their architecture, helping them make improvements that they will achieve their goals, whether it’s stability, multi-cloud implementations, or they might try to do something, there’s a lot of scale. And then, there might be something we’ve learned already that can help them. I would say customer success has been a big learning for us.
Michael Schwartz: Has that investment in customer success also translated into increased revenues per customer year-over-year, so they’re buying more, or other products, or other divisions?
Shannon Williams: Well, it’s still new enough that I wouldn’t say if I know how correlated those two things are, but we certainly believe they are. We are investing in it because our bet is helping a customer be successful, with even a departmental implementation or a single app deployment is going to pay dividends for both retention of that customer and that workload.
So, a year later, when they decide they want to renew that support they bought last year, they have a really good feeling that, “Yeah, that was a great investment. Partnering with these guys has been useful.”
But certainly that also works internally. As they use it, they seem to spread the word. I mean, we have seen over and over and over again the power of the success of a Rancher deployment spreading within a company.
Users love Rancher. It’s a user-oriented product. What’s so cool about a product that has 30,000 open-source users is, it says something about how usable it is. It’s like terraform, you use it, it’s pretty straightforward, you like it and you go, “Cool. This is easy. I can get this.” You tell your friend, “You should use terraform. It would help you do something.” It’s kind of same with Rancher.
If all those users are using it, they are clearly getting some value from it. When somebody in your company says, “Hey, use this.”, and you’ll probably benefit from it. And there’s no barrier. I don’t have to start by going and getting a license to try it. I can just use it. It tends to spread the same way. It’s just the word of mouth and the power of it kind of spreads.
So, we found that making them successful and making sure those early champions are well-armed to explain why they chose Rancher, and they got a really good implementation, they don’t get bitten by a bad config, or maybe not knowing the best practices, it helps us in the long run for sure.
Michael Schwartz: I’m sure you’ve been hearing about open-source strip-mining from large cloud vendors, but what I’m wondering is, do you think it would be good or bad if some mega cloud company offered a Rancher-based service?
Shannon Williams: I think it would be great personally. From our perspective, the value of these mega cloud providers is always tied into a big ecosystem that they’re trying to build around. What we find is that organizations want to live in those ecosystems, and leverage those ecosystems, but they know they’re not going to live in just one of them. So, they want lots of them. And the more that those ecosystems interact or work together, or do things that help them work together, the better off they are.
In so many ways, I think the strip-mining analogy is that it’s a rough analogy because, well, it’s true that some of these providers don’t put a lot back, and there’s definitely been some ugly competition between open source and commercial. For the most part, I think their relationship has actually been pretty beneficial, mutually beneficial between the cloud providers and the open-source software developers.
It’s often where it’s really struggling, where you‘ve seen it’s struggling is when organizations haven’t had a great business plan our route to market, or they haven’t been able to commercialize their own products. And then, all of a sudden, it gets embedded into something larger. And then, the only monetization of it happens in the cloud.
I think that’s where we see most of the problems. I think that’s going to continue. I think that that was happening before as well. You know, ideas are developed, but are never really taken to market fully or are not pushed into the market aggressively. Organizations build upon those something new, or something tangential, or something that accelerates them. And that is what ends up being the big success.
To me, that’s business. That’s something that’s going to happen in any space, whether it is open source or not. And, yes, in our world, people can take and build on it very easily, but that’s what you know you’re getting into when you’re starting an open-source software business. And if you don’t, you really should research a little bit more.
This is a knife that cuts in many ways, from a business perspective. And I certainly would look at the world, and I certainly wouldn’t call foul if that happened to an open-source project. I’ll give you a feel, in China, Rancher is incredibly popular.
From early days, my co-founder Chan grew up in China, and so, you have someone who can speak Chinese and talks about it in China – Rancher became really famous. We’ve had multiple times where startups have kind of emerged competing with us in the market, selling Rancher and providing support around it.
Our experience has been that that, as long as we continue to push forward the innovation and organizations really value what we do, they’re going to want to work with us. They are going to benefit from working with us.
As long as we keep pushing it forward and building the product better, that will continue to be the case. But you have to know what you’re getting into. I don’t feel like there should be a huge shock if you build an open-source product, and someone forks it, and does something cool with it, that’s kind of the idea.
Michael Schwartz: Moving to slightly higher level, do you have any thoughts about when entrepreneurs should use the open-source development methodology to develop a commercial product?
Shannon Williams: For me, I think it’s about the product you’re trying to build, and what you think your route to market needs to be. If you’re entering a market that you think is pretty competitive, and has a lot of different products, and you know you’re going up against much more well-funded organizations than you, then, I think open source is a really, really important one to consider and to look at. Because it allows you to get adoption in what would otherwise be a really hard market.
If your only feedback is going to come from a handful of companies you can convince to POC you or pay for it early on, you are going to have a hard time building momentum. And you’re going to have a hard time having good conversations with users who either like or don’t like what you’re building.
To me, I don’t know, I’ve been building nothing but open source for 11 years, so it kind of feels to me like everyone should just build open source. I don’t find that it’s ever slowed down our monetization. It’s always been a benefit. But I certainly would say that if you’re building something that you think is transformational, that actually has a broad audience that will adopt it, open source should very much be what you’re considering.
If you’re building something that’s probably a service, and it’s going to be hosted, I think open source can be enabling capability, but I wouldn’t worry too much about the open-source side, I would just focus on building the SaaS platform product tool that you are building a cloud service.
Because I think in those cases, open source is less important than it is an on-premise software or fundamental software. You’ve seen with Docker, open-sourcing, and having an open source success is not by any means enough to guarantee a commercial business success, but it puts you in a position where you have a great chance to engage with users, listen to what they think is necessary. Next steps, what they’re excited about your platform for, your product for, and what they’re willing to pay for, and build on that.
Michael Schwartz: Last question, any advice for new entrepreneurs starting a business around an open-source platform?
Shannon Williams: Of the four of us who started Rancher and started Cloud.com and everything, I’m the non-engineer. My role in the early time of building a company, I was considering my role then to be how to connect with users, like how to connect to people even before you have a product.
When we were in our first 6 months, our first year, I spent all day, every day, thinking about who are potential users could be, based on the direction we think we were heading, and reaching out to people, introducing myself and introducing the idea we’re building, and getting feedback.
You always have to be thinking about the next milestone of users, “My gosh, how do we possibly get to 10 companies using our product?”
And the only way I can ever found that works to get to 10 is to find them by hand. To think, “You know, I think this makes sense for somebody in that space.” I really believe that if you as a founder can’t explain your value proposition enough to get someone to sit down on the phone and talk to you about it, and maybe watch a demo.
Especially when you can tell them, “Hi, I’m Shannon. I’m one of the founders of this new startup called Rancher. We’re trying to solve this problem, and I thought it might apply to you guys. I really love your feedback. We are not trying to sell you anything, we just want your feedback on what we’re doing.”
If someone doesn’t want to talk to you with that pitch, you might be barking up the wrong tree with your idea. That initial response, if you can’t just explain what you’re trying to build to someone right away, and if you can’t get a meeting, it’s probably worth reflecting on what you’re doing, and maybe tweaking, and then trying some different approaches, trying some different messages.
Because if you can’t get a meeting, it’s going to be really hard to get a sell. It’s going to be really hard to get a user, it’s going to be really hard to convert them into a paying customer.
But if you explain to someone, most people love to talk to entrepreneurs starting companies, especially if they can really clearly communicate what it is they’re trying to solve. And that validation early on goes enormously towards then calling that person back in three months, and saying, “Hey, we got a first beta ready, would you like to take a look at it?” And getting those first 10 is hand-to-hand combat.
Really the first hundred is hand-to-hand connecting to people, showing them the product, showing them the value, and getting to use it. Every once in a while, you have these runaway crazy successes, where everyone’s like, “Oh, my gosh, I can’t believe – how did we live before this existed?” But most of the time, it doesn’t work like that. Most of the time, you have to connect, talk, demo, listen to the feedback, and go back and consider how far on or off your strategy you are.
Michael Schwartz: I said it was my last question, but now you just raised another question, and I can’t resist. Previously you mentioned that a lot of the leads for customers were from inbound, from customers who use the software, liked it, and then called you to purchase a support subscription. But 50 deals a quarter – that’s a lot of business. That’s really pretty stellar. And I’m wondering, what’s the right mix of inbound and outbound marketing sales to push for, or how do you balance that?
Shannon Williams: First step for all of this is find a real market. When you find a real market, things get a lot easier. Because you have to have something going on that’s causing people to look for a solution, they have to have a problem.
So, to your question, if I had my druthers, I’d have a 100% coming inbound, so everything coming inbound means that the market is actively looking for solutions. My brand is well enough known, we are the company they should at least talk to about this to get a demo. Ideally, it’s open-source, just download it, and install it, and try it, and see what you think.
I, from day one, believed in inbound as our goal. So, that meant, instead of spending a lot of our early dollars on advertising, for example, I spent almost everything we did, online communication to users. And that meant, oh, my goodness, we wrote dozens and dozens of pieces of content explaining how to use Containers, and Kubernetes, and Docker, to help people find us.
They may not be looking for Rancher, but they were looking to solve a problem. And so, we really tried to build a list of the lots of the problems they were trying to solve.
We hosted an online meet-up every month that grew to have thousands and thousands of people register every month. It was crazy. We just run them today – I just did one last week.
And what we said was, “Hey, come, it’ll be our smartest technical people. We will stay as long as you need. We’ll demo whatever it is we say we’re going to do. I won’t just show you a bunch of slides, we’re actually getting this code, we will teach you how to do it. And we will stay until every Kubernetes questions are answered.”
So, these things would run two hours, three hours, but they allowed people to cross hurdles, to learn how to build the CI/CD Stack on Kubernetes, or how to do monitoring on it, or how to deal with logging, or how to use containers and the cloud – whatever it was we were trying to solve that month, we really focused on it. It was really that. It was education, community, content that, coupled with early references that we built by hand, in that hand-to-hand phase, got the word out.
By continuing to invest in that, we were able to kind of sow so many seeds of open-source users that as they matured, and liked what they usd, they contacted us. The right mix for me is a 100% inbound from the open-source community. But what we did find was, as we grew, we started to run into bigger organizations. They have entrenched vendors.
All of a sudden, we might have won a line of business users, and then they just said, “Hey, we love this Rancher. We are going to use it for application A, B, and C.” But 80% of the company was using something else that they’ve maybe built themselves, or maybe they bought something, some other product a couple years ago to do PaaS, or something.
And so, because those organizations started to look and say, “Why aren’t you using this? Why are you using Rancher?”, we had to support them and show other people in the organization, “Well, actually, this isn’t the same. It’s different, and here’s why it’s different.” What we did find was there was longer Enterprise sales cycles, so we needed good high-quality sales people to work with bigger companies.
But the positive was, we found that those companies actually really appreciated that it was open source. And the fact that you already had one over, a group of people who really loved it internally, meant that you kind of solved, in a lot of cases, the biggest problems these IT teams were facing, which was, they were building stuff and no one was using it anyway because they were just going to the cloud, they were building something themselves.
So, when we could tie together, the IT organization, which is like doing everything they can to support forward-looking development while still being secure and still being cost-conscious. And teams that have usage and feel like they’ve got found something cool, it was just like made it for a much easier sales motion than your traditional either selling top-down or kind of getting some executive buy-in, and then hoping people use your product once it was brought in.
I don’t know, does that answer to your question, Mike? I kind of feel like I ramp up there.
Michael Schwartz: Yeah, that’s lots of great info. Shannon, thank you so much for joining us today, and being so honest with your answers.
Shannon Williams: Mike, it was my pleasure. Thanks for doing this. I love your idea of open source entrepreneurs just sharing and talking about what we do. I think it’s a phenomenal business model. It is a real transformation of the relationship between the developer of a really powerful software and the consumer of that software. So, it’s something I have enormous passion for.
Michael Schwartz: Best of luck with Rancher, and congratulations on all the success.
Shannon Williams: Thank you so much, Mike. You too. Have a great one.
Michael Schwartz: Thanks to the Rancher team for making this happen. Transcription and episode audio can be found on opensourceunderdogs.com. Music from Broke For Free and Chris Zabriskie. Audio editing by Ines Cetenji. Production assistance by Natalie Lowe. Operational support from William Lowe. Transcription by Marina Andjelkovic.
The Twitter handle is @fosspodcast. Rate us on iTunes if you like this episode.
Next week, we have James Waters, SVP of Product at Pivotal. Until then, thanks for listening.
Michael Schwartz: Welcome back to Open Source Underdogs. I’m your host, Mike Schwartz, and this is episode 38, the last in-person interview recorded at the Open Core Summit. Our guest is Isaac Schlueter, CEO of npm Inc.
If you want to learn more about npm, Isaac was a guest on Founders Talk Episode 61. And for an interesting perspective on the npm ecosystem, you might want to listen to Changelog Episode 355 – it’s an interview with C.J. Silverio, as a former CTO of npm Inc. She provides an interesting perspective on the economics and the technical challenges of running the world’s largest package registry.
I hope you enjoy this episode. And if you like it or you’d like to start a discussion, tweet at us. Our Twitter handle is @fosspodcast.
So, without further delay, onward with the interview. Isaac, thank you so much for joining us today.
Isaac Schlueter: Hey, happy to be here.
Michael Schwartz: Some business people listening to this podcast might not know what npm is or what it does – can you give a really quick explanation?
If you’re depending on a platform, or a module, or a library, or something, you can automatically pull in all of those updates and keep your app up-to-date.
Isaac Schlueter: There is a couple of reasons for this. The first one is, if we go back to the kind of the history of npm, when I decided to start a company around it, it was my side project for about four years.
And it grew in popularity. It was running on donated infrastructure from this company, Iris Couch. We just grew to a point where the scale was too massive for them to be able to afford to keep doing that.
I looked at my options, and starting the foundation was definitely on the list of things that I could do. Another option was, find a home for it in some big company, try to get hired by Google or Microsoft, or somebody.
The reason why I decided to start an independent company was simply owing to the scale and the rate of growth that we were seeing. So, the typical way that a foundation operates, you raise a bunch of money from a bunch of companies who have some vested interest in whatever the thing is, whether that’s an open-source project or some other thing. And then, you spend that money on keeping the thing going, so that might be, having developers work on the project, your managing governance, or marketing, whatever.
Within npm, we had this exponential growth curve that we are still at the very beginning of, in terms of the number of users on the npm platform. We’d grown to about a million users. Our rate of downloads and package growth was just astronomical.
So, we kind of did some back-of-the-envelope math and realized like, “Okay, well, we could go, raise a couple million bucks to start a foundation and be able to put some resources behind this thing. But what are we going to do next year? We’re going to need 10X as much. And then, the year after that, and the year after that.
The task of just kind of continually being in fundraising mode was pretty daunting. Especially because it’d be hard to justify that the benefits to each of those member companies would also keep increasing enough to justify them, increasing their investment.
On the other hand, if you have an exponential growth curve of almost anything, even rising costs, you can take that to an investor and say, “Here’s the thing: it’s a thing that’s growing, it is a thing that’s exciting.” You can tell a story about how you’re going to go about monetizing that in the future, and that’s something that is sort of a good fit for a venture-back startup.
Michael Schwartz: Most people use npm for free – what do you actually sell?
Isaac Schlueter: We sell two main things right now. The first is npm Orgs product, which is a multi-tenant SaaS thing that you can use to store your private code within your organization. That’s used primarily by smaller companies or front-end development teams within larger companies.
The price point there is $7 per user per month. It grows depending on the size of the Org, you can have multiple packages all underneath that same Org.
The other thing that we sell is our product called npm Enterprise, which is a single-tenant instance of the npm Registry and website. It has some additional features, like single sign-on, or security policy enforcement, that kind of thing, which is more of a need at bigger companies.
Michael Schwartz: What kinds of companies use the Enterprise products – do you segment the market at all?
Isaac Schlueter: The sweet spot for us is about development team of 50 or more. We do some market segmentation to go after different sectors. There are some sectors that we focus on, but obviously, we will sell it to anybody who wants it. There’s a fair amount of inbound that comes in as well.
We’re seeing the most traction in sectors that have really high compliance, policy and security compliance needs, so financial industry is a really big one. And there’s also a ton of customers with money to spend on their development practices, and they get a lot of benefits by having their developers able to build things in a more frictionless way.
The other sort of category of markets that we go after, where we’ve seen some good results, are companies where there is sort of an internal agency model, where you have a web development team that has multiple different website properties.
There might be hopping between different websites that are all kind of under one big corporate brand. And in that case, there’s a lot of benefits to being able to reuse those modules.
Michael Schwartz: In terms of marketing, you were sort of starting from a nice position because everyone knows npm – how do you organize sort of the marketing effort so that people know what the commercial offering is? And how do you organize the sales – do you just wait for inbound or you do any outbound marketing?
Isaac Schlueter: We do a fair bit of outbound marketing, and it’s a little bit of a double-edged sword. Everybody knows npm, but not everybody knows npm Inc. or npm Enterprise.
One of the challenges that we ran into, which I think is common among a lot of companies that are operating in open-source communities, is that people have heard of the thing but they haven’t really heard of the product.
One of the things we heard is, “Oh, npm? That’s a company??” I just thought packages came out of the ether. I didn’t realize it was downloading from somewhere.”
So, when it comes to our marketing efforts, a fair amount of the work there is in continually beating the drum of like, “Yeah, we have things for you.” “If you need policy compliance, if you need security, if you need proprietary code, and you want to manage it, using the things that your developers already know and love, then we have a solution for you.”
When we go through the sales process, typically we have an internal champion, which is usually engineering architect, or engineering manager, or something like that, who sort of intuitively understands the benefits of npm.
Then, the sale process tends to be one of making the case to folks who are not already deep in this ecosystem. That tends to be people in kind of like internal development tools, purchasing team, the CIO’s office – it can take a couple of different shapes, but, you know, the folks within a large Enterprise who managed to spend on development tooling.
Michael Schwartz: Diverting a little bit from marketing, one of my guests said to me that it’s almost better to start a company around a product that you don’t write, an open-source product that you don’t write, because all those engineers who are working on the open-source thing, they’re not billable, or they’re not contributing to their commercial product – do you feel that friction at all, where maybe part of the team is really committed to the community mission but maybe other parts of the organization are more interested in the product than actually generate revenue? How do you reconcile that?
Isaac Schlueter: It can be a tough needle to thread. I mean, not to dispute the past guest who said that, there’s some sense in what they’re saying, but obviously, I do disagree because of what I’ve done.
I think that the challenge, or at least the puzzle, is to figure out how do we continue to make good on our community mission in such a way that it serves our product interest, and how do we design our product interest in such a way that they’re served by the success of the open-source community.
We have certainly made some missteps in the past. One of the biggest things that makes good intuitive sense. You have an engineering team, you have a web team, you have a backing team. Of course, you’re going to have an open- source team, but the minute that you start doing that, you create this unhealthy dichotomy.
Even if it’s just in your own thinking as a founder, and as a manager, as an entrepreneur, where it can be very easy to get into these dysfunctional patterns of being resentful about, “Well, these five engineers are spending all their time on the open-source stuff, and we’re just giving that away, and how is that helping the company?” “And here I am, busting my hump every day, trying to make our website better, and trying to sell products and trying to get new log-ins and new sign-ups.”
And every time you want to build some new thing, it’s like, when
we run into this case of like, “Should we give this thing away or should we charge
for it?” And the thing that I’ve come to after five and a half years of doing
this is – if I was smarter, maybe I would have come to it sooner –
is just that that’s the wrong question.
The minute you find yourself asking, “Should this be free or should it be paid?”, you’ve already kind of committed the fundamental thinking error of putting those two things at odds.
The better way to think about it is, “What is the free thing that will get someone to pay for this?”
So, what can we give away in such a way that it will open the door for an upgrade path, and that will open the door for a paid product that is a very clear enhancement to the thing that they’re getting for free.
Some of the best companies in the space that I’ve seen tend to have an approach of, like, their explicit goal is that individual developer should never have to pay for our product. But, a company should almost always have to pay for it.
And that really clarifies the thinking, and it clarifies a puzzle in a really interesting way. Because anything that involves a team of ten people, writing a proprietary application, like, they got to pay for that. That’s a company, that’s a for-profit company.
Now, okay, it could also be like a school or it could be a nonprofit org – you can always give those folks a coupon, that’s not actually a problem. But with our Enterprise product and with our Orgs product, I think we’ve done okay. Orgs are free if they’re open source.
If you have five people collaborating on an open-source project, and they want to keep a bunch of modules under a namespace, they don’t have to pay for that if it’s all open source. And we really see that as part of the nice, easy transition from like an individual working on open-source, a group working on it, and then up to a group working on some kind of paid product.
One of the things that we did not anticipate when we made Orgs free was actually it increased our paid Orgs signups.
We’d always intended to do some kind of, like, first month free, type of trial type of thing, and just kind of didn’t get to it because it takes time and attention, and there’s only so many people and only so much code you can write in a day.
And we decided that we want to make Orgs free for open-source projects. Because there was a handful of different open-source projects, and we gave them an Orgs, one of our database markets just went free. And we were kind of like, “We should just make this a thing.”
When we did that, what was surprising was, people at companies would sign up for a free Org, add their whole team, try it out for like an hour, go, “Okay, this is going to work, and then, they’d flip the switch to be a paid org.
That’s for me when kind of the light bulb went off. Like, “We should not be thinking about what is paid and what is free, we should be thinking about what is free, so that it makes it easier to buy the paid thing, if you need it.
Michael Schwartz: So, it was all on the honor system? You could sign up as an Org?
Isaac Schlueter: You couldn’t publish anything private. You couldn’t have a package in your organization that had access control attached to it. Anything you published in a free Org would be open to the entire world.
Michael Schwartz: You really almost had to invent a business around this because I can’t say there was like any direct model you could choose. And one of the hardest parts of that is figuring out what to charge for that, especially because you didn’t have a lot of data. I’m wondering since you started the last five years, have you had to pivot on the pricing model a couple of times? Or has it been relatively stable, and did you get it right?
Isaac Schlueter: Yeah, we just stuck the landing – it’s been perfect. No problems at all. I wouldn’t say that we’ve pivoted on the pricing model. We have made some changes that I think are somewhat subtle. And most of those I’ve been owing to user experience.
Around in 2016, or beginning 2017 I think – I forget the exact dates now, it’s all lost in the mists of time – when we originally released our Orgs product, our paid Orgs product, basically an organization, again, you build things in the simplest way possible with the stuff you have because you’ve got to ship something, and if at one point it was perfect, you waited too long. And just the easiest way to do it was to say, “An organization is a subscription that belongs to a particular npm user.”
That gets us into some real interesting subtlety I think that not a lot of Org users, then or now, really fully appreciate it. But the idea was, your Org would have an owner – that was an npm account.
The real big problem that came up, and it came up fast, was, well, what happens when that user goes away, what happens if they leave the company and now what. It’s still billing to their account and their account has this credit card attached, it is a corporate credit card, and like, the only way to resolve it was actually to go through our support team, which, I love our support team, I think that they’re great, they do great work, and I’m really happy that they’re there, and supporting our community, and our customers, but every time somebody has to contact support – that’s a mistake we made, that’s something that we needed to fix.
So, we kind of went back to the drawing board and said, “How do people think this works? How do users think this Orgs thing works?” They think that they create an Org, and they think that they just pay for the Org, and the Org has some user who is administering it, but they can change that user.
So, what that said to me and what we kind of landed on was, the organization itself should be the primary first-class kind of billing entity. And then, the user account of the subscription, and everything else, is attached to that organization, not to some individual user.
Then, that shift, due to some other sort of subtleties, and how it was implemented, we realized that if we made this transition, a bunch of Orgs, who are currently not paying for users who have access to their packages, would suddenly have to start paying for those user accounts.
And the way that we addressed it was, we just collected all of those cases where that would happen, and we applied a coupon to all of those accounts to give them a discount and said, “All right. Like, your bill isn’t going to go up.”
Yeah, we probably could have just said, “Well, bad news. I know you’re paying $7 a month now, but it’s now going to be 21 because you got these other two users that technically are part of this other Org, even though they’re in your Org also.” And it got really hairy, but we figured that the user experience hit just wasn’t worth it like, “Thank you for being an early subscriber, an early adopter.”, but moving forward, it really vastly simplified it.”
The organization is a top-level thing, it’s like a first-class entity in our system. Every user account costs 7 bucks a month – that’s it. There’s no like discounts if you’re in multiple Orgs or anything like that.
Nobody complained, some folks got an email that said, “Hey, you know, we’re changing our pricing model. This would make your bill go up, but here’s a discount, so it won’t.” There was basically no reaction, which is what we’re hoping for.
Now, our Enterprise product, regarding pricing, yeah, we’ve been all over the map there. You talked about there not being data, well, with a self-serve product, you have quite a bit of data. It’s really easy to just throw a survey out there, and like, yeah, it’s going to be noisy, and you’re going to get a dozen people were like, “Oh, I wouldn’t pay more than a penny.” But you can wipe out the outliers, and get some kind of at least directional data.
One of the things we found was, there’s already some services out there, like GitHub costed 7 bucks a month for Orgs at that time. I think they’ve since changed their pricing model for their Orgs products, so it’s like $25 for the first 5 users and then $9 after. We thought about doing something like that in our sales, mainly in the future. Just to kind of help people get over that initial hump.
But once you had your first 5 users, it’s very, very sticky. The easier we can make that seem, it’s like 25 bucks and you get 5 users – that seems cheap. But if it’s $7 a user, and you only had two users, there’s a pretty good chance you might not like stick with the product. If you get those 5 users in, now you’ve got five people all collaborating on code, and they’re not going to abandon that for anything because now it’s kind of in their process.
So, with the Enterprise product on the other hand, there really is almost no data, and it’s very difficult to get that data. A lot of Enterprise products, even if you go to like companies, providers, websites, and you look at their Enterprise products, it says, “Call us.” You are kind of in this like arm wrestling match with the procurement department, where your price is, like, you give us ‘whatever we can get out of you’ basically is the price.
I think with our Enterprise product now we start at $50 a seat, and the product has quite a bit more features in it than our previous generation of our Enterprise product which was quite a bit cheaper. And we also have a minimum number of seats in order to qualify for an Enterprise product. We don’t offer it for less than 20 seats.
The nice thing about that is that it immediately selects out everybody who’s not actually going to need the benefits of this product, who is not going to need the policy enforcement and security features of it.
They are not going to be as well served by that product like they should really be buying Orgs. So, it’s tempting to look at pricing as like the way that you make money, but really, another way to think of it is like, how does a pricing act as a filter for who should be using this thing, and how does it work as a signal.
If you have a product, and you have your product break down your pricing page, or whatever, there are companies that are going to just look, and they’re going to say, “I don’t want the cheapest one, I don’t want the most expensive one – give me the one in the middle. I don’t want to look at all these words.” And they’re just going to buy it.
You need to think of, like, who is that user, who’s that persona and kind of focus your research there, and then, work backwards, like, “What is their budget? What can they pay?” And then from there, you’ve got pretty good answer about your price.
Every Enterprise is going to try and make some argument for why they should be paying less. So, start high and let them push you down. And also, like, if you don’t start high enough, then they’re not going to think that it’s legit.
Michael Schwartz: Was that one of the hardest parts of migrating from I guess open-source repository or open repository to business? Just getting that right?
Isaac Schlueter: On the list of hard things, that doesn’t even make it top 10, there is quite a bit that’s much more challenging. I mean, the other thing about product is, I think it’s really much more art than science, and certainly, there’s product managers out there who are like pounding the table as they listen to this, and sure that I’m super, super wrong about it.
But, so much of it is, you need to figure out a price that you won’t go bankrupt. And then, you need to figure out how to sell that at that price. And the specific number, is it 8, or is it 9, or is it 20, or is it 25.
I think at the end of the day, that probably matters a lot less than have you built a product that people want to use, and have you priced it in such a way that it sends a signal that those people actually are the ones who should be using it.
If you look at the pricing of wine, great example of this — I don’t know, I’m going to offend some wine snobs in your audience, I apologize – a lot of the pricing of wine is like completely arbitrary.
It’s like, are you somebody who likes the expensive wine or who doesn’t care, or you’re like somebody who kind of wants, “I want it to be good, but like I don’t want to spend a lot.” I mean, all wine, it’s all fermented grape juice. It’s not that different, it’s essentially just overstock of wine, that’s why they’re able to sell it so cheap.
But that price signals a particular kind of buyer who is likely to benefit from that product. And on the other end of the spectrum, it’s the same kind of thing. You’re buying this $500 bottle of wine because you want to show off how rich you are, and in order to show off how rich you are, it has to cost $500. And so, that’s why people buy that.
In the world of software product management, we like to pretend that we’re a little bit more rational because we’re all like tech people and we are very cerebral and logical. We do math, and it still largely just kind of comes down to like, what are the products that your product is like, how much do they cost. If you just copy them, it’s probably you could do a lot worse.
Michael Schwartz: So, now I have to ask a question – what were some of the hardest challenges? Please, take top, one or two.
Isaac Schlueter: I set myself up to that one, didn’t I? I mentioned a kind of the split brain that can happen within an organization when you separate out your free, or open-source, or community offerings from your paid offerings, and think of them as different things. That’s a very, very easy error to make, but it’s a very pernicious one that really gets in everywhere.
And I think it, in order to avoid that error, you have to think about that design, not just in your product design but actually in your organization design, in your strategy, in your go-to-market, in where you get your investment from, and who you have on your board. Like it has to really, really inform everything about your company in order to steer yourself away from that kind of problem.
Another big and easy mistake to make is having an on-prem and a SaaS product at the same time early in companies like them. Eventually, you’re going to need to have an on-prem product. And if you’re positioned well to do a bottoms-up sale, that has to be a SaaS.
Because no development team — if it’s five people on a Dev team and you’re trying to convince them to use this tool, they’re not going to spin up a server and install it and operate it themselves – they’re just not set up for that. If there’s a SaaS offering, they’re going to take that one.
And as an early stage company, when you’re talking about like 10, 20 people, if you are building products, like you’re going to take every single shortcut you possibly can. And the biggest shortcut you can take, if you have an on-prem product and a SaaS product, is to start putting big ‘if blocks’ in your code base. And you can tell yourself like, “Oh, they’re the same code base, were totally keeping them in sync.” It’s all one big Dev team.
What’s going to happen is, even the same developer working on both things is just going to put a big ‘If Block’ and say, if process dot, end of dot enterprise equals true, and then basically fork in place, which is even worse than actually forking two code bases. Because now you have this kind of like convoluted ball of mud.
We originally did have an on-prem Enterprise product, we still have some customers who are using it, even though we’re still trying to kind of like nudge them to our Enterprise SaaS product. We reached a point as a company, where we sort of realized we can’t keep running this Enterprise product, we’re actually losing money on every sale, because the cost to support and operate and get a customer up and running is just too high.
So, we pivoted somewhat, we kind of instead said, “How do we take what we do with the registry and with the website, with the Orgs and everything else?” “How do we make a SaaS offering there?” And what do the Enterprise customers actually need for that?”
We’re still figuring out kind of how to play in that space, and how to best have that integrated and connected with our self-serve products, but it’s still a huge step in the right direction. I think hindsight being 20-20, going out the door really in our first year with an on-prem Enterprise product and a SaaS team’s product at the same time, seemed fine. It seemed like a good idea at the time.
A bunch of people told me, “Well, you need to really make sure that the code bases don’t diverge if you do that.” I heard that from a bunch of folks at GitHub, who made the same kind of error, and I was like, “Okay, noted. Don’t let the code bases diverge.” Got it. What they didn’t tell me was, “You’re going to let the code bases diverge. That is absolutely going to happen – it’s inescapable.” You can either be a SaaS company or an on-prem product company, and those two companies are very different shapes.
If you’re going to be an on-prem product company, that means there’s a lot more of a top-down sale most likely. Or it just has to be so easy to install and start running like on a laptop. It’s almost certain that you’re going to need some really good professional services skills within your company, because making a customer successful with that product is going to require that you have somebody who knows how to stand it up, and how to operate, and kind of which buttons to push, and which knobs not to push, how to tell if there’s a problem – all of that stuff.
That means training, that means customer success, that means like really building in good metrics into the product itself, but in such a way that they’re not going to offend people who don’t necessarily want data collected about them, or if it’s behind the firewall, like, how that all works.
On the other hand, the way that you go to market with a SaaS product is completely different. It’s more about adding hooks and adding limits and adding these pay walls within your free product. So, when you go to your settings page, or you go to like view some metadata, or you go to view a report, or you go to add a new package, they can say, “Hey, you need to pay to use this feature. And those are two completely different mindsets.
At a certain point of maturity, you could reach a point where you have enough, maybe you fall of the bottoms up path, the bottom up path eventually gets to the top, and the top down path eventually gets to the bottom. But if you try to approach it from both sides at the same time, I just feel like that almost never can work out well. Now, there are companies that end up doing both, but if you really look carefully at the companies that are successful doing both, most of them started on one end, and then made it to the other.
Either they started as a top-down company, and they did well enough with like evangelizing, and marketing, and getting adoption, and gaining traction within these large companies that it became sort of a de facto standard. And then open-source parts started to kind of become the way that developers expected to do things.
Or they started as a bottoms up strategy, where every developer just eventually started to expect that this is how things work. And when they came to a big company they said like, “We need to sign up for these.” And then, eventually, they built out features that built up to that enterprise-level. And obviously npm loses position to do the bottoms up thing, and so, approaching both the same time was — I would not do that again.
Michael Schwartz: What’s your approach to building the team?
Isaac Schlueter: Before there was a company, there was me and there was one guy who was in Thailand. Another couple of folks, one was in Eastern Europe – again, this was a whole donated infrastructure stuff, so whatever that other company was doing. I didn’t really recruit them, it was kind of just like who I ended up with. And luckily, some of them were really good. A lot of npm’s success really owes to that.
When we founded the company, you know, it’s easy to forget now, because it doesn’t feel like it was that long ago, but video conferencing was not as good as it is now. Chat apps were not as good as they are now. Slack didn’t exist, Zoom didn’t exist. I think Zoom might have existed, but it wasn’t what it is now. It wasn’t back then easy-to-use.
So, initially, we would focus our hiring on the Bay area, which seemed reasonable. It’s what you do, it was a Bay area startup. We opened an office in Oakland, mostly because that’s where I live. We went from there, so that the initial team was almost all coming from Oakland. There’s one person we got doing op stuff, who is in South Africa. And part of the challenge was like adding remote people was really hard, because the whole team is there in Oakland.
Like, we’re talking about strategy, and tactic, and products, and technical direction, and stuff over lunch, out everyday, like, it’s really, really hard to keep people in the loop if they were not colocated with us.
We eventually moved from IRC to Slack, and we started doing more and more stuff on Slack. We found that we actually needed to have a little bit more time zone coverage. So, we added some other developers, we hired somebody who was in Europe, and that really pushed us to operate in a more distributor friendly way. So, doing more of our discussions on Slack, having our meetings with Zoom.
We kind of just kept adding remote people. It was like, “Well, there’s those two developers we want to add, we want to hire.” And like, can they do remote, and one of them is remote, and you do that again, again, again, and after a while, it got to a point where like, our CEO is in Halifax, our CTO is in Toronto, I’m here in Oakland. We have this big beautiful office, and I’m one of like four people in it.
When we rented that office, we had this plan to like eventually grow to 50 people. And we were looking at the office we were in. We were 13 people, and we did not fit. We had a single conference room, a single room with a door that closed, and we grew to about 13 people, and we were just like, “This is ridiculous, we got to get out of here.”
We found a bigger space, we knew that we would end up growing to between 30 and 50 people over the next couple years, so we’ve rented the space that could house that many. I think it was just a few weeks or a month ago actually, or maybe a couple months ago, where we had this interesting situation where our landlord wanted to move us to a different spot within the building.
You know, we’ve been thinking for like a year how stupid it was that we had this big Oakland office, and like, we’d really like to get rid of it, but we’ve got another year on the lease. And they’re like, “Hey, we want to move you from the 11th to the 5th floor.” And we’re like, “How about we just leave?” They are like, “Yeah, cool. We get to rent the space out at 2019 prices instead of keeping your lease? Yeah, go.”
So, it actually worked out great. It was a little bit sudden, the way that sort of fell on our lap. But yeah, now we’re just 100% remote, everybody works from home, and that freed up a lot of capital for us to actually offer like a monthly work from home allowance, to cover things like internet, and the desk light, or whatever work expenses you might have, whereas previously, it was like we really can’t afford to do that because we’re spending our whole office budget on an office.
If you want to work in the office, like, we got this great office, but most of our staff was not in the Bay Area. So, in terms of like, where do we recruit people or how do we find talent, we do get a lot of resumes, we do get a lot of interest especially in technical roles.
We use a combination of just our networks, which has some pros and cons. The obvious pro, hiring somebody you know is you know them, so there’s a good chance that there’s a little bit more of like a connection, they may be a little bit more motivated to make it work, etc.
The downside is, you probably know people who are like you, and so you can very quickly and easily get into a bad cycle, where your kind of diversity just goes off a cliff. Or even worse, we’re like people who are kind of in the crowd, or like included in decisions, or have a little bit more power or authority within the company, then they probably sort of can get very like toxic and weird that way. I think that we’ve avoided that for the most part.
The other thing we’ve done in, especially tough to find rolls, we’ve had some success with executive search firms, we’ve done that a couple of times. And then, also posting stuff on LinkedIn, on Lever, on our other social media channels. We have our own npmjs.com/jobs that shows what roles we have open, and people apply for them.
Michael Schwartz: The last question. Any advice for new entrepreneurs who are starting a business where open-source is a part of their business model?
Isaac Schlueter: I talked about this a little bit, but I’m going to go ahead and just repeat myself, because I feel like this is really important and really easy to miss and really easy to not understand the importance of it.
You have to craft your plan such that doing the free thing actually serves your strategy. And there’s a lot of subtlety to that. I don’t have like one weird trick that will fix everything. But you definitely need to think of, like, “If we give this thing away for free, what happens?”
Part of the thinking there is, imagine that you have like ants roaming around on a dirt floor or on the ground, if you pour some honey in one spot, that’s going to change the whole ecosystem. And that’s kind of what happens when you start giving away something for free, whether it’s an open-source product, whether it’s a service that you say, like, “This is free for open-source packages or for open-source projects, or for open-source users whatever.”
You’re creating a pile of honey in the middle of all these ants that are currently just kind of roaming around in their own different ways, like, they’re all going to find it, and they’re all going to come to it. It’s like, “Okay, now what?” What I mean by that is, when you get something away for free, you are fundamentally kind of like disrupting an ecosystem.
It’s important none of the ants are complaining about the honey, but you’ve now changed the shape of the scenario. And that can be really, really good, or that can be really, really hazardous.
It’s tempting to be like, “Oh, I’m charging for this thing and I’m giving this thing away.” And how do I convince the free people to buy the paid thing? Like, you’d really need to back several steps up and think, “What do these people need? What’s the thing that I can sell them that will address that need? And what’s the free thing that’s going to drag them over?” Instead of saying, “What do I give away for free?”, and then separately from that, “What do I pay for it? How do I balance these two?” They have to be one thing in your mind.
Michael Schwartz: Isaac, that was super interesting. Thank you so much for joining us today.
Isaac Schlueter: Thanks for having me.
Michael Schwartz: Huge thanks to the Open Core Summit for connecting us to Isaac and for volunteering their only sales office to provide a quiet place to record. Don’t miss the next Open Core Summit. It was one of the best conferences I attended in 2019. Where else can you get a critical mass of open-source founders in one place?
It’s essential that we foster an event like this so we can share experiences about what’s working in open-source business.
Transcription and episode audio can be found on opensourceunderdogs.com.
Music from Broke For Free and Chris Zabriskie.
Audio editing by Ines Cetenji.
Production assistance by Natalie Lowe. Operational support from William Lowe.
Have comments? Tweet at us. The Twitter handle is @fosspodcast.
Please, subscribe to the podcast on your favorite podcast platform. Every subscription helps. Next week we have Shannon Williams, one of the founders of Rancher. He was fantastic, so don’t miss this one.
Until then, thanks for listening.
Ben Golub has lead several open source software ventures, including Gluster and Docker. Storj monetizes open source by creating a distributed file storage network. Using the network, people can securely store files. And owners of Internet connected computers can put their unused disk capacity to work. To lower transactions costs, Storj launched a true utility token, which has intrinsic value. It simplifies transactions of an alternate 150+ fiat currencies. This episode was recorded in person at the Open Core Summit.
Michael Schwartz: Hello, and welcome to Open Source Underdogs. I’m your host, Mike Schwartz, and this is episode 37, with Ben Golub, CEO of Storj.
I was really excited to schedule this episode because for a few years I’ve been wondering if there’s some cryptocoin business model that might work in the open-source world.
This is the second of three episodes that we recorded at the Open Core Summit in San Francisco in 2019. It was a fantastic event for open-source teams and founders, and I highly recommend attending the next one.
Ben was previously the CEO of Docker, he was also the founder of Gluster, which was sold to RedHat. He has a pretty deep understanding of the trials and tribulations of building a business around open-source.
After finishing the interview, I wasn’t 100% sure this was really an open-source business model after all, but Storj is definitely one of the most unique companies I’ve ever learned about. So, with that said, let’s roll the proverbial tape.
Michael Schwartz: Ben, thank you so much for joining us today.
Ben Golub: My pleasure.
Michael Schwartz: Ben, before Storj, you helped found a company that launched a little product called Docker – can you tell us a little bit about your journey? How did Storj come about, and why did you move on from Docker?
Ben Golub: Yeah. I’ve now been at 8 startups, four CEOs, so I’m a glutton for punishment. I actually started my career doing international development, so my first failed startup was a business school in Uzbekistan that had a business model, which was I think, “Teach people how to read a balance sheet and then democracy will flourish.” And that didn’t quite work.
But from then on, I’ve been involved in sort of the first version of the web, ran a number of businesses at VeriSign, was the CEO of Plaxo, was the CEO of Gluster, which we sold to Red Hat, and then ended up at what was dot.Cloud, and it eventually became Docker.
Right at the time, Docker had this crazy notion of taking a container that we used to run a PaaS and said, “Hey, can we make this available to the world?” And Solomon Hykes, the founder, and I introduced this notion of a container. And I think in sort of excellent open-source fashion embraced the community, embraced something that was disruptive.
We saw it grow, and it became tremendous. I think it helped change the industry and became a driving business. I’m an early-stage startup guy, I’m not a late-stage startup guy, and I think that once you want to get to a certain size, where it’s 500, 600 people, and you’re closing in on a hundred million revenue, there are people that are better at scaling PaaS than I am.
So, I moved on. I still obviously love the company. And then, I got approached by Shawn Wilkinson, who had this crazy notion as a student at Morehouse College that you could build Airbnb for disk drives, and that’s what I’m doing now.
Michael Schwartz: I think of Storj as decentralized S3.
Ben Golub: That’s absolutely accurate. Deliver something that’s S3, its cloud storage, but it’s delivered across a huge network of disk drives that we don’t own, that are run by individuals and data centers.
Michael Schwartz: So, for every dollar raised, 60% goes to the person with the hard drive? The other $0.40 I guess goes to storage, the company – how do you use that $0.40 to help build the ecosystem?
Ben Golub: It’s a really good question. One of the most important things that we do is, we sort of build equivalent of really large self-storage data centers, without spending any capital, and we just compensate the people who run the nodes.
We are onto the same thing on demand side as well, so rather than hiring hundreds of salespeople and giving away open-source software for free, we’ve come up with the notion that open-source drives 2/3 of the cloud, so we give a portion of our $0.40 to any open-source software company.
Usually, our way is, we also have partners in the Storj space, we are partners like Mongo, FreeNAS, FileZilla and Influx, and it’s really a great win-win.
Michael Schwartz: Who are the users of Storj? What type of applications is it good for?
Ben Golub: Its really general object storage, which means that anybody who’s generating a large file that is going to be read a lot, it’s an excellent use case for us. That’s good for backup, it’s good for serving videos. It’s good for distributing software.
The world of course creates lots and lots of data every year, and about 90% of it that’s being created is sort of large files, which is a perfect use case for us.
Michael Schwartz: Some would say that you have to be ten times better than a previous existing solution to motivate people to move – why would someone use Storj over Amazon S3?
Ben Golub: That’s a good question. And they almost have generalized it to the centralized cloud storage offerings. One interesting note is that while the price of disk drives has come down roughly 50% over the past five years, the price of cloud storage has come down maybe 10%, during a period in which the amount of data of course has exploded.
We are significantly cheaper, we are also profitable. We are also significantly, we think, a much better security model. And we can’t read your data. It is almost impossible for a hacker to get your data, or get a treasure trove data – it’s like sort of encrypted sand on an encrypted beach.
We also happen to be faster. We happen to be 100% durable, and at a significantly lower price. What we’ve found is, there’s almost insatiable demand for people to try us out. Now, it’s early, so people are dipping their toes in the water, using test data first, or you know, low value use cases, but we think when they see what we’re doing, they’ll be here.
Michael Schwartz: Google tells me that Storj as a cryptocurrency issued on the Ethereum platform. The price they told me is $0.1514 cents, and a 24-hour trading volume of three million, prices up 3% in the last 24 hours.
Ben Golub: Oh, it must have been my speech.
Michael Schwartz: It is a circulating supply of $144M coins, of max coin supply of 425M coins. So, my question is, how does a cryptocurrency relate to the monetization strategy of the company?
Ben Golub: Our basic economic model is that we quote prices for Storj, and we quote them in dollars. And as a consumer of our service, you can either pay for storage with us in dollars or in our cryptocurrency.
If you are a provider to us, if you are renting out your disk drive, we pay you a dollar rate, we pay you using our cryptocurrency.
And you can either hold onto that, you can use it to buy storage on your own, or you can trade it on one of the 11 + exchanges that are using us.
Unlike a lot of other crypto companies, we’re primarily a decentralized storage company. And the crypto is a great accelerant, it lets us have hundreds of thousands of people get paid in 180 countries and build things like smart contracts. But we’re not a mining company, we are a company that is first and foremost about delivering a much better approach to storage.
Michael Schwartz: Why was the cryptocurrency a better way than just settling in cash?
Ben Golub: Well, it turned out to be very difficult to settle in cash in small amounts. It’s very difficult to do things like smart contracts using cash money. We are in 180 countries, so what we found is that having the cryptocurrency made it much better for us to build a large network.
Now, we could certainly be entirely fiat-based, but then, there would be additional fees, but this seems to align well with our interests.
Michael Schwartz: You’ve said in the past that there’s a disconnect between the value created by open-source software and the amount of economic empowerment – what did you mean by that?
Ben Golub: If you look at for example the cloud market, which is now a 180-billion-dollar market, over 2/3 of all of the workloads are open-source based. In fact, if you were to include Linux in that, it’s about 90% of the workloads.
It is very clear statement to make that open source built the cloud. If you look at the total revenue generated by pure-play public open-source companies, like the Red Hat’s, and the Hortonwork’s, and Cloudera’s of the world, their total revenue is about 5 billion. So, 5 billion out of 180 billion.
If you talk to any open-source company that’s doing things in infrastructure, what you’ll find is that the primary way in which they are being monetized now is by Cloud companies, who, for rational reasons, basically give away the software for free, in order to drive consumption of additional compute cycles, or additional storage cycles.
And unfortunately, cloud computing is the biggest trend and monetization by giving away for free is the biggest way that open source is getting monetized. And there are really only four companies on the planet that are capable of running large public clouds. That to me is a huge disconnect.
Michael Schwartz: On this podcast, we’ve had several guests who are worried about what we called Cloud strip-mining of open-source software, and they see it as really an existential threat to the open-source ecosystem.
And yet, Elastic, Redis and MongoDB are doing pretty well. Is this a victimless crime? And is it desirable for the companies that develop the open-source companies to capture all, or even a majority of the revenues, in the ecosystem?
Ben Golub: I agree that there are a handful of successful commercial open-source companies, I happen to have been at a couple of them, but these are just a handful of them. And almost all of the ones that you mentioned have essentially gotten to their state by spending hundreds of millions of dollars to go directly to the on-premise businesses.
And while I think it is wonderful, and it’s great that there are success stories that there are, I don’t think we would be happy if we said, “Hey, there are only five successful farmers in the world out of millions of farmers.” We wouldn’t be happy if we said, “Hey, there are only five or ten, successful companies in general.”
There is so much potential, and so much of these trillion-dollar IT industry, and 180 billion-dollar Cloud industry is being driven by open source, but if it isn’t flowing back in, then, we’re really not going to see the potential that open-source could really bring to us. In much the same way that I don’t think telecommunications was delivering on its full potential until we went to the internet.
Michael Schwartz: So, selling to these large enterprise customers, as you mentioned it, an on-premise software product is really expensive to scale support in sales. And it could be tens of millions or even hundreds of millions of dollars actually build that kind of infrastructure – but does decentralized cloud approach change that for these companies?
Ben Golub: Yes. For an open-source company that partners with us, if they have an open source project, whether through paid users or free users, generates lots and lots of storage. My guess is that they are generating lots and lots of money for one of the big four cloud providers, but are not seeing any of that.
Instead of trying to come up with a new kind of license, we come up with a new kind of cloud, a centralized cloud, like Storj, it’s entirely in our rational benefit to say, “Hey, if you have an open-source company that drive storage to us, we will give you a healthy chunk of the revenue that we get. And so that’s what we do.
All of a sudden, they’re able to build up a sustainable revenue source that doesn’t require hiring lots of salespeople, it doesn’t require trying to solve the multi-cloud problem for the 500 large companies in the world that they can do that.
Now, we may not be-all and end-all, we may give them the first two years of additional runway, so that they can build a sustainable base, and then go after the enterprise – and that’s fine. But getting from big community to successful enterprise sales is a really hard gap to close without the cloud.
Michael Schwartz: Recently I was reading an S, and I did a search for open source, and the only place I found it, was in the risk section that, you know, somehow using open-source might come back and bite us, and we might have a liability. Do you think that the public is really aligned with this view that open source is a good thing?
Ben Golub: I think there’s no question to me that open source itself is the dominant way that software is getting written and consumed. Go to any enterprise, and it’s far more likely to find that they are open-source first rather than proprietary.
If you look, all these same things are happening, whether it’s Containers, or Docker, Kubernetes, or Mongo, or databases, or in operating systems, or in machine learning – it’s all happening in open source.
But the monetization of that is broken. It’s not that anybody questions that open source is a right way to build great software, it’s that the monetization model that used to be fairly clear has now gotten disrupted by the public cloud.
Michael Schwartz: Because one of the best monetization strategies of offering and as-a-service is now not available?
Ben Golub: It’s not available. If you are a small company, it is almost always a much better idea to say, “Hey, let me service lots of small and medium-sized customers first with something that looks like a service, rather than trying to do on-premise.”
You might eventually get to on-promise, but unfortunately, that model, which used to work pretty well for open source, is really difficult now. And it’s not only that you sort of have this gap between large community and getting to on-premise, but increasingly, even the on-premise market is now becoming dominated by public cloud.
Michael Schwartz: Do you think that using the open-source development methodology materially contributes to the business?
Ben Golub: It really depends. I’d say open source is not a strategy, it’s a tool. And you have to find the right approach to open source that matches with your business strategy. But, if your strategy — Docker certainly could not have happened had we been proprietary.
We could not build a huge ecosystem and get so much usage and integration if we were proprietary. And then, the challenge becomes okay.
Now, we’ve got millions of users and billions of downloads, and lots of enterprises are interested in how we turned that into monetization. But, honestly, that’s a much better problem for me to try and solve than, “Gosh, I’ve got some proprietary. I can’t take anybody even take a look at it, and it doesn’t work with anybody else’s stuff.”
Michael Schwartz: What do you think are some of the indicators as to when the project should be — where open-sourcing it might be helpful?
Ben Golub: I think that there are a few different things to look at. I think, first of all, you want to, in any project, do that 10x thing that you said. If you’re just coming up with an open-source version of salesforce, and the only difference is, it could be slightly cheaper, that is not going to happen.
The disruption was being SaaS, the disruption isn’t on the code side. But I think that, to the extent, what you are building requires a strategy that wants to build a large top of the funnel. You know, if it’s something that’s developer-centric, if you have a strategy that depends on having lots of integration, if you have a strategy that depends on being disruptive, then those cases, I think, you want to look at open source. If you’re just an end-user application – probably not.
Michael Schwartz: You mentioned that with Storj, there’s a virtual cycle of investment, growth monetization, and innovation – can you unpack that a little bit because that’s very concise?
Ben Golub: Sure, again, we are a different kind of cloud, and since 2/3 of cloud workload is given by open-source, we’ve sort of elected to try and make the open-source community part of our go-to-market, but in a mutually beneficial way.
In the model that we have, if you’re an open-source company, and your product generates lots of data whether by your free users, by your page users, it doesn’t matter, backups, if you build a connector that gives your user the option to send that data to us, versus another form of object storage, will give you a chunk.
What does that set up? It sets up a nice virtuous cycle, in which open-source innovates, open source generates revenue for us, like in similar decentralized networks. We, in turn, send revenue back to open source, which allows them to innovate further and build their own business models, and it continues.
Michael Schwartz: You mentioned that decentralized cloud is potentially a new business model for open source. And I understand how you’re saying, if you write an open-source piece of software that uses Storj for file persistence, that you could generate revenues from that. Can somebody build a company like Storj that uses a decentralized approach to something else?
Ben Golub: Yeah. There are companies – we are sort of decentralized S3, as you said. There are other companies out there, like Xiamen and others, who are trying to do decentralized DC2.
Of course, there are a lot of interesting decentralized payment companies, there are interesting decentralized CDN companies. Each of these has basically been taking a fairly horizontal use case that the cloud companies deliver, but deliver it in a decentralized way. And I think, in all cases, we would all be well-served by embracing this notion of mutually beneficial relationship with open source.
Michael Schwartz: The only company that we’ve interviewed, who has issued a cryptocurrency, do you think that there’s opportunities to use cryptocurrencies for other purposes? Maybe to help either fund or reduce transactions cost for developing or monetizing?
Ben Golub: Absolutely. I’ve seen lots and lots of interesting crypto companies, and there are lots of not so interesting ones that are just ‘fly by night’ operations. But, among the interesting ones, with blockchain and cryptocurrency, what we needed to do is sort of create these large decentralized networks, where trust is sort of built into the network, rather than residing in a particular individual.
And you can make payment algorithmic. There are a lot of interesting experiments, for example, to say, ”Hey, let’s reward people for contributions to open source based off of using crypto currency, and doing it in an algorithmic manner.” And it gets really an interesting idea.
But ultimately, for anything like that to work, somebody has to be able to drive economic value for the open-source to begin with.
And my guess is that’s not the people who today are generating the value, which is the public cloud companies.
Michael Schwartz: From a legal business perspective, it’s fairly technically challenging launching a cryptocurrency.
Ben Golub: Yeah, we were sort of fortunate that we did it right. And we also, in 2017, we had a network built and launched before we did a token sale. The token sale had utility from day one, and we’ve tried really hard not only to be enterprise-grade in terms of our product, but to be in a serious enterprise-grade in terms of our governance and management of the token and our treasury policies, inside our trading and governance, all those good things.
Michael Schwartz: Storj actually holds cash or an amount of cryptocurrency that’s let’s say unissued – is that how it works?
Ben Golub: Yes. We generated in our token sale 425 million tokens, and then in essence, we broke the mold. So, there will be no more ever created. We sold 75 million in our initial token sale. Since that time, of course, review tokens to compensate people who are running nodes, some people have paid us back in tokens.
Right now, there’s about a 125 million storage tokens in circulation, and then, the remainder we have, the biggest chunk of that, is in time lock, so that it won’t be entering the market in an undisciplined way.
Michael Schwartz: I could probably keep asking you questions about cryptocurrencies for the next half an hour.
Ben Golub: Oh, that’s okay. Happy to answer that, but now, I’ll be honest, I find cryptocurrency far more interesting than decentralization. Because, ultimately, I think that if that’s a tool, and cryptocurrency is a small part of blockchain, and blockchain is a small part of decentralization. Decentralization is in some way even bigger than Internet, because Internet in itself is decentralized.
Michael Schwartz: Slightly off topic question, but is the acquisition of Red Hat by IBM a good thing for the open-source software segment?
Ben Golub: I think it really depends on how IBM manages it. Some companies do a great job at acquisitions and some don’t do a good job. I have to say that I actually sold a company to Red Hat Gluster, which, of course, Red Hat has now become part of IBM.
I think to the extent that IBM enables, or allows, Red Hat sort of to open-source roots, but helps it sort of continue to flourish as a shining example of commercially successful open source, I think it’s great.
Personally, last year, I was able to say, “Hey, it’s fantastic, we now have more than Red Hat.”, as an example of a public open-source company, and Red Hat, and Hortonworks, and Cloudera and RealSoft and, and now Mulesoft has been acquired. Cloudera and Hortonworks have combined, and Red Hat is now part of IBM. Elasticsearch entered, but there’s fewer public open-source companies.
Michael Schwartz: Now, we have less.
Ben Golub: Yeah. And, of course, the largest one is now no longer independent.
Move To Open Source License
Michael Schwartz: Recently, several prominent companies in our industry, like Cloudera and Chef, moved to an all open-source strategy, then moved away from open core. Do you think open core has peaked and will move back towards a more truly open-source model?
Ben Golub: Well, it’s interesting, because on the one hand, you’ve seen some people become more permissive with their licensing, and then you’ve also seen other companies become more restrictive, and come up with a sort of new licenses to deal with the Cloudera.
I don’t have a dog in that fight, except I think that the answer to monetizing the cloud isn’t a new kind of license, I think it’s a new kind of cloud. And that’s where we come from. Because, ultimately, yes, you can add value to open source by making it better for large enterprises, whether it’s through proprietary modules, or services support, or subscriptions, or packaging.
I think there’s all kinds of variations on a theme. What we need to do is find a way that you can make open source monetizable for large numbers of small and mid-sized companies, or even larger companies that are running in the cloud.
Michael Schwartz: Putting storage solution aside for one second, what do you think are the biggest challenges today facing entrepreneurs who want to build a business around an open-source software project?
Ben Golub: I think that the first challenge most have to do is, like any great open-source project, build something compelling and build an exciting community around it – that’s a hard thing to do.
I think that what they then need to figure out is how do they build a sustainable business model that can carry them from the time they have a really big community to the time that they have a sustainable economics.
Along the way, it gets really difficult. Even if your community is successful, how do you manage your community, how do you monetize, how do you make it possible for people that participate in your community, without undermining it, and how do you avoid going down to the point where all that you get from a large company is just charity.
I’m not saying charity in a bad way, but I’m saying, when I was running large open-source communities, what I wanted from the cloud companies wasn’t some cloud credits. I didn’t want them to say, “Hey, I’ll put two people on your thousand-person projects.”
It’s nice, but what we really needed to do was have a mutually beneficial business relationship, so that we could invest and grow.
Michael Schwartz: What advice do you have for the entrepreneur who needs to lead this open-source effort? You’ve been through the entrepreneurial journey many times, and I’m just wondering if you have any advice for the person who is actually going through that journey?
Ben Golub: Well, of course, it is a journey. As they say, it’s a marathon, not a sprint. I think, personally, what you have to do is, you have to love what you’re doing. And I think especially for an open-source, you have to believe that the journey will be worth it even if you can’t feel the successful business.
Because, what you are doing, it’s interesting enough for you, and it’s going to be hard to build something interesting enough for the community. But having done that, I think you need to think really clearly about where you want to be each year over the next five years. I think you need to think really clearly, from my point of view, over what your monetization strategy is going to be, and who are your users, and what is your use case.
I think far more startups fail because they don’t pick a direction than because they choose the wrong direction. I think if you articulate internally a really clear direction, and then, you’re consistent in saying that’s your model, whether it’s open core, or service and support, or access, or whatever it is, and then you are relying on everybody in your company – I hope choice of strategies is right.
But even if it’s slightly wrong, at least you’ll all be running in the same direction, and you can change course. The worst thing that I’ve seen in startup after startup after startup is, they don’t pick a direction.
Everybody runs at five different directions, and they know they are failing and they don’t know whether it’s because one of those is wrong or because all of them are wrong.
Michael Schwartz: Ben, thank you so much for taking the time out of the conference today to record the podcast.
Ben Golub: Great questions, thank you.
Michael Schwartz: Huge thanks to the Open Core Summit for connecting us to Ben, and for making space to record at the 2019 Summit. Don’t miss the Open Core Summit next year. It’s a fantastic event for founders and open-source teams.
Transcription and episode audio can be found on opensourceunderdogs.com.
Music from Broke For Free and Chris Zabriskie.
Audio editing by Ines Cetenji.
Production assistance and transcription by Natalie Lowe.
Operational support from William Lowe.
Have comments? Tweet at us. The Twitter handle is @fosspodcast.
Please, subscribe to the podcast, or add it to your favorites on your platform. Every subscription counts.
Next week, we have Isaac Schlueter from npm, the last of the in-person interviews from the Summit.
Until then, thanks for listening.
Have comments? Tweet at us. The Twitter handle is @fosspodcast.
Please, subscribe to the podcast, or add it to your favorites on your platform. Every subscription counts.
Next week, we have Isaac Schlueter from npm, the last of the in-person interviews from the Summit.
Until then, thanks for listening.
Bart Copeland, is the CEO of ActiveState. Since the 90s, millions of developers have used the famous ActiveState distributions of Python, Perl and Tcl. In this episode, Bart narrates ActiveState’s journey, including several pivots and ownership changes. Stay tuned to the end to find out how they were able to pivot to the open source thing that they do so well.
Michael Schwartz: Hello, and welcome to Open Source Underdogs. I’m your host, Mike Schwartz, and this is episode 36 with Bart Copeland, CEO of ActiveState.
If you’ve ever installed Python, Perl, or Tcl on a Windows workstation, there’s a pretty good chance you use the ActiveState installer and distribution.
ActiveState is one of the oldest open-source companies in existence. The founder was Dick Hardt, who some of you might know as one of the editors of the OAuth 2.0 specifications, among other notable achievements.
This episode is the first one we’re publishing that was recorded in person at the open-core summit. If you’re a fan of the podcast, you heard Joe Jacks, a few episodes back, describing the event which did not disappoint.
Don’t miss the next one if you can get to San Francisco. Especially if you’re a founder or entrepreneur interested in open-source software development.
ActiveState made some major pivots, although I think they ended up returning to their roots. It’s a pretty fascinating story. So, without further ado, here we go. Bart, thanks for joining the podcast today.
Bart Copeland: Thank you, Mike, it is great to be here.
Michael Schwartz: ActiveState was founded in 1997, which makes it one of the oldest companies we’ve interviewed so far. It was acquired by Sophos, I guess in the 2000s, and then, it was bought out by management.
Just focusing on what happened after the acquisition, can you take us back to the time after the buyout happened, and how you refocused a company?
Bart Copeland: It’s a really good question, Mike, but I should start with, in order to understand the refocus, we need to understand a little bit of history of why ActiveState was acquired in the first place.
ActiveState started in 1997, it was all around open source, building specifically language distributions around open source for the developers. Developers had needs specifically around Perl. Then, anti-spam became a huge problem. ActiveState came up with an anti-spam solution called Perl MX, and that caught the interest of Sophos.
Sophos acquired all of ActiveState, but Sophos really wanted the Perl MX product, which eventually became PureMessage under Sophos. The CEO Sophos had a lot of affinity, and pride, and admiration for all of ActiveState. And the other team, the language distribution team, was dormant within Sophos, and he did not want to do anything to hurt that team.
That’s where I got involved, and I was an early investor in ActiveState, but I wasn’t part of management. But then, Steve Munford, the CEO of Sophos, contacted me, and I, with a couple of few other outside investors, we acquired the team, the technology, the customers and the ActiveState brand.
And what we wanted to do leaving Sophos, is, we wanted to do the next great thing. We often said, “We want to do the next PureMessage.” So that started us on what we refer to as chapter 2, or version 2.0 of ActiveState. So, 1.0 was 1997 to 2003. And then, 2.0 was after the dormant period, from 2003 to 2006. And 2006, that’s when we started ActiveState 2.0.
Maybe, before I go on, did I give you a good grounding of…?
Michael Schwartz: Sure. And what was the plan when you bought it out?
Bart Copeland: There was two key plans. The first key plan was, we needed to extract ourselves from Sophos. There’s all this infrastructure and technology overlap that we needed to distract ourselves from, so that was our first plan.
The second plan was, let’s go do the next great thing. And that’s what we were going to do. We were a team, I think at the time, we were about 16 people or so. One other key caveat, above all this, was, I wanted to do it organically. I didn’t want to raise a bunch of money. I said, “Let’s do this the good old-fashioned way. Let’s drive revenue, let’s reinvest that revenue, our profits into growing even further.” So, that was what we embarked on.
Michael Schwartz: Would you say that you’re similar to Anaconda, or RedHat, making an open-source software distribution, consumable by the enterprise, by providing reps and warranties, and liability protection, and patches, and aligning with the enterprise procurement process?
Bart Copeland: The short answer is — I’m going to give you two answers, the short answer and the long answer. The short answer is, I say, we do the same thing that RedHat does for Linux, but we do it for open-source programming languages.
We have RedHat Enterprise Linux or RHEL, and it’s a enterprise-grade distribution of Linux. We have Enterprise grade-distributions for Perl, Python and Tlco, and there’s a lot more we’re doing there. That’s a short answer.
The longer answer is, our whole mantra at ActiveState is twofold. Mantra number one is, making open-source easy for the enterprise. Mantra number two is, making open source that just works for developers.
When it comes to open source run times, whether you’re the enterprise or the developer, there’s different needs. But if you look at the complexity it is today, to build a language distribution from an open-source ecosystem, and have that consistency across operating systems, managing all the dependencies, managing the security issues, managing the license issues, and then, keeping it updated, and making it really easy to deploy and share with other developers, making it really easy to move that distribution from your dev environment to your test environment, or your staging environment, or it’s your production environment- it’s not easy.
We do a number of things that make it easy, as well as the indemnification that you talk to. There’s really two audiences, there’s developer audience and they have their needs, and then, there’s the Enterprise audience and they have their needs. And our goal is to meet both audiences’ needs.
Michael Schwartz: So, from a revenue perspective, what are the most important products, and which products do you think are the most promising for future growth?
Bart Copeland: I talked about the versions or chapters of ActiveState. Under chapter 1, the most important product in terms of revenue potential and growth was Perl MX product.
Under chapter 2, it was the Stackato product. The Stackato was our private PaaS offering. That product was sold to HP in 2015.
However, under chapter 3, it’s our language distributions product. But here is the important thing to recognize, Mike. Under chapter 1, and chapter 2, and under chapter 3, this has been a steady growing business, our language distribution business. What we’re doing different under chapter 3, is we’re trying to grow our business so that it doesn’t bifurcate. Because, if you notice in chapter 1 and chapter 2, we ended up with two business units.
In chapter 1, we had the language distribution business, and we had the Perl MX business. Under chapter 2, we had a language distribution business, and then, this product called Stackato, which I touched on briefly.
So, we ended up with two business units under chapter 1 and chapter 2, and I really felt what was important for us, as a company going forward under chapter 3, is, let’s have a unified product offering, no bifurcated businesses or two-business unit.
Our real growth opportunity and potential for ActiveState going forward is around this whole area, what we refer to as open-source language automation. This is a category that we’re leading in. It is bringing automation to your open-source runtime.
And, as you know, Mike, in the hole open-source ecosystem today, there is a lot of movement towards bringing automation to the software development life-cycle. We are touching on one aspect of that, and that’s the open-source runtime.
Why this is so important, and why we see this is a huge opportunity, not only for ActiveState, for a lot of people in the open-source ecosystem is that developers today have lost the freedom to do what they do best, and that is, write code.
Developers today are spending more time doing things other than writing code, they’re dealing with security issues, they’re dealing with license compliance issues, they’re dealing with IT compliance issues, they’re dealing with bug fixes. And it’s knowing that developers are losing their efficiency in doing what they do best.
Furthermore, developers are not able to use the best tools to do the job. What we’re trying to do, as a company, is to help free up developer, so they have the right tools to do the best job, and they’re doing what they do best and love to do, and that’s just writing code.
So, in summary to your question of, “Where is the biggest potential for ActiveState?” – It’s around this whole category that we have created called Open-source Language Automation.
Michael Schwartz: ActiveState is serving many large customers, but the market for programming language is a very horizontal market, probably every company on the planet can use it. Do you segment the market in any way?
Bart Copeland: We do, and we don’t. There’s two ways we look at the market. The first way we look at the market is, we think of the developer, and we think of the large enterprise – we’re constantly thinking about that.
At ActiveState, we talked about bottom-up and top-down. Bottom-up is, we think of the developer, and how do we create an experience for them, to be very easy for them to consume our products and use them in working with us quickly.
The top-down is, the developers using our product, bring it into an enterprise, they bring it to their boss, and they say to the boss, “I really like to use the ActiveState platform in greater detail at the job.” That’s the top-down, it brings in the decision-maker, it brings the buyer. So, that is one way we look at the market.
The other way we look at the market is, in terms of verticals, who has the greatest affinity for the types of solutions we build and sell. And historically, and going forward today, we’ve had a lot of success in obviously high-tech.
We’ve had a lot of success in banking and finance, we’ve had a lot of success in aerospace and defense, we’ve had a lot of success in insurance, and we’ve had a lot of success in manufacturing. Whereas we haven’t had a lot of success for example in healthcare, to give you an example where we haven’t had success.
But on the whole, though, we don’t do a lot of segmentations, because you’re right, it’s a very horizontal play for us. And what we try to do is, we try to make our softwares accessible to as many developers as we can globally. Throughout the planet, we have downloads all over the planet. The number one download is the US, and I think after that, our downloads are really big in China and Japan, and then, in Europe.
Hopefully that gives you an idea of how we look at the marketplace. And I guess, if I would really wear my marketing hat, we could do a lot more segmentation that we’re doing than we’re not doing.
Michael Schwartz: So, drilling down into the team a little bit, how do you organize the sales effort for such a global market? And how is that sort of adjusted over the years?
Bart Copeland: The first thing is actually, the adjustment has been the same under all versions of ActiveState, or all chapters of ActiveState, 1, 2 and 3. The selling motion has been the same. The selling motion from a sales organization is effectively comprised of account managers, account executives, and customer success managers, and inside sales reps, and depending on where you are in the selling cycle, involves those individuals.
Typically, what happens, we — and I got the other aspect of sales engineers — we get a potential opportunity. Usually, it comes from a developer, or group of developers, using our solution within an organization. That then leaves to greater interest into, going from the free version to a paid version. That involves an account executive, with a sales engineer, they work together, and we do this all over the phone.
All our selling is done over the phone, rarely do we go on-prem to an organization. It’s done over the phone, or through a series of video conference calls. Then, relationship is made, a deal is consummated, all our deals are based on annual subscriptions. That’s a recurring revenue model. Once the deal closes, then it goes to our customer success manager.
The customer success manager with her team, their job is to make the customer successful. Then, there’s an account manager that is brought in to nurture and manage the account, and renew it, and work with the account, to help them in other areas of their business, where our solutions can help them. And that’s typically the cycle that we work on.
Now, that is for the Enterprise tier. One thing that I haven’t touched on, Mike, is that we, not only have an Enterprise tier, we also have a lower-tier pricing structures. We have five tiers, we have the Community Tier which is free, but then, we have the Coder Tier, the Team Tier, the Business Tier, and the Enterprise Tier.
For the Coder Tier, Team Tier and Business Tier, that’s handled by an inside sales group that deal with the smaller price point products.
Michael Schwartz: I noticed that you have an OEM license – is that a material part of your business? And how did that come about?
Bart Copeland: Yeah. If you look at our business today, at the enterprise level, about 50% of the revenue at the enterprise level is enterprise subscriptions, and the other 50% is OEM. So, the way it came about is that when you get a distribution supported from ActiveState, there’s two ways you can consume that distribution. One way is, you consume it internally, and you consume it internally for all of your internal Dev practices or Dev applications that are enterprise wide.
However, another way you can consume our distributions is, you bundle it with your product, and you sell that bundle to your end-users. For example, you may have a product that requires a Python language distribution to run your Python product on your customers’ systems.
Then, we OEM our language distribution as part of a bundle, and that’s how it came about. It’s a sizable portion of our business, the OEM portion.
Michael Schwartz: Are there other partnerships that you think are important to ActiveState?
Bart Copeland: So, going forward with the ActiveState platform, around open-source language automation, we feel the partnerships that are really important, it is right now looking at the whole landscape around CICD, around what GitHub and GitLab are doing, and what the cloud providers are doing, specifically AWS, Microsoft Azure and Google with Google Cloud platform, as well as we watch IBM Cloud, it’s kind of the number four cloud player.
Those are the three key partnerships. We’re looking at other areas that we are concentrating aggressively. I would say there’s another area, fourth area of a bunch of miscellaneous groups that we feel are important. For example, we feel it’s very important to play well in the whole RedHat ecosystem.
Another ecosystem we feel it’s important to play well is in the VMware ecosystem. Another very important area, which is more around standardization, is the Docker ecosystem, or the containerization ecosystem, to make it very easy to consume our distributions as containers.
Michael Schwartz: You mentioned a few tiers of product – would you consider ActiveState distribution to be open core?
Bart Copeland: Absolutely, yes. If you look at what comes off of the platform, the ActiveState platform is all about building your language distribution, certifying it, and resolving.
So, when I say building, you decide which packages you want from the open-source ecosystem, you decide which of the language runtime you want to use from the open-source ecosystem. For example, to stick to Python, you want Python 3.7, you want 35 packages from PyPI, you bring that all, and that’s all open source.
We then build it for you, for the operating systems you care about. You have three choices: Windows, Linux and Mac. You build it for the operating systems you want. That then is created as a distribution, the core of the distribution is open core, because it’s relying on all the open-source licenses that exist, and we preserve that.
Once you build the distribution, then, we certify it, we check for any “dependency hell” issues. What I refer to as dependency hell, we check for any security violations, we check for any license issues that you may have decided as a user, there’s certain licenses you don’t want.
The other thing we do is, we resolve any issues that come up automatically in the background. You’ve got this distribution on the ActiveState platform, and the result is, the dependency breaks or there’s a CV threat – we fix that automatically and we alert you.
Where I’m going with this in the spirit of your question, all of that is still open-core. It’s all based on all the open-source ecosystem, but the platform itself is closed-core. That’s the closed proprietary layer on the outside.
Michael Schwartz: Over the years, have you significantly adapted your pricing strategy, or has it been relatively stable? Let’s just talk about the distributions, what you’re still in.
Bart Copeland: The distribution business has been relatively stable. The key thing that’s different is, historically, we’ve been distribution as-a-service. You come to ActiveState, and we provide you a distribution as-a-service. Now, we’ve evolved the business, where it’s, you self-serve with the platform and build your own distribution. It’s a software-as-a-service solution.
The pricing for the most part is the same, but we’re offering a lot more for the same price now under the ActiveState platform.
Michael Schwartz: One of our guests previously made the case that it’s better to sell open-source software that someone else writes because, otherwise, you are funding engineers who are basically not billable – would you agree with that?
Bart Copeland: Yes. But I think you have to find a fine balance. Because, if you are always taking and not giving – that’s not good. From my perspective, you have to have a very fine balance of how you’re dealing with the open-source ecosystems.
Michael Schwartz: There are new programming languages every year, it seems. I’m guessing if you’re a new programmer, you’re not going to start learning Perl or Tcl – has that made these products more valuable, maybe as you face less competition in the tools market?
Bart Copeland: I believe it makes it worth value for two reasons. The first reason is what you mentioned. It is that we have a lot of legacy languages that we support, it is very important to the enterprise. Because, for example, and some of your listeners may laugh at this, is that we support today Perl 5.12.
We have Perl 5.28, but we have enterprises, we have applications and production, and we support 5.12 for them, because it’s easier for them, if we support Perl 5.12, to migrate to 5. 28.
So, in that sense, that’s very valuable to us and valuable to our customers. But at the same time, the same customers are saying, for new applications, for greenfield applications, we need to use the new languages, and can we go to ActiveState to get the new languages.
Our goal eventually, with the ActiveState platform, is to support any language that our customers want to use. We’re not there yet, but that’s the vision for the ActiveState platform.
Michael Schwartz: Which languages do you think you’re maybe in sooner than later?
Michael Schwartz: Can you talk a little bit about your approach to building the team? Does location weigh into the hiring equation, or are you willing to use remote people?
Bart Copeland: That’s a really good question. My philosophy is, we go where the talent is, we don’t force the talent to come to us. So, we are a company about — what is it today — think about it, just under 2/3 are head office in Vancouver. But I think it’s getting closer to 50%. The other 50% are distributed throughout North America.
Our philosophy is, as I said, we go where the talent is. And as a result, especially on the development side, we are hiring developers, wherever the talent is. We have developers spanning four different time zones, from West Coast all the way to Halifax, which is one hour further than the East Coast time.
But we tried to bookend it within those time zones, because we haven’t yet expanded to either the Asian market or the European market, just because of the collaboration. We wanted to be able to collaborate in real time. We use Slack aggressively as an organization.
So, the answer to your question is, we are very open to a distributor organization. We think we’re doing a really good job of managing a distributor organization. There’s a number of things we do to include all of our virtual activators. We call ourselves activators at ActiveState. And we refer to our remote activators as virtual activators or remotes.
Here’s some things we do to make them feel inclusive. We use Slack aggressively. Most of our Slack channels are all public within the company, so everybody can see what everybody’s doing. There’s freedom to lurk, there’s freedom to participate.
We have regular company meetings once a month, with the entire company, with video on. We also really encourage video meetings all the time. Every morning, all the teams, various teams have daily stand-ups, the agile methodology, all those daily stand-ups are done with video or a video conferencing.
We also try to have all our activators, at least twice a year, come to head office, so we fly everybody in. We have them all together, so they can build relationships and cross-pollinate.
Also, many tech companies have a lot of nice fringe benefits, like free drinks, free food, we bring in a warm lunch every Friday, we call it “free-lunch Friday”. Unfortunately, our remote activators don’t have access to that, so what we do is, we send them a food package once a month with Amazon Prime — and I’m not sure exactly how we do it, I’m not involved with it myself — but we actually ask them what they would like and we arrange it in an Amazon Prime, and we deliver it to their homes.
And the other thing we do is, various members of the remote team fly up on a regular basis to interact with the head office as well. These are some of the things we do to promote inclusive environment, and also needs to grow. Because it’s very hard, given the type of work they are doing, to find all that talent in Vancouver – I would say it’s impossible. It’s not very hard – it’s impossible.
Michael Schwartz: As a sort of Python hacker myself over the years, I’ve been on the ActiveState site a number of times, looking at code examples – how do you choose which efforts to invest in? And how do you invest, I guess the R&D or community work that you do – how do you prioritize it?
Bart Copeland: It’s a really good question. I don’t have a good answer for you on that. At the end of the day, we have to find a balance between investing in developers and solutions for developers and meeting their needs, and balance that with ultimately the enterprise, because they long-term pay the bills. And we need a healthy balance there.
One of the things I should touch on, Mike, is that, if you look at ActiveState through its entire 20-year journey, there’s something common through that 20-year journey. And that commonality is as follows: every single product has been based on open source. Every single product has been built and designed with the developer in mind.
And every single product has been built with a developer and the enterprise in mind. If they take the intersection of those three, that’s our sweet spot, that’s where we make money. We’re constantly trying to find the balance because we are a company that’s growing organically.
We don’t have outside money, we have to rely on our hard work and creating a happy balance between developers, who don’t want to pay for things, which we’re fine with, but finding and giving them those solutions that they’re free to use, and then find that happy balance with developers and the enterprise who are prepared to pay for what we offer.
Michael Schwartz: So, you’re 20 years in, which is not something a lot of tech companies can say – how far do you look ahead to the future? Are you looking 20 years out?
Bart Copeland: I look in three to five-year timeframes. Because if you look at ActiveState history, under ActiveState 1.0, we were focused on Perl, the high-rapid growth of Perl, and with the anti-spam problem under ActiveState 2.0, again we were focused on language distributions, and we were focused on the whole cloud computing space, and specifically for us, platform-as-a-service.
Now, we’re focused on open-source language automation and helping make software really work well for developers in the next three to five years.
Because tech moves so fast, the industry is so vibrant and so exciting. And I often say to younger developers, younger people getting into tech – because I’ve been it now for 30 years– I say, “We are still in the early innings. We’re like an inning 2.”
If somebody said to me this is a 100-year cycle we’re in right now in tech, and we’re still in it 20 years or so, we got a lot to do. It’s just starting to get exciting. I’m kind of looking here, I’m at the
the latter part of my career, and I’m looking at my two young sons, who are just starting their careers, and I want to do it all over again.
Because I think it’s going to get even more exciting. But the point I’m trying to make here, Mike, it’s very hard to look beyond three to five years in my view. We, right now, are focused on this audacious goal of building a platform for open-source runtimes and specifically solving the problem around open-source language automation. That’s our focus, that’s a three to five-year plan. We’re going to deliver on that, and then we’ll regroup again.
Michael Schwartz: Quick question on governance. As a bootstrap company, do you have a board of directors? What does governance look like in a bootstrapped company?
Bart Copeland: Bootstrap company, by definition, that means we’re a private company. So, the company is owned by its employees and some key shareholders. And I believe in good corporate governance, and there is a board. The board is comprised of some of the key shareholders – it’s a very small board.
I think it’s important, as a CEO, that you get external advice, so in addition to having a board, because that’s one form of advice, I have a group of advisers that advise me as well and advise my leadership team.
And I think that’s very important. I think as a bootstrap company, you shouldn’t do things in isolation. It’s very important that you have individuals that are not in the trees with you, and they can constantly spot and say, “Hey Bart, have you considered this, or what about that?”
There’s four of us on the board. And then, I have three other advisers, who are not part of the board, but advise me one-on-one.
Michael Schwartz: Last question. Any advice for new entrepreneurs, who are launching a business around an open-source software project?
Bart Copeland: Oh, that’s a good question, Mike. I think there’s a general advice, and then there is advice specific to open source. The general advice that I give — and I do a lot of Angel Investing with young entrepreneurs, and invest in small promising individuals and companies — the advice I give is, persistence, and perseverance and focus.
If you believe in something, stay at it. Don’t lose your focus. That doesn’t mean you shouldn’t pivot, but if you look at people who are successful – it’s about perseverance and persistence. That’s the general advice.
As far as open source is concerned, I think my advice is, I love open source. It IS the future. When I first started an open source, people were saying, “This crazy. Why are you doing open source? There’s no future in it.” Now, open source has one. There’s so much power in collaboration in open source.
My advice is, if you are not using open source, then there’s something wrong with your company. You should BE using open source. It’s the way to go. It is the de-facto standard to build a great organization.
Michael Schwartz: Bart, that was fantastic. Thank you so much for joining us today.
Bart Copeland: Thank you, Mike, it’s been great.
Michael Schwartz: Thanks to Bart and the ActiveState team for making this interview happen. Thank you, thank you to the Open Core Summit team for giving us a table at the event to promote the podcast, and for giving up their sponsorship room a few times, which was the quietest place we could find to record.
Please, support the event. We need more events like this to grow the industry and to share our experiences in person.
Transcription and episode audio can be found on opensourceunderdogs.com.
Music from Broke For Free and Chris Zabriskie.
Audio editing by Ines Cetenji.
Production assistance and transcription by Natalie Lowe. Operational support from William Lowe.
Have comments? Tweet at us. Our Twitter handle is @fosspodcast.
Please subscribe to the podcast and add it to your favorites on your podcast app. That helps us get the word out.
Next week, we have Ben Golub from Storj, who will take us through the first open-source, blockchain business model.
Until then, thanks for listening.
Loris Degioanni is the Founder and CTO of Sysdig, a platform for cloud-native visibility and security for workload production. In this episode, Loris discusses how his past entrepreneurial experiences have helped shape a successful business at Sysdig.
Michael Schwartz: Hello and welcome to Open Source Underdogs. I’m your host Mike Schwartz, and this is episode 35 with Loris Degioanni, Co-Founder and CTO of Sysdig.
For you, older geeks out there, Loris is a legendary technologist who is one of the authors of Wireshark, a tool, which used correctly, could seem like black magic to layman. So, hearing the voice behind Wireshark is probably reason enough to listen to this episode.
Sysdig has raised over $120M on revenues of $30M, employees around 200 people, so to say that they’ve been successful for a company founded about six years ago is an understatement.
Loris has some unique metaphorical advice for entrepreneurs at the end of this interview, so make sure you hang in there. Enough of my blabbering – let’s get on with it.
Loris, thank you so much for joining the podcast today.
Loris Degioanni: Thank you for having me.
Michael Schwartz: What was it about Cloud Native infrastructure that gave you the idea for Sysdig?
Loris Degioanni: This is actually sort of a long story. Cloud Native infrastructure is, in my view and in terms of the rationale and motivation to Sysdig, just an inflection, one of the many inflections and radical changes in computer architectures.
We’ve seen several of them in the last couple of decades, the switch from physical servers to virtual machines, the generated arrays of VMware and similar companies, the evolution of virtualization into public Cloud, like Amazon AWS and so on, and most recently, the birth of containerization and modern application orchestrators like, for example, Kubernetes, created by Google.
Each of these big radical changes in the ecosystem typically require to reinvent the functionality that was available before, because the whole ecosystem needs essentially to update to the new paradigm. That’s essentially what I’ve done when I started Sysdig.
I essentially reapplied my previous experience in open-source and commercial products, and I just tried to make something that would be perfectly suited for the new world of cloud computing and Kubernetes.
To give you a little bit more context essentially, I come from a background, I’ve done computer networks and network packet capture for the first 10 years of my career, started in 2000. In particular, my first company was called CACE Technologies, and was behind an open-source packet network analyzer called Wireshark that essentially reshaped the industry of being able to essentially capture network traffic and look into networks.
That company was acquired in 2010 by a bigger company called Riverbed. When I was at Riverbed, I became the CTO of one of their business units, and I was in charge of the product roadmap for the business unit that was doing visibility and performance management for networks and applications by using essentially network packets and so on.
I realized that despite the business going very well, the world was changing, and so, I tried to essentially reapply what I did in open source and commercial, in the previous generation to the new world of Cloud Native and Cloud Computing. That was the summary of the basic reasons why I started Sysdig.
Michael Schwartz: When you started Sysdig, did you start by writing some tools? And I’m wondering if a community coalesced around those tools from the beginning.
Loris Degioanni: Yes. And again, I’m going back, and I will do it probably multiple times during this podcast, to my previous experience with Wireshark, with network packets, because there are several parallels.
When I started my first company, essentially we already had Wireshark, and even before that, a network packet capture for Windows as strong established open-source projects.
That allowed us, me and my co-founders to bootstrap a business in a way that was very efficient, with minimal cost, and allowed us to create a brand and reach a pretty substantial market by just essentially having a very strong and very visible open-source property that was very relevant for our class of buyers.
In that first experience, first myself, and other people in that community that then started the business with me, operated the open-source tool and worked with the community for many years before we started a business.
When I started Sysdig, my second company, I definitely tried to leverage as much as possible the learnings, and in particular, I already knew how effective an open-source tool, adopted by the broader community, would be to bootstrap an enterprise and infrastructure company.
When I started Sysdig, I was in a different situation because I didn’t have an established open-source property, but I decided essentially to create one, to leverage its properties to successively create a business.
First, you need to make something useful. And you need that to be useful enough that people at least want to install it, try it, use it, maybe use it in production. And that both is validation for your idea and also as your initial source of marketing, visibility, lead generation and so on.
What I did with Sysdig was, essentially the basic idea was like what I was doing before with packets was going to be irrelevant because packets as a data source are not accessible anymore when you have, for example, virtual machines instances that are running on Amazon AWS.
You just have machines that are floating on somebody else’s network or infrastructure. You don’t really have access to the router for example to extract these packets to get inside.
Similarly, when you are running containerized infrastructures, based on Docker or Kubernetes, you have these many, many little elements that are pretty opaque, and you cannot really see what they’re doing from the network point of view.
I created a technology that would allow people to gain these insights again, by essentially sitting in the operating system, like for example Linux, and collecting signals, like system calls from this operating system.
Long story short, I sort of came up with a technology that would work again and reestablish that kind of visibility. By doing that, I stumbled into something that would have quite a bit of value for the community.
I decided to release this technology initially as open source, to create essentially a tool that would gather a community around it.
This was in 2014/15, so the very first release that we did of Sysdig was bringing these technology as open source to the community. And to the point Sysdig was born, and to the point the community noticed us, and to the point we started having people talking about us, we started having people installing our tools, and that was how Sysdig was bootstrapped.
Michael Schwartz: I see. So, Sysdig, the company, actually predated the first release of the software?
Loris Degioanni: That’s correct. Sysdig was incorporated a few months before the very first release of the software. Then, of course, the company created a bunch of commercial tools on top of the Sysdig technology. But the timeline was, company started, open-source Sysdig released, and then, commercial products came like two years later.
Michael Schwartz: Sysdig has several product offerings delivered both as software and as-a-service. Today, what are the most important products from a revenue perspective, and which products do you think have the greatest growth potential for the future?
Loris Degioanni: I was saying before I’m going back again to the analogy of network packets, and if you look at network packets, they are a very rich and powerful data source, on top of which you can build many different things.
On top of network packets, you can build a router, a firewall, an intrusion detection system, a forensics tool, performance management tool, visibility monitoring. It is just because packets are data source that is a very horizontal, very rich in content, and typically pretty straightforward and lightweight to collect.
As I was saying before, with Sysdig, the original technological advancement that we did was inventing the new data source that would be similar to packets in terms of properties for Cloud Native in the next generation, which means that similarly to packets with these data source, you can create several classes of tools.
Sysdig in particular has multiple open-source solutions and multiple commercial solutions built on top of them. In particular, from the open-source point of view, we have Sysdig, which gave the name to the company, which is a command line open-source tool that is comparable to like TCPdump or Wireshark, but for modern cloud-based Kubernetes-based infrastructures.
Then we have a tool called Falco, which is a rule-based intrusion detection and runtime protection tool, which I often compare to open-source tools like Snort, or Suricata, but for modern Kubernetes environments.
Falco and Sysdig are completely open-source and are completely community-oriented. On top of them, we’ve built two commercial products. One is called Sysdig Monitor, and it’s for visibility, performance management, alerting, dashboarding, and so on.
The other one is called Sysdig Secure. Sysdig Secure is a bunch of functionality to essentially protect modern workloads that are based on Kubernetes, including forensics, including runtime detection and protection, including vulnerability management and image scanning, and many other things.
Michael Schwartz: Do you bundle those two together, or do you sell them individually?
Loris Degioanni: We bundle them together. Of course, you can buy them individually, but the majority of our customers buys them together.
Michael Schwartz: With regard to cloud, or as-a-service delivered vs. software delivered – which one is more important to you?
Loris Degioanni: I would say equally. As-a-service is the future, is our preferred way to deliver our product to our users. At the same time, Sysdig has many enterprise customers.
Actually, we mostly serve as target customer demographic enterprises, like financial, healthcare, media, and so on. As you can imagine, the SaaS model is something that everybody aspires to follow in terms of vendors, but some of these customers are still not ready for that.
As you can imagine, a substantial portion of Sysdig’s biggest customers’ demands from us software that they can install in their data centers.
Michael Schwartz: The commercial tools – are they commercially licensed, or is it just a commercial’s binary?
Loris Degioanni: These are commercially licensed. Essentially the model that Sysdig is following is our core technology, and some of our core pieces of functionality are open source.
I was mentioning Sysdig and Falco before. Those are part of our commercial offering, but at the same time, the commercial offering, instead of just being like licensing and support for our open-source tools, tries more to create bundles that include some of our open-source technology and orchestrate it to work essentially at large scales, and complements it with some proprietary functionality that we’ve built on top of that, which includes both pieces of functionality that are missing in the open-source offering, and workflows and user interfaces on top of everything.
Michael Schwartz: Would you say it’s an open-core business model?
Loris Degioanni: I would say Sysdig is a unique open-core model. It is open core, but, for example, I do not compare it to — I have no idea – your typical MongoDB. There’s open-source core is more like a relatively small piece of a broader offering, rather than just the core of what we do. This is by design, by the way.
I always found it a little bit challenging to just commercialize what we’ve built in open source because you tend to pretty quickly fall into the dynamic, by which you’re always thinking about every new feature that you build.
Should I open-source it, or should I “make money” out of it. And I typically don’t like to be in the situation. I like to have the freedom, to have this choice to take every time. I prefer to build stuff where there’s a more clear demarcation between what’s open-source and what’s commercial.
They work more like together in symbiosis, rather than being an extension of the other one, and you have more space to evolve two sides in a less, let’s say, stressful way.
Michael Schwartz: Yes. Would you say then that it’s more tools, where certain tools are open-source and certain tools are commercial – and that’s how you draw the line?
Loris Degioanni: Yes. Tools and also use cases based on these tools.
Michael Schwartz: One of the things I have recently observed is Cloudera, the database company, and also Chef, have gone to a model, where they say everything is 100% open source.
Has this changed your thinking at all about maybe whether to open-source or not certain components?
Loris Degioanni: Partially, from one point of view, there’s the dynamic that you’re describing, which I’ve definitely noticed.
On the opposite side, there’s some other companies struggling a bit to decide exactly what their posture should be, in particular with regards to cloud providers like AWS, taking maybe their software and packaging it for the users.
Elastic was one of the most recent examples of that. I think that there’s no perfect mix, there’s no perfect approach. I think that every product is different, every ecosystem is different, every company is different.
Again, from our point of view, more than looking at what other companies are doing, which we definitely do and we take it into account, we try to do our best to find out what’s best for our users first, and then, what allows us essentially to grow our business.
Michael Schwartz: Do you think that open-sourcing of the some of the software has materially benefited the company?
Loris Degioanni: Absolutely. Has and still is material benefit in the company. One example that I can bring is, I mentioned Falco, as one of our core open-source initiatives. We’re putting quite a bit of focus around it because, as I was telling you, there’s an exploding ecosystem, the Kubernetes one, which is more and more shaping to become the operating system for the cloud.
So, the platform on which everybody will build their applications in the future. One thing that is interesting is that Kubernetes is really gaining a lot of traction, and nowadays is essentially been adopted by all of the major product vendors, because it was an open effort.
It was designed to be this kind of lingua franca, completely community-oriented, completely open-source to build your modern applications.
We at Sysdig strongly believe there’s the strength of Kubernetes, and every single component and piece of functionality in Kubernetes eventually will be community-oriented and will be open source.
That’s why we did something that is not super common in the security industry. We started open source first. Security industry, compared to other industries, is still quite a bit more protective and a little bit more proprietary in its approach.
But in Sysdig, we just decided, “Okay, first would be the tool.” It will be Falco. We try to make it part of the ecosystem, we try to make it part of the Cloud Native computing foundation, and we do our best to make it part of the stack.
This is, of course, with the goal of providing value and functionality and security for the broader community, and there is something that can be like a standard, a part of the stack in the future. But, of course, doing that also made us very quickly one of the key players in Kubernetes security as a company.
Despite us giving to our community this important component for free, it’s also helped us essentially grow our revenues in the space. So, yes, this has been very useful for us as a business.
Michael Schwartz: Attaching to this really fast-growing ecosystem and becoming part of the stack had a huge marketing distribution advantage for you.
Loris Degioanni: Yes, and attaching to an ecosystem like this is only possible if you’re truly community-oriented right. That gave us an advantage, compared to our competitors, and is allowing us to grow faster than our competitors in that space.
Michael Schwartz: You made an interesting comment about security not always being open source. I don’t know if you know but my company is in the identity security area, and we’re open source.
I was just reading one of the S-1 of our competitor, Ping Identity, who’s going public, and I did a text search for open source and their S-1, and the only reference I could find to it was a mention of the risks of open source software, and how the use of open-source software might come back to hurt them in the future, and therefore was a risk to investors.
Do you think there’s a disconnect somehow between investors’ perceptions of open source and the reality that you see as a technical professional using open source?
Loris Degioanni: I think that traditionally, for sure, in the investment community at any stage, starting from seed to going public, there’s been skepticism in the investment community.
There’s been skepticism because one of the things that many people say is that open source has generated less winners than expected, and not a lot of these winners have become really, really big. We could argue with it, but I’m just reporting what I’ve heard several times in the investment community.
At the same time, I am seeing more and more investors becoming sophisticated, becoming smarter, understanding what open source means, actually supporting it. I can, for example, make two examples that are extremely close to me.
I have two investors that bet on Sysdig pretty early on, Bain Capital Ventures and Accel, and in particular, my board members, Salil Deshpande, and Ping Li, and Eric Wolford, from these two firms – these are really strong open-source believers that really understand what an ecosystem means, are able to drive it, have a track record of generating successes with open-source companies.
The investors are there, the mindset is changing. I’m seeing, even just recently, multiple funds, these funds being created to focus specifically on open source. I think that the enterprise space, which is the one where Sysdig operates, is particularly ripe for disruption from open source.
I think that despite things not probably being where they should be, they are changing quite fast especially driven by a group of people that are leading the charge. In the future, we’ll see more and more of this, exactly for the reason that you just mentioned.
Open source will become, even more than now, the approach that dominates the software industry, and software is becoming more and more important. So, there’s no escape. The winners will be generated, existing players will be disrupted, and sometimes, it takes a long time, but it always has effects.
Michael Schwartz: What do you think are some of the biggest challenges today for open-source startups?
Loris Degioanni: Since we were just talking about funding, related to that is business model. I think that in some verticals, for example databases, we now understand the open-source model, like the go-to-market model pretty well.
We witness MongoDB, Elastic — there’s many of them, Cloudera — we witness to many success stories that essentially leverage sort of a similar playbook, or at least a variation of two or three playbooks.
I feel that in many of these areas, the go-to-market motion is less established, less proven and still requires a lot of creativity and experimentation from the founders, which also means that at the beginning, the open-source model can be relatively expensive to fund.
From one point of view, you’re focusing on your community, and that takes work, especially when you’re a small team, and takes focus. You have to do that, which means that you’re investing upfront, and you’re spending time and money upfront, have to essentially figure out the approach to market and the business model.
In my opinion, having bootstrapped, two open-source companies – that’s also the most delicate and the toughest part of the journey.
Michael Schwartz: One last question, because you have started two businesses, and I would’ve imagined most people who started one would know the dangers and emotional roller-coaster of that journey and not want to do it again, but do you have any advice for entrepreneurs that people going through that process of starting a business and not only starting a business but starting using open source?
Loris Degioanni: I wish I was able to say something magic that teaches people how to do this. I think that the only thing that I learned about, especially about the very, very early stages of a company is don’t give up, it’s really inch by inch.
Celebrate every little small success because that’s how you survive. You will get a thousand punches for every little success that you have. You need to cling to those because it is really a game of inches. It’s just the way it is.
And number two is, jump in the pool on the deep end, in the pool with sharks, and this is the best way to find out if you can swim or not.
I think if there’s something that makes me different from other people that maybe have not started company or have not been successful, that is, I just do it to survive. And yeah, we’ve seen what happens with Sysdig because it’s still relatively early in the life of the company.
But at the same time, Sysdig has over 200 people now. So, it’s a pretty decent-sized organization, and I still try to learn how to swim even at this stage.
Michael Schwartz: Thank you so much, Loris, for sharing some of your thoughts today.
Loris Degioanni: Thank you very much for having me. It was fun and pleasure.
Michael Schwartz: Thanks for the Sysdig team for helping to organize and promote this podcast.
Transcription and episode audio can be found on opensourceunderdogs.com.
Music from Broke For Free and Chris Zabriskie.
Audio editing by Ines Cetenji.
Production assistance and transcription by Natalie Lowe.
Operational support from William Lowe.
Have comments? Tweet at us. The Twitter handle is @fosspodcast.
iTunes listeners, send us here five stars, and please subscribe to the podcast – that really helps us get the word out.
Next week, we have Bart Copeland from ActiveState, another legendary company in the open-source ecosystem. Don’t miss it!
Until then, thanks for listening.
In this special rebroadcast episode, we revisit the conversation held by Adam Stacoviak, host of The Changelog, the renowned podcast for developers, and Donald Fischer, Co-founder and CEO of Tidelift. Tidelift offers subscription-based support and maintenance for open source dependency applications, powered by the project’s maintainers themselves. In this episode, Adam and Donald discuss Tidelift’s mission to elevate open source software by supporting both the users and maintainers of open source projects.
Michael Schwartz: Hello, and welcome to Open Source Underdogs. I am your host, Mike Schwartz, and this is episode 34, featuring an interview with Tidelift Founder and CEO, Donald Fischer.
Tidelift’s mission is to pay the maintainers of open source software, including the developers who maintain libraries buried deep in the stack.
They have a brilliant and simple way how to do it. This is a really special episode of Underdogs because we’ve been given the opportunity to rebroadcast one of the best open source podcast teams out there.
If you don’t know The Changelog, it’s an epic podcast with currently more than 350 episodes. The hosts are Adam Stacoviak and Jerod Santo.
I’d run into Jerod at the Open Core Summit this past September. This episode is Changelog #324, which itself is a rebroadcast of the related broadcast Founders Talk, which features in-depth, one-on-one conversations with founders, CEOs, and makers.
Founders Talk is hosted just by Adam. He asks all the questions that I would have asked and adds more.
A big thank you to Jerod and Adam for sharing this interview ad-free. Thanks a lot, guys. Without further ado, here we go.
Adam Stacoviak: What’s it like to be on a mission of making open source software better, for everyone? Donald Fischer is one of four co-founders and the CEO of Tidelift. Their mission – to pay the maintainers; to pay the maintainers of open source software and provide a new spin on the highly successful business model that’s a win/win for the maintainers, as well as the software teams using the software… So I asked Donald what’s it like to be on this mission.
Donald Fischer: It’s amazing, actually, to be on that mission… And it sort of naturally is an outgrowth of everything I’ve been working on for the last 15 going on 20 years, actually. I’ve built my career in and around open source, in a couple of different ways, and so when we saw this opportunity to sort of contribute something new to the equation with Tidelift, we decided we had to go for it, because we saw the opportunity to create a new win/win scenario for all kinds of different stakeholders in and around open source.
Adam Stacoviak: I wanna go back into your past and figure out what got you here. What makes you and the rest of the team at Tidelift the team that can make this happen? Help me understand more about you and Tidelift and what you’re doing.
Donald Fischer: We’re building a methodology with software, and a set of practices to help professional software teams make better use of open source software, and the way that we do that is by helping to address a bunch of pragmatic concerns that professional software teams have with the software that they use.
That’s in areas like security, licensing and legal issues, just everyday ongoing maintenance… And the way that we address those problems is really what’s new with Tidelift. We do it by partnering with the individual open source maintainers and teams of maintainers who work on open source projects, and we kind of ask them to provide these professional-grade assurances for their individual open source projects or components.
Then what Tidelift does is we basically join those together and we represent them to these professional software teams as a whole product. In so doing, we essentially address two different challenges. One is that professional software teams – they need support, they need maintenance for the software that they use, whether it’s open source or not. And on the other side, it creates this economic opportunity for open source maintainers to do something that’s very closely related to the ongoing development of their software, and something that they’re best equipped and best situated in the world to do, but now for the first time for many of them, they can do that in a context where there’s an income associated with it, and an income that scales.
Adam Stacoviak: To kind of give some – maybe I’m speaking for you in some sense, so help me course-correct what I’m saying and make sure it’s accurate, is you did a lot of interesting things with Red Hat, there’s a lot of things you and some of your team members have learned from the experiences of Red Hat, and obviously, Red Hat is one of the most successful with supporting paid versions of open source, and support, and things like that.
Are you bringing a lot of what you’re doing now from your experiences with that? Is that safe to say?
Donald Fischer: Yeah, definitely.
I had the privilege of being part of the early development of Enterprise Linux at Red Hat, and all my co-founders also had tours of Red Hat around the same time; we all knew each other back then and worked together and stayed in touch since then.
But honestly, what we’re doing now is also informed by an awful lot of other experiences, in other open source communities and commercial ventures around open source communities; it’s not just a Red Hat copycat, it’s actually – if you want to put it in reference to Red Hat, it’s almost a generalization or an evolution of the Red Hat business model.
Adam Stacoviak: Yeah, where like their focus was one single open source project and one right way to scale it, to enterprises, and support, and all the things that everyone’s aware that Red Hat does – you’re doing it at scale across open source.
How do you make the decisions then to choose which projects to work with?
Donald Fischer: Ultimately, remember that the way that we frame our solution is that we’re solving real-world problems for professional software development teams who are already building with open source components, but don’t have the kinds of safety net assurances that they would expect traditionally from enterprise software vendors.
So to your question of how do we choose which open source projects and maintainers to engage with, actually our subscribers choose; the customers of the Tidelift platform – they essentially direct us towards the maintainers who are best suited to participate in Tidelift. There’s a mechanism for doing that whereby we’ve built a software platform that attaches to the software development process at our customers, it sort of integrates with their code collaboration platform, sort of in a similar way to how a continuous integration system would connect, and we look at the open source components that our subscribers are using in their projects, in their applications, and then we go and recruit the open source maintainers of those projects to provide professional assurances around them.
So we just kind of follow where our customers are voting with their feet, so to speak.
Adam Stacoviak: And potentially their money too, since it’s a subscription.
The word alone elicits that there’s some sort of recurring payment into some sort of system that’s monthly, yearly, biannually, or whatever that might be; some sort of commitment on the long-term (or some sort of term) that says “We wanna use enterprise-level type software that’s open source, that includes support, includes SLAs (or whatever they may be needing) on a certain duration” and their vote is essentially participating in that subscription, but then saying “Hey, this is the software we’re using.
Can you go out and establish these relationships with those maintainers?” Is that how it works?
Donald Fischer: Yeah, exactly. So in other words, a customer of ours will subscribe to Tidelift for one of the applications that they’re building, connect to our software, connect to our software infrastructure. Now we have a lens into what are the actual open source components that they’re using…
Adam Stacoviak: Dependencies.
Donald Fischer: Yeah, I was about to say, not just the top-level components, but we look at the transitive dependencies as well, all of the packages that those depend on…
Adam Stacoviak: The entire tree.
Donald Fischer: Yeah, we build the tree.
And then the way that we’ve packaged it is we charge the subscriber a fixed cost for all of the packages in the Tidelift subscription. It’s sort of like a Netflix subscription in that way, where Netflix might not have every movie that you want to watch, but if it has a lot of the kinds of movies that you like, it’s gonna be interesting for you to be a subscriber; there’s always more movies joining the catalog.
So we sort of simplify it by charging one blanket subscription price, and then we bill the subscribers on a monthly basis for that. Then at the end of the month we take each subscriber’s payments for that month and we split them up and allocate them specifically to the participating maintainers of the packages that they use.
So a subscriber’s dollars only ever get directed to the participating maintainers for the actual packages that that subscriber is using, and that’s one of the ways that we align the interests up and down the system.
And if there’s not a participating maintainer for a particular package that the subscriber is using, we sort of note and increase the potential payment that would be available for a new maintainer who showed up and agreed to participate in the Tidelift system. So we sort of create an incentive for somebody to – we signal the funded incentive for somebody to come along and take us up on following through on those maintenance tasks around that particular package.
Adam Stacoviak: So if I’m a maintainer and I’m participating in this, my “income” or “revenue” generated from this style of funding for my project or my teams – is that number coming from Tidelift, does it ebb and flow then because of that? Or is there some sort of barrier or predictability they can have into how they can begin to step away for their full time job or do this full time, or whatever it might be? How do they understand the income that’s possible, and even not just possible, but on a day-to-day or month-to-month basis, how does it ebb and flow?
Donald Fischer: This is actually one of the fundamental reasons why we started the company, and one of the fundamental contributions that we wanna make – it’s really hard to dedicate your efforts on an ongoing basis to an open source project if you’re not sure what you’re gonna be paid tomorrow, or especially if your income is swinging erratically in terms of what you’re receiving related to your open source project. So our goal, in other words, is to make it a lot more predictable month-to-month.
It doesn’t mean that your income could never ever go down in the Tidelift system; as I said, we pay the maintainers based on subscribers using their software, so if all of a sudden none of our subscribers are using that software anymore, the amount could go down. But in reality, once software is in place, it tends not to go anywhere; just new software gets added.
On the other hand, we’re growing quickly, the audience of participating subscribers, so the total dollars in and the number of potential teams that might be using your project for any given maintainer is increasing. We think that what will practically happen as a result of this model is that open source maintainers will see much greater predictability and have sort of a steadier income to depend on, which is in contrast to some of the other existing models for funding open source projects that might be more episodic if they’re based on grant funding, or sort of bounty kind of mechanisms.
Actually, I think all of those systems are great, and anything that is funding open source is laudable and awesome, but we just saw an interesting opportunity to contribute another model that’s additive and incremental on top of those.
Adam Stacoviak: I wanna rewind a little bit back to the dependency tree that you mentioned, just for those listening who may not be intimately familiar with how software works, which leads into one of your acquisitions, and you can speak to that if you’d like to. But it just kind of helps to get a lens into the dependencies of dependencies; so when you have an open source project or just a project in general and you’ve got an application you’re building, when you use Vue, for example, on the front-end, well Vue has so many layers of dependencies beneath it that whenever you, as you mentioned, come into the platform, you’re scanning their dependencies, and it probably points out some opportunities to grow as you’ve mentioned you are.
But I kind of wanna just touch on that a little bit, because not everybody listening to this is that familiar with the software process and what dependency trees actually are, how deep they might go as dependencies of dependencies; Vue has tons of different things it relies upon, and all those things tend to be other open source projects that are probably not receiving funding or really have any sustainable model behind it, aside from maybe side work. Which is fine, that’s open source, but we’re looking for ways to make it enterprise-level and enterprise-grade, I’m assuming. Is that right?
Donald Fischer: Yeah, that’s right. The issue of the lack of appreciation or really understanding of how much software exists below the visible water line is really remarkable.
For example, we recently wrote on our blog about look at React – super popular web front-end framework, born at Facebook. If you go through the prescribed Hello World creating a new React application, using the very well-executed Create React App tool, you’ll end up with a sort of Hello World web app based on React, and that thing by default will have 1,103 dependencies as of the last time we that we looked.
But the beauty of open source software is that the vast majority of those are coming from somewhere else, from somebody else. But all of them are getting built into your React application.
So if you’re a professional software team at a large enterprise that has a bunch of goals around security and compliance or needs/requirements, things that you need to comply with, it raises a lot of questions about “Who’s on the hook to support all that stuff, and why would they be on the hook?” To which our answer is the best reason for them to be on the hook, or a great additional reason for them to be on the hook is that they’re getting paid to do the work to make those things true about those open source components. That’s really the meat of what we’re trying to do.
Adam Stacoviak: An example that – I’m not sure if you’re familiar with Nadia or not, but Nadia Eghbal, when we first learned about her was several years back, and we’ve since done a podcast with her called Request For Commits.
Donald Fischer: I’m a long-time fan of Nadia’s and the show. I recommend it to all of your listeners who have not yet explored those paths.
Adam Stacoviak: And it is retired, so when you go listen, just know that, and send us your hate mail; we wanna hear more of it, because we wanna do more around sustainability of open source, but that show just is in a retired state, for its own reasons. But the last episode does tell you why, so if you’re really curious, just listen to the latest episode.
But you know, she’d written about the economics of open source, and the example she used was the rate at which Instagram was able to become a billion-dollar company and then be acquired by Facebook – I don’t mean to keep going back to the Facebook well, it just happens to be that example. But Instagram was built on open source software.
Now, I’m not that intimate with the details of what they’ve given back to open source; I don’t know what Facebook’s involvement is, and they’ve since acquired Instagram, but that was the initial yardstick, at least by Nadia, on like, you know, Instagram was worth – the acquisition was like four billion? One billion? I can’t recall right now. It was like 4 billion dollars from Facebook, so somehow they got to that value and they were built upon open source software.
So going back to your model – we have this economic need of all these dependencies, and they would have never been able to get there building all the technology on their own. They had to lean on open source. So there’s a responsibility there to support the dependencies beneath the tree.
Donald Fischer: Yeah, there’s a couple different ways to look at it, honestly. One lens of looking at it is to say if you’re building on all of this software, you owe it to the creators to allow them to drive some participation in the value that they’re creating. First of all, I agree with that; I think that’s a very reasonable worldview. But it’s hard to get large organizations to open up their checkbooks for things that are purely morally justified.
One of the things that we’re bringing to the table with our model is we’re just inviting professional software teams to act out of their explicit self-interest, and we’re helping open source maintainers create a new service offering that didn’t exist before, that we’re seeing as very appealing to a lot of the professional software teams who are using their software. And again, the specific service that we’re helping put together is a community of maintainers who are proactively committed to maintaining the individual open source packages to a well-defined standard, and then Tidelift’s role in that is to sort of be the intermediating agent that helps all of those individual open source maintainers and teams connect to a particular professional software team in an organization.
We’re not asking people to buy a Tidelift subscription mainly because it’s a morally correct thing to pay the maintainers; we’re inviting people to buy a subscription because it’s in your best interest to pay the maintainers.
When you pay the maintainers, the software that you’re using is better and more reliable, and we’re adding some business process and technology to the mix that helps you kind of define what is meant by more well-maintained and reliable, and sort of gets everybody on a common, shared mission.
Adam Stacoviak: So you say “professional software teams” – I think I know what you mean when you say that, but put it in laymen’s terms for me and the listeners. What is a professional software team as it relates to what you’re doing with Tidelift?
Donald Fischer: When we say “professional software team”, we’re typically referring to a team building software within an enterprise.
Enterprise is kind of a silly IT word, or entrepreneurship business word; it means a company, and often times like a larger company. Again, I’ve spent the last 20 years in and around open source, so I know one of the beautiful things about open source is that it’s accessible to all different kinds of audiences.
If you’re an indie developer – I mean, I started working with open source, getting involved in open source when I was a student. There’s individual entrepreneurs kind of picking up raw open source and building with it. It’s awesome; it’s part of the beauty of the whole thing.
There’s also big teams inside of mega-corps that are building with open source as well, and those different audiences have different needs in and around the software that they’re using. When I’m doing a side project on the weekend, kind of cobbling together some open source components to sort of scratch my own itch, for sure I do not need an enterprise support contract, I’m not super-focused on intellectual property documentation for this thing that’s only ever gonna live on my laptop and never go anywhere. But when you have a team at a financial services company, or a healthcare company, or an industrial company, and they’re building the core software that powers those businesses, and in 2018 for sure they are building that with open source software, they would love to have some additional guarantees around that software.
So the open source software, by the open source definition, gives them a bunch of capabilities right off the bat for software that’s under an open source license. They can access the source code, they can change it, as long as they adhere with the different requirements for what they need to do if they redistribute it.
But the open source license doesn’t give you somebody who’s on the hook to make sure that security vulnerabilities that arise will be dealt with in a timely way. It doesn’t give you any certification around the licensing of all the components of the software that you find that are connected to that, or that are dependencies of that… And it doesn’t give you any kinds of assurances about what’s gonna happen with the software in the future – is somebody gonna keep caring for it, and taking care of this essentially living organism that the software projects need to be, as the world evolves over time?
Those are the things that we think that professional teams need, that not all open source developers need, but professional teams do need it, and as a result, they’re willing to pay for it. One of the things we’ve done in the Tidelift context is verify that by talking to a lot of those organizations, surveying a bunch of those organizations; we shared the results of a broad survey we did this year that said something like more than 80% of professional software teams were very interested in paying for those kinds of assurances around the open source software that they use.
Adam Stacoviak: Another aspect to the professional software teams I thought you used in this context was describing the teams creating the software, meaning the open source software. Did you use it in that context as well? Like, when you’re identifying who to work with?
Donald Fischer: No. The way that I’ve been using the terminology “professional software team” – I’ve been focusing more on the subscriber side in our terminology, or the consumers of open source software.
I actually think there is a really compelling opportunity on the creative side of open source to also, in a sense, professionalize there. And I wanna be careful about what I mean by that word, professionalize. Open source maintainers, whether they’re paid or not, it is demonstrably true that they create amazing software that is prograde, is used in real-world applications all over the place.
I guess a missing part of the “professional” definition there is that often times they don’t get paid for the work that they do, so it’s hard for it to be a profession for the individual open source maintainer.
So I do think there is a double entendre there, which is “We would love to help open source maintainers make it their profession,” and that’s really one of our ambitions with Tidelift – to enable more open source creators to dedicate more of their time to their open source projects, innovating the features and functionality there, also just like doing the everyday kind of maintaining it tasks. And if we, all of the users of open source, give them the license to do that, and the necessary financial incentives to do that, then we’re gonna benefit, because the software that we all use is gonna be better. It’s awesome.
Adam Stacoviak: The reason why I asked you that question in the opening was I’d heard you use it and I thought that your reference was essentially helping to understand the type of maintainers or type of teams that maintain software describe them. That’s how I thought you were using it in that context, which is why I opened up with that question. Because I wanted to understand more so like when you focus your attention on – I know that a lot of your subscribers are the ones that are leading you to, down the dependency tree which matters to them, because they’re paying for the subscription, and essentially, you said they’re leading with their feet. That it would describe the kind of teams that are good candidates to be a part of this, because they can provide the support, they can provide the other assurances that enterprise teams need to rely on open source.
Like you said, in 2018 it’s pretty difficult to build software today in any real capacity without using open source… So we have to find ways to support it, and I asked you that question to think that maybe you’re describing a type of maintainer, a type of maintaining team, their philosophy, the way they organize, the way they govern, what are healthy balances in there… I thought that’s what you were talking about, that’s why I went that direction.
Donald Fischer: Yeah, so just to comment on one really fun part of what you were touching on there – I think the really happy news here is that teams inside of larger enterprises that have the requirements for security, licensing, maintenance kinds of assurances around the software that they use. It turns out the software projects that they’re picking to build their new applications out of, the software components that they’re taking out of the package managers, they’re the same ones everyone else is using. They’re using the same components at a big bank that I’m using to do my weekend project.
So it’s actually a really nice situation, where if those professional teams are interested in paying for these additional assurances, the creators of those open source projects and technologies can access that income that’s associated with that, it gives them the license to spend more time on the projects that they’re creating, and then the improvements or increases in functionality – that can be shared by everybody, the payers and the non-payers. That’s actually one of the beautiful things about open source.
Adam Stacoviak: That’s why I love your name, Tidelift. That’s the underlying (to keep the puns going) current of what you’re doing here; you enable subscribers to lift the tide of everyone. Like you said, I could be using whatever the library may be that’s part of the Lifter project you have going on, which we’ll dig into more. If I’m paying and they’re getting supported, then I’m just enabling others to benefit from my subscription, and then therefore funding of those maintainers in those projects. I love the name, it’s spot on.
So we spent the better part of maybe 40-ish minutes kind of digging into the context. I wanted to go into more of the getting started, where the idea came from, some of the background even, which is sort of like the crux of what this show is really about. Which I love doing – a deeper explanation of what Tidelift is and what you’re doing there, for the better part of 40 minutes.
Let’s kind of rewind a little bit and just get a picture of some of your personal experiences, and maybe the experiences of other team members. But maybe let’s start off with back in 2017 when this began – from what I understand, you were in venture capital, you stepped away, you had this idea.
I believe this began with a fundraising round; I’m not really sure. Can you go back to those details and help pave the way for how this got started?
Donald Fischer: My personal history briefly is I started out as a programmer, I studied computer science.
As we talked about before, I had a really interesting tour at Red Hat starting in the early 2000’s, and was able to be part of the team, participating in building the Red Hat Enterprise Linux business there, which is really an amazing thing, that is I think often under-appreciated in the IT industry.
Adam Stacoviak: Absolutely.
Donald Fischer: Red Had as a whole is an over three billion dollar recurring revenue business now. It’s really a beautiful and amazing thing, and there’s a lot to be learned…
Adam Stacoviak: Did you say billion?
Donald Fischer: Yeah, three billion dollars a year in revenue.
Adam Stacoviak: Three billion… Just to make you say it twice, because that’s pretty big.
Donald Fischer: Yeah, it’s big.
And you know, it just steadily grows. It was an amazing time when – you know, I did not figure this stuff out myself, by the way, but as a team, and as an organization, we learned a lot of things about what (again) professional software teams that are using open source really need, and that doesn’t just come for free. And we’ve figured out a model that was appropriate for that set of technologies at that time, and it has continued to evolve to support a steady business today.
What I did after Red Hat is I’ve spent almost a decade as an investor, working with early stage founders who were starting and growing businesses around open source communities, and I chose to focus on that theme… Because I’ve personally just always been fascinated and sort of in awe of how open source communities arise. This phenomenon where technology will come from a creator or a small band of creators, and then a crowd of individuals will start to kind of assemble itself around that technology.
You see technologies sort of form these tribes, and when I say tribes, I mean in a good way… Not in a tribalism kind of way, but in a sort of…
Adam Stacoviak: A Seth Godin way.
Donald Fischer: …collective way, yeah. It’s really amazing.
You might join the Python tribe, or the Ruby tribe; or maybe it’s not a programming language, maybe it’s the deep learning tribe, or something like that, right? But it starts to become part of individual people’s personal identity, their professional identity. It’s really a powerful thing, so what’s always fascinated me is if there’s this fundamental energy around technologists sort of assembling themselves in these tribes – there’s so much power to it – and what are the opportunities to add a commercial component there.
The thing that I’ve always really focused on is not just how do you go kind of harvest that energy from the community, which I think is a very pessimistic way to view the world, but can you build a complementary business that sort of amplifies the energy in one of those communities that helps capture more resources to invest more aggressively into developing the technologies, or advocating, evangelizing the technology? How can you build businesses that sort of amplify those communities and make them even more successful, and make the individuals within them more successful?
I think there’s a really fortunate history of startups and businesses of different scale being built over the last 15 years now that do that, and that’s just been a phenomenon that I’ve loved to follow, and sometimes to be part of.
Adam Stacoviak: I think the important thing to draw from this is it seems to me that you’ve spent a lot of your life trying to find ways to support open source, and it’s either helping certain types of businesses build themselves around open source through venture capital and investing, and I’m sure in a lot ways leading product, because that’s also part of the investor’s role, is to be somebody who is an adviser to the direction of the business and the viability.
I think the other important thing you said there was that you’re the support, rather than – I forget the exact language was that you used, but essentially, you’re there to amplify versus to draw and take away from the energy. What was the word you used of how you’re not attaching to the community?
Donald Fischer: I think the language that I used was instead of trying to harvest energy from these communities, it’s like “Can you actually build an engine that contributes net energy back to the community, that helps it grow and become more sustainable, as opposed to sort of drawing energy off of it?”
Those are the really powerful companies, and also I think they help to form really powerful communities.
If you look at the different businesses that have been built around Linux, or different big data technologies, or core systems-level databases and things like that, if you can get a community going that has complementary and additive businesses, that’s a beautiful thing.
And to connect that to the story of Tidelift, I’ve been a student of that phenomenon for a long time now, and I’ve had the great opportunity to work with a number of other folks who are also fascinated by the same kinds of dynamics.
One of the things that annoyed me about the existing models for commercializing open source or building these complementary businesses around open source is that, you know, if you look at something like the venture capital model, where I was personally quite active, there’s only a relatively small number of open source projects or communities or tribes (if you will) that have enough scale to them for the traditional venture capital model to work.
Adam Stacoviak: Yeah.
Donald Fischer: There definitely are some… At this point, there’s several dozen substantial venture capital-backed companies that have been formed, are performing, several have gone public.
It is a model that works, but it only works for a really pretty small subset of open source in general. And one of the really interesting things to me is that it only works for a subset of the commercially relevant open source projects.
So I would often, as a venture capital investor, meet with entrepreneurs, open source creators who had projects, they had lots of real-world professional users – often times the users that they had were asking them for “Hey, can get a support contract for this, or a service-level agreement for it?” and yet they didn’t really fit the venture capital model of going and raising X million dollars and then building a company from scratch with all that that entails; building a sales force, a finance function, a way to handle subscriptions, a level one support team and so on.
So when I started talking to my co-founders, the gentlemen who eventually became my co-founders at Tidelift, we looked at that problem and that opportunity and we said essentially “What if we build that go-to-market mechanism, like the sales and support and finance, back office kind of stuff, what if we just build that once, instead of asking every open source project to do it themselves, and then just let the open source projects and teams plug into it?” Sort of like in the way that creators plug into Etsy.
You know, one of the beautiful things about these marketplace models is if you’re amazing at creating some craft good, you can go to Etsy, and Etsy helps you access an audience of people who are interested in your kind of thing, they handle all the payments, and the logistics, and customer service issues and so on, and you don’t have to go learn how to do all of those things. Etsy is kind of your partner for doing that. You get to focus on conducting your craft. That’s one of the things we’re trying to do with Tidelift – we wanna make it possible for open source teams who are building technologies that are used by these professional organizations to be able to access some of that potential energy and income that can be associated with that, without having to go become salespeople, or customer support people themselves.
We’ll kind of do that with you, in the sense of do that for you, as the open source creator; you plug into our infrastructure and you focus on making the open source project amazing. We’ll help with all the bunch of the business stuff.
Adam Stacoviak: These teams generally would still have to be the ones providing the service-level agreement, right? If I understand correctly, you may institute it and do the business-level side of things to ensure that there are subscribers that have desires to bring on certain lifters or whatever, but it’s still the lifter’s job – which is a term we haven’t defined yet, so maybe it’s a part of your response, to help me understand really what a lifter is, or what that role is there. Because they’re gonna have to eventually support that software, and provide the enterprise-grade stuff that you’re selling as part of the subscription. This whole general sales thing – that’s what the product is, it’s reliable, it’s supported, bug fixes etc.
Donald Fischer: The way that it work is that one of the things that we add to the equation by creating Tidelift is we are an intermediary between the professional teams that are paying for these assurances and the individual open source maintainers.
A couple benefits of that – one is that we turn a many-to-many relationship that would basically be impossible for every open source application development team to strike a business agreement with every one of those 1,100 Npm module maintainers that goes into their web app; we allow them to have one place to go, which is Tidelift, and then we sort of federate all of the participating maintainers behind that.
So we have a relationship with each of the paying subscribers, and then Tidelift also has a relationship with each of the participating maintainers. And what we ask the maintainers to do – it’s actually detailed on our website, for any maintainers who are interested in understanding what we propose in our model…
We ask maintainers to look after their projects according to a certain set of criteria. These are things like work with our security response team if there is a new security issue that arises, sort of make sure that it’s addressed in your particular package, or if there’s an issue in one of your dependencies, make sure that your package is adjusted to take account for that, help us documenting new releases that are happening, any licensing changes – we sort of record all of that. Those are the kinds of things that we ask maintainers to do.
Just to highlight – at least for now, we’re not asking maintainers to fix a bug or add a feature, or provide help desk support for a runtime issue that was encountered by a subscriber. Those things — there are open source business models associated with that; they’re challenging business models, because they scale with the number of hours that an open source maintainer has in their day.
There’s only so many support tickets you can respond to, or so many consulting engagements that you can have. So since that’s already possible in the world, we’re trying to focus on sort of a new model, which is doing things that can be done once where many people benefit from them, like resolving the security issue – you do that once, and all of the users get to benefit from it.
Our part is to create the alignment of interest, so that those things always get done with predictability, and we do ask our participating maintainers (lifters, as we call them) to do those things, and then Tidelift’s role is to make sure that everybody is following through correctly, deal with any kinds of issues that come up.
Adam Stacoviak: You used the term “a well-defined standard” earlier in the call. I am assuming that that means that it’s either written down once, or it’s the way things are, or it’s maybe a case-by-case basis with each lifter or maintaining core team, that they say “Okay, Tidelift, we wanna be a part of this, we wanna be a lifter. Sign us up, we’re ready to go,” and then there’s something in these well-defined standards that says “Hey, this is what you’re committing to.” Is that accurate? Can you describe that?
Donald Fischer: It’s more like a set of open source project best practices that we ask our participating maintainers to follow.
And here’s actually another really great part of how this all works – most open source projects that have a substantial user base are already doing most of these things, or all of these things.
This is things like having a responsible disclosure policy and adhering to a responsible disclosure policy around security incidents, or using two-factor authentication on all of your systems that are involved in the build and distribution chain for an open source module. Sort of like checklists for healthy living as an open source project.
Those are the things that we ask open source maintainers who are participating in our system as lifters to do. And even though many of them are doing most of those things by creating a uniform standard where everybody who is participating in the Tidelift system is doing all of those things, it allows us to represent that this collection of software as a whole meets those standards to our subscribers.
And again, that’s worth a lot to these professional software teams that are building enterprise applications; if we can show them a menu of healthy open source project attributes that we’re ensuring are true for the dependencies that they use, they love it. And it’s a modest cost for them to pay, to ensure that the software that is really powering their business is well cared for.
Adam Stacoviak: Most companies have co-founders. In this case, you have three other co-founders, I believe. What’s the story there? Who are they and how did you all meet?
Donald Fischer: Yeah, this is the best part of Tidelift for me, it’s my co-founders, and then the team that we’ve built to go on this mission together with us, and it is an interesting story.
I have three co-founders – Havoc Pennington, Jeremy Katz and Luis Villa. We’ve all known each other pair-wise for at least 15 years, and a couple of us go back longer than that.
As I mentioned before, we all intersected at Red Hat in the early 2000’s, and then we’ve collaborated on different projects since then… And each of us sort of has a different ingredient that we contribute to the mix.
I talked about my background a little bit; a lot of it is sort of the business side of open source. Havoc, our co-founder, currently is leading Product for us. He is a long-time veteran of the open source world. He was originally one of the founding voices in the GNOME Freedesktop community, the Linux desktop, and co-led the creation of the GNOME Foundation, which continues productively to this day, and implemented a lot of the software himself that powers the GNOME desktop.
I got the chance to work with him first when he was leading the desktop development team at Red Hat. Then Havoc has interestingly gone on to do tours in a couple of other interesting and different open source communities. He was working for a stretch in the Scala community, in sort of the greater Java world, and then most recently was back in the Python data science community before we got together to start Tidelift.
Then the third co-founder is Jeremy Katz. Jeremy is an amazing technologist. I got to know him when he was one of the core developers at Red Hat, then he went on to sort of grow his professional portfolio beyond just open source – he was an early employee at HubSpot, the marketing SaaS company. He led the implementation of this product called Stackdriver, which was a startup that was sold to Google and now serves as essentially the management console for the Google Cloud platform, so really a seminal piece of software in the cloud generation.
And our fourth co-founder, Luis, has (I think) the most unusual story, which is Luis started with the rest of us as a programmer, open source developer, but Luis ended up going to Law School, and then closing that loop by becoming an open source legal expert, really, one of the widely respected voices around legal issues associated with open source.
He did a really interesting stretch working with Mozilla, where he actually led the drafting of the Mozilla Public License 2.0, and then he had a really interesting time at Wikimedia Foundation, the organization behind Wikipedia, dealing with a whole bunch of open content issues there, and sort of leading the community effort there as well.
So it’s a really interesting set of disparate backgrounds and professional experiences, grounded in having all been open developers, software developers, and open source participants in the early years. I guess what we’re trying to do is bring those different experiences back together and apply them back where we all started, trying to make open source work better for everyone, the creators and the users.
Adam Stacoviak: It’s an interesting mix of people. Obviously, you’ve got business, you’ve got — I’m sure everyone was somewhat involved in coding, at least at some point in their life, but taking a role on that, having a role in Google and what powers that, and then legal; the licensing part of open source is, to some, often overlooked, but pivotal to how it could be used.
We see license changes in business; there’s some recent news not long ago with Redis around Commons Clause, or License Zero. All those things have implications. And even React – because you’ve mentioned them earlier, and we even logged that, about who actually supports React.
They had – I’m not sure of the details because I don’t follow this closely, but it had some concerns around the community, the way Facebook licensed React. We’ve even had Heather Meeker on Request for Commits, since you’ve mentioned that earlier, and with Nadia – we had a deep conversation around the importance of licensing.
It sounds to me like you’ve got an ensemble of the right components to do Tidelift… And I don’t know how you did it, but that’s pretty insane that you have. And it’s even more interesting that you all intersect at Red Hat.
Donald Fischer: Yeah. I mean, I just feel so privileged to work with these gentlemen, and then again, the team that we’ve brought aboard to share this mission with us; it’s a lot of fun. But to the point around licensing – the legal code is one of the technologies that makes open source possible.
It is sort of a technology onto itself, and like other technologies, it’s complicated. It’s complicated for the creators to make the right sets of decisions around “Which license should I use? What are the tradeoffs?” and so on. It’s also really complicated on the consumption side, and that’s (again) one of the things that we’re trying to help address for professional teams that want to engage with open source in the right way.
They don’t have the time to each go become an open source legal scholar like Luis did, so we’re gonna try to create some tools and standard ways to approach this, that let them get the advantage of some of that substantial knowledge that Luis has accumulated in his days.
Adam Stacoviak: I’m sure this is the case for most founders or co-founders, but I find it kind of interesting that each of you have a particular milestone in your career, each of you can point to a particular thing you’ve done that is widely notable, to say – not so much that this is why you do what you do or you belong here, or you can trust you, but it’s like you all have some large-scale contribution to the community you’re currently serving through what you’re doing now. And to say “We’re part of the community. We’re not just entering (like you said earlier) and trying to solve a problem, and we’ve never been here before. No, we’ve been boots on the ground for decades, and our resumes and the work we’ve done before” is what you point to to prove it.
Donald Fischer: Yeah. I mean, the only caution there is that every situation is different. One of the things I always try to remind myself is to learn from the past, but not to over-apply models from the past, because sometimes they can be misleading. The world changes.
The world is a lot different now in 2018, in terms of where open source is in the software ecologies in general versus 2002. Back when we were doing the first version of the enterprise Linux business model in 2002, most professional companies looked at Linux and said “This thing looks crazy. What do you mean free software? How could this possibly work?” etc.
Now, fast-forward 15+ years later, there is no proprietary software to buy in most of these categories, right? It’s pretty hard to go find a proprietary application framework to build with these days. It’s almost complete takeover by open source, but our point that we’re trying to highlight with our work in Tidelift is just because open source is everywhere, it doesn’t mean that software doesn’t need to be maintained.
In fact, it sort of heightens the question of “Who is taking care of that software, and why?”
Adam Stacoviak: Right. Who is responsible, yeah.
Donald Fischer: Yeah, and who needs it to happen, and how do we connect the dots?
Adam Stacoviak: Well, let’s close the loop on this idea of sustaining open source, maintaining open source, this phrase that often gets put out there and talked about, and the actual mechanics of what that really means. There’s other models out there, and every model is needed, because you said earlier “Hey, if money is coming in open source – great! Let’s not say one way is wrong or right”, but I wanna kind of go into the differences of other models.
We’ve talked to Pia Mancini on here before around OpenCollective, we’ve talked to Eric Berry around CodeFund, previously CodeSponsor… I haven’t talked to anybody from Patreon before, but we’ve definitely talked to Evan You on Request for Commits and several others. Henry Zhu from Babel on how they’re leveraging their ability to go full time and using those platforms to really good advantages.
But then here comes Tidelift – so what is the biggest difference between Tidelift and other models where they could be seen as like more charity, or somewhat value-based?
Donald Fischer: First of all, just to get on the table – the more, the merrier.
Adam Stacoviak: Right.
Donald Fischer: I’ve said it before, I think every channel to pay the maintainers is additive, and so we’re just trying to add another option into the mix, and probably “the answer” is not one of these, it’s a polyglot solution of multiple of these working in different ways.
I do think that we have a somewhat different approach than a lot of the systems that have been implemented before, and it comes back to just being very practically-minded around not just asking organizations to pay back the maintainers that created software that they’re using because it’s the right thing to do, not only because it’s the right thing to do.
We’re seeking to give them the additional self-serving reason to do it, which is if I pay for a subscription that covers these open source components, I know that there is somebody who is committing to me that they’re gonna care for this software.
And when we say “care for the software,” it’s written down what we mean by it, and if an issue arises, I’m gonna have someone to go to; they’re committed to work with me. So it’s something that they don’t get if they don’t pay, and we think that’s compelling to a certain audience.
And again, we’re more oriented towards these software teams within enterprises. That’s not particularly compelling to most hobbyist developers. They’re not really the audience for Tidelift, at least at this moment. Not the one that we’re targeting, at least. And for hobbyist developers, I think there’s a bunch of other options on the table.
By the way, as a hobbyist developer on the side myself, I happily contribute to a number of different funding mechanisms for the projects that I use. I think it’s great, and I love doing it, and it makes me feel good, and everybody should.
Adam Stacoviak: I definitely echo what you’re saying on “the more, the merrier.” One question I have for you though is like, since you’ve said you’re a listener or this podcast, and you listened to one of the latest episodes with Eric Berry, one thing I can recall him saying in the conversation we had was around this extra layer. So the example we used in that show was Jack Lukic, who was the creator of Semantic UI, which we actually use here at Changelog; it’s the UI framework we use for our back-end.
And the question in the conversation there was essentially like layering on one more thing for a maintainer to do. So Jack may be really great with user interface, maybe really great with the framework, and that’s all he may really wanna do, but he’s hit a stopping point of time invested because of the lack of funding. So in the Tidelift model – and maybe Jack is not the perfect person. Jack may be considered a hobbyist, even though his project is used tremendously, and very vital to so many projects that are using it. But he may not have the time or the desire to wanna do the other things to support or to be in the Tidelift model; how does that fit in?
Donald Fischer: I think if I was to rephrase the question, it’s like “What if the open source maintainer or team isn’t interested in doing the Tidelift-style maintenance?”
Adam Stacoviak: Assurances, yeah.
Donald Fischer: We sort of look at that, again, from the – think about it from the open source user’s perspective. The user is still interested in having somebody look after the security, look after the licensing and the maintenance of this component.
So if the current contributors to that project are not interested in doing that, can we create an incentive for some new contributors to join the project to do that? And one of the patterns that I’ve witnessed being in and around open source communities is when somebody shows up in an open source community and they say “Hey, I’m interested in doing some of the grunt work around here, to sort of help with some of the day-to-day maintenance tasks,” especially if everybody else has already passed on volunteering to do those things, usually they’re accepted with open arms.
So I think that our model can potentially help in those scenarios by giving someone else a nudge to sort of show up and volunteer… It’s not really volunteering, because they get paid to do it.
Adam Stacoviak: They’re getting paid!
Donald Fischer: Yup. “Pay the maintainers” is our mantra.
Adam Stacoviak: I like that tagline a lot. It’s short, it’s three words, it gets to the point. Pay the maintainers.
I like that. And you said “The more, the merrier”, I think that’s what everyone is saying – let’s just find ways to pay the maintainers, so that they keep maintaining, so that they keep innovating, so they keep really just enjoying it. Open source is fun to be involved in.
What makes it not fun is whenever you’re not – not so much not rewarded, but just when you feel depleted at the end of the day because you wake up to 35 new issues, all these different things, and then you’ve got your day job, and your family, and your life.
That’s what drags it down and makes it very difficult to scale, and maybe why earlier you mentioned venture capital. Capital wasn’t a great option for it, just because of the way the market worked. There’s all these different ways, but this is just one of several ways we can pay the maintainers, and I like that mission a lot.
Donald, we’re coming to the close here. I’d like to end with this question. Super-secret – something’s going on at Tidelift that maybe people aren’t aware of; you know, I don’t know. Is it a new announcement, something coming up…?
What’s something that no one knows about that you could share here on the show today? Or even tease, whatever it might be.
Donald Fischer: Yeah, I’ll just mention a little tease.
We’re gonna have some really exciting to us, and I think relevant news coming out in the next couple of weeks, talking about getting to a certain kind of scale milestone on the Tidelift platform. Stay tuned for that.
Stop by Tidelift.com, depending on when you’re listening to the podcast, to learn more about sort of showing the model working at some interesting scale that we think people will find compelling.
Adam Stacoviak: When you say “milestone”, it means the big deal, right? So this is a big deal.
Donald Fischer: It means we’re reaching another waypoint on our journey to demonstrating the Tidelift model working at scale… And paying the maintainers.
Adam Stacoviak: Gotcha. So even if you’re listening to this distant in the future, and this announcement has since passed, we’re gonna update the show notes for what Donald is talking about; we’ll definitely link it up, whatever it might be.
I don’t know where it’s at, but wherever it is on the internet, we’ll link it up, so just go back to your show notes. We’ll make sure we have those up to date.
Donald, anything else in closing? It’s a fun journey that you’ve been on, from your history in open source, all of the different co-founders that have worked with you on this, the mission you have to fund open source, in particular “Pay the maintainers” – I love that.
Anything else you wanna say in closing to the listening audience that may be interested in the journey of open source and what it’s about?
Donald Fischer: First of all, I would just say thank you to you, Adam, and to the Changelog and Founders Talk for covering these topics, because I think you’re a really important voice and you’re shining light on important issues. I guess that would be my parting thought – these issues are important. As a lot of folks now have pointed out – you referenced Nadia did an amazing job shining a light on the importance of open source software…
Adam Stacoviak: Yeah.
Donald Fischer: We have now decided collectively to build our civilization largely out of software, and that software is open source.
So if we want our world to be a great one, we need our software to be great, and that means we need our open source software to be great. I’d just invite everybody who is interested in these topics – learn more about the different models that are being proposed.
I’d love for folks to come and learn more about Tidelift, and talk to us and help us evolve it in the right way, take it the right way; launch additional models. Let’s try a whole bunch of things, and collectively I think we can have a really positive impact on the world.
And thanks a lot for paying attention and putting this in front of an interested audience, Adam.
Adam Stacoviak: Absolutely, man. Thank you so much for saying that. This has been a labor of love for many years, turned business, and we’ve been fortunate in that. And if it weren’t for our listeners and those contribute to open source, and this entire community, we would not be able to exist obviously, because there’d be nothing to talk about.
But we’re just so thrilled that we get to be in this position; we’ve been down a long road, and I’m honored to have 1) you on the show, then 2) you as a listener… And when I mentioned things, even in the breaks, you were like “I’ve already listened to that.” I didn’t know that you were that passionate about – you know, sometimes people say thank you, but you’re an actual listener, who listens to every show, or at least a lot of them. That’s awesome, I love that.
Donald Fischer: Keep up the good work, man.
Adam Stacoviak: Thank you, Donald. It was a pleasure, and I really appreciate it.
Donald Fischer: Thanks for having me on.
Adam Stacoviak: All right. Thanks for tuning in for this week’s episode of Founders Talk. Do me a favor, assuming you’ve got some value from this episode, share with friends, rate this show on iTunes, favorite it on Overcast – this is the best way you can help me and this show, and help others to discover it too.
Find all our shows at changelog.com/podcast.
Subscribe to the master feed changelog.com/master. Get every single show in one feed.
Thank you for tuning in – I’ll see you on the next one.
Peter Mattis is the Co-founder and CTO of Cockroach Labs, the company behind the popular cloud-native, distributed SQL database, CockroachDB. In this episode, Peter discusses their experiences transitioning to a new, less permissive open source license, and how open source startups are evolving business models to maintain competitiveness.
Michael Schwartz: Hello, and welcome to Open Source Underdogs. I’m your host, Mike Schwartz, and this is episode 33, with Peter Mattis, Co-Founder and CTO of Cockroach Labs.
Peter has some hilarious insights into the open source startup world. To me, this episode highlights how open source business models have evolved, how companies who witnessed the proverbial carnage of the last five years are adjusting their license and business models accordingly.
I’m about a month behind schedule right now, this podcast was recorded September 11th, 2019. Peter was in New York City, as you can identify by the frequent sirens in the background.
So, without further ado, here we go. Peter, thank you so much for joining the podcast today.
Peter Mattis: Glad to be here.
Michael Schwartz: Quick technology question, and then we’ll revert to business. In the database space, companies are moving into adjacent markets. So, Redis starts to add persistence, MongoDB starts to add caching – in this kind of market, what’s the sustainable advantage for CockroachDB?
Peter Mattis: It’s an excellent question. What we see as our advantage right now, is we’re a blend. We didn’t move into adjacent markets, but we saw a gap in the market.
There’s NoSQL databases that have been out for a decade and getting a lot of traction because they provide this ease of use and easy horizontal scalability. But we also saw those databases as failing application developers, because they put a lot of burden on the shoulders of application developers due to their lack of transactions, lack of schemas, lack of indexes.
We saw this place in the middle, where we could have a horizontally scalable, distributed SQL database. A niche we’re occupying is to actually make this a geo-distributed database, so we can scale geographically and support global applications.
This is becoming an increasing need in the market, with regulations such as GDPR, but also with the advance of new technologies, people are just adopting faster speeds from the products they use. A user in Singapore wants to access their bank data, and make it feel instant, not make it feel like they’re jumping halfway across the world to get access to their data.
Michael Schwartz: Your new BSL license, or Business Source License, states that the one and only thing you cannot do is offer a commercial version of CockroachDB, as a service, without buying a license. What I’m wondering is, would this actually be a bad thing? Because Elastic and MongoDB haven’t exactly done badly since Amazon offered their software as a service, so, maybe would it even help you?
Peter Mattis: That’s a fantastic question. The thing is, this is, to some degree, a risk mitigation.
Elastic and MongoDB, I think if they had the choice, they would go back and put a license like this in place. Especially in the case for Elastic, they’re too far upon to go back, and they can’t retroactively apply that license to the source code like that.
That threat from the Amazon’s and Google’s is real. They sure wish they could have taken business maneuvers three years ago. We’re not facing this threat this year, we probably won’t face the threat from the major cloud providers next year. But it’s two years down the line, by the time we get there, the opportunities, the moves we can make are much more limited.
We had significant internal debates about this, and this is a way to just kind of de-risk some of those eventualities. I feel that BSL has come out of this nice balance. Three years down the road, our current release of CockroachDB will be active and fully open source. But then, we’ll have another three years of time to have further improved it.
We actually kind of see that combining our incentives with the incentives that users and open source users, purely closed source software maybe never has a time frame where it’s going to become open, even when it’s reached end-of-life for the company.
Our software will have that time frame. Every three years, on a rolling basis, it will become an open source. And this is our means of protecting against eventualities that could seriously harm or completely destroy companies viability.
Michael Schwartz: Was Michael Howard and MariaDB influential in coming to that conclusion?
Peter Mattis: MariaDB certainly was. We were looking out at ways that we could protect against the stripmining that’s taking place of open source, where company like Amazon can come in and take what has been developed by another entity, and just extract all the value from it, by providing it as a service.
Don’t get me wrong, what Amazon is doing, from the amount of work and the services there, can oftentimes not be flowing back to the original developer or developers, or open source companies. This is a huge existential risk, and for open source developers, independent ones, this is just kind of like supreme irritation, “Hey, I developed this work to make this awesome, beautiful bit of open source, and someone else is actually getting all this value from it.” That kind of sucks.
We were looking around for ways to protect against that. We considered a number of alternatives, we considered closed sourcing more of the product, we never wanted to do that. We considered not doing anything, we just continued with business as usual and tried to fend off the Amazon’s or Google’s, and that also felt insufficient.
Like I said earlier, the BSL felt like a nice balance between the two, and gives us a pretty strong measure of protection, but it doesn’t completely close off the source.
Michael Schwartz: So, it’s pretty hard to write a database?
Peter Mattis: Very hard.
Michael Schwartz: Is the community materially adding value to the product?
Peter Mattis: I would say yes and no. I mean, databases – it’s yes, in a sense we get a lot of feedback from the community about the things they need to the things they want to use.
There’s modest actual code contributions from the community, not huge code contributions. The database is a complex piece of software, and there’s no way around that. You need to have kind of main specific expertise, and even within Cockroach Labs, the company behind CockroachDB, there’s main specific expertise within various teams.
People working on the SQL optimizer have expertise about doing the SQL optimizations; versus people working on a web UI frontend, need specific knowledge about observability patterns; versus people working on a transactional layer that need to know about distributed transactions and protocols like Raft.
What we see is, it’s not a very approachable product for a random person to come online and make contributions. That said, we have had contributions, people who have been able to do stuff, both at the edges and kind of deep within the product. Over time, I expect to see that increase. Especially, as the company grows, we have more energies to support those efforts.
Michael Schwartz: Is the business team and the developers of CockroachDB – is everyone centralized, or is it remote?
Peter Mattis: It’s not all remote, it’s not all centralized. We are primarily based in New York City – that’s the headquarters, that’s the executive team is primarily based. We do have a remote office in San Francisco, one in Toronto, we have developers in Seattle, and then, a couple more scattered in other places.
This hasn’t been purely intentional. It’s been opportunistic, as we got these people, as we found people who had expertise in various areas. And of course we have the sales people distributed to their various regions.
Michael Schwartz: So, with containers and auto-scaling, the old way of pricing database seems to be totally broken – did you find that you needed to reinvent a pricing model for your product?
Peter Mattis: We were actively undergoing discussions about the way people want to consume and pay for databases and services internally right now.
We have a pricing model for, if you get an enterprise license and you want to deploy CockroachDB on premise. And that’s kind of the more the standard, you pay for a number of cores, paying is based on what kind of CP you’re using.
This is kind of translated over into our Cockroach cloud offering, which is still currently in private beta. But we’re very much looking towards a day in the future, where there’s more of a pay-as-you-go, usage-based pricing.
That seems to be the easiest thing for consumers and application developers to use. It eliminates a lot of the headaches of capacity planning, but in order to go along with that kind of model “pay-as-you-go,” you need to have a database that scales elastically. And that’s what we’ve also been developing and putting a huge amount of energy into.
Michael Schwartz: I think the industry is reeling a little bit after the acquisition of Red Hat by IBM. Do you have any thoughts on what that means for the commercial open source market?
Peter Mattis: Red Hat was the original open source software company. They have a unique success in their model. And their model embraced open source tightly, and provided services and support for open source.
And the common wisdom is that other companies trying to follow those footsteps have run into difficulties of having just a pure support in services model.
So what does the acquisition of Red Hat mean?
One, it’s kind of a sign of like, “Hey, this company existed and grew to a massive scale.” And it was seen as a very strategic move by IBM to buy them. They worry a little bit about what’s it’s going to mean for all the open source goodness that Red Hat was doing, but I think also open source has evolved past with Red Hat.
We see the big companies, the Facebook’s, and Google’s, and Amazon’s, also embracing open source, but also an ecosystem of startups were embracing it from the early days.
So, coming to my overall conclusion, I think the industry had already moved past Red Hat by the time that acquisition had happened.
Michael Schwartz: MongoDB recently commented that their open source strategy was primarily related to marketing. Is commercial open source just sort of bait and switch?
Peter Mattis: What do you mean by bait and switch?
Michael Schwartz: The benefit of the open source, they’re saying really was to get you to use the product so that you would buy something, so it’s really just a marketing channel?
Peter Mattis: I mean, if something is viewed as a go-to-market strategy, then what I think about open source is, people can just download and start using your product without going through some heavyweight handholding from a sales rep – I think there’s a huge liberty in that.
I very much prefer to use products, so I can just download and start kicking the tires rather than going through whatever that is – giving someone my email address, or getting on a phone call. I see that as kind of a marketing strategy.
There’s also a strategy, especially with something like a database, that there’s concerns. A database is a very score of what businesses do. They’re storing data in this thing, it is holding the crown jewels for companies.
For us, there is a bit of a concern of, like, how do you get a closed source database going again in this day and age, when as a startup people are wondering like, “Oh, will you be there in two years?”
With open source, at least, it is a reassurance that no matter what happens with Cockroach Labs, CockroachDB the database will still be there.
I don’t think it’s a complete bait and switch. I think there’s aspects of it that are self-serving, there’s aspects that are altruistic as well. I very much know that I originally got into open source due to those altruistic aspects, seeing all that open source code out there, being able to get inside, tinker, learn from it.
I thought that was great. I wanted to get back to it, and I still have those feelings. I also have to balance that out if you want to have a company that’s successful and looking at how open source can be part of that.
Michael Schwartz: Recently Cloudera and Chef have moved to an all open source strategy. Do you think we’re going to see more of that trend?
Peter Mattis: I think we’re going to see a period of time of experimentation in different models.
There was kind of this feeling that there’s wisdom about, here’s how you build a product that’s open source, you have open core, we saw Enterprise licenses. Then all this moved to Cloud. And being able to monetize your open source as-a-service has kind of flipped things up in the air and started creating a period of time of innovation.
So I’m excited to see this innovation happening because we’ll see what shakes loose out of it. We’re not taking that path and making everything open source, other companies are. Some of them are going to be successful, maybe we’re successful, and history will be the judge of that.
Michael Schwartz: Let’s talk a little bit about Cockroach. How do you segment the market?
If you have a database, you can sell literally to anybody. Do you just wait for customers to try it and call you? Or, is there any way like, you’re looking at the market to break it down and sort of attack the market?
Peter Mattis: We don’t necessarily do the segmentation in the same way you might see at other companies, where they might just segment it purely on, like, “Oh, this is banking, this is healthcare.” We do have those segments, but we’re also looking at use cases, and we kind of segment on use cases.
Broadly speaking, in the database market, there’s two huge segments – if you’re looking at the first level of division – and that’s between the analytics databases and transactional databases.
We very much have placed ourselves in the transactional database market. That’s like the kind of the first level of segmentation. It’s part of our marketing message, we want to be the system of record for various workloads.
And storing, knocking the analytics workload, but actually storing the transactional process, and storing the user records, ledgers, the healthcare records.
The further segmentation that takes place is, where we are getting traction with regard to these use cases that people are comfortable moving on to CockroachDB now, versus the ones that they will be uncomfortable moving in the future.
Part of this is like, we break down the Fortune 2000 we look at, we break down those big enterprises, all of them have heavy database usage. But also be looking at the startups that are coming new into the space. And for startups, there is doing our marketing message and then training our sales engineers or account executives to identify the use cases that fit nicely with the current CockroachDB capabilities.
Michael Schwartz: Of course, there’s no license enforcement in your product, so you can’t force companies to get to call you and get a license. Is the business really on the honor system? How do you get customers to actually get a subscription?
Peter Mattis: We do have Enterprise functionality in the product. And you have to have Enterprise license to do that. In order to get an Enterprise license, this is where you need to get the subscription, you have to talk to our sales people in order to do that. But because it’s open source, there’s no strong cryptography around this. There is a little bit of cryptography but it’s nothing strong, it’s nothing unbreakable, because it’s open source; people could violate that.
That way, it’s on the honor system. Is that viable? I think in the U.S. it is viable, and in most of the world, it is viable.
In China, it’s kind of a notable exception, where they’re very willing to not play to that spirit and just take this stuff for free. But even there, we have a little modest bit of traction with Baidu, out in China.
I think the interesting thing and the interesting advantage that CockroachDB and Cockroach Labs has, is that it’s running a database without actually having a support contract; it’s a very foolish maneuver for any company to make.
It’s almost like another fiduciary duty to have such contracts in place because, if any, like risk offers, those company was to look and say, “Oh, hey, what are the risks to this business?” “Oh, I’m running on this open source database, we actually have no relationship, no support contract with the company behind that database.” They would be raising their eyebrows until they jumped off the top of their head.
I think that way, we’re in kind of a very nice position where people who come in, they use this as open source, with testing and development, they kick the tires of the product. And when they actually start getting production, they’re like, “Whoa, wait. We definitely need to come talk to them,” and that’s when they engage with our salespeople.
Michael Schwartz: Of the products and services you offer, which is the most important from a revenue perspective today? And which product or service offering do you think has the most promise for the future?
Peter Mattis: Today, it is kind of on-prem Enterprise licensing, where we deliver CockroachDB as “shrink-wrapped software.” We don’t actually deliver shrink-wrapped per se, we give people binaries. This is essentially binary software that they run in their data centers. Sometimes, they run it on the public cloud. Right now, that is by far the majority of our revenue.
We saw the writing on the wall way back, a couple years ago that providing CockroachDB as a service was going to be our future. And we’ve been working towards that future. We’re starting to have revenue come in on that. And I very much expect that to be increasing.
It’s hard to predict a time when those revenue streams cross, but I see that the revenue from the cloud over the next year will be increasing dramatically.
Frankly, the revenue from our on-premise deployments is going to be increasing too. It’s hard to say which is going to have the steeper inflection curve yet.
Michael Schwartz: Has Kubernetes and containers threw a wrench in your world at all?
Peter Mattis: No, Kubernetes has actually been great for us.
Kubernetes provides easy running administration of stateless services, stateless applications, but most databases don’t fit into that role very nicely. CockroachDB fits in there very smoothly. CockroachDB runs on Kubernetes nicely.
We have a ton of our customers. It’s the single most popular way to deploy CockroachDB is on top of Kubernetes. Additionally, we’re using it as Kubernetes is the backbone for a Cockroach cloud service. And that’s how we run CockroachDB. So, not only throwing a wrench, Kubernetes is a bit of a wave we’re riding like right now.
Michael Schwartz: Cockroach Labs has had some pretty epic funding rounds. I’m wondering if you have any advice for entrepreneurs on how to survive this process?
Peter Mattis: My co-founder Spencer, he is fantastic, he has a kind of a superpower at talking to the VCs. And I think you need to have one of the founders of the company be in that role, where he’s interacting with our VCs, our current ones, as well as potential future ones frequently. It is a little bit like a never-ending process.
You finish one round, and other people are candidates for the next follow up round. And you’re always kind of thinking out to that future.
Cockroach Labs is in a fairly nice position, where the database market is huge and well understood. And it’s well understood that it’s not going to disappear. It might get disrupted in various ways, and we see some of those disruptions happening. Oracle is the elephant in the database market, and yet, to some degree, a lot of people can say of them it’s yesterday’s news.
AWS is kind of the growing elephant, and maybe it’s the gorilla in the room to work with elephant, it’s the thing that everybody’s paying attention to. They’re kind of changing the revenue breakdown in that space, but there’s just such a wide market area. There’s plenty of room for new entrants, and that’s one of the things that our investors saw, and they’re excited to buy.
They know there’s money, it’s not like we’re out there developing a new market from scratch. We’re breaking into an existing market with entrants, who are both very aggressive as well as entrants, which seem to have befallen by the wayside.
Michael Schwartz: The business is not super old. I’m wondering if you have started to work on developing partnerships, or collaborations, or maybe what companies have really helped you so far in the market?
Peter Mattis: We do direct sales to companies, we also have partnerships with various companies, with ObjectRocket, it’s a Rackspace company, partnership with IBM, and a number of others – I don’t have a list in front of me. But a handful of partners we are starting to work with, integrators as well, and those are certainly important ways for databases to get used and integrated into the system.
We’re also trying to work with companies that aren’t buying us directly but are building their own products, top of databases, and want to work with CockroachDB. We’ve seen this in the banking sector for instance, where there’s companies that are running new infrastructure for core banking services to the major players. They’re looking at CockroachDB is enabling them to provide additional functionality.
Michael Schwartz: When you raise VC money, there must have been a renewed effort to sort of shore up the sales and marketing – has it been working?
Peter Mattis: The history of Cockroach Labs is, we spent kind of two years getting to our first 1.0 release of the product. We built something, we’re always painting a vision of, “Hey, this is what we’re going to build.” And people are like, “Oh, no, it’s going to be too hard to build.” You get that first proof point you built, you get the 1.0 version out there, and they are like, “Ah, okay.”
People are saying they’re going to use it, but are they actually going to use it? So, that third year was about, “Okay… yeah.” We had users who started kicking the tires and a few risk tolerant users getting it into production.
It’s at the end of the third year, when we actually started convincing people to give us money for it. Those were very early efforts at the sales side.
Then, of course, as of 2018, last year, we really started seeing an increase or ramp up in the revenue to the point where we’re like. “Okay, it’s time to actually put more fuel onto that fire.” And that’s where the next round came in. This was just recently, but we saw that it’s time to start putting more sales teams together.
So, in 2018, it was primarily one sales team. Actually, I don’t even know the number of sales teams right now, it actually might be up to seven or eight sales teams. And that’s usually an account executive, plus a sales engineer, who are starting to flesh out professional services offering as well. But you do this all with the signals that these things are needed.
Buying our professional services, because we just had sales engineers acting that rule, now it’s gotten to the point where it’s a full time role, and we were actually looking to increase headcount there. We want to add account executives, which are just kind of pure overhead, until you actually can see that, “Oh, yeah, we have a product that you built that people are willing to give you money for.” And it’ll actually work for the customers and production.
That’s where we were getting all that evidence in 2018, whereas the timing of the fundraise is, like, you’re trying to get from milestone to milestone in the lifetime of the company. The first funding was to build the product, the second bit of funding was to get to an initial revenue, and this latest funding is to be growing the revenue to a place where we can really start expanding the sales team aggressively.
I mentioned marketing as well, meaning there’s more effort going on the marketing side as well. When you grow in sales, you often grow in marketing, kind of in tandem. The sales people need food, and the people put the food in front of the salespeople are the marketing team. They’re generally the initial marketing qualified leads, which get handed over the sales, become sales qualified leads, and eventually some of those become customers.
Michael Schwartz: Do you consider the training for it, to be part of the marketing of the product, or just part of the product?
Peter Mattis: Training is an important part of marketing, it’s an important part of delivering like the full product. There’s a basic way in which training is marketing, which is people who get certified or do training on CockroachDB, they’ll tweet about it, they’ll tell their friends, “Hey, I did this thing, this database is really cool.”
In some ways, it’s just kind of purely direct marketing in that sense, but it’s also part of the product. People need to know how to use it. CockroachDB, we put a ton of effort in making it simple, and yet, it’s still a complicated product, and they want to know how to use it.
By giving them that education, they self-service themselves, and we have to put less money into support. We still put a lot of effort in support, just hopefully there’s less of it, because people are trained up on how to use CockroachDB properly.
Michael Schwartz: If you were to start another software company tomorrow, would you make it open source?
Peter Mattis: I would love to make it open source. Probably would.
I think if I was to start another one tomorrow, the big difference is, it’ll almost certainly be some kind of SaaS offering. Software-as-a-service from the get-go instead of running it on-prem.
We were coming out with CockroachDB in an inflection point, where, even when we were founded four and a half, five years ago, when we were having these conversations, we knew database-as-a-service was the future. And yet, we’ve also seen it wasn’t quite here yet.
So, we’re trying to bridge this chasm right now between the old way of writing databases and the new way of consuming them to be as-a-service. The market overall, and all the big Fortune 500 companies, they almost all have cloud strategies to get off their private data centers into the public cloud. These things will take a while to unfold, but there’s just this huge, and we have seen only the tip of the iceberg of how that’s going to unfold.
My feeling is now, you can sustain yourself as software-as-a-service now, and it has been true for a while in a number of different markets. But I think you can do it for a database as well. I’d do open source, I’d do it database as a service, or I’d do whatever software-as-a-service, if I was starting up a company tomorrow.
Michael Schwartz: Last question. What do you think are the biggest challenges for new companies trying to use open source as part of their business model?
Peter Mattis: The challenge is, you might be overly optimistic in how much impact open sources has, like the benefit you are getting from the community. And there’s success or disaster that can happen there.
If you develop something open source, and it actually gets incredible community traction, then there’s actually a huge problem that comes with that, which is managing the development at that point.
It’s almost like the open source product can become owned by the community, and they can take it and nudge it in directions that aren’t necessarily in the strategic long-term vision of the company itself. I think kind of struggling that is an enormous challenge.
Any company has this. People come and say, like, “I want X, Y, Z feature.” And you’re like, “But that’s going to conflict with this other feature that has been asked for.” With open source the challenge is, they can just go and do it. They can fork it, they know it’s open source, they can do what they want with it. And trying to manage that can become a huge, huge challenge.
Michael Schwartz: Okay, Peter, thank you so much for joining us today and sharing all that great advice and insights.
Peter Mattis: My pleasure. It was great chatting with you, Mike.
Michael Schwartz: Thanks to the Cockroach Labs team for helping to organize and promote this podcast.
Transcription and episode audio can be found on opensourceunderdogs.com.
Music from Broke For Free and Chris Zabriskie.
Audio editing by Ines Cetenji. Production assistance and transcription by Natalie Lowe. Operational support from William Lowe.
Have comments? Tweet at us. Our Twitter handle is @fosspodcast.
iTunes listeners, send us your five stars – this can be your open source contribution for the day.
Next week, we have a change of format. If you don’t know The Changelog, it’s an epic open source podcast currently with more than 350 episodes, the hosts are Adam Stacoviak and Jerod Santo.
We’re going to republish an amazing episode of The Changelog, you’ll have to tune in next week to discover which one it will be. A big thanks to Jerod and Adam for sharing this interview ad-free. Don’t miss it next week!
Until then, thanks for listening.