software | Open Source Underdogs

Episode 68: Solomon Hykes, Co-Founder / CEO Dagger

March 15, 2024 Marina Andjekovic 0:28:54 Comments Off

Intro

Mike: Hello and welcome to Open Source Underdogs! I’m your host Mike Schwartz, Founder of Gluu, and this is episode 68 with Solomon Hykes, Co-Founder and CEO of Dagger, but also formerly the co-founder and CTO of Docker.

Back in February, I recorded this episode at the Civo Navigate conference in my hometown of Austin, Texas. If you want to hear the latest and greatest cloud native stuff and meet companies like Dagger, you should check out Civo Navigate. It looks like they are planning a US and Europe event each year.

This episode is a little on the long side because we cover some questions, relating both to Dagger and Docker. But if 45 minutes aren’t enough for you, there are a bunch of other interviews with Solomon, so just check the interweb.

And with that said, let’s just cut to the interview, so we can get to the main attraction. Here we go.

Y-Combinator Playbook?

Solomon, thank you so much for joining us on Open Source Underdogs.

Solomon: Thanks for having me.

Mike: I’m just going to dive into this with Dagger. Your approach seems very YC to me – who are the developers in pain that build Dagger?

Solomon: Yeah. Dagger came out of a process of talking to a lot of software teams about their pain, and the pattern we saw emerge was the problem of the deployment pipeline. You know, CICD, everything that happens after your code’s ready. But before your application is live, everything in between is just, painful, painful and complicated. And so, we’re focusing on making it a little less painful, a little less complicated. So, it is very YC, it’s the standard Y-Combinator playbook.

Community Lead Growth

Mike: What is the Daggerverse and Daggernauts, and what do you mean by community-led growth?

Solomon: Daggernauts are people who think of themselves as part of the Dagger community. Community is — I mean, it’s an overused word, but it’s really important to us, community-led growth is our business strategy. And the idea is, if you build a product for developers, and those developers are excited enough about it that they will not only use it, but show up on an online chat server to talk about it, come to meetups to talk about it, write blog posts about it, tell their friends, help each other – they become more than users.

You need a new word for that, so we use the word community, and then we market the product together. Sometimes we sell it together, and we write software for it together, so that that can become a way to grow as a business. It’s hard to do correctly, because you have to be authentic, you can’t fake it. Because a community will only form if there’s actually something in it for them, and it can’t be just transactional – they have to feel valued, respected, but when it does work clicks, then it’s very powerful.

Monetization?

Mike: As I understand it, you have an open-source project under the Dagger GitHub – your trademark – and your strategy is to monetize by selling a maybe cloud-controlled plane or dashboard, where enterprises can really see value. Am I on the right track?

Solomon: Yep, totally. Open-source engine, optional proprietary control plane.

Mike: What is the business value that enterprises are actually seeing, where they decide, “Okay. I want to go with the commercial offering.”

Solomon: Well, first of all, the commercial offering is very new. Our priority is adoption of the engine. If an enterprise can use both, that’s great. If they only use the engine, and they need to take a little more time to evaluate the commercial products, wait for a feature to be available, then, that’s totally fine. We’ve designed it that way.
For example, our cloud product does not have a self-hosted version yet.

So, some customers do not care, and they’ll buy it today. And others are waiting for this self-hosted version. When we talk about the business value of Dagger, we’ll talk about the whole of the platform, open-source engine cloud for the buyer. Either it solves a business problem for them, as a complete platform, or it doesn’t.

Unique Features

Mike: There’s a number of tools in this area already, who are those super fans who say like, “I know about all that other stuff, but that’s not for me. I really need this Dagger.” Who are those people?

Solomon: Usually, in every software team, there is at least one person who’s the designated DevOps person, they’re the person who will have to fix the build, or make it faster, get the CI pipeline going, sort of support the developers in shipping. And then, over time, as the team grows, you’ll have more than one.

And in larger enterprises, you’ll have entire team, platform team, DevOps team, whatever – those people are typically the people who will get excited about Dagger because it makes their job easier.

Developers we help indirectly, the DevOps people we help directly. The main reason they get excited is because we don’t force them to throw away what they have, will improve the stack they have incrementally their terms – that just makes everything else easier.

Prioritizing Core v. Commercial?

Mike: Is there ever any friction when you’re figuring out how to allocate scarce resources at Dagger, on, “We should work on this core feature that is in the open source, or we should work on some features that improve the cloud offering, which will help us monetize.” And how do you balance those?

Solomon: Yeah, it does happen all the time. In fact, we’re small enough that it happens even within the open-source engine. Also, right now, we’re at an inflection point, where the core product is done – well, it’s not done, but it’s well-defined, and it’s well understood. And we have a community of people who are using it and want to use it more and more, which means they’re reporting bugs, they’re asking for features – there’s an incremental roadmap that we’re executing on.
Meanwhile, we’re building out this commercial product, which is, like I mentioned, it’s much newer, and it needs a lot of work. Resource contention is a problem. I don’t think we’ve found the solution. Honestly, focus is our friend here. For example, I mentioned we’ve prioritized adoption of the open-source engine.

So, to be honest with you, over the last six months, I think we got a little bit too ahead on the commercial products. We approached it like we could build both at full speed in parallel, but then we realized, when we looked at what people were asking for on both sides, we realized, okay, we can build both, but we cannot build both at the same level of priority. So, we’ve changed our text slightly, and we’ve decided to make it clear that we are prioritizing the core open-source engine at the moment.

And with the resources they are left with, we’re developing the commercial product. But we’re narrowing the scope of the features of the commercial product – in practice, that meant going from two flagship features to one flagship feature in the commercial product, for example. I think it’s just mostly being realistic and also being flexible adapting to changing circumstances.

Community v. Monetization?

Mike: I’ve noticed that with a number of start-ups, their initial focus is really on getting adoption and getting those super fans and then figuring out monetization later. I’ve also had guests who said they should have thought of monetization from day one and built around that. Where do you come out on that?

Solomon: I think there’s a balance to be found for sure. For example, I’ve just said, we had to sort of scale back a little bit on developing the commercial product. I’m still very glad we started developing it early, and we’re validating it, whether there is something that anyone is willing to pay for, and also, a million details along the way – how much to charge for it, is it cloud or on-prem, what market are we competing in, who are our competitors.

The clock starts the day you start building it. And I do think completely putting off even thinking about it for potentially years can be a mistake. So, we were pretty deliberate about starting early, but then, once you’ve started, you got to manage your priorities – that’s our approach.At Docker, it was all on community and think about monetization later for sure. And it worked. I’m not surprised when you say some people regret not working on monetization sooner. I completely understand.

Why Trademark is important

Mike: Actually, I would like to dive deeper into the monetization because that’s really interesting, but before we even get there, maybe just any thoughts about the use of the trademark, and how you’re approaching Dagger differently from a trademark perspective.

Solomon: At Docker, we underestimated the importance of protecting your trademark when you’re building an open-source platform. Ironically, the best example of doing that right is also the same company that abused our trademark the most – namely RedHat. RedHat really is a great model for how to be extremely open on your code. Red Hat has always been serious about open-source licenses, opening up even proprietary products from companies that they bought. They would open up the code. They really walked the walk on copyright on the license of the code itself, but the way they made it work is they’ve always been extremely strict and enforcing the use of the RedHat trademark.

It is the best model for an open-source business. The stricter you are on the trademark, the more open you can afford to be on the code. In practice, that means this is open source – you can fork all of it and redistribute it. It’s all fair game. You can take all of it or modify it and redistribute your modified version. But you can’t call it in our case Dagger, you have to call it something else.

Ideal Use of Trademark

Mike: What was the impact on Docker as a result of people, or organizations, using the trademark?

Solomon: The problem was the kleenex problem basically, that Docker washing became the problem. As Docker popularized containers, and containers became the hot new thing, Docker became the hot new thing, and the Docker brand became very valuable. You know, the whale logo, everything associated with it – something new, something exciting. This community that was just blowing up – we had I think 120 meetup groups around the world, hundreds of thousands of people physically coming every week to just show each other a cool stuff they were dealing with Docker.

That brand was basically very valuable, and anyone, any vendor could just take it and say, “Oh, yeah, we do that.” Of course, it meant that Docker as a business did not enjoy as exclusive a competitive advantage as it deserved.
And also, over time, it hurt the quality of the experience, because you could go to a random vendor and they tell you you’re getting Docker. So, you install their thing, and you think you’re getting Docker, but you’re getting some weird Frankenstein product that maybe there’s some Docker inside it somewhere.

But the experience is not up to my standards, or the standards of the Docker team. So, you’re going to walk away disappointed, it didn’t work properly, it wasn’t compatible. They said it would be portable, but it only works on this vendor system, whatever the problem is. And now you’re going to associate that negative experience with the Docker brand. So, losing control of your brand is a really terrible thing to experience. The way to not lose control of it is to enforce your trademark in a very strict way.

Mike: Although Dagger is open source, you don’t want anybody doing Dagger hosting, or introducing a Dagger powered product. What about the hosting side? We’ve heard a lot about open-source data. If somebody used just Dagger hosting, we’ve seen WordPress hosting here in Austin – where are the limits, or where are the boundaries?

Solomon: Our approach is, if you think Dagger hosting is a great thing to do, come talk to us, and we’ll partner. Actually, we’re having conversations now that actually becomes forcing function for designing it. Okay, let’s talk about what does Dagger hosting mean actually. What that experience will be is not as straightforward as hosting a database. There are questions of what’s going to run on the client, what’s going to run on the server – those things are still being worked out. So, now we get a chance by forcing people who want to sell hosting for Dagger to come to us.

Now, they’re part of the design conversation, now these potential partners, we are showing them the architecture we have in mind, we’re showing them the feedback we’re getting from our community what they want.

And now, we’re all going to design this together. And if it still makes sense in the end, and they’re still interested, then they’ll get a license to use a trademark. Or they could just say, “You know what? This is great. We don’t need your brand, we just want the code, and we’re just going to do hosting, or something – they change the name, and then they can host it now, they don’t need our permission for that. Keeps us honest at the same time.

Mike: Because they have the right to use the software.

Solomon: Exactly. Because it’s actually open source. There’s no special license or anything.

HashiCorp shows system worked?

Mike: There’s another company I thought you were going to mention when you mentioned RedHat, and I think RedHat’s also underappreciated. But I was thinking of HashiCorp. They actually did and continue to do a very good job of defending their trademark – TerraForm.

However, they did run into some friction with the community. Because, after a billion downloads of their software, they changed to a non-OSI approved license. And there was some blowback from the community. And I think they broke a social contract in a way. By your definition, they did it right, but is there anything they could have done better?

Solomon: I think that episode with HashiCorp was actually very useful for start-ups like Dagger that are earlier in the journey. We’re telling the markets, “Here’s our open-source product, here is our business model around it. And it’s a sound model, and you can trust us that everyone wins.

RedHat was very useful in standardizing part of that model. Okay, RedHat has opened everything, and they’ve been very strict on the trademark. And they’ve been successful, so that helps us make our case. But one question we can’t answer with only that example is, okay, but what if later you change your mind, what if later the founders leave, and the professional CEO takes over? Or, what if you sell? And you can’t say, “No, we won’t.” I mean, because you don’t know. And that’s what happened to HashiCorp.

And what’s wonderful about this example is that it turned out okay for the customers. Because what’s happening now is, there was a fork, it’s run by a foundation. Now, there’s one more option. After HashiCorp made this decision to break the social contract, basically they were punished or rewarded, depending on how you look at it, with a community-run alternative, which customers can now choose to switch to at any time.

Now, I get to say, well, we don’t plan on doing this, there’s no good reason for us to do that, but just in case, a few years in the future we change our mind for whatever reason, here’s what will happen: we’ll get forked, there’ll be a community-run alternative, and you’ll get to use that. So, it’ll be fine.

Mike: So, the system worked.

Solomon: Yeah. I think the system worked. I have no clue if in the end, this is good or bad for HashiCorp, if they made a mistake, or if it’s not that important. I mean, I don’t really have an opinion on that, but I know it helps us make the case for our model now.

Do we need a new OSI model?

Mike: We’ve recently attended SoCon, the State of Open Conference in London, and Bruce Perens gave a talk, where he suggested we need a new open-source definition. And we see open-source companies moving to other types of licenses that are slightly more restrictive. Do you have any thoughts about whether maybe we need some innovation in this area?

Solomon: I think we do. Honestly, the elephant in the room is this battle over what’s open AI – well, there you go [laughing], that’s the problem right now. What does it mean for AI to be open and what happens when the closed vendor has opened in the name, and then you have open-source models that have a closet says, you know, Apple can’t use it, or something. Neither open AI, nor so-called open-source models today, meet the OSI definition of open source. Is that okay or not, that’s the debate. But I think given just the enormous attention on AI right now, if anything causes the state-of-the-art in this area to change, it’s going to be that.

Every other ongoing point of contention is dwarfed by the focus on AI. That’s my opinion. Maybe that’s an opportunity to leverage that attention and that desire for change. And that those tensions channel it into constructive changes to the standard. It’s dangerous, because maybe what ends up happening is the standard shifts in the wrong direction.

It’s possible that we regress, that we actually instead of getting incremental improvement on the current OSI model, maybe we lose benefits of it that we take for granted at the moment. And on top of all of that, even the definition of software itself is called into question. Like, what if all the software is generated by a model anyway.
So, I’m glad it’s not my job to figure that stuff out. I’m glad I’m not the expert.

Does Open Source Pattern Match with a Tragedy of the Commons?

Mike: A professor here at UT, and we’re recording this at University of Texas, Austin, wrote a paper comparing open-source to tragedy of the commons. She asserts that actually open-source economics pattern matches with some of the things that go wrong in a tragedy of the commons and proposes some remedies.

Solomon: I completely agree with that analogy, but I also think it’s getting applied wrong. Because common use of a limited resource – that needs to be replenished, the land. But software doesn’t need to be replenished – it doesn’t matter if one person downloads it, or 10,000 people download it. The bits themselves, once shipped, are not a resource that needs to be replenished. But the maintenance effort, the support burden is. And so, I think the grazing is not when you download the open-source software and then you use it without paying back. I think that the grazing happens when you’re filing a bug on the GitHub repo, and you’re expecting a maintainer to read it and then answer your question.

Or, you are sending a patch that you really need to see merge for your own downstream needs, and you need a maintainer to review it and give you feedback on it, ideally merge it yesterday. That’s grazing.

So, the resource, the equivalent of the land is not the software. I think the equivalent of the land is the people maintaining it. Because those maintainers behind the scenes are burned out. They are holding the world on their shoulders, and a lot of times they’re volunteers. But even if they’re paid, we’ve had people burn out of Docker because the world showed up, and they all wanted the Docker engine, and they wanted this new thing merge, and they needed this bug fixed, and they all needed it yesterday. And some of them were very demanding.

And some of them had millions and millions in contracts on the line, and RedHat was a culprit in that, for example. And we had people burn out not just from Docker, but from tech. Because they just cannot take it. You know, I have great hair now, and I didn’t when I started as a maintainer of the Docker project. We need to solve that. And I think tragedy of the commons is a perfect analogy there.

How to Maintain a Mountain of Open Source?

Mike: You mentioned open AI, and when I look at open AI, I see that it’s built on a mountain of open source. But they have the connection to the customer, which gives them that sort of last mile that enables them to extract value. What I’ve noticed is that there’s an inexorable stream of CVEs. That, because my software is built on a mountain of open source, some of those dependencies are always getting a rear patching once a month, just to keep up with it.

And I think the expectation for an open-source project is not just that it’s open source, but almost like this social contract that you will continue to patch it forever. And when the next log4j happens, we expect you to do it tomorrow.

Solomon: I agree. Yeah, that’s part of the problem. It’s like an open-source project is a service. The unspoken contract includes everything you’re talking about – ongoing maintenance, ongoing support, ongoing operations of the project itself, running the CI pipelines for it. There’s no system in place for doing that in a sustainable way. I think it’s an unresolved tension in our industry today.

I just think sometimes we go down the wrong rabbit hole, trying to solve it, because we just frame the problem – it’s not a software piracy problem, the problem is not that people are using the software for free to make money because that’s normal, that’s expected. If someone has to wake up at 4:00 a.m. because a really terrible security vulnerability was just discovered and they have to patch it because only they know how. And they were volunteers, and they have billion-dollar companies depending on it, and the billion-dollar companies are the ones calling them – that’s not okay. That’s like fundamental problem for everybody involved. And that’s an actual real-life scenario. That stuff happens. So, yeah, we got to figure that one out.

Lessons from Docker Monetization Battles

Mike: Yeah. This is a global problem, and it’s really hard to solve global problems. I’m going to switch back to Docker, and again, excuse my ignorance, I’m not a Docker expert, about the history either, but one thing I have noticed is that they seem to be doing a little better now.

Solomon: Oh, yeah, yeah.

Mike: And so, monetization and pricing you mentioned, I wasn’t even going to ask you about your price journey for Dagger because it’s too early. Whatever you think of now probably is going to change. But you do have some interesting perspective, I think, on having this incredibly, maybe epically, record-breaking popularity in terms of who loved the software, but then also challenges around monetizing. And then, also now, the ability to see what they’ve done. And I’m just curious if you had any thoughts on what they’re doing now?

Solomon: Of course. A very common thing I hear is, “Docker struggled as a business because they gave too much away for free.” And I really think that’s wrong, meaning Docker was correct to open source, and it never had to be backtracked. Docker never had to change its license and anything while I was there, and after. At no point did Docker have a regret open-sourcing something – there was no temptation to walk it back. I think that’s a victory.

And second thing, there were many, many opportunities to monetize on top of this immensely popular open-source project. And many companies successfully did that, pretty much the whole tech industry made buckets of money off of Docker, except for Docker, for a long time. And that’s not anybody’s fault other than Docker’s.
Docker failed to build a commercial product that was exciting enough for people to buy. That’s the reason Docker struggled. It was purely an execution problem. It was ours to lose, and we screwed it up. And all this typical startup failure ways lack of focus, which comes from an inability to say no to something, so you can actually focus on other things.

And it’s just lack of discipline on hiring and expenditure and strategy. So, ultimately, instead of shipping one great commercial product, we shipped eight average ones. If you look at the numbers, if you go up to the point where Docker got closest to that, and it got recapitalized and split in two, and the commercial part got sold off to Mirantis.

And the core assets, the brand, the open-source tools, the developer tools lived to fight another day. By that point, Docker had spent 300 million dollars to build a 60-million-dollar business. The math doesn’t work out. So, yeah, that was the main reason what caused Docker to be successful now, is a very simple – they had to downsize, sell off that failed enterprise business, they were left with the open-source Docker engine, Docker Hub and Docker for Mac, these desktop apps install Docker on your desktop. The simplest thing in the world. It just so happens that when we shipped that back in 2016, we did not make it open source. So, we have this really easy Mac application: click, click, you got Docker. We bundled that as a binary, and we did not open source it, and nobody cared. And it was free. And then, one day Docker said, “You know what? This application is still free unless you make this much in revenue as a business, and then you have to pay us now.”

And that was it. That turned Docker into a successful business pretty much overnight. So, not sure what lesson to take from that. The product that we ended up monetizing successfully in what, 2020 let’s say. It had been there for four years. You just had to put a price tag on it.

YC Twice?

Mike: So, you’re a new entrepreneur. Are you going to recommend going through the Y- Combinator?

Solomon: Yes. 100%.

Mike: On your second start-up, did you go through YC again?

Solomon: I did.

Mike: Can you talk a little bit about why? Like, you knew everything from the first time around, why did you do it again?

Solomon: It’s a complicated answer. The shorter version is, I joined a little bit later. It’s three of us co-founders at Dagger. My two co-founders, Sam and Andrea, they were first employees at Docker. They left, and they started something new. And I joined a little bit later. The reason I joined later is because I was taking a break, and I was a visiting partner at Y-Combinator for one batch. If you do this thing, they invite entrepreneurs to be a partner for a little while. At the same time, they were asking me the exact same question you asked me, “Hey, should we join YC?”, and I said, “Yeah, you should join YC totally. You’ll meet new people, you’ll get a lot of help.”, because they were first-time founders.

And they ended up assigned to me, so I was their partner, one of their partners. We spent a bunch of time together at YC. I was a partner, they were founders, and we talked about their idea what to do. And then, we got excited about it together. And at the end of the Y-Combinator batch, I joined as a founder, which means that now we’re a YC company, but like technically, I did not go through YC as a founder of the first time, if that makes sense. I did not have the opportunity to make that decision. But if I had had the opportunity, I would have done it.

Because I had been through YC, but my co-founders hasn’t. So, as a group of founders, we had not gone through it together. And that’s very valuable. And also, YC got better over time. New partners, new programs, new resources, and more importantly, more alumni.

So, the other founders in the batch are some of the smartest people you’ll meet. Being surrounded by other founders and talking about your founder problems with them, and then staying in touch and growing your network that way and helping each other after you leave Y-Combinator. That’s incredibly valuable. I always tell everyone, you should join YC if you can. And if you’re an outsider, or a first-timer, then even more so.
And if you say, “Okay. I’m a second-time founder, I’m not going to do it.”, I’ll still say you should do it, but I understand the way you’re not doing it. If you’re a first-time founder, there’s no reason not to go through YC, if you get a chance.

Advice for Open Source Founder?

Mike: Last question. Do you have any final advice for founders who want to use open source as part of their business model? Just some quick advice.

Solomon: Yeah. I would think of it as a tool in your toolbox, as a founder. It can be the perfect tool, or it can be the wrong tool. It really depends on your product, your positioning in the market, your strengths as a founding team. So, I would not blindly apply a playbook. And I would always make sure that if you’re open sourcing something you know why, especially for engineers, engineer founders.

There’s always a pressure to open-source everything, because you want to be loved and respected by your peers, giving things away. Open source is just a shortcut to that. Sometimes, the right answer is to not open source something to withhold it. And sometimes the answer is to open source. It really depends on the situation. So, be strategic about it, my general advice.

Closing Credits

Mike: Solomon, thank you so much for sharing all this with our audience, thank you so much.

Solomon: Thank you.

Mike: Thanks to the Dagger team for volunteering Solomon, to Alex from Resonance Public Relations for suggesting this interview, and to the CIVO Navigate team for the logistical help with the recording schedule.

Don’t forget to check out CIVO Navigate next year if you want to learn more about cloud native technology.

Cool graphics from Kamal Bhattacharjee. Music from Broke For Free, Chris Zabriskie and Lee Rosevere.

Next episode, in a slight divergence from the format, we’ll hear from Patrick Bachmann of Open Ocean, in his role as Venture Capitalist that funds high-growth open-source software start-ups, informed by his roles at MySQL and MariaDB.

Until next time, thanks for listening.

Episode 62: Amandine Le Pape, Element CO-Founder / COO, Messaging and Collaboration

June 8, 2023 Marina Andjekovic 00:24:33 Comments Off

Almandine Le Pape is the Co-Founder and CEO of Element, the the company behind the Matrix protocol, which deines a “chat” and collaboration protocol that enables federation across Slack, Rocket.Chat, Element, and many other implementations.

Episode 55 – Miguel Valdés Faura, CEO and Co-Founder of Bonitasoft

December 2, 2020 Marina Andjekovic 00:29:04 Comments Off

Intro

Mike Schwartz: Hello and welcome to Open Source Underdogs. I’m your host, Mike Schwartz, and this is Episode 55, with Miguel Valdés Faura, CEO and Co-Founder of Bonitasoft.

Not every tech company follows the same trajectory to success. Hypergrowth is great if your market supports it, but the world of infrastructure software is diverse, and hypergrowth can subject your business to unreasonable risk.

To me, Bonitasoft was a reminder that a CEO’s responsibility can transcend shareholder value. While the primacy of shareholder value seems axiomatic in Silicon Valley, it’s worthwhile for entrepreneurs to weigh that risk. Miguel and his team did just that, and their success validates the idea that business models are not a one-size-fits-all proposition.

As a side note, as I was doing my research, I noticed that Miguel has interviews in Spanish, English and French. American CEOs are lucky to speak two languages, but three is pretty exceptional. Anyway, I hope you enjoy the interview. This was the last of 2020. So, without further ado, here we go.

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

BPM Market Overview

Miguel Valdés Faura: Thank you, Mike, for having me.

Mike Schwartz: So, although this is a business podcast, you’re a technical founder, and sometimes, it helps to have a high level of understanding of the market. Business Process Management, or BPM, it’s still an important way to think about how to apply technology, but the technology landscape has changed so much since 2001, I guess when you started the project, and even since 2011, when you started Bonitasoft. Why is BPM still a good way for companies to think about how to build applications?

Miguel Valdés Faura: Good question. So, it’s because companies – I like to say that it is all about processes, a ton of processes that are required to run a company, some that are more critical than others, but BPM technology has been here for a while to help companies, to rethink, re-invent and automate their processes, whatever, they are critical or not. Also, I think it is something that is here for a wider dimension, and of course, the market is evolving because also the needs of those processes are changing in organizations.

Project History

Mike Schwartz: So, the Bonita project itself started at the French National Institute for Research in Computer Science. The project was transferred to the Bull Group, and then, in 2009, you started BonitaSoft with Charles Souillard and Rodrigue Le Gall?

Miguel Valdés-Faura: Exactly.

Mike Schwartz: And also, over the years, how is the community grown? Is the Bull Group still involved, and are there other important contributors in the ecosystem?

Miguel Valdés Faura: BullGroup, which is now part of Atos, at the origin, is involved, but as a partner. It is one of those hundred employees, partners that we have – I’m talking about Consulting and System Integrators Partners that helps customers worldwide with the Bonita implementation, but nothing more, meaning that over the years, Bonita self has grown into an international community that goes beyond specific companies, but, also, having individuals working sometimes as freelance models, as part of the bigger companies.

And I think that’s one of the main achievements now. We have now a community of around 150,000 individuals working with Bonita, not all of them of course are contributing, it is only a small portion of this contributing code, but there is people participating in answering questions in the forum, or translating the products – there is a lot of activity in the Bonita community that is not relied only on one company.

Why No-Code Is No-Go?

Mike Schwartz: In an interview a few years back, you said that the no-code approach does not open the possibility for developers to write code that meets business needs. Can you expand on that? Don’t business people love drag-and-drop GUIs, to build BPM workflows?

Miguel Valdés-Faura: Yeah, a good one. So, probably, it was referring that with this new trend of local done, this new kind of developers, the thing some analysts were calling business developers, at some point, we were facing with people that are not skilled in development to build some complex applications, and at some point, they’re going to face some limitations. Of course, a lot of people like to build on applications, using drag-and-drop, as I mentioned, or visual tools, but when the application gets more complex, or when you need to customize a little bit more the application, at some point, developers need to be part of the game as well.

So, I’m not saying that it’s not useful to have business people participating in the development projects. I’m not saying that the local movement is not something that is real, I’m just saying that we need to find a balance between things that can be done graphically, and first that require code, and it’s about how those two different skill sets can collaborate, how business people or people without development skills, can also work on the same project with developers.

Probably, those two personas are not going to use the same thing.

Customer Profile

Mike Schwartz: Thousands of organizations use Bonitasoft, but switching to the business side a little bit, from a revenue perspective do you see the 80/20 rule, where 20% of your customers make up 80% of your revenues? And if so, what does that 20% segment look like, with regard to use cases or industry verticals?

Miguel Valdés-Faura: In terms of the verticals, of course, I think it’s not only something -particularly Bonitasoft, all BPM vendors, you know, have a lot of traction in market that are highly competitive. So, for example, insurance, banking, telecommunications, because there is a lot of pressure to do better than the competition, because there is a lot of processes that are related about how you provide better services to your customers, and how are you going to retain those customers by providing good services.

So, those will be probably the main four sectors in which Bonitasoft is evolving and getting customers, and also, potentially the ones, in which other vendors are also evolving. In terms of the split or the size of the customers that we have, we have this idea from the very beginning to focus on medium and large organizations.

So, there are some BPM vendors that are focusing on smaller implementations, we are really focusing on complex implementations and meet large organizations. So, the majority of our customers, like 75% of our customers, will match that criteria. And the majority of the project implementation inside those projects are either core or critical to their business. We usually don’t start working with a customer in less critical business process, but this is part of our strategy. And, of course, our product is better suited for those complex implementation.

Value Proposition

Mike Schwartz: Kind of a basic question, but what would you say are the most important value propositions for your customers?

Miguel Valdés-Faura: First of all, we are selling a platform, not a product, so, what we want is like to bring together those two personas that I was referring in a previous question, so business people or less skilled people, in terms of technical skills, and how developers can work together. So, we have a platform, in which you have clearly separated the visual programming capabilities versus the coding capabilities. So, in a sense, we are taking the benefits of the majority of things that we see in an open-source project. So, extensibility, open architecture, which APIs, compatibility with other open-source technologies that are things that appeal to developers. And at the same time, we have an integrated platform, a unified platform, that is also providing visual capabilities to less technical people. And, also, this clear separation in which, depending on the skills that you have, you can use some of the capabilities of the platform, and depending of your skills, you can use some others – these are the things that make us different, and that people like about our solution.

Monetization

Mike Schwartz: Bonita project is open source, and Bonitasoft has a platform built around that – how exactly do you monetize?

Miguel Valdés Faura: So, we sell subscriptions – package additional capabilities to the open-source version, and also, some professional services. And those subscriptions, minimum is an annual subscription, are sold either for people that are deploying the Bonita platform on premise, or people that are using our cloud offering now. But, in two situations, we are basically adding capabilities on top of the open-source solution, like for example, monitoring capabilities and scalability. And we package that together with a professional support, SLAs, contractor warranties, as part of this subscription. Also, it’s a 100% of our probably related revenue is a recurring revenue.

Cloud Strategy

Mike Schwartz: Cloud hosting is really a great business model, and I heard you mention that you have a hosted offering. How has the hosted offering evolved over the years, and do you see that becoming sort of the most important way that you deliver the software? Would you say self-hosted is still going to be more important from a revenue standpoint?

Miguel Valdés Faura: Yeah, a good question. I think in our space, the BPM space, and particularly because of the nature of the projects that we target in our customers, as I was referring as core or critical, we still have a lot of people using the on-premise version, especially in banking insurance that are sectors that are still using a lot of on premise, or they are starting their cloud movement, using public clouds, but not really externalizing everything to SaaS solutions. So, on-premise is still really a big majority, but we have released our cloud service 18 months ago, and we already see a traction. So, there is more and more customers also embracing that new offering – I will say today is more like 80/20. We expect that this is going to change.

It took us a while to offer a Bonita Cloud version because we didn’t show a lot of demand previously. We, as I mentioned, we started seeing some companies that are more and more interested. We really believe that it’s going to be maximizing in the next years, but again, the on-premise is still the number one option today for our customers.

Prioritization Of R&D

Mike Schwartz: So, how do you prioritize your R&D effort, because you’re still contributing to the open-source project, but you are also building your commercial like extra features. And how do you prioritize R&D?

Miguel Valdés Faura: That’s a tricky one for every open-source company. Because you need to make also clear rules about what are the developments that are going to go open source versus the ones that are going to go commercial, and the same applies to the teams – do you have the same organization working on the two kind of features, do decide to have different organizations?

So, we have evolved over the years, but one thing hasn’t changed is that we have defined from the very beginning clear rules about what is open source and what is not. For example, we didn’t want our open-source version to be something that cannot be put into production, because that was not the essence for us, the essence for us as open source.

So, the open-source solution at Bonitasoft you can develop, and you can put it into production, however, for example, as soon as you’re talking about scaling – if you need to CCP, if you want to do clustering, those are the kind of things that, from the very beginning, have only been available in the commercial version.

Also, first of all, is about defining the rules, so, your development team knows what goes into one edition versus the other. Not only your development team, but also of course the community, the community using the open-source version and also your customers – it needs to be really clear. Secondly, over the years, we have evolved, also, in terms of how the development team is a structure, to be more focused on one product, one edition, meaning, one set of people for developers working, one part of the product that is either open source, or is commercial, which, of course, is a way simpler to manage from a management point of view.

Cloud Native Opportunity

Mike Schwartz: In the Cloud Native world, scaling is sort of table stakes, like Kubernetes out of the box is clustered, and my company Gluu, we’ve decided that we’re going to make scaling sort of part of the open-source, just because it seemed like it’s hard to get adoption in the Cloud Native world unless you support Kubernetes, and Kubernetes has clustering.

Do you see a similar trend in the BPM market? And are any challenges or opportunities around Kubernetes and the move to Cloud Native?

Miguel Valdés Faura: Even before Kubernetes, the move that we saw was the adoption of Docker. So, four years ago, we started to demand Docker super, as a way to use and deploy Bonita. So, that’s one of the first that we did. So, to certify a Docker image for people wanted to start their projects, it took us depending of the geography some time, we got that traction from the US, a little bit less in Europe in terms of adoption of the Docker image. Now, it’s a reality – there are more and more people using that. And, of course, those people are also asking now, “Okay, let’s combine that with Kubernetes.”

We have decided that Bonitasoft, that this is part of the kind of the capabilities that we can provide as part of our Cloud Edition. So, the elasticity capabilities that are offered to our Cloud customers is based on Kubernetes. And I think that the value to the customer is that we are able to manage that automatically for them.

This is something that we are at Bonitasoft proposing in our Cloud offering. But if someone wants to do it on premise, and they want integrate, the current Bonita on-premise version without the Kubernetes and manage Elasticity, they can do it.

But at Bonitasoft, we have a package to make it really simple for people who want to use the Cloud service.

Growth While Pivoting

Mike Schwartz: As you know, investors are super-focused on top-line growth. They want growth, growth, growth, but when there are major technology shifts, like from 2011 to today, seems like a different world. It’s hard enough to survive, let alone to grow a 100% per year. Can you talk about some of the challenges of achieving this high level of growth, especially if you have to pivot at the same time, like you probably did over the last couple of years?

Miguel Valdés Faura: A really good question. I mean, you know, it looks like hopefully things are changing, but when we started Bonitasoft off in 2009, and especially in the years that follows, looks like everyone needs to become a hyper-growth company. And of course, I really was trying to raise a lot of money, and we did it as well as Bonitasoft. And, of course, raising a lot of money means also at some point delivering really high growth. But things are changing, and I think that that’s okay, and that’s possible in some situations, it’s something you need to also be willing to do.

We wanted, at some point, growing the company that way at Bonitasoft, especially at the beginning, we decided to change. We decide to change because we wanted to build a more sustainable business, and of course, the level of research you take, if you are always following the hype- growth is a big risk. Because, of course, you are depending a lot of on money from investors, usually high-growth means high losses. So, you need to raise money. Of course, missing some of your targets can put the company at risk.

So, we decided five years ago to change, and embrace what we call a sustainable growth business model, in which profitability scheme for us, in which we try to grow as much as we can, if the company is profitable, and learn in environment in which people are enjoying their day-to-day work.

Now, we have to switch from one to the other, and I think that the pandemic that we are living these days is also reminding us that potentially that’s also a model that some other companies should consider..

Transition From Growth To Profitability

Mike Schwartz: That’s very interesting that you’re saying, “switch to high-growth as long as its profitable”, but how did you manage a relationship with your investors? Were they on board with that, or was there some friction around, saying, “We don’t want to accept this high level of risk?”

Miguel Valdés Faura: You mean, at the beginning, or when we decided to change to a more sustainable growth model?

Mike Schwartz: When you decided to change.

Miguel Valdés Faura: I think they were happy to see that after seven years of existence, we wanted to start looking to profitability. I think at some point that’s important for a company. And so, they were okay with that. And, then, of course we think that we have another kind of discussion with them because we are not asking any more money, the company is profitable for the last four years. So, then, do we need to deal with all the things like, okay, are we looking for an exit, are we looking to grow and do some acquisitions that we want to continue to grow the business organically – but, in any case, you are not forced to raise money which I think is good for us, and in some situations also good for investors.

Building The Sales Team

Mike Schwartz: So, it’s the technical founder one who’s been on the business side for a long time. Building a sales organization is really challenging – is there anything you’ve learned about building the sales team that you’d like to share with startup founders?

Miguel Valdés-Faura: Yes. It’s maybe because I’m also an engineer by training, but, of course, we did a lot of adjustments in the sales organizations over the years, and we’ve made a lot of mistakes and we’ve learned a couple of things. We made some great success, but you know, for the last four years, we are operating with sales methodology that probably you know this, it’s called Customer Centric Selling methodology, which is really focus on the value that you can bring to the customer, that is more focused on quality versus quantity, in which you do, not a lot of prospection, but you are really trying from a marketing perspective to have people really interested in having a discussion with you, and spending a little bit more time and trying to provide a solution that is, as I mentioned, to the problem.

So, then, you can surely acquire a new customer, but also make sure you can renew over the years. And this is one of the big things that we did. And we did it by having a mix in the sales team, people that are coming from different backgrounds, including engineering.

And I think that’s one of my first learning is that you can’t have people that have an engineering background that are doing exceptionally with that, and I think we’re seeing that with more and more companies.

Second, you need a methodology that is really focusing on providing value and delivering value to the customers. And this methodology needs to also be shared with marketing, and needs to be shared with the rest of the organization, including product teams know. And that has been a big change for us. Of course, we didn’t need that from one day to the other, but that move to this new methodology, having the right mix of people and focusing more on content and maturity of our leads than on quantity and prospection, has made a big difference for us.

Partner Strategy

Mike Schwartz: You mentioned that Atos was still a partner, and perhaps, there are other partners who are either bringing you business or you see as critical. But can you talk about like the role of like how the partner strategy has evolved over the years?

Miguel Valdés Faura: Today, we have three different kind of partners – we were talking about Atos, we have a category that we call Consultants and Systems Integrators Partners. As I mentioned, we have something like a hundred and plus of those partners, so, including CGI, including Atos, including Sopra, and then, other things that you in the U.S., you call it more boutique-like partners, or people that are more specialized in one particular sector. So, implementing projects in insurance or in banking. For example, in the U.S. people like Evoke, in Latin America people like Indra – this is one category. Those kind of partners are helping us either to identify new opportunities and also to do the implementation.

By the way, 62% of our new business is influenced by those consulting partners. Second category will be the technology partners. So, there’s no surprise here, this is about integration of our product with other products in a similar market. So, for example, we have those kind of partnerships with the UAiPath in the RPA space. We have this kind of partnership with a DocuSign. So, basically that means bi-directional integration between the two products. And I joined go-to-market, in which we think that the two products combined can bring more value to the customer.

And the third type of partners that we have are OEM Partners. So, it’s people or companies that are embedding our technology and reselling as part of their product. So, to name one that is more representative. Talend is doing that, Talend is that integration leader that is embedding Bonita as one of their offerings. So, those are the three kind of partners. And of course, this thing has been evolved, and has been over the years. So, we started with putting a lot of effort on Consulting and System Integrators Partners, and then we started to focus, in a second step, on more of the technology side of the story.

OEM Patnerships?

Mike Schwartz: You mentioned OEM partnership, which is interesting for open source, because I think that companies who want OEM can use the open source and become part of the ecosystem. What is the driver for a company to OEM in open-source product?

Miguel Valdés Faura: A good question. I think is that the nature of the technology that you are embedding, if you are embedding just Log4j for logging – that was, at least, used 15 years ago, – or Hibernate for persistence. Potentially, it’s the same done embedding, BPM engine or Workflow engine.

So, if you are embedding a solution, that is more like a project or a platform, that is in some way critical to the other solution that is embedding, potentially you’re going to look for, not only can I do it from a license perspective, but also, potentially, you are going to contact the other company to do a partnership. So, that’s what’s happening a lot in our ecosystem – embedding a VPN engine or embedding the whole platform, embedding a workflow solution is something that’s potentially going to be used for mission-critical things.

So, if that is the case, even if the license allows you to do it, potentially, you are going to also look for some help from the company that is building that. And of course, then, it could be also an issue with the license. You know, some of the licenses, for example, the GPL license are not allowed to embed directly without having an OEM equipment in place or changing the license. So, it could be either a license issue, or it could be that you need some helping if something goes wrong.

Licensing

Mike Schwartz: I normally don’t ask about license because I’ve actually been thinking about doing a whole another podcast, or maybe in a season or something, just on licensing, because it’s a complex topic.

Miguel Valdés Faura: Yeah.

Mike Schwartz: And, of course, Bonitasoft’s project’s been around for a long time, but is it GPL license – can you just talk for a second about the open-source license that you’re using, and maybe why?

Miguel Valdés Faura: The open-source project is really under the GPL license, and it’s more historical reasons, this is how we started the project. You know, at that time, it was the time when MySQL was – those kind of projects were appearing, it was the time of Enterprise middleware – so, we kept that license because that was also all discussions around open-core business model. And we didn’t change the scene that, for example, we are now also launching new ones, new products in which, we are also moving to some other license like Apache or MIT. But we kept, for the Bonita project, the GPL license because this is the one that get everything started.

Mike Schwartz: It sounds like the less permissive license actually has benefited you. But I think there’s sort of a knee-jerk reaction or policy among entrepreneurs these days to use permissive license, like MIT or patchy, but it sounds like GPL actually helped you in this case.

Miguel Valdés-Faura: Yeah, it kind of helped, for example, we’re talking about the OEM, it can help the OEM space, some of the people are going to see that there are some restrictions, and then, of course, there is this debate about, okay, but if I’m burying a GPL library, it’s going to be contaminating my project, but usually when you have that issue is because the project that you are building is usually something that you want to follow the open source, you want to commercialize something, just by liberating all those people work in open source, so, yeah, as you mentioned it, it’s always a complex discussion.

But, yeah, I think there are some benefits of using GPL, there are potentially some drawbacks depending of what do you want to build with that license – I think it depends. So, it is not magical rollover for what is the best license to use in your next project.

Keys To Growth In 2021

Mike Schwartz: So, there’s a lot going on today. We have the pandemic, moved to Cloud Native, changes in paradigms, like continuous delivery. What do you think are the keys to growth in the next few years?

Miguel Valdés Faura: I think nobody knows. I think we need to be humble, especially with everything and all those things that are going on, that are going on these days. But you know what, I will be back to my – what I was talking about the sustainable growth. I think that more than ever, being in a business, running a business in which you know that you are profitable, that you are of course trying to maximize, and you are ambitious to maximize the growth, if you are still profitable, having a strong customer base that this renewing year after year is what makes a big difference, especially when there are some situations that they want to do, are facing now.

Because, of course, if you don’t have that, and for some reason, you just stop signing new customers, or signing the new customer database that you were signing before. If you have a strong customer base, you’re going to suffer more than others. So, I will be back to that concept of sustainable growth because I think it’s what makes the company less risky, more sustainable in the long run.

Advice For Entrepreneurs

Mike Schwartz: You know, startups are roller-coasters. I personally don’t recommend starting a company, especially a tech company, to anyone who’d asked me, but for those people crazy enough to dive into entrepreneurship – do you have any advice for new entrepreneurs who are launching a business around open-source product?

Miguel Valdés Faura: I will have one. It’s obvious that I think it is good that we remember that from time to time, which is, there are no two companies that are alike, so, the same applies to founders. Don’t pretend to be somebody else. Of course, listen and learn from others in your ecosystem, but be yourself. And if you create a company, as you mentioned, if you are crazy enough to create the company, try to be surrounded by people that share the culture that you have in mind, the strategy that you have in mind. Don’t pretend to be a CEO that you are not. And that’s – I go back to – not all the companies need to be the same, not all the companies need to be unicorn, not all the companies need to follow the same business model, but you need to be really comfortable about the choices that you make, otherwise, it is going to be even harder than you know it simple journey.

Closing

Mike Schwartz: It’s 55 podcast. I always ask that question at the end – no one’s actually given that answer yet, but I have to say I agree with that a100%. So, thank you for being the 55th guest, and best of luck this year. And thank you so much for being on the podcast, Miguel.

Miguel Valdés Faura: Thank you very much, Mike, for inviting me. It was a real pleasure.

Mike Schwartz: Special thanks to the Bonitsoft team for helping us to schedule the interview. Editing by Ines Cetenji. Transcription by Marina Andjelkovic. Cool graphics from Kemal Bhattacharjee. Music from Broke For Free, Chris Zabriskie and Lee Rosevere.

This is the last episode of 2020. Next year, I’ll keep going, although probably at a somewhat slower rate. If you have any ideas for the direction the podcast should go in 2021, I’d love to hear your feedback. You can contact me on the website opensourceunderdogs.com. Happy holidays, founders! Hang in there, and keep an eye out for new Season 4 episodes after the New Year.

Episode 54: Justin Borgman, CEO of Starburst, the Company Behind the Presto Project

October 27, 2020 Marina Andjekovic Comments Off

Intro

Mike: Hello, and welcome to Open Source Underdogs. I’m your host Mike Schwartz, and this is the episode 54, with Justin Borgman, Chairman, CEO, and Co-Founder of Starburst, the company behind the Presto Data Access Project.

Before we get started, I have a quick request – we all want to help open-source founders and startups. I make the podcast, but I need your help to get the word out, so tell your friends, post on LinkedIn, tweet out a link, post on Hacker News, or follow me and share one of my posts on LinkedIn, whatever you think makes sense, go for it.

One of the themes of Machiavelli’s the Prince is Virtu e Fortuna—virtu meaning excellence in your domain, and fortuna meaning luck, whether good or bad. I really like how the story of Starburst exemplifies this 500-year-old insight.

Justin has a ton of domain virtu. He has deep technical knowledge, but he’s also on the lookout to harness fortuna. He’s one of the few podcast guests to acknowledge it. And Starburst earns its name because it’s one of the most stellar open-source business success stories I’ve heard in the last few years.
There’s so many great insights in this episode, a lot to think about. So, without further ado, let’s get on with the interview.

What Is Presto?

Mike: Justin, thanks for joining the podcast today.

Justin: Hey, Mike, super glad to be with you.

Mike: Before we dive into the business stuff, I find it’s helpful to talk a little bit about the technology. Can you start by giving a brief history of the Presto project? What it’s good at, and how the community coalesced around it?

Justin: It was really back in 2012 for developers at Facebook, Martin, Dain, David, and Eric came together to create a new infrastructure project that would be a faster way of querying data at Facebook. Facebook, of course, collects massive amounts of data, hundreds of petabytes worth of data , and needed a faster alternative to a prior project that they also developed and they called Hive.

Hive was a SQL engine for Hadoop, and it just wasn’t fast enough. So, Presto was created to be a faster means of accessing that data. But it has one really important differentiation in addition to the speed, which is the ability to access data anywhere. So, it’s like a database without storage – that’s kind of one way to think about it.

So, it looks at storage in other systems, which could be Hadoop, it could be S3 and AWS, it could be a traditional database, like Oracle, or Teradata, or Snowflake. And regardless of where that data lives, Presto can reach it, query it, and deliver SQL-based analytics.

So, that’s kind of what makes it special, is the ability to access the data everywhere. And that’s gained particular momentum, I would say more recently, as many large enterprises have data silo problems, where they have data in a bunch of different databases, and are now perhaps moving to the Cloud in some fashion.

Mike: And if I’m not mistaken, high concurrency is one of the areas that make sort of this data access plain different?

Justin: Yes, exactly, it’s very fast, and can support high concurrency. And in a lot of ways, this technology was sort of, I like to say built in reverse, in the sense that it was tested at ridiculous scale from day one. You know, very often, when you start something new, you don’t really know how it’ll work at scale until you get people using it. But because it was really born out of the internet companies, Facebook, and Uber, Airbnb, and Netflix were all early adopters to use the technology, it was really tested, and at scale, and as a result delivers great performance and concurrency.

Origin Story

Mike: Starburst is not your first company, you are part of a team at the company called Hadapt that’s sold to Teradata in about three and a half years, I think.

Justin: Yep.

Mike: How did that experience lead you to Presto?

Justin: In a lot of ways, this is really a continuation of that journey that began 10 years ago. So, that was 2010 that I started Hadapt. Hadapt was a spin-out actually from Yale University and the computer science department – there’s some research called HadoopDB, which was pretty pioneering research at the time, in terms of thinking about Hadoop as a data warehousing solution, and being able to deliver fast SQL analytics on top of Hadoop.

So, we spun that out, raised Venture Capital, built that business over nearly four years, as you mentioned, and then sold it to Teradata. We had ups and downs, definitely lessons learned through that experience. And I think, really, my discovery of Presto after arriving at Teradata in 2014 was kind of an exciting opportunity to reimagine the strategy that we had with Hadapt.

So, Hadapt was the SQL engine for Hadoop, Presto is a SQL engine for anything essentially, allows you to access data anywhere.it was an opportunity to basically take all the lessons learned from the first experience and start to apply them over again.

It was actually my team from Hadapt that ended up contributing a tremendous amount of software to Presto, and working with the guys at Facebook, who created it to really make it an enterprise-grade piece of technology. And I think, as we started to see Presto get more and more capable, and see more and more people use it, that was what created the idea in our head that maybe there was a business to be formed around this.

Community Engagement

Mike: It’s a really interesting opportunity, and I can’t actually think of another example like it, but when I’m talking about open source, I sometimes talk about three types of open-source companies. One would be volunteer, where a bunch of guys or girls get together and write some piece of software that they love, but not necessarily for a business.

And then, I talk about corporate open source, where there’s some piece of software, where a company funds it, but it’s not their core business, but then, they realize that makes sense for them to collaborate like Kubernetes, let’s say ,and Google, and these pure-play, open-source companies, where the company behind it is developing it, and they’re the main contributors.

And so, lots of great open-source projects come out of this corporate open-source area, the podcast that is mostly focused on pure-play because they were trying to help entrepreneurs and founders start open source, use open source as part of their business model. But you’ve sort of, like, created a very interesting situation, where you have a mix of corporate and pure-play because you’re benefiting from, not just the community, but, really, Facebook is a big contributor to the project to — I heard almost 50/50. So, how’s that really evolved, and how do you continue to encourage this very symbiotic relationship?

Justin: You’re right. Preston has a very interesting history to it, an interesting journey. It started as a small project at Facebook. When we got involved at Teradata, we were able to apply a few million dollars a year of R&D budget into advancing that as well. And then, of course, you’ve got a few other companies contributing also along the way.

And, as a result, all of that kind of accelerates the development of the project. And I think that maybe what’s most unique here is not only that Facebook created great infrastructure software as a byproduct of their business – they’ve certainly done that before – but rather that there was kind of a commercial partner very early on, and myself, and my team at Teradata thinking about the commercial applications of this.

So, you know, back in 2014, Presto was still in its early days, Facebook wasn’t trying to monetize it obviously, that’s not their business, but we were already thinking about how this could be used by Fortune 500 customers, and what difference this could make to their business. And I think that led to its very enterprise-applicable evolution, and set us up really well to eventually commercialize this in 2017, when we left Teradata, the creators of Presto joined us from Facebook. And we went off on our way to build this business.

Idea Incubation

Mike: So, you were working on Presto while you’re at Teradata. And did Teradata ask for any equity, or how did that work when you told Teradata, “We want to start this company basically working at Teradata? Like, what was that like?

Justin: Yeah, well, what was interesting about that – and I guess just to set the context, I think Teradata, from 2014, when they acquired my company through to probably today, has gone through various iterations of kind of rethinking their overall strategy, in terms of how they evolved into this next generation of sort of Big Data platforms. Because they had great success in the ‘80s, ‘90s, and early 2000s, as this kind of monolithic data warehouse, where you would ingest everything and store it in one place.

But obviously that became very expensive over time. And the appliance model, hardware and software combined, wasn’t necessarily set up for this future as people move to the cloud. So, they’ve gone through a lot of iterations. And it was really in that iterative process, where they weren’t really clear where they wanted to go, that they actually felt like Presto is maybe a distraction for them.

So, that actually created the opportunity, I think, for us, to say, well, we think it’s a little more than a distraction. And, you know, we’d be happy to sort of take that off your hands and work on this together.

So, it was a very amicable split – we remain partners, we’re still partners today, where we work together on some customer accounts, the technologies work together, we can access data in Teradata, for example, from Presto. So, that partnership remains. But it was one that I think for them, they viewed us as sort of taking Presto off their hands because there were maybe close to a dozen companies within their customer base that were using Presto. So, we were able to deliver really first-class support to those customers, you know, not provide any interruption there, even as we left and formed this new business. So, they don’t own equity, it’s purely a partnership.

Identifying Opportunity

Mike: It’s just amazing like how you deal your business, is you got a huge company Facebook to help you grade and test this infrastructure. You got to do R&D in Teradata, and then you started the business with customers – it doesn’t get any better than that really.

Justin: Now, you’re absolutely right. And believe me, the good fortune is certainly not lost on me. You know, advice I give to entrepreneurs of any type, not just open-source entrepreneurs, is to just have your eyes open to opportunity. I think it passes us all by all the time, and very often we miss it. And I think seeing it, and then, you know, running and jumping on it, it certainly has been beneficial in my career. I’m even going back to my first company and spinning out technology from Yale, which you could argue was the great benefit of various government research grants, funding that research in the first place. So, keeping the eyes open and seeing an application for where it could become a business.

When To Raise Money

Mike: So, initially, you didn’t have to raise money because you had some customers that came that provided some runway, but you did raise a series A, and I guess, October 2018, so, pretty recently. So, what was in the decision process to say, “Okay, now capital is going to help us.”, like what were some of the benchmarks that you reached, that helped you say, “Now is the time we should do that.”?

Justin: So, that’s exactly right. We started without raising any capital. That allowed us to build a profitable cash-flow positive business over those first two years of operating, which I think, by the way, as an aside, gave us a lot of opportunity to be patient and sort of think through exactly what we wanted our go-to-market strategy to be, what kind of strategy we wanted to take around monetization.

And we didn’t have the pressure of investors necessarily breathing down our neck, which I think many, many entrepreneurs have in those early days. So, I think it was a great way to start a business, what forced us to change and actually consider taking capital was really a realization that the market opportunity was bigger than we felt like we could actually satisfy growing at purely an organic rate.

So, we took that series A really as a growth round, you know, even though it’s called the series A, I think it’s a little bit misleading, because it’s probably more like a series B for most companies in that. Not only was it a large amount of money 22 million in that first round, but it was really deployed towards expansion and rapidly growing the business. Less so about proving product/market fit, which is more typical in a series A.

As you said, we did a series B shortly thereafter, which was probably more like a series C, adding another 42 million. So, we’ve gone from raising nothing to now 64 million. And really I think that was all made possible by really building the fundamentals first. Making sure you have that product/market fit sorted out, and then, you know, applying fuel to the fire to expand.

Revenues Pre-Investment

Mike: What was the revenues when you raised the series A?

Justin: Yeah, well, if it was 12 months looking forward, I would say it was already looking north of $10M at that point. So, that allowed us to really take the funding and apply it to, again, expansion rather than kind of sorting out the basic product details.

Mike: And what year did you actually start the company?

Justin: 2017.

Mike: That’s pretty amazing – two years to go to $10M. It’s pretty stellar.

Justin: Thank you. I mean, again, I think a big advantage here was that, in some ways, this was like building the same company over again – I mean, there are a lot of differences between this and my first, but they’re also enough similarities, just in terms of the types of customers that we sell to, the types of use cases, the types of problems that they’re trying to solve. So, I think that historical knowledge was advantageous for us to just move a little bit faster this time around than we did that the first time.

Balancing R&D Investment

Mike: Okay, switching gears a little bit into more basic business stuff. You mentioned in one of your previous interviews that I listened to, that Starburst is basically pursuing an open-core strategy. So, performance, robustness, security patches that goes into open source, things like connectors, security, ease of use, I guess GUI deployment stuff, goes into the core. One of the questions that I’ve sort of wonder about is, how do you decide how to prioritize R&D in open source versus the enterprise features when you go the open-core route?

Justin: Yeah, I mean, I think that’s the key question. So, it makes sense why you’re asking it, and I think it has to be on the mind of every open-source entrepreneur. And it’s a delicate balance because, on the one hand, you want to make the open-source project as useful as possible to get widespread adoption. Because really that’s your lead generation vehicle – I think that’s the way to think about it.

A lot of people say open source is really just another form of a freemium business model. There’s a free component, and that just happens to be open source in an open-source model. And then, how do you kind of upsell to the Enterprise version. So, for us, I think the logic was, what are the reasons why people use Presto anyways in the first place.

And we think performance is a core element to that. So, we wanted to make sure that performance is always great, right out of the box, with the first experience of it, including the open-source version. So, that’s why a ton of work goes into open-source around performance enhancement, scalability enhancements, those kinds of things.

And then, we think about, well, what do people in enterprises, who are willing to pay for this stuff, what do they want. And that’s where it is, things like security features, which are just essential for any large, mature enterprise things, like role-based access control, data masking, if you’ve got social security numbers or credit card numbers, being able to mask digits appropriately, having audit logs for querying.

And then, because Presto access is all these different types of data sources, it also made logical sense that if you’re going to access a database like Oracle, or Teradata, or IBM, all of which are very expensive in their own right, well then, a customer, probably, is willing to pay for enhanced connectors to get faster throughput to those systems.

So, that was kind of the logic was trying to like think through what are the enterprise features that someone is willing to pay a premium for, versus what just produces an out-of-the-box great experience. Because I think so much about open source is really people doing their own self-evaluations of the technology. So, self POCs, if you will, so, you want to make sure that’s great, because you can’t control that. You may not even know who downloaded it in the first place. So, that’s where you really want to put I think a lot of energy into the open-source project. And then, it’s as more of those production features that are important to the larger enterprises, where those I think you can hold back.

Why Not 100% Open Source?

Mike: I interviewed Mike Olson from Cloudera, you might know him.

Justin: I do, oh, yeah.

Mike: He was one of my first guest, and he gave a very similar comment to what you were just saying. And he was quite emphatic about it. And yet, Cloudera recently switched to a 100% open-source strategy. And other open-source companies have also, for example, Chef, and of course some of the older, Linux distributions are, RedHat and SUSE are all open source.

And so, one of the things I’ve been wondering myself is, you can use the open-core strategy. It makes perfect sense I think to business people, but I also wonder, this license is paying for the right to use the software. Do you think that customers are actually paying for the right to use, or they’re paying for the engagement with your organization? And do you think, if you made it all open source, it would actually negatively affect your revenues, or customers would still want to engage with Starburst a company?

Justin: I think I can speak from experience here, because part of what’s interesting about our history is that we’ve kind of evolved through the various open-source business models in our brief history. So, when we first started the company, we didn’t have any proprietary IP, so we naturally just sold support contract. So, the early customers that we started with were just support contracts.

I think the challenge that we quickly identified is that support alone is not the most compelling value proposition. It is to some, I’m not saying it’s not, but it’s not a sufficiently compelling I think to win over a broad set of customers.

I think that’s where the open-core model, at least for us, really created an inflection in the business, where, you know, now we had a real tangible reason. And, by the way, for what it’s worth, I think we learn this actually from our own prospects, that those who are actually huge fans of Presto, who are huge fans of us even, who were champions of what we’re doing, but couldn’t quite get the purchase across the line in those early days and that first year of our operation, because they couldn’t justify or explain to their boss why one would have to pay for something that was free essentially. And that was the tricky conversation was like, “Well, you get this for free, why would you pay for it?” Like, “We don’t need support, you guys are smart, you can support this, right?” And those are the kinds of conversations that can take place. So, I think that’s where the open-core model is really helpful to the business.

Monetization Strategy

Mike: You’re selling a product that’s almost like a data access product, like I call the Presto Interface, and it connects two back-end databases. How do you price an interface, like what are the buckets – I don’t need to know the price but I’m just wondering like, how do you land and expand, and how do you set up the model, so that it’s easy enough for customers to understand, and you can charge enterprise software rates for it?

Justin: The way that we monetize this is based on CPU consumption. Technically, we actually anchor on Virtual CPU consumption because so many of our customers deploy in Cloud environments. So, that’s the underlying metric, and the reason that’s a good proxy for us is because basically Presto is a technology that scales out super effectively, and is leveraging compute-intensively to execute the query.

So, it’s basically, like, the more queries you have, the more data you’re accessing, the more complexity of the workload, and the more users who are hitting the system you talked about, the strong concurrency that Presto provides. Those are kind of the dimensions that drive CPU consumption up, and we just monetize with that. It’s a straightforward metric I think that customers easily understand, and seems to work for us.

Optionality

Mike: In one of your previous talks I listened to, you talked about optionality, and how you recommended basically that optionality essentially drives freedom – how does Presto help you get that optionality?

Justin: Presto creates optionality by virtue of being disconnected from storage, is essentially not having its own storage layer. I used the analogy in the beginning that we’re like a database without storage. The other way I put it for people who are familiar with data warehousing is, we provide data warehousing analytics without the data warehouse. That’s another way to think about it.

So, because of that, it basically allows you to think about Presto as an abstraction layer, above all the data sources that you already have. And you can kind of skip the complex and time-consuming task of having to move data around, create copies of data, ETL it, extract it, transform it, and load it into another system, instead you can just do that at query time, and access that data, and get your results.

So, that gives you a lot of flexibility, and I think one of the ways we’ve seen that play out is, we have a lot of customers that have a classic data warehouse, maybe it’s Teradata or Oracle. And then, they’ve got some kind of a data-lake strategy, and maybe that’s either Hadoop on-prem, or maybe it’s S3, or some Cloud-object storage.

And the first step might be to use Presto to just join tables between these two systems. You’ve got some kind of user behavior logs in your data lake, and you’ve got billing data in your classic data warehouse, and you want to be able to correlate the behavior with the billing, let’s say. That would be a very common use case for us. You can do that with a simple query and Presto.

Now, what that allows you to do then, as a second step, is, essentially, hide from your own end-users, be them internal analyst, data scientist, or even customers. Where the data actually lives, they don’t need to know that they need to go to the data warehouse to get the billing data, and they need to go to the data lake to get the user behavior – they’re just submitting a query, and they don’t know where the data lives anymore.

And by doing that, you’re able to actually decouple your end-user from where the data is stored and give the architects in the organization the ability to now decide, based on cost or performance, where that data should actually live. So, you don’t need to pay Oracle or Teradata tremendous amounts of money to store your data anymore. That is, of course, the most expensive storage you’re going to find.

You could instead choose object storage, like Ceph from RedHat, or there’s a company on the West Coast called MinIO, which creates S3-compatible object storage. And that’s very inexpensive, relatively speaking. And you can deploy all of your data, or start to migrate your data into this lower-cost storage, and still be able to access it, while your end-users are none the wiser to where the data lives – they’re just getting their results. So, I think that’s where you kind of get to create this optionality and be flexible about where you put your data over time.

Mike: In addition to the technical level, I always think about optionality as, does the open-source license itself also lead, or open-source infrastructure in general, also lead to more optionality and freedom?

Justin: For sure. I mean, I think the notion of not having vendor lock-in is really important to customers. Increasingly so, I think they’ve been burned over decades of very expensive technology that becomes legacy technology, and then, their stock and the pricing goes up. And they don’t feel like they have much ability to resolve that. And I think the open-source license in and of itself gives customers a lot of comfort, in knowing that, you know, a worst-case scenario, they can always roll this themselves, with the open source. But also, Presto is able to read open data formats, which is also great. Because I think data lock-in is probably the worst kind of vendor lock-in.

And in a traditional database system, once the data is loaded into the database, it’s kind of not easy to get access to or get the data out, without continuing to pay for that database system. But if you’re using open data formats, which we’d really pioneered during the Hadoop era, these are like ORC or Parquet, if you’re familiar with those file formats, you can store them anywhere and query them with a multitude of tools. You could use Spark to train machine-learning models, working off the same Parquet files that you’re querying via SQL for Presto. And I think that gives customers a lot of flexibility as well.

Open Source V. Commercial Market Size

Mike: I read a lot of articles about how enterprises are really moving towards open source, certainly when you look at the large consumer-facing services, like you mentioned, Netflix, Facebook, etc., they’re building a lot on open source. Then, you look at the size of the market, and you see that, actually, from a market percentage of open-source software is still only a tiny amount – is the move to open source really real, or is it more hype than reality?

Justin: When you say the market is small, do you mean measured in dollars, or what’s the metric there?

Mike: Dollar, yes.

Justin: Yep, makes sense. And that’s the key piece. I think it’s probably super widely used, but the percentage of open source that actually gets monetized is relatively small. And I think that’s what’s translating to the overall dollar amount, seeming small, relative, to the proprietary solution. I think if you measured in terms of impact to businesses and organizations, I think it’s actually probably the reverse actually, where you might have more open-source software having bigger impact than the proprietary.

But, of course, the challenge – and I suppose this is the purpose of your podcast – is figuring out how to monetize that effectively, so that you can build a successful business, while having that broad impact that open source provides. And I do think that, as vendors, we’ve gotten smarter over the years about how to do that.

I mean, the way I think about open-source business models over history is that it started with the sort of pure-play support model, just offering support, nothing proprietary. I think kind of Generation 2 was the open-core model that we’ve spent time talking about. You know, Cloudera popularized that, as did many other companies. And I think Generation 3, which is actually where we’re moving as well as a company, is cloud-hosted, SaaS offerings.

And, basically, being able to make part of the value proposition, the simplicity of the solution that you can deliver as a SaaS, and I think data bricks is a great example of that. So, I think that’s kind of the next frontier. And I think, as more and more open-source companies move in that direction, I think they’ll probably have better success in monetizing that background usage of the open-source. Because, there’s so much you can control now from a SaaS perspective to really enhance the experience, that is just easier for customers to use your SaaS solution, rather than having to maintain it themselves.

Starburst Cloud Strategy

Mike: I normally ask companies if they’re developing a SaaS offering. And I think that there are some companies where it’s been really successful like MongoDB, Eli Horowitz from MongoDB is emphatic that cloud is the best business model and everyone should be doing cloud. In doing the 50+ podcast, I found that the results have been mixed, where sometimes companies find that it’s a good way to reduce the try by fly time, where the cloud offering is a good introduction, but then the revenues are mostly derived from the enterprise, like self-hosted version.

And it takes a lot of effort to actually — it’s almost like a whole new product, like you’re building a software platform, a great software platform, and then, building the SaaS is almost like a totally new product in different business endeavor. What’s Presto done in this area? Are you working on it? And do you have any thoughts about how that experience is going, sort of making a cloud offering out of the software?

Justin: We definitely are working on it, and we have been actually for quite some time. And it is hard work. I think there’s no doubt about it, but I do think that some recent innovations around Kubernetes actually make this easier than it maybe was a few years ago. Because Kubernetes can kind of create a uniform, almost like operating system, if you will, that you can deploy your software within, and therefore, sort of create the software once, rather than having to have all these different kind of custom versions for different types of deployments.

I think that’s a game-changer. It’s certainly something we’re betting heavily on, as we approached that by trying to create the same experience, regardless of where customers deploy.

Single-Tenant V. Multi-Tenant SaaS

Mike: Most of the old cloud services were multi-tenant, but, are you thinking, like with Kubernetes, we could maybe build a single-tenant and deliver sort of like, “We’ll host it for you, you’ll host it.”, but it’s going to be sort of the same thing?

Justin: That’s exactly right, yeah. You know, I don’t want to give away too much of our strategy just yet because we haven’t released the cloud product yet. But I think those are really important concepts that you highlighted there, that we’re very interested in.

Building A Sales Team

Mike: So, something you must have done a really good job at is building the sales organization, because $10M in sales hasn’t happened by accident. And I think sometimes founders underestimate how difficult it is to build a sales and marketing organization – did you have any thoughts or advice you could share on, like how that went for you, like, how you pulled it off, like how do you do it?

Justin: Yeah. I think the first step I would say is trying to understand yourself as the entrepreneur – what the sales process looks like, like, what are customers buying, how do they understand the value proposition. And I’m a big believer in entrepreneurs selling the first few customers themselves. I think you learn so much, even from a product management perspective of what you need. You get to experience what your sales reps will experience when you start to scale up. So, I’m a huge advocate of that.

The second thing I would say is find a great sales leader. Because you know there are folks out there who have done this many times before, and know what it takes to sort of scale up a sales organization. And, certainly, that was impactful for us in finding our VP of sales, who’s done a great job of really scaling up that organization quickly.

Team

Mike: One question I had was, the pandemic has changed things were much more remote – were you remote before the pandemic, and what’s your plan for growing the team in the next couple of years?

Justin: We were not entirely remote, but we did have some level of distributed nature to our team. Before the pandemic, we had major teams in Boston, the Bay Area, and then, actually Warsaw Poland as well, as an important development center for us. So, we kind of had to work across these three geographies, which are obviously spread out by 9 hours of time zones. And I think that gave us maybe a head start on the pandemic. But to be perfectly frank, I mean, I would much rather go back to actually having an office, and being able to interact on a one-on-one basis personally, with so many of these people.

Because I think what’s been weird for us is, we have scaled so quickly this year that I have not met probably half of our employees at this point, which is just a weird thing, to have grown the company so much. And the only interactions I’ve had have been over a Zoom call. So, that part I miss. I do think we’re all trying to make the best out of it, of course. And I think good best practices are sort of documenting everything, having frequent all-hands meetings, where you get everybody together, but there’s still no real substitute I think for one-on-one interaction.

Founder Advice

Mike: The last question, any advice for new entrepreneurs who are launching a business, and they want to use open-source software development as part of their business strategy?

Justin: My advice would be to think early about that key question that you asked earlier in the podcast about what your monetization strategy is going to be, and on along what metrics are you going to, or what criteria I should say, are you going to be separating the enterprise value proposition from what you give for free, and I think kind of have a strategy early on and stick to it. Because I think that will just make the decision-making process so much easier for you as you go along. You won’t have to debate each and every feature that you come up with – you’ll just sort of know because it will fall into a framework. That would be my piece of advice.

Close

Mike: Justin, thank you so much for sharing all this knowledge and experience with us.

Justin: Thank you, Mike. This was fun, and it was great meeting you.

Mike: Thanks to the Starburst team for reaching out and coordinating the podcast. Audio editing by Ines Cetenji, transcription and episode website by Marina Andjelkovic. Cool graphics by Kemal Bhattacharjee. Music from Broke For Free, Chris Zabriskie and Lee Rosevere.

Next time, we’re joined by Miguel Valdes Faura, CEO and Co-Founder of Bonitasoft, a global provider of BPM, low-code, and digital transformation solutions.

Until next time, stay safe, and thanks for listening.

Episode 51: Cloud Native Agility, Reliability and Stability with Weaveworks CTO Cornelia Davis

August 3, 2020 Marina Andjekovic Podcast Comments Off on Episode 51: Cloud Native Agility, Reliability and Stability with Weaveworks CTO Cornelia Davis

Interview with Cornelia Davis, CTO of Weaveworks, a leader in the cloud native infrastructure open source software ecosystem.

Episode 45: Continuous Deployment with Tracy Ragan, Creator and CEO of DeployHub

April 28, 2020 Marina Andjekovic Podcast Comments Off on Episode 45: Continuous Deployment with Tracy Ragan, Creator and CEO of DeployHub

Episode 45 of the Open Source Underdogs Podcast: An interview with Tracy Ragan, CEO and Co-Founder of Deployhub.

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

December 3, 2019 Michael Schwartz Podcast Comments Off on Episode 38: npm Inc.– From Software Registry to Software Business, with Isaac Schlueter, Chief Open Technology Officer

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

Transcript

Intro

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

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

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

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

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

Isaac Schlueter: Hey, happy to be here.

What Is Npm?

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

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

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

Why Inc. Not Foundation?

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

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

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

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

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

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

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

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

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

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

Npm Products

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

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

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

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

Market Segments

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

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

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

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

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

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

Marketing / Sales

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

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

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

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

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

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

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

Free V. Commercial

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pricing

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More On Pricing

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

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

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

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

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

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

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

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

Lessons Learned

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Team

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 5^th floor.” And we’re like, “How about we just leave?” They are like, “Yeah, cool. We get to rent the space out at 2019 prices instead of keeping your lease? Yeah, go.”

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

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

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

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

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

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

Advice For Entrepreneurs

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

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

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

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

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

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

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

Closing

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

Isaac Schlueter: Thanks for having me.

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

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

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

Music from Broke For Free and Chris Zabriskie.

Audio editing by Ines Cetenji.

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

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

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

Until then, thanks for listening.

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

November 26, 2019 Michael Schwartz Podcast Comments Off on Episode 37: Storj – AirBnb for Your Disk with CEO Ben Golub

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

Transcript

Intro

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.

Origin

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

Ben Golub: My pleasure.

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

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

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

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

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

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

Is Storj Distributed S3?

Michael Schwartz: I think of Storj as decentralized S3.

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

How Does Storj Make Money?

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

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

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

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

Who Are The Users Of Storj?

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

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

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

Why Use Storj Over S3?

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

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

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

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

How Does The CryptoCurrency Work?

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

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

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

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

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

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

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

Why Use A CryptoCurrency?

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

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

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

What Is The Disconnect With Value And Economic Empowerment?

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

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

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

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

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

Is Cloud Strip-Mining A Victimless Crime?

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

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

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

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

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

Does Decentralized Cloud Offer An Alternative Business Model?

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

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

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

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

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

Does The Market Value Open Source?

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

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

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

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

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

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

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

Does Open Source Materially Contribute To The Business?

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

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

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

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

When To Open Source

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

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

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

Storj Virtuous Cycle

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

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

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

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

Other Decentralized Opportunities?

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

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

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

Other FOSS Cryptocurrency?

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

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

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

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

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

Challenges Of Launching A CryptoCurrency

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

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

Treasury / Governance Of Currency

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

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

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

View On Red Hat Acquisition

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

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

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

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

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

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

Michael Schwartz: Now, we have less.

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

Move To Open Source License

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

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

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

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

Biggest Challenges For Open Source Businesses?

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

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

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

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

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

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

Advice For Entrepreneurs

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

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

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

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

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

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

Closing

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

Ben Golub: Great questions, thank you.

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

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

Music from Broke For Free and Chris Zabriskie.

Audio editing by Ines Cetenji.

Production assistance and transcription by Natalie Lowe.

Operational support from William Lowe.

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

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

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

Until then, thanks for listening.

lliam Lowe.

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

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

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

Until then, thanks for listening.