"We didn't focus"
If you haven’t read the story in InfoWorld about the death of Docker, it’s a must-read for anyone building a commercial open source company, or for that matter anyone building a company in the cloud native ecosystem. There are a couple key points I wanted to call out, though I hope that readers will just read the entire article and save it to refer to later.
We never shipped a great commercial product,” Hykes told InfoWorld while on vacation in France this summer. “The reason for that is we didn’t focus. We tried to do a little bit of everything. It’s hard enough to maintain the growth of your developer community and build one great commercial product, let alone three or four, and it is impossible to do both, but that’s what we tried to do and we spent an enormous amount of money doing it.
When I speak with founders on my podcast and ask what they wished they had done a better job of at the beginning, focus is usually the first thing they mention. I even see the inability to focus coming out when I run workshops — it is nearly impossible for founders or business leaders to focus on just one value their product provides, even if it is an incredibly important value.
It seems to be human nature to want to feel like we’re covering all our bases. But trying to do everything can prevent us from doing anything really well. In Docker’s case, this meant creating a handful of meh commercial products because they weren’t focusing.
In fact, open source startups are already at a disadvantage when it comes to focus — by definition, an open source startup is trying to do at least two things at once. One is building an open source project that is both technically brilliant as well as also being supported by a thriving community. The second is building a commercial product that is likewise technically brilliant and likewise loved by a large number of customers.
That involves at least three major skillsets, only one of which is engineering expertise — the one thing most founders have plenty of. Community building is a major skill, but it is not the same as sales and marketing, which come into play for the commercial product.
Open source companies are therefore already being pulled in many different directions. It is even more important for them to stay focused on doing an expectional job on the one commercial offering they choose to offer.
With the benefit of hindsight, Hykes believes that Docker should have spent less time shipping products and more time listening to customers.
Listening to customers — what they like, what they don’t, what they actually value about a product — is critical to any company. For open source startups, it’s important to do it even sooner, often before you even have a commercial product available. That’s because what customers say can influence not just what features to include or what market category to slap on the product, but what open source monetization strategy to follow in the first place.
If it were up to Solomon, we would have stuck on the community-oriented route to create virality. If it was up to Ben, we would have moved more strongly to the business side earlier. That tension caused us to do both in a half-assed way.”
Focus isn’t just about going all in with one product — it applies to business strategy too. There are different open source monetization strategies. Choosing the right one requires absolute clarity about who your customers are — that’s why it’s a good idea to be clear about that before even developing a commercial product. But this comment shows that you can’t try to follow multiple open source business strategies at the same time — you have to choose one.
In the end, Docker was trying to go in too many directions, and that is largely why half of the company was sold to Mirantis. Will what’s left of Docker succeed? It’s telling that the current CEO said that his goal is to focus on the core market of software developers — there’s hope that by focusing on the core market and meeting their needs, Docker the company will yet survive.
What about Kubernetes?
I haven’t addressed the Kubernetes question yet — with the benefit of hindsight, that seems like a major omission. But Kubernetes was not always destined to be more popular or more successful than Docker Swarm — in fact, Docker Swarm’s focus on simplicity could easily have either killed of Kubernetes or even co-existed with Kubernetes. In fact, I imagine that a ‘simpler Kubernetes’ would be a compelling message for many companies. But the point is by that time Docker was spread too thin anyway — and perhaps never should have been the company to create a simpler container orchestrator.
What lessons can you learn from this story?
Here are my major takeaways from the Docker story:
Focus from the very beginning
Listen to what your customers say and what they value
Understand what you do better than any of the alternatives and focus on delivering that
Docker’s ultimate problem, as the article makes clear, is that it did not do enterprise support as well as Red Hat did. It was never going to beat Red Hat at its own game, and it made a mistake in trying to. If instead Docker had focused more on what it can do better than anyone else, the course of containerization history might be different.