Home How Not To Manage An Open-Source Community, Courtesy Of Docker

How Not To Manage An Open-Source Community, Courtesy Of Docker

Docker, the darling of development and operations professionals alike, used to be a sterling example of how to build a community. At least, that is, in terms of writing software that’s easy to understand and adopt

But when it comes to crisis management, Docker hasn’t done so well lately.

In a blog post and then a series of Twitter broadsides (the modern-day equivalent of the rashly written “reply all” email), Docker founder Solomon Hykes ripped into critics, competitors and interested onlookers, challenging the integrity of CoreOS, which had just announced Rocket, a rival Docker runtime.

See also: Popular Coding Framework Node.js Is Now Seriously Forked

While Hykes later apologized for his Twitter storm, acknowledging that he “made the classic mistake of feeding the trolls and definitely went a little overboard on the snark,” it’s worth digging into Docker’s response to better understand how open-source communities should operate.

He Knew He Was Right

It’s tempting to want to respond to haters or others with real or perceived ill-intent. It’s also almost always wrong, even when you feel your company or project is being libeled or slandered. 

For one thing, haters are a good thing. (As I’ve written previously, they’re a “leading indicator of success.”) No matter how much their words or actions may burn, responding to them is usually stupid, largely because doing so amplifies and legitimizes their voices. Also, as the Rocket discussion on Hacker News reveals, CoreOS was tapping into real community concerns that may not have been adequately heard before.

See also: Haters As A Leading Indicator Of Success

For Docker, the best course of action was and is simply to deliver an excellent product, while responding (in a measured fashion) to the substance of any criticism. As Hykes belatedly told me:

Even better, let the community respond. Perhaps Hykes felt the community cavalry wasn’t arriving quickly enough. Or perhaps, as he insists, he felt compelled to counter CoreOS’ “false claims” that risked “smear[ing] the hard-earned reputation of the project.” Totally understandable. 

But Docker first amplified the smear by first putting out a blog post on the CoreOS Rocket announcement (signaling a major concern), all while blithely assuring everyone that “we want to emphasize that this is all part of a healthy, open source process. We welcome open competition of ideas and products.” 

Et Tu, Brute?

Except that it doesn’t, at least going on its words over the past few days. But the hard truth of open source is that every day, if you’re doing it right, you’re enabling others to fork your project. As early open source pioneer Brian Behlendorf famously said, “the most important requirement [in open source] is the right to fork.”

In the case of CoreOS, it’s not forking Docker—it’s simply providing an alternative runtime. I don’t blame Hykes and the Docker crew for being upset about this. At MongoDB and other open-source companies where I’ve worked, I’ve had to deal with annoying forks or parasitical projects. But that’s the bargain. 

Guess what? That’s also the essence of a real community.

MySQL had to deal with a clutch of rival storage engines, but the MySQL community was better for the introduction of InnoDB and others. Red Hat would have loved to be rid of SUSE and Ubuntu snapping at its heels, but the market is better for having all in the kernel pot. Cloudera and Hortonworks would like nothing more than to eradicate the other, but both are needed for balance.

Which is why Hykes was wrong, if all too human, to eviscerate CoreOS (“coreos rings a bell, it’s the lightweight distro focused on running Docker and nothing else? Kind of lost their way though”) and to rebuke potential partners/competitors (“wattersjames you’re a monolith vendor supporting another monolith vendor, retweeted by another. This is a joke”). 

Because even if Hykes correctly critiques them as competitors bent on Docker’s destruction, the reality is that even ill-mannered neighbors are valuable in an open-source community.

Communing With The Enemy

Successful community engagement starts (and ends) with humility. I’ve heard it said that “pride is concerned with who is right, while humility is concerned with what is right.” This has always served me well in working with communities. Unfortunately, what is good for a community is not always good for the company sponsoring it.

As such, Hykes misses the mark when he basically defines his preferred community as those that participate in the Docker community as users, not vendors (read: potential competitors):

Imagine if that feeling permeated the Linux, Hadoop, Drupal or other prominent open-source communities. They would die. There is always tension between competitors on a truly open project (e.g., Cloudera, Hortonworks, MapR, EMC and others on Hadoop). That’s good for the community. 

As Pivotal executive James Watters told Hykes,

https://twitter.com/wattersjames/status/539894506586263552

What Watters says of Docker is true for all open-source communities. As hard as it can be, a community is more than just the smiling, happy code contributors. It’s also the noisy neighbors who yell a lot but do little. It’s the users who complain. It’s the competitors who want to piggyback on a project’s success and hijack its momentum for their own.

It is, in short, about being open, both to the things we love and to the things we don’t.

But let’s be clear: this is brutally difficult in practice. Docker’s response was perfectly rational. Hykes and team have done an exceptional job building up a community that will define the next generation of software development and operations. They don’t want that jeopardized by someone hijacking their community.

But to become a true industry standard, Docker will have to deal with the dark underbelly of community engagement, and with a forced smile, if not a buoyant cheer.

Lead photo by Daniel X. O’Neil

About ReadWrite’s Editorial Process

The ReadWrite Editorial policy involves closely monitoring the tech industry for major developments, new product launches, AI breakthroughs, video game releases and other newsworthy events. Editors assign relevant stories to staff writers or freelance contributors with expertise in each particular topic area. Before publication, articles go through a rigorous round of editing for accuracy, clarity, and to ensure adherence to ReadWrite's style guidelines.

Get the biggest tech headlines of the day delivered to your inbox

    By signing up, you agree to our Terms and Privacy Policy. Unsubscribe anytime.

    Tech News

    Explore the latest in tech with our Tech News. We cut through the noise for concise, relevant updates, keeping you informed about the rapidly evolving tech landscape with curated content that separates signal from noise.

    In-Depth Tech Stories

    Explore tech impact in In-Depth Stories. Narrative data journalism offers comprehensive analyses, revealing stories behind data. Understand industry trends for a deeper perspective on tech's intricate relationships with society.

    Expert Reviews

    Empower decisions with Expert Reviews, merging industry expertise and insightful analysis. Delve into tech intricacies, get the best deals, and stay ahead with our trustworthy guide to navigating the ever-changing tech market.