Merge by committee

TL;DR: There is an emerging anti-pattern, whereby organizations review and discuss issues and pull requests in regularly scheduled, closed meetings, a practice that almost certainly sets the project up for failure.

4 minute read

The hardest part of open source for any organization isn’t security or legal concerns, or even the code itself. The hardest part of open source for large organizations is learning to work like an open source project. There is an emerging antipattern, whereby organizations review and discuss issues and pull requests in regularly scheduled, closed meetings, a practice that almost certainly sets the project up for failure.

A traditional, closed-source workflow

A typical closed-source development workflow might include a project manager who gathers feature requirements, prioritizes tasks, and assigns them to a development team. The process will likely involve regular status meetings, and perhaps a daily standup meeting to resolve any blockers that emerge between status meetings. When issues arise, or when new features are requested, they’re generally addressed at a separate project planning meeting. These meetings generally take place in conference rooms, and are almost always limited to the development team and perhaps the product owner.

All too often, organizations attempt to graft this traditional, closed-source workflow to open source projects. Open source is more than simply publishing code. It’s a workflow, a philosophy, the modern approach to building software, both inside and outside your firewall, and if you don’t treat it as such, the organization and the open source community will almost certainly have a subpar experience.

The problem with closed-source governance

One problem with trying to apply closed-source workflows to open source projects is that often only a small subset of the project’s developers — those that happen to be on your organization’s payroll — are invited to all those status, standup, and planning meetings. As decisions are made that affect the project, the majority of your project’s stakeholders, both technical and non-technical, have no means of participating, nor can they contribute their experience or expertise. Not to mention, all the relevant technical details likely live in written discussion within the project’s issue tracker, and it’s unlikely that the outcomes of the meeting will be sufficiently memorialized to document what decisions were made, or more importantly, why. Simply put, meatspace meetings don’t naturally capture and expose process with the same fidelity as their digital counterparts.

Another problem is that, while scheduled meetings work well when developers are in the same place and all work the same hours, open source projects are global, meaning it might be 3:00 AM for a developer in Tokyo, when you have your 2:00 PM planning call. By virtue of being distributed, open source is, by design and necessity, both asynchronous and agile. It’s not uncommon for an issue to be reported by a user in one time zone, confirmed with additional details by a user in another timezone, fixed by a contributor in a third, and closed by a maintainer half way around the world, all within the span of a few hours. The pace of an open source project is measured in minutes or hours, not the weeks or quarters that synchronous meetings are optimized for.

Non-blocking is better than blocking

You may see then, how such a distributed workflow is incongruous with only being able to make decisions that affect the project during a special one hour block once a week. As a contributor, if I have to wait a week for feedback on my proposed change, and then another week for it to me merged, it’s unlikely that I’m going to contribute again. It’s simply not worth my effort. Rather than make progress on the next feature, developers are forced to spend a disproportionate amount of time blocked by your administrative processes. While such delays may be expected in closed-source software, absent a weekly paycheck to coerce the developer into staying, there’s a good chance they’ll find another, more responsive project that works at the pace that they want to work.

I know of government agencies that have weekly standing meetings, where stakeholders gather, print out open issues and pull requests (because of course, there’s no Wi-Fi), draft an agenda, and discuss each comment one-by-one, assigning action items for individuals to reply to particular threads on behalf of the committee. I couldn’t design a more heavy weight, more ill-suited process for maintaining an open source project if I tried.

While a good first step would be to invite any project stakeholder, inside your organization or otherwise, to join, either in person or remotely, you’re still applying a highly centralized governance model to a decentralized workflow. It’s a long-standing joke that design by committee produces terrible results. So why, when presented with the opportunity to reimagine how they work, do so many large organizations instead try to concentrate the project’s ability to act in such a bottleneck-prone process?

A holistic approach to open source

Instead, organizations wishing to transition from traditional, closed-source workflows to more modern, open source approaches to software development should do two things:

Decentralize governance - Individual maintainers must be trusted and empowered to act in the project’s best interest. If a user requests a new feature, project maintainers should provide feedback immediately, speaking as individuals, not on behalf of some semi-secret committee. If a contributor proposes a change, the code should be reviewed by a developer, and the merits discussed alongside the code, as it’s submitted, and open to everyone involved. Naturally some issues, such as the project goals or roadmap, may warrant a broader discussion, for which more synchronous meetings (open to everyone) will be more appropriate, but whether technical or non-technical, individual maintainers should have the authority to run the project on a day-to-day basis. Delegate authority to the greatest extent possible, absent overriding policy or administrative concerns. Use your move to open source to adopt the ideal workflow, not the workflow your organization has used since the cold war.
Minimize information imbalance - The problem with maintaining a closed-source workflow, while working in the open, is that you end up duplicating much of your efforts. Organization’s often have two classes of stakeholders (those inside the organization, and the rest of the world), two means of requesting new features, two means of discussing proposed changes, and two means of receiving project updates. This creates a significant imbalance, both in terms of information and the ability to contribute. Instead, your project should have one class of stakeholders, pushing internal discussions outside the firewall to the same tools external stakeholders use. Want to propose a feature? Open an issue. Think something’s a bad idea? Comment on the pending pull request. If an external stakeholder doesn’t have access to a given resource, internal stakeholders shouldn’t use it until they do. Not only will this empower external stakeholders to contribute on equal footing as those inside your organization, it will simplify and modernize internal workflows, allow you to rely on best of breed tools, rather than century old management practices.

Maintainer, not manager

As a project maintainer, think of yourself as the host of the world’s most boring cocktail party, rather than as the manager of a top-down, command-and-control, code assembly line that happens to be public. Open source is about joining a community bigger than any one organization, and to be successful, you must embrace the role of community organizer (with an expanded definition of stakeholders), not one of project manager, seeking to “manage” feature requests, or an ephemeral pool of free labor.

How you work is equally important as what you work on. If you take your first or second step into the world of open source, without retooling your workflows for working in the open, you’ve only published your code, you haven’t open sourced it. While it’s certainly possible to run an open source project by committee, it’s highly unlikely that the project will see much success, at least by any open source standards.

Originally published June 22, 2015 | View revision history

If you enjoyed this post, you might also enjoy:

Ben Balter is the Director of Hubber Enablement within the Office of the COO at GitHub, the world’s largest software development platform, ensuring all Hubbers can do their best (remote) work. Previously, he served as the Director of Technical Business Operations, and as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →

This page is open source. Please help improve it.

Edit