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.