How to make branding decisions in an open community

Docker's recent rebranding efforts offer a lesson in public decision-making.
478 readers like this.
putting the pieces together
Image by:

Opensource.com

On April 18, Docker founder Solomon Hykes made a big announcement via a pull request in the main Docker repo: "Docker is transitioning all of its open source collaborations to the Moby project going forward." The docker/docker repo now redirects to moby/moby, and Solomon's pull request updates the README and logo for the project to match.

Reaction from the Docker community has been overwhelmingly negative. As of this writing, the Moby pull request has garnered 7 upvotes and 110 downvotes on GitHub. The Docker community is understandably frustrated by this opaque announcement of a fait accompli, an important decision that a hidden inner circle made behind closed doors. It's a textbook case of "Why wasn't I consulted?"

"Inner sourcing" refers to the application of open source principles within the walled garden of a closed organization. What Docker has done here seems something like the reverse, applying closed organization principles to an open source community.

Maybe we can call this "inner circling."

Learn about open organizations

Inner circling can be a difficult tendency to resist. In fact, I've seen it crop up recently in several open source communities of which I'm a part, including the Sustain conference (key organizers hold a private weekly call), and even the Open Organization Ambassadors group (Red Hat editors privately control Opensource.com). It's something we all need to work on. Let's look at four questions that can clarify how to do better.

Who are you? There's a subtle (but important) difference between a closed organization that does some things openly, and an open organization that does some things privately. The former will naturally tend to make closed decisions unless the organization has an ulterior motive for operating openly in a particular situation. However, the more you identify with your community, the more that vetting decisions large and small before you consider them settled will become second nature. Where do you locate your identity? In the open with your community? Or behind closed doors with an inner circle?

Why did you reach this decision? Even an open organization must make some decisions privately. At Gratipay, for example, we've identified "legal, safety, security, and support matters" as the exceptions to the rule of open decision making. However, when announcing a closed decision publicly, explaining the thought process behind your decision will help your community to take your decision on board. When Gratipay had to reboot due to legal uncertainty, we went to great lengths to explain the complicated legal issues to the community. Yes, that's a lot of work. But it's worthwhile for preserving and even enhancing the community's trust.

There's a subtle difference between a closed organization that does some things openly, and an open organization that does some things privately.

Docker has some great reasons for renaming their open source project to Moby, and making the decision privately may even be reasonable. For instance, renaming Gittip to Gratipay required two epic bikesheds. With a community the size of Docker's, a public conversation could've become simply unmanageable (though Mozilla's recent open rebrand would suggest otherwise). Even just a few sentences by way of honest explanation could've turned some of those downvotes into upvotes.

Where do you make decisions? Let's assume for a moment that the Docker-to-Moby decision was made publicly (the pull request doesn't actually say). Where was it discussed? On a mailing list? Another GitHub issue? A Google Hangout? A link clearly labeled "more details" gives motivated individuals the ability to do their own research and answer their own questions. This also helps people better understand where they should pay attention to avoid surprises in the future.

How do you make decisions? Links to sources (or the lack thereof) give some implicit clues about how your organization makes decisions, but, to borrow from the Zen of Python, "Explicit is better than implicit." Jono Bacon's book, The Art of Community, includes a whole chapter on governance and decision-making. Recent conferences and books in the Platform Cooperativism movement have been exploring the relationship between cooperative governance models and open source. One way or another, setting clear expectations about how decisions are made builds trust.

Once the dust settles, rebranding the Docker open source project to Moby will probably turn out to have been a fine decision. However, a more open process for making that decision could have resulted in less dust in the first place. Had Docker avoided "inner circling"—importing closed decision making into an open community—their rebrand could have been a source of trust instead of tension.

Tags
The Open Organization
Leadership and management
Chad Whitacre
User profile image.
I'm the founder of Gratipay, an open organization with a mission to cultivate an economy of gratitude, generosity, and love. We help companies and others pay for open source—and we're funded on our own platform. Offline, I live outside Pittsburgh, PA, USA, and online, I live on Slack, IRC, and GitHub.
More about me

5 Comments

Avatar
Sandra McCann | April 25, 2017
No readers like this yet.

Great article and example on how open decision-making or at least opening up the rationale behind decisions is important for community engagement. This can apply even to closed, hierarchical organizations, to gain support and understanding for closed-door decisions. Great stuff!

Avatar
Ben Cotton | April 25, 2017
No readers like this yet.

Great article, Chad! The most successful approach I've seen is to develop a plan in a small circle and then release it to the community for refinement before adoption. This still allows the community to be involved, but it helps cut down on the bikeshedding compared to starting from an empty page.

Avatar
Chad Whitacre | April 25, 2017
No readers like this yet.

Good suggestion, Ben. I've seen that sort of process work well recently with the Open Organization Ambassadors group. For example, when we transitioned to using GitHub a few months ago, Bryan developed a plan in private that he presented more broadly for discussion before it was finalized. They key is to hold the decision open until everyone has had a chance to weigh in. That can be scary, but like you say there are ways to mitigate some of the risks.

Avatar
Bryan Behrenshausen | April 25, 2017
No readers like this yet.

The "bring a proposed plan to the community for discussion" approach works better than the "pose a question or problem to the community and wait to see what takes shape" approach, I think, because it jibes with cultural norms and anticipated practices from open source software communities, where people seeking to propose changes accompany said changes with sample code that demonstrates the function or utility of those changes.

In fact, in coding communities, this might be the expected approach: Don't just tell me what you want; show me. This works well because those proposals advance overtly functional/performative language that's supposed to do something, and people can then respond to the proposal by digging into its mechanics, testing it, seeing if it really does work, etc.

In communities like ours—where we produce prose, not code—or in cases where proposed changes involve that special kind of mechanics we call a "governance model," those changes pertain to something more abstract, less functional/performative, and therefore more difficult to assess in any kind of straightforward or clear-cut manner.

Still, the practice of bringing something to which a group can respond is preferable here, too.

Related Content

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.