Working in Between Public and Private

The default working model for open source projects is working in public: public bug trackers, public forums, “pull requests welcome”, and so forth. Sure, there’s some level of gatekeeping – it’s extremely rare for an open source project to accept code from anyone without some level of review by a trusted group – but the key point is: you don’t need permission or an invite to get started, you can just show up.

This is also the default for many small-to-medium-sized companies’ engineering organizations: while the engineering department is usually split into smaller teams, anyone from any team with sufficient time and interest is welcome to hop into another team’s slack channel or corner of the codebase.

However, there are situations where this doesn’t work (I’ll talk about a few of those situations below). When that happens, the impulse is to go full-on in the other direction, and work entirely in private. “Private” meaning: work done by a select group of insiders, with no mechanism for the broader company/community to get involved.

But… it’s not a binary! There are many working models that fall in between fully public and fully private. This blog post is about those middle-ground options. My goal is to convince you to think about using them more often. If working in public isn’t working, consider adopting a middle-ground option instead of retreating into fully-private.

Ends of the spectrum

The two options, as usually presented, are:

Working in private

All work is done by a select group of insiders. There’s no mechanism for someone outside the group to add themselves. Conversations happen solely within the group. Perhaps there’s some level of reporting out, but if so it’s a one-way communication: “look, we did a thing”.

The problems with this model, especially in the context of open source, seem fairly obvious. There’s no mechanism for feedback from outside the group. Work is presented as a fait accompli. This model is not great for building community, and it’s also pretty risky: if the in-group gets something wrong, they can go pretty far down the wrong path before finding out about it. This is how you get, for example, companies launching new versions of their product that are significantly worse than the older version¹. Or less dramatically, a group working in private on a pull request that never lands because they missed something critical early on.

Working in public

The other end of the spectrum: all work happens fully out in the open. As discussed in the introduction, this is usually the default for open source projects and, to a lesser degree, small-to-medium-sized companies. There’s almost always some level of gatekeeping, but the key part is: you don’t need permission or an invite to get started, you can just show up.

There’s a reason why this is the default for open source: it works! (Most of the time, that is – but we’ll get to that.) Open source projects live and die on the strength of their community, and this model optimizes for community engagement. It also maximizes your changes of getting great contributions from someone outside (or new to) your community.

When working in public doesn’t work

But from time to time, we run across situations where this “no permission required” model breaks down. Two examples that come to mind:

1. Design decisions. There’s a reason why “design by committee” is a pejorative. Good design relies on a strong vision, and too many voices only dilutes a vision. I’ve seen this hold true for both visual design and API design – matters of style and taste. These situations don’t have clear “correct” answers; there’s a universe of good options. That’s a recipe for paralysis, where it feels impossible to move forward because there are too many credible options. Or, if it does move forward, it does so as an average of many competing options, and thus is confused, or bland, or otherwise incoherent – because it’s no longer a design with a vision behind it.

2. Filibuster. Sometimes, a public conversation ends up getting dominated by one (or a few) loud voices who, for whatever reason, are willing to talk way, way more than anyone else. Instead of making space for community consensus to form, they dominate the conversation, drowning out other voices through sheer volume. People who might have good contributions don’t want to get involved because reading through hundreds of pages of forum posts, most by the same person, is exhausting. Thus filibusterers create a false sense of consensus as their point of view appears to dominate. (And they burnout/exhaust other community members in the process.)

These are real dynamics; anyone who’s worked in open source long enough has seen them happen. I’m thinking of several real-world examples of these dynamics as I write this. So it’s understandable that, when faced with one of these situations, people conclude that working in public is the wrong approach.

However, here’s the fallacy I want to address: faced with a situation that’s wrong for a fully-public working style, many people conclude the only other option is to do the work in secret, and only present it to the larger community when it’s done.

In between public and private

This is a wrong! There are all sorts of options that lie somewhere in-between “anyone can show up and contribute” and “only insiders allowed.” It’s quite possible to set up a working model that has most of the benefits of working in public – a wide net for contributions, community engagement and involvement, rapid and frequent feedback mechanisms, etc. – while also retaining many of the benefits of working in private – more rapid movement, less bikeshedding, ability to execute a clear vision, etc.

If working in public isn’t working, consider adopting a middle-ground option instead of retreating into fully-private.

Common successful patterns for in-between-public-and-private working models

While there are innumerable ways to structure a middle-ground approach, the ones I’ve seen be successful share a few common patterns:

• A clearly-defined charter or mission that lays out what the group is for, what its remit is, who the membership is, and so forth. This is a key bit of transparency that lets outsiders know who’s doing what and why. And having a clear scope keeps the the group on track, and prevents surprises (“I didn’t know they were working on that!”)

• Leadership buy-in: whatever “leadership” means in your context, it needs to support the charter of the group. Sure, occasionally that “leadership” may need to override a sub-group’s decisions, but the general expectation should be that whoever chartered the group has their back.

• Clear rules and procedures for adding and removing people from the group. This could be elections, appointments, an application procedure, etc. The specific mechanism is relatively unimportant; what matters is that outsiders need to be able to understand why the group composition is the way it is, and what mechanisms are available to join.

• Regular report-outs: the group needs to report on what its doing, frequently enough to (again) provide transparency and prevent surprises. Frequency varies a lot depending on the nature and scope of the group, but somewhere between weekly and monthly is a good starting point for most groups.

• Well-defined, structured mechanisms for broader input: finally, the group needs mechanisms to take feedback in. This needn’t be a free-for-all; it can be structured (feedback forms), timed (notice and comment periods), public or private, etc. What matters is that outsiders who want to contribute have a direction to channel their energy. If they don’t, it’ll spill out into the kinds of unproductive sprawling public discussions you were trying to avoid in the first place.

If working in public isn’t working, consider a middle ground

I hope this opened your mind to more options for working models beyond fully-public and fully-private. If you do end up choosing a middle-ground working model, get in touch – I’d love to hear about it!