Docker Founder Must Right His Ship - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT
IoT
Cloud // Infrastructure as a Service
Commentary
12/5/2014
12:02 PM
Charles Babcock
Charles Babcock
Commentary
Connect Directly
Twitter
RSS
50%
50%

Docker Founder Must Right His Ship

After some controversy this week, Docker needs to show it has the maturity needed to manage an open source project.

 Holiday Gift Guide 2015: What Techies Want
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)
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

Charles Babcock is an editor-at-large for InformationWeek and author of Management Strategies for the Cloud Revolution, a McGraw-Hill book. He is the former editor-in-chief of Digital News, former software editor of Computerworld and former technology editor of Interactive ... View Full Bio
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Charlie Babcock
50%
50%
Charlie Babcock,
User Rank: Author
12/9/2014 | 2:22:09 PM
Containers too important to be left to the experts
For additional comment on this rift, see Matt Asay's experienced point of view: How Not To Manage An Open Source Community, at http://readwrite.com/2014/12/04/docker-coreos-how-not-to-manage-open-source. InformationWeek is seeking additional outside comment on Rocket and Docker in the belief that dense computing via containers is too important to be left to the technology generals. Solomon Hykes comments below. Sebastian Stadil, the cloud veteran at Scalr, is being solicited to bring his experience to bear on this topic; others are welcome to express their point of view. Contact [email protected]
Charlie Babcock
50%
50%
Charlie Babcock,
User Rank: Author
12/8/2014 | 1:52:19 PM
Solomon Hykes responds
In a serie of Twitter posts Dec. 7, Solomon Hykes responded to the CoreOS ciriticism of the Docker project. Between 11:15 and 11:30 a.m., he issued a series of Twitter posts, which said in aggregate:

"Hey Charles, thanks for the detailed write-up on the recent criticism of Docker. I thought I'd clarify an important point...  The entire point of CoreOS is that Docker somehow recently evolved to handle build+ship+run. In fact it has done so since day 1. Literally everything CoreOS says about Docker's design has been true for at least 18 months. They had countless opportunities to bring it up but never did. Example: we held our first governance board last month. The minutes are public. You can see that CoreOS said nothing at all. Why is it that, if the topic was so important to them, they failed to bring it up at the every event designed to listen to such criticism?"
Charlie Babcock
50%
50%
Charlie Babcock,
User Rank: Author
12/5/2014 | 12:45:40 PM
'It's been difficult for others to make contributions...'
I think Red Hat's Lars Hermann hit the nail on the head when he said Docker has made it easy to use Linux containers but "it's on a path to go from a formatting system and set of tools to a platform," with the tools hard-wired in. As a consequence, "it's been difficult for others in the Docker community to make contributions."
Laurianne
50%
50%
Laurianne,
User Rank: Author
12/5/2014 | 12:30:47 PM
Docker: Next?
Balanced and thoughtful analysis, Charlie. What do you want to see Docker do next, readers?
Commentary
Learning: It's a Give and Take Thing
James M. Connolly, Editorial Director, InformationWeek and Network Computing,  1/24/2020
Slideshows
IT Careers: Top 10 US Cities for Tech Jobs
Cynthia Harvey, Freelance Journalist, InformationWeek,  1/14/2020
Commentary
Predictions for Cloud Computing in 2020
James Kobielus, Research Director, Futurum,  1/9/2020
White Papers
Register for InformationWeek Newsletters
Video
Current Issue
The Cloud Gets Ready for the 20's
This IT Trend Report explores how cloud computing is being shaped for the next phase in its maturation. It will help enterprise IT decision makers and business leaders understand some of the key trends reflected emerging cloud concepts and technologies, and in enterprise cloud usage patterns. Get it today!
Slideshows
Flash Poll