Docker Founder Must Right His Ship

Holiday Gift Guide 2015: What Techies Want

(Click image for larger view and slideshow.)

Success can build a feedback loop that sustains its own momentum, making those who are successful certain they are doing the right thing. I don't want to charge Docker with such hubris, but recent events illustrate why open source code projects function the way they do.

The beauty of open source code is that there are breakpoints in the feedback loop. Some outsider speaks up and says, "What you just did was wrong, the code was no good, the function doesn't belong in the heart of the product, and, by the way, your code review process stinks. Maybe I'll start my own project."

The threat of a fork keeps project leaders on their toes. They don't want to give up a major initiative, along with a segment of their best developers, to a competing project. Somewhere in its recent rush to prominence, Docker's code leaders didn't listen. There must have been rumblings of discontent within the ranks about Docker's direction. In effect, the drive to standardize and make Linux containers more useful just split off a dissenting group: CoreOS's Rocket. It remains to be seen whether Rocket becomes a legitimate threat to Docker's place in the cloud container driver's seat.

[For more on Rocket's competition with Docker, see: Rocket Vs. Docker Will Come Down To DevOps.]

Docker didn't come up with the original Linux control groups or Linux namespaces on which containers are based. If it began assuming what's good for Docker Inc. would always be good for Linux containers, it was on thin ice. Docker founder and CTO Solomon Hykes was skilled at envisioning what could be done next from a developer's point of view with containers, but developers aren't the only parties with a stake in containers. And not all developers fit into Docker's definition of what developers should be doing. For some, "open," as in Docker open source, began to feel more like a straightjacket.

Leaders in open source projects tend to be good at doing two things. They recognize good code when they see it, but perhaps more importantly, they can both listen to submitters and infer from the code the submitter's point of view. I've always been struck by how much the committers of a project are able to conclude about the talents and attitudes of contributors from brief email exchanges and the code itself.

In some cases, with little or no face-to-face interaction, they accept and congratulate the contributor or they reject and advise a would-be project participant. When arguments ensue, they don't hesitate to say when someone is getting a little full of themselves. Egos are kept in check, and issues are decided on how well the code fits into the strategic direction of the project. Committers are elected for the task by the community because their abilities to both listen and think on their feet show up in their comments on other people's work.

Brian Behelendorf did that with Apache. Linus Torvalds did it with Linux. Marc Fleury did it abrasively with JBoss, forking the project in process (but the fork never went anywhere because he continued to guide the code's strategic direction wisely). (JBoss was acquired by Red Hat in 2006 for $350 million.)

In the aftermath of the Docker fork, it seems clear that not a lot of quality listening has been going on. Docker's Hykes is a skilled code creator; some people call him a technical genius. He's responsible for establishing Linux containers in what may prove to be their most widely used format. But like I said, successful open source project leaders also listen.

Solomon Hykes
(Source: DockerCon)

About a month before CoreOS publicly broke away from the Docker project, on Nov. 6 Hykes issued 13 Docker tenets. After CoreOS went public Monday, Hykes responded in a blog post and on Hacker News: "Hi, I created Docker. I have exactly three things to say," with number three being a reference to the 13 tenets.

Hykes' first comment was: "Competition is always good ... Docker brought competition to lxc [Linux containers]. And now tools like lxd, rocket, and nspawn are bringing competition to Docker. In response Docker is forced to up its game and earn its right to be the dominant tool. This is a good thing."

Next, he said: "'disappointed' doesn't even begin to describe how I feel about the behavior and language in [CoreOS's] post and in the accompanying press campaign. If you're going to compete, just compete! Slinging mud accomplishes nothing and will backfire in the end."

Hykes was objecting to CoreOS's post on its Rocket container runtime. The post set out CoreOS's goals and objectives and didn't hesitate to cite how it differed from Docker. In establishing an open source project, all of the foregoing should be fair game.

His third comment led to his 13 tenets; the last three are most relevant here:

"11) Anyone is free to try 'embrace, extend, extinguish' on Docker. But incentives are designed to make that a stupid decision.

"12) Docker's scope and direction are constant. It's people's understanding of it, and execution speed, that are changing."

And, saving the best for last: "13) If you USE Docker I should listen to your opinion on scope and design. If you SELL Docker, you should listen to mine."

These three points treat the Docker ecosystem of partners and contributors in a condescending fashion. Everyone in the community has the right

Next Page

1 of 2