This week we talk with Solomon Hykes, creator and founder of Docker, the open source platform for distributed applications. Solomon discusses the shift from DotCloud to Docker, why you should trust your instincts, why a good product can survive surprisingly long without marketing, and much more.
Listen to the podcast in the player above, or click here to download it directly. Subscribe on iTunes or do so manually by using this RSS feed.
Show notes
Transcript
Alexis: Solomon, thank you for taking time on your schedule to join us on the podcast!
Solomon: My pleasure, thanks for having me.
Alexis: Not a problem! Alright, so before we get to Docker and dotCloud and all that good stuff, tell us a little bit about yourself.
Solomon: Sure. I’m a 30-year-old programmer, made entrepreneur, made CTO. I grew up in France; I have a complicated and irrational family. I was born in the US, but grew up in France most of my life. Did engineering school there – I’m in software engineering – and I’ve always been really fascinated by this general trend of taking lots of computers and wiring them up together and using them as one computer. I thought it was the coolest thing ever, and started to think of that pool of machines as something that can continue to exist even as the individual machines come and go. That was always kind of my thing even at school, and most of my projects had revolved around that cool concept of upgrading what it means to – upgrading the definition of a computer, really.
And so that led to me taking on various jobs focused on IT and infrastructure management, automation, and after a few jobs doing that, I realized–
Alexis: Actually, before we get too far away from the whole “I was raised and studied in France thing,” I’m sorry if this gets too personal, but man, there’s no accent. It is amazing [chuckling].
Solomon: Yeah. I was born in the US; my dad’s American, and so even though I grew up in France, I continued speaking English with my dad. My mom was French-Canadian and she’s an English translator, so she also speaks perfect English. It’s very disturbing for guests because the whole family – we have a big family, and everyone’s switching back and forth between English and French the whole time, mid-sentence. We don’t even notice. So that’s why.
Alexis: Alright! Sorry, I had to ask.
Solomon: No worries.
Alexis: In doing my research, listening to another interview that you did, I was like, “Whoa!” I got to ask about this.
Solomon: You could say I’m an undercover French.
Alexis: [Chuckles] Alright. So you’ve been working on some jobs that focused on orchestrating computers together and making sure data flows between them. How does that lead to dotCloud?
Solomon: Mostly, what led to that was the realization that we were all kind of reinventing the same wheel over and over again, and I think that’s still true today, but it was very, very true in 2007. That’s when I quit my last job and decided to do something about it.
So in 2007, I realized, “Okay, every job I’ve been at, I’ve had to write the same kinds of scripts, follow the same kinds of patterns and developing and deploying code and managing machines.” It just seemed like a huge waste, right? I thought, well, these last three jobs I’ve had, multiply that by every job that involves some sort of CIS Admin and development work and automating the deployment of software across many computers in a coordinated way – that’s a lot of wasted engineering time.
I started looking into standardized tools and I realized, “Okay, well there’s bits and pieces, but they don’t form a cohesive whole.” I can’t just set this thing up and then I’m set. And I like to use the comparison to things like the iOS or Android in the mobile world. If I’m developing for that kind of a computer, then that’s a nice, paved road. You have the SDKs and documentations and it’s all kind of figured out.
Alexis: You don’t have to whip out a machete and clear your own path.
Solomon: Exactly, and it really felt like the early days, and so I couldn’t find tools that qualified that into a lot of commercial offerings. There was one called Opsware at the time that claimed to be this magical platform that would automate, take your whole data center and absorb it and automate plumbing to it. I evaluated it, tried it and it was just super expensive, and it was very big and monolithic, and it was not what I had in mind.
I thought, well, what if we did an open source version of something like that? It was very vague at the time what the form factor would be. Opsware sold for something like a billion and a half dollars to HP, and I was like, “Wow! So people agree that doing something like that is valuable.” Because up to that point I thought, “Oh, a CIS Admin who codes – these are just what you think is cool when you’re a CIS Admin who codes. No one really cares about this other than me and my buddies.” It turns out, “Wow, looks like a lot of people care about this.” And that’s why I quit my job and said, “Okay, I’m not sure how this is going to happen, but I’m going to try and build tools like that that everyone can use in a standardized way to do this, to deploy software to a lot of computers in a coordinated way.
Alexis: Alright. What was the origin of dotCloud for that? I mean what were the early days like?
Solomon: So the early days were – there were three phases. First, a very, very – you described kind of clearing your way with a machete. The first phase was like that – just figuring out everything, figuring out what code you’re going to write, for whom, what’s the vehicle for that, is it even a company? It wasn’t clear if this should be a startup or if this should be a research lab, so just figuring out everything.
To be clear, for a while, everyone around me said, “Oh, awesome. You quit your job to do this awesome thing. Tell me more about it.” And then I would give them the extents of my plan and roadmap, which was not much. It was basically a gut feeling and something I thought that was cool like, “Oh, you’re an idiot.” [Chuckles]
So I moved back to Paris because I lived in California at the time, and moved into my mom’s basement and started from there. We bootstrapped the best we could; I’ve been consulting the custom development jobs, whatever jobs we could find basically.
It was a small crew, with the four of us; we all did these random stuff and then in the evening we would hack on pool open source prototypes. What we converged towards – it was a lot of fun, it was a terrible business and no one remembers this. By the way this is a different dotCloud than the dotCloud most people know. DotCloud, the Heroku competitor, the Platform as a Service – this is before that. This is phase one, no one knows us, no one cares.
Interestingly, a lot of the breakthroughs came from that period. First of all, the use of containers, were not as lightweight servers which was at that time was how everybody used them, but as a unit of software delivery. Something more like the JVM or JAR, something a developer reasons about. I build it, and then I ship it, then I run it. It was a different use of existing technology. So that came out of that period among other things. Anyway, that’s phase one, didn’t go anywhere as a business but was a lot of fun.
And then around 2010, we joined Y Combinator and transformed dotCloud from a little bootstrapped consulting shop doing open source on the side, to a Venture-backed California based startup doing Platform as a Service. So we launched dotCloud.com, a Heroku competitor in late 2010. That’s the beginning of phase two, which is the dotCloud most people know.
Alexis: Let’s spend a little more time here at phase two of dotCloud. So you get to Y Combinator – this is obviously a big boost in many ways. How did you manage traction in the early days? How did you spread the word?
Solomon: That was the big question and we had no clue how to do it. Honestly, Y Combinator really helped us.
Something to keep in mind is we were really not your typical startup material. We did not start from a clear business objective. We did not even start from a clear need in the market. We didn’t start from “this group of people have this problem, therefore we’re going to provide this solution and then we’ll sell it in this way”. Then make your way back from there and produce an MVP, etc. We took it completely the other way around.
We were engineers, and we had this general sense that something awesome was underway. We weren’t sure what but there’s just this gut feeling that a lot of people are going to put lots of computers together and use that as one computer and run software on that like one computer, it’s going to be completely automated and it’s going to be awesome. I really want to do that. Beyond the feeling that it was going to be awesome and important in some way, that a lot of people will need it, that’s as far as we went in terms of a –.
Alexis: A business model.
Solomon: Yeah, a market analysis or anything like that. We weren’t even sure – and the key insight that was missing was the people to go to first are developers.
If I had to summarize what we learned in YC, it’s that technology is not enough. You need a product, and to add a product, you need to find an initial group of people that have a need, and then you need to solve that need in a way that gets them excited.
Maybe it sells your technology short because there are a million things that could be done with your technology and you’re only going to be doing one, but at least someone will care because right now no one cares.
Y Combinator is very good at beating that into people who don’t have a clue, like us. That’s really what they do. I would go talk to Paul Graham and say, “We have this amazing technology and we’ll do this and do that. It’s this universal layer using containers and there’ll be all this different verticals and different industries will use them for different things.” He’s like, “No one cares.” [Chuckles] Nobody cares! So find a group who will care and start from there.
So we did that and eventually that led us to this idea of “Let’s go after this category of Platform as a Service.” Web developers have this very specific problem – they write these web apps and it’s hard for them to get them online, so let’s help them do that. There was a company called Heroku which did that really, really well, but only for Ruby on Rails apps. There was a lot of chatter, a lot of interest in something like that.
Alexis: But for Python or for JavaScript.
Solomon: For Python, exactly. There were some clones popping up for each of those silos that e were thinking, “Well that’s all the same thing, it’s just containers.” So from the technology point of view, that’s silly, it’s easy.
Turns out it’s hard in other ways. But from a technology point of view it’s not that hard. You package up the application stack into a container and you put a code on top and that’s a container. Our tech did that, so we didn’t really see why everyone was so excited; it seemed obvious to us. But we were really bad at other things like UI or explaining to a developer why it matters to them but we learned along the way.
The result was like Heroku, but for multiple languages. It turns out that was a very exciting story for a lot of developers because that was what they needed. It was just at the moment where there was a true explosion in different stacks, different languages, different frameworks, different databases, and web developers really, really wanted to mix and match.
They were not finding what they needed in these different siloeds – Heroku for X Heroku for Y – because they had to go and work with ten different companies to run ten different parts of their stack. With the help of Y Combinator we crafted that story and we launched on that story – Heroku for everything, basically, and we were the first to do that, and we got a lot of buzz out of that.
The very early days – January of 2011 we launched the beta of dotCloud; got a big TechCrunch article, a lot of buzz. Tons of people have signed up for the private beta and that got us goingl; we built up from there.
Alexis: Speaking of some of the growing pains might be UI and marketing, what were some of the growing pains at dotCloud in those days and how did you solve them?
Solomon: Marketing and UI were big growing pains [chuckles]. This was a company of systems engineers, and everything else – ops and systems – so we knew how to run stuff in production at scale. We know how to monitor it, we knew how the system worked under the hood, and we had that excitement, that instinct that a lot of people should benefit from that, and clearly a lot of people were not. So the fundamentals were sound, but marketing to developers is a craft and we did not master that craft at all. It was very hard for us to compete with companies like Heroku which are very good at that.
We learned along the way, but it was painful because in our minds, marketing is marketing. I’m an engineer; marketing is all that stuff that I don’t want to do. It turns out that marketing is a very broad topic and beyond the buzz words and beyond the characteristics that annoy programmers, it’s incredibly important and valuable and not necessarily stupid like a lot of programmers think.
I think, by the way, that’s a pet topic of mine. I think this whole culture of “Oh, if you’re a programmer and you get into the business of trying to convince people that what you do is interesting; you’re impure or you’re selling out.” That is the stupidest thing you could possibly say because if no one uses your code, why are you writing it? We’re supposed to be solving people’s problems, whether we like it or not, we live in a society where a lot of things compete for people’s attention and you got to make the effort.
If your code’s worth it, you got to make the effort to explain it, package it up, and think about why is it relevant to – why is it worth this person’s attention. That’s marketing. I thought it was really interesting, I approach it as an engineering exercise, but it was definitely a growing pain.
Alexis: So I imagine that with growth means that you have to hire more people. What were some of the first roles that you hired for?
Solomon: With dotCloud, and we’re still talking about phase 2 right? Phase three, spoiler alert, is Docker. With dotCloud, our maximum was twenty people. For three years or so, we went back and forth between five and twenty people. So we learned a lot, but the kind of problems we had were not about hyper growth. They were mostly about things that are true at any size, like how do you select the right people, how to convince people to stay, how to make sure people get along with each other, how do you find the balance between a fun environment. You spend so much time with your colleagues, you want it to be fun but at the same time, we respect people’s boundaries, not create this weird bro startup where you feel like you have to go drink with everyone even if you don’t like drinking. That was an interesting puzzle for me.
Alexis: As Twitter tells me, a vital part of that was Carcassonne?
Solomon: [Chuckles] Board games are cool. It’s interesting because part of it is also figuring out a way to hire a diverse set of people. It’s also an interesting topic because that was a perspective coming in as an outsider into Silicon Valley.
Silicon Valley attracts a lot of people from all over the world, from very different backgrounds, but at the same time it could be really homogenous. What was interesting for us is we were not your typical –.
Alexis: You were not so homogenous.
Solomon: We’re not homogenous at all. The starting point of dotCloud at phase two was five French people landing on shore and setting up camp on San Francisco basically. But we tried really hard not to create a French company, like in a French bubble.
We tried to hire people who lived here or lived in other countries but wanted to move to California. Turns out, expatriates, even if they’re from different countries, they have a lot in common. They’ve come all this way to achieve something, they have a different perspective; they don’t take things for granted. I think if you’re born in the system, in Silicon Valley, it’s easy to take things for granted.
Alexis: Yeah, you’re in the bubble.
Solomon: Yeah, you’re in the bubble sometimes your whole life. You went to high school in Palo Alto, you went to Stanford, got a gig at Google, your ex-Google buddies brought you on board on their startup – that description fits a lot of amazing people, that’s not the point. It’s interesting to have different perspectives and that’s something I think is very valuable. It helps build a healthy culture.
Alexis: Speaking of, what are some other qualities you look for when you’re hiring folks?
Solomon: We try to hire adults. I guess that’s the best way to describe it. When you’re in a startup – and this is true now at Docker, which is a very different environment – we’re growing incredibly fast. Unlike at dotCloud, we have a product that has reached critical mass. An amazing number of people want it and tell us about how much they want it. So there’s hyper growth, something that never happened to us at dotCloud. I’m switching to phase three here but it’s the same thing.
You want to hire people who can handle a situation like that and still – through the ups and downs, the insane highs. There are things that happen at Docker that are just ridiculous.
When Microsoft announced they were going to bundle it in Windows 10 and sends a large number of engineers to contribute, to port Docker to Windows in the open like any other open source contributors – that was a huge –.
Alexis: A big win.
Solomon: That was a big win, and so it’s easy to lose your focus and fall into –.
Alexis: Yeah, “We’re on the top of the world!”
Solomon: Exactly, or just assume that whatever comes next, we’ve earned it. Of course, things are going well because we’re Docker; we did this, we did that. You want people who don’t fall into that trap because the reason they’re here is not for that moment; they’re here because they want to build this and they want to do good work.
There’s a builder’s attitude to life where at the end of the day it’s about the work you do and the impact you have in the world in the healthy way – I’m not sure how to describe it better than that. A lot of programmers are that way, but a lot of non-programmers are also that way; that’s something I learned. Some people are builders and some people are not, and we like to work with builders.
Alexis: That’s a good way to put it; I’ve never heard it put quite that way. Now that we’ve mentioned phase three a couple of times, I think it’s time that we ease into it. Bring us up to speed on how that came about.
Solomon: Sure. We’re building this business, we got dotCloud and it’s working, we’ve got paying customers, we’re scaling it, we’re going through all the growing pains. A year goes by and two years go by and it’s still good and it’s growing, but it’s not amazing. We’ve never seen amazing so we’re not sure.
Alexis: You don’t have a barometer.
Solomon: Yeah. Things are going up, there’s more customers and when we find a leak in the funnel – something that causes our customers to leave – we fix it, and then they stop leaving and we move on to the next problem. We figure out how to do support properly, we tweak the pricing and all that, but it didn’t feel like we were in a position where we could really play to our strengths.
And particularly, what was pretty draining is initially we’re carried by the novelty of Heroku for every language, and then eventually the novelty wore off and others followed the model. Eventually Heroku got around to supporting multiple language.
Other platforms came about copying that model; Cloud Foundry launched and OpenShift launched by Red Hat. These were open source versions, and so what you start seeing was number one, that Platform as a Service in general was not a huge market. There was no big winner, there still is no big winner in Platform as a Service. It’s not that big of a category in the first place.
Number two, and more importantly, for us it felt like the starting point made sense. We had this amazing technology that we’re interested in, let’s pick something and focus on that thing, one application to that technology, and now we have a product. We have a starting point, but now we found ourselves in a place where mostly it was about getting better at marketing to developers, getting better at scaling and operating a business, better conversion rates from the landing page, better retention rates, things like that – all very interesting problems, but not our core; it didn’t have to do with our understanding of how systems work–.
Alexis: With building, yeah.
Solomon: With building, right. It was disconnected from that initial gut feeling, that initial excitement that caused me to quit my job in the first place, that whole phase one.
So it felt like we reached a local maximum. We were looking for a way out of that local maximum but we weren’t sure what it was. So we tried a bunch of things and eventually after a few failed experiments, we tried to go back to the roots, basically.
We said, “Hey, what if we open the trunk of the car – metaphorically, the car being dotCloud – and took the engine out?” It turns out it needs an upgrade anyway because we’ve been running it in production at large scale for two years now and we need to tweak it and upgrade it. But what if we went further than that? What if we ripped out the engine and rebuilt it completely based on everything we’ve learned from the beginning?
All the way from these first experiments with containers; all the way to everything we’ve learned running it at scale for all these customers at dotCloud – all of that is based on containers. It’s based on this engine that could package up any software and run it as containers, and then these containers could move anywhere.
What if we took that component and turn it into its own product, sort of a Lego brick, kind of the universal Lego brick for building systems like this? So maybe our competitors would be interested and maybe other companies that are not a big fan of Platform as a Service because it’s too specific, it’s too monolithic, it’s not configurable enough. That was one big problem we had on the space in general. It felt like Platform as a Service – customers, it helped them get started, made their lives easier in the beginning, but then they were looking for that Lego feel that they could remove any piece and tweak it and start building their own version of it.
Alexis: And they ask, “What about support for this or that? I have to build it.”
Solomon: Exactly, and it turns out there’s an infinite variations of that. You can’t chase them by just adding them yourself; there’s too many configurations, combinations of changes.
We thought, “What if we let them do that with our core container engine – it can do that, right?” and that’s what we did. We started open source project on the side and we called it Docker internally.
We wrote it from scratch – it was actually an explicit requirement that we should not copy paste the existing code. We should force ourselves to rethink through all the problems and draw from our experience but not be limited by it either. We started showing it around to people that we knew were interested, that were on the same space. We showed them to the Heroku folks.
Alexis: [Chuckles] That must have been an awkward meeting for them.
Solomon: Not really because, what’s interesting with Heroku is I know the founders well. They left the company now but I knew them well over there. We were competing, sometimes pretty fiercely but there was always a lot of mutual respect because they were builders, basically.
We said, “Hey we want to do this thing, what do you think?” And showed it to other people. Other companies in that general space and a lot of people were very excited. They said, “We have something like that; that we started or that we were going to start, but we’d rather just pool efforts and build it together, because that’s not our value add.” This should be a standard building block that everybody uses, and it’s much more powerful actually if everybody uses it. It’s like Lego – if it’s the same shape of Lego brick, if it’s the same connection system then there’s a lot more bricks you can use and that a lots more powerful for everybody.
We just expanded from there and gradually showed it to more and more people. Eventually, we had 60 people in this closed open source and then it leaked.
Funny story: the way it got leaked is, so we had this list of people I knew and we would knock on their door and say, “Hey, want to see a demo of our thing we made, and what do you think?” Eventually we thought, “Let’s try to add a larger group of people. There is this conference. It’s called PyCon.”
Alexis: Oh yeah, very familiar with it.
Solomon: This is March 2013. I said, “Hey, have Lightning Talks. Let’s do a Lightning Talk about containers and maybe we can give them a demo of Docker if we felt like it’s the right crowd.”
We prepared this little demo of Docker. Here’s what I was picturing – I was picturing ten to three people in a back room, cramped together, talking about a Linux container, the least sexy topic ever for a Python conference.
Turns out Lightning Talks are a big deal on PyCon apparently, and they put them in the main room and it’s the main track; these are five-minute slots. So I show up, and there’s 900 people [chuckling], all watching as I give this terrible demo of a Hello World explaining why we’re doing Docker, what it is, here’s a sneak preview, and people really liked it. It was taped and so the video was put online and a lot of people watched it.
Then the next day our unfinished homepage for this future project yet unlaunched was posted on Hacker News and stayed on number one for two straight days or something crazy like that. Something really unusual, which by the way we did not know for most of the day until somebody said, “Psst! You’re on Hacker News and there are 200 comments. You guys should probably go and check it out.” [Chuckles]
Alexis: And comment on stuff.
Solomon: Yeah, and comment. That told us that people are excited and basically an ever-expanding way of more people getting involved and getting excited and asking, making suggestions, sending patches, all the way to now, a few years later.
Alexis: Fun fact here, if I did my research correctly, the initial release of Docker was on Friday the 13th. March 13th, 2013.
Solomon: It’s very possible [chuckles].
Alexis: It’s somewhat ironic that you might have launched on Friday the 13th but everything went fantastically.
Solomon: Maybe that’s a launch guideline; whatever you launch, do it on Friday the 13th. It’s going to be a crowded calendar.
Alexis: It sounds like you didn’t have all that much of a problem with marketing Docker. Still, as time goes on, marketing as you mentioned earlier, is still pretty essential. What are some things that you had to overcome and maybe some strategies that might help other folks when it comes to their projects or products?
Solomon: It’s interesting because it was the same group of people that “marketed” Docker when we first launched it. It had a really basic website; it was not that attractive. It did not have the famously cute logo at the time. It has an image I had copy pasted of a cool Lego construction with containers. I don’t know if you’ve had that one. It was a set with a truck and a train and then a container you can move from one to the other and it had this cool crane to move it from one to the other. I put the picture of that; that was the logo for a while. I think Lego said “You guys should take it off.” It was not a marketing-driven exercise at all.
It’s really funny because now that Docker is very popular and we did get around to getting more polished at marketing. We now have a PR firm and we are organized about how we talk about journalists, for example, when we make announcements for things like the Microsoft partnership or things like that. We got around to that pretty late.
Before that all we had was one guy, Julian, who basically helped organize meet-ups for the people who really wanted to get together to talk about Docker and we’re going to do it whether we liked it or not. We would provide chairs and pizza, and they would show up and we would all have a great time showing each other cool hacks on Docker. We would show what’s coming in the next version.
The first meet up was 15 people, the second was 40, the one after that a hundred, and now there’s 140 meet-ups around the world. So there are more meet-ups than there were people on the first meet-up.
Our marketing for the better of the first year was almost entirely just managing that, but it was happening whether we want it or not. There’s a strong sense – I’ve never seen anything like that before. We did this thing and we showed it and all of a sudden this community of people appeared and said, “Okay, that’s our thing now. We’re going to take this and we’re going to make it awesome. You’re welcome to keep doing what you’re doing.” It really felt like this community appeared and then gave us this mandate of “try to keep things organized”. It’s been challenging but that’s where marketing comes from.
What I was saying, it’s really funny, because now every once in a while we hear someone say, “Oh Docker, it’s all marketing fluff and no substance.” Again, back to this instinctive decision of the programmer thing of, if you’re explaining to people why your work is good, you’ve sold out, you’re evil. I think that’s really sad because it discourages people, but also it’s really funny in our case, given what we know of how bad we were at marketing in general [chuckles].
Creating demand on our own – you need to have a product that people love and a community of people who are enabled to use it and talk to each other and do cool things with the product, and then you can have marketing. That’s what I learned really, that’s my lesson: product comes before marketing. When it comes to software products, a 100% you can’t out market your way out of a bad product, ever.
You can actually survive surprisingly long with terrible marketing and an awesome product, but that was not our case because Julian – it was one guy, but he was really good. For example, he managed to keep those 140 meet-ups on track and now we have a whole team doing just that. Now there’s DockerCon which is like on a giant meet-up. That would be my advice.
Alexis: Now it sounds that the community is largely attributable to the fact that Docker is open source. What have you learned about working with open source projects? What have been some of the hard things to deal with?
Solomon: There were two months that were really hard. The very beginning was hard because it required a hard decision and the decision was “How open should we really be?” That’s actually not an obvious decision because there are lots of ways to do open source.
Actually, at dotCloud, we had open sourced lots of things, but never like that. The way we usually open sourced was, we wrote a program that we use internally, and then we made it available on GitHub and continue to develop it in the open. But it was an extension of our internal engineering effort which is that you got a team and people are assigned in different parts of the product. But really its one team and people can change the code of any area of the project.
If you’re an employee of the company then you are expected to go in and improve all these projects. If you’re outside the company, you’re welcome to send a patch and we’ll gladly review it and maybe merge it but we’re not making a special effort to involve you in the design discussions, the long-term road map or anything like that.
That’s how most open source projects sponsored by companies are. It’s not necessarily a bad thing, but we decided that we did not want to do that. We decided that because of the nature of it, the goal being to create this standardized Lego brick and get a lot of different companies to collaborate in developing it together – that was the explicit goal.
Remember, the reaction of the first few people we showed it to was exactly that. They said, “Hey, we’re doing something already, but if you guys want to open this up we would love to just merge and join efforts.” So we had to accommodate that and we wanted to accommodate that, so we made a decision, which is a difficult one, which is to say, “We’re going full open design completely. We’re going like Linux.”
It’s difficult because for the company and for the people in the company it means just because you work in the company doesn’t mean automatically you get a say. You’re just the same as any other employee of any other company. The only thing distinguishing two people is whether they’re a maintainer or not. So there are rules that are inherent to the project. The project becomes its own entity in a way.
The first few days, it was funny because it was a side project, so it was me and another guy, and everyone else was working on dotCloud, the regular dotCloud. They see this repo pop up, one more repo under the dotCloud org and they’d be like, “Oh, that looks cool; I’m just going to change it a little bit.”
Then I’d walk up to their desk and be like, “Don’t change that, no. It’s different, you got to send a pull request and there’s a mailing list here and we’re going to discuss it and there’s a maintainer system, and it’s this cool thing.”
Their initial reaction was, “That’s stupid, it’s slow. We got to discuss everything and I could just merge it now.” We had to make that call that it was going to slow us down initially as overhead, but it would be worth it because we could build a real large community and we could scale the project much, much, much larger. And that’s paying off in a big way now.
Alexis: Now, you touched on something that I was thinking about. How did you convince the team at dotCloud that Docker was the right thing to be working on, but on the same thread, how did you convince investors?
Solomon: Good question. The first prerequisite to pull this off is to have awesome investors. We were lucky and we had really good investors. We optimized for it. What I mean by that is when you raise money you can optimize for different things. You can optimize for the absolute best financial terms on paper. You can optimize for the absolute best partners. You can optimize for the fastest fundraising. You can optimize for a lot of different things. You can optimize for the least dilution for the founders. There’s a lot of different ways. Sometimes you can achieve multiple goals at the same time, but usually you have to choose. Definitely whether you know it or not, you’re optimizing for something.
Our approach was to optimize for the best individual partners. It’s also different to go for the best partners – the best individual VC versus the best firm based on the brand of the firm, because different investors work on the same firm. We went for the best individuals, the individuals we really want to work with most, just like a hiring decision, plus good terms – it had to make sense financially.
We were lucky in that sense because dotCloud at that time was a hot opportunity because it was Heroku for everything. Heroku was taking off in a big way and it had just sold for a very decent amount. I think over two hundred million dollars or something like that. To really make the simplistic math, two hundred million from this company, they did one language; these guys do ten languages. No one did the math in that way but the opportunity seemed big, so we can easily get good terms. So we optimized for getting the best partners.
My point is really you can be deliberate about it. At some point, for example, we optimize for – these are terms we are comfortable with, we like them, they’re very good. Probably if we drag things on for another two weeks we could squeeze another whatever percentage point out of dilution less or maybe some extra cash for the same dilution.
But is it worth it? No, because while you’re raising money, you’re doing nothing else. At the end of the day, money in the bank is great but you’re supposed to build a company.
Anyway, we needed great investors. We had Peter Fenton from Benchmark, Dan Scholnick from Trinity, Jerry Yang, Mike Burstein. Their attitude was, “Look, it’s been good but not amazing for the last two years. You’re doing the right thing. You’re looking for the root cause, you’re attacking the problem – better conversion, better retention, improve the product. We’re seeing just like you that the Platform as a Service market is not the incredible high growth market that we thought it would be. Whatever you want to do, we’ll support you, basically.” They had the patience to follow us through, one failed experiment, two failed experiments, three failed experiments. Holding me accountable, but not bailing, not pressuring us into selling – nothing like that.
At some point I came back and said, “I have this gut feeling, the same gut feeling that I had when I first quit my job to start this. We’re going to do this; it’s going to be amazing. Here is the outline. There’s a lot of uncertainty but in a nutshell, we’re going to take the engine out of the car; everything I just told you. We might fail but at least we’re going to fail doing something that is us and is based on what we do best.” It’s not going to be trying to be Heroku with better pricing or throwing cooler conference. We want to do something that was distinctive, that was us. They said, “Alright, go for it.”
Alexis: So the plan for a – actually, within the company, too, was it fairly easy to get everybody on board?
Solomon: For most people in the company we were very careful not to disrupt their day-to-day as we worked on the beginning of Docker. So that whole phase where it was a side project – me and someone else going and knocking on doors and showing it, et cetera – that whole time, everyone on the company was focused on executing. So what we did not do is stop everything and then start brainstorming with 20 people and say, “Okay, what do we do next?” It was a small bet first, and then eventually we saw it was beginning to work.
Well in small ways – it wasn’t clear whether it will be huge or not. There was something, people seem unusually excited. It’s been 20 demos in a row and everyone’s excited.
So what do we do? Just around the time where we went to PyCon and gave that talk, basically after that talk, after the 800 people and the video went viral, et cetera, we’re like, “Okay this could still crash and burn but clearly there’s potential. What do we do?”
That was a tough decision. Eventually the decision was we’re focusing on Docker; we’re not going to do dotCloud anymore. We did not shut it down; we actually kept running it for a whole year and lost almost no customers during that year. Actually, dotCloud grew larger during that year when we stopped focusing on it than at any point in the past, which was a little depressing.
But we stopped focusing on it; we focused on Docker. For most people on the team, that’s when they learned that, “Okay, we’re going to be doing Docker.” Some of them were okay with that, some were not and left, others were not convinced but decided to give it a try. Others unfortunately I had to lay-off because it was too many of us to survive the whole thing. It was definitely not an easy moment. It was a big, kind of “This is a big bet on the company.” It was a bet the company moment.
Alexis: Right. And just to be clear on the dotCloud status, its heart is still beating, right?
Solomon: DotCloud the company has been renamed to Docker. It’s the same company all along. DotCloud product is still running; we have since sold it to a former competitor called cloudControl based in Germany and they’re running it. They’re working on integrating the two products together. The heart is still beating, the customers are still supported.
Honestly, I’m very proud of that because I think we worked really hard to convince a lot of people to trust us with their applications. Some of those applications, their entire business is based on it; there’s a lot of startups using dotCloud. I really, really, really did not want to be sending that email saying, “Thanks for an awesome ride; you got a week to vacate the premises.” I hate those emails. I understand when they happen but I really didn’t want to have to do that. We worked really hard to make sure that we didn’t let those customers down.
So we were very transparent. We said, “This product is no longer our focus. We’re not going to try very hard to be the most innovative PaaS out there, but what we told you we’d do, we’re going to keep doing.” If that meant going maybe a little slower on Docker, then we’re willing to pay that price.
It turned out we were fine because we invested a lot of effort in automating the operations of dotCloud in the first place using containers. So we were able to run it with not a big investment, like a rotation of maybe two to three people running it and supporting it.
Alexis: So from the outset, the monetization model for Docker was the classic commercial open source where you get a lot of people using it, and then you do support, education services right?
Solomon: Actually that’s part of it, but we’re actually rethinking the model of commercial open source in general. It’s a key aspect of the innovation of Docker. We think there’s a new way to combine open source and business because we’ve learned a lot and I think we have seen the first generation model but open source and business took a while to get used to each other. Still today there is that feeling that you have to be primarily one or the other but they don’t mix really well. I think that’s kind of putting your head in the sand to say that. At the same time, some models work better than the others.
We are specifically not saying we want to be the next Red Hat, which is what you described right? Support subscription, training, pro service, et cetera. We’re selling some of that because –.
Alexis: People want it.
Solomon: Exactly, there’s demand for it that’s necessary but not sufficient. The other requirement is it has to be truly good for the project for the company to sell this. The nice thing with selling support is that you’re helping companies feel good about using Docker; you’re helping them be more successful using Docker. When you’re selling training, you’re helping more people use Docker better. That benefits the open project; it benefits everyone else. As a business we think it’s a good starting point but that’s not the plan – it’s kind of, I guess, stage one.
We’re also selling something else in parallel. We’re selling a product that we call Docker Hub and that’s a cloud service. That’s the main thing that’s changed compared to the time where most successful – first generation open source companies were started. When that model was designed, cloud did not really exist. Today cloud exists, but not only does it exist, IT departments, where most of us come from, are spending more and more of their money on cloud services. If you’re only selling support and training, it’s very difficult to make money selling cloud services, which is what, increasingly, everybody wants. And so we’re selling Docker Hub.
What Docker Hub is a very simple always on–service for discovering transferring storing containers across your data centers, across your machine, wherever you are. If you use the metaphor to shipping containers, it’s kind of the logistics hub. There’s a lot of cool services that you can sell over time that are not a premium version of Docker – that’s specifically something we don’t want to do – but there are services that are optional; if you use them it makes the experience of using Docker better. It’s very complimentary, and I think over time, we expect to make most of our revenue from that.
Alexis: Since we’re nearing on an hour here, I’m going to try and squeeze in a few more questions. How do you manage burnout and keep yourself organized at the same time? Because man, are you busy [chuckles].
Solomon: [Chuckles] Good question. I’ll be honest – I’m happiest when I find some time to build something. That’s been an ongoing learning experience because launching a cool new open source tool is very different from managing an open source project with 800 contributors.
I think we’ve merged 10,000 patches since we launched. The median, if you sort all these 10,000 patches by how quickly they were merged or rejected, so processed, the median patch took one day.
Alexis: Wow [chuckles].
Solomon: That’s through a small number of maintainers. I did not personally review most of them, but a small team of maintainers who work with me did. They’re doing an amazing job.
One of the lessons is managing and scaling a project like that is very different from starting it. We’re going through a transition right now where Docker is growing in scope. It’s actually no longer one tool; it’s a collection of tools that you can compose. That helps deal with the scaling problem and it helps deal with burn out, which was your question, because now Docker is now more of an umbrella for multiple components.
It’s possible to go back and forth between managing the more mature components and then going back to have some fun and launch a brand new component – an experimental component – or participating in the early days of a new component.
By component I mean, Docker initially did three things. It could download and upload containers, so push and pull, et cetera. It could run them, execute processes in a sandbox environment, et cetera. And it could build them, so as a kind of specification system to go from source code to a new container. These are the three things you could do, so that’s three components.
That’s mostly not changed until six months ago when we started introducing new components that you could use or not. Now there’s a component for managing the machines which will then run your containers because a lot of people start with just a Mac or a Windows laptop and they’re developing and –.
Alexis: And they put it in Linux.
Solomon: Exactly, they want to put it in Linux, but which Linux? They need a VM or a machine somewhere. There’s a new component called Docker Machine which, you say, “Docker Machine add” and it’ll create a machine either in your laptop or in the Cloud somewhere, ready to run your containers. That’s pretty new, so playing with that is cool, and there are a lot more of those components.
That really helps me, when I feel like I’m overwhelmed with just the ongoing, never-ending scaling work, managing lots of other people in the open source and the company; you just go back and hack something new. That’s always fun.
Alexis: So the secret is to change the scope.
Solomon: Yeah, and to allow for the scope to expand because there’s two extremes that you want to avoid and the happy middle is really hard to find.
On one extreme you do one thing once, and then it grows and grows and you manage it and you never do anything else, and that’s hard. It’s hard to stay motivated. It’s also hard for the users because there’s so much more they want you to do, but you’re not doing that.
On the other extreme, you launch a new thing every month and then as you go, you forget about the previous things and it doesn’t fit together as a cohesive whole. That’s also hard because in the end you’re doing a lot of new things but you’re not progressing towards a grander ball. It’s not like you’re building a Lego castle one brick at a time.
I like building the castle one brick at a time. We’re looking for a happy middle where it’s distinct components, but they still come together in an integrated way. I would say that’s the secret to try to find that balance.
Alexis: What’s one mistake you’d rather not repeat? I told you I’d save the hardest questions for last.
Solomon: You didn’t tell me that [chuckles]. It’s not so much I can’t think of mistakes.
Alexis: There’s too many to choose from [chuckles]?
Solomon: There’s definitely too many to choose from, also a lot of mistakes I made are not that interesting and useful to others [chuckles].
I would say not to not trust your instincts, especially when you’re doing something new; starting a company or a new project. I think for builders in general, it’s really hard sometimes because you have that gut feeling that something must be built, and you have that instinct of “that’s good, that’s not good” in what you want to build. You don’t really know where it’s going to lead, but you got to follow it. A lot of times a barrier is erected that makes it harder to follow your gut feeling.
For example, you have to justify in advance what you’re going to spend your time on. To justify in advance, a lot of times the people you have to justify to whether it’s your boss, your board or whatever and they’re gonna say, “Well, what is it you’re going to build? Explain to us what it is and why it’s worth your time.”
A lot times you can’t really put together a compelling argument because you have to try it out first. You got to try a prototype and mess around and tinker. So the problem is a lot of times when you’re put in that situation, you give up because you think, “If I can’t explain it, I’ll just give it up. Maybe they’re right.” Sometimes you got to just do whatever it takes to still follow a gut feeling.
Sometimes it creates friction, sometimes people get upset and they think you’re arrogant. Sometimes you got to say, “I know because I know.” You don’t want to do that and tell other people what to do unless they want to do it with you. You need a space where you’re in control of what you’re building and you have the freedom to experiment and make your own mistakes. Some people never get around to creating that space for themselves because they don’t trust their instincts.
Surprisingly, the number of times where I didn’t listen to my initial instinct and then later found out that I was right, just saying that it’s socially not accepted to say things like that.
Alexis: No, no – well.
Solomon: A little bit. And enormous number of times where I was wrong. Sometimes you got to listen to your instincts – I guess that’s the lesson, I don’t know if it’s very useful.
The worst feeling in the world to me, I have no problem of being wrong – I try all sorts of things and then I’m wrong. Actually I love it because I just learned something. The worst feeling is when you wanted to do something, you had an idea and then you went against your nature, and you end up doing something that you don’t truly believe in. You allowed yourself to veer off that path, and then you’re wrong and it turns out the initial thing you wanted to do was right. That’s the worst feeling in the world.
Alexis: With that, I am going to follow my dreams of becoming an acrobatic competitor in the Olympics [chuckles].
Solomon: Nice [chuckles] follow your instincts.
Alexis: Sorry, I had to make the joke. I like to think of things that way as well. So now the very last question which we covered in the pre–show: what’s your text editor of choice?
Solomon: [Chuckles] My text editor of choice currently is Vim and as I was telling you earlier, I do not have strong opinions about these things. I tend to just use whatever tool is there, which leads to hilarious episodes where the people who I work with who usually have strong opinions about these things and are very sophisticated in their choice of tools and configuration will look at me in despair and pity and eventually do something about it.
For example, I graduated from engineering school in 2006 and in engineering school they teach you use Emacs. So from 2006, for many years after, I used exactly the same Emacs configuration that I learned in school because it works – why change it?
Then I worked with Sebastian, my co–founder at dotCloud, and he’s very particular about his set up and very sophisticated and has a really cool set up. It was just driving him crazy that I had this really terrible set up. And eventually he said, “Ahhhh!” and so converted me to Vim. I said, “This is cool, I could use that.”
He gave me all his secret, his awesome, fine-tuned Vim config. That was in 2009; I still have the exact same config. I have not changed one line in it. He still makes fun of me because his has since evolved and improved and I’m like, “No, I’m good. I’m happy with this one.”[Chuckles].
Alexis: [Chuckles] The grass is not greener on the other side.
Solomon: Yeah, but the nice thing with Vim is it’s everywhere so I can SSH into any box. Every once in a while they don’t have Vim and I have to use Nano but that’s not the end of the world [chuckles].
Alexis: Alright. Where should people go if they want to learn more about Docker?
Solomon: Docker.com is a good starting point. Specifically, if people want to get involved in contributing, one thing we worked really hard on is to make it a great place to contribute and join the community.
There are a lot of people other that have a lot to offer to open source and they’re not sure where to get started. There are a lot of people out there who are looking for an excuse to hack on something and then go.
Alexis: That’s true.
Solomon: Yeah, and there are a lot of people out there who are not programmers but would love to help in other ways, and there are lots of ways that you can contribute in very valuable ways, even if you’re not a programmer. We work really hard to make these people feel welcome and help them find something to do.
Sometimes it’s a little chaotic because Docker, a lot happens. The project is really active but the best place to start for that is the IRC channel on FreeNodes. There is #docker for general discussions and docker-dev for people who are interested in contributing.
I really encourage anyone who wants to give it a try to come by and say, “Hey, I want to help, what should I do?” We’re working on tools to make that more of a self-service thing, like a list of suggestions for projects with a guide to get you started, but the people in there are really nice and I want to emphasize that because some IRC channels could be pretty snarky, an insider’s club.
We worked really hard for that to be not true of the Docker channel. I’m very proud of that fact that the people on this channel surprise me every day with nice and helpful they are. The motto is there is, “There is no stupid question, period”.
Specifically if you want to get involved with the community, beyond using Docker, which obviously you should do, there’s a great online tutorial for that. There’s a gazillion resources for using Docker at this point. But for participating, we really need help because it’s such a high volume project and it’s not that many people.
Alexis: Alright, so if we would like to follow you on Twitter, where could we do that?
Solomon: So my Twitter handle is @solomonstre – S-O-L-O-M-O-N-S-T-R-E.
Alexis: You can follow Binpress @binpress and myself @alexissantos.
Solomon, we’ve made it through on the other end, just over an hour. I honestly could talk to you for about another hour but we’ve both got things to do.
Solomon: Thanks so much for having me, it was a great time.
Alexis: Not a problem! And for the listeners, we’ll catch you next week.
Author: Alexis Santos