The best way to make a decision is to decide

Making decisions in an open source community is hard. Most communities have some sort of consensus model where major decisions require broad support. There’s not just one Big Boss who can come in and unilaterally decide. But sometimes decisions become bogged down in an attempt to get unanimous support or achieve the One Best Decision™. If you’re the person who is supposed to make the decision, make the damn decision.

Consensus is important. People want to feel like their input matters, especially when they’re contributing on a volunteer basis. If participating in your project stops being fun, people will leave. It’s hard to make sustainable progress if you can’t get the majority to go along with you.

But we sometimes overcorrect toward consensus. In those cases, the decision drags on. If a decision is ever made, it no longer has momentum. It might be the most correct decision, but it loses impact because it sits in a state of limbo for months.

In most cases, a good decision made quickly is better than a great decision made slowly. You can iterate on decisions, and that works better with short cycles. The smaller the decision — or the easier it is to reverse — the less time you need to spend building consensus. This is not to say that you should go around making a bunch of decisions on your own. That’s chaos.

Instead, you should have a defined process for how decisions are made: who can gives input, who is empowered to make the decision, and what the time frame looks like. Set a deadline and then make the best decision you can. The process doesn’t have to be complicated — it’s better if the process is simple — it just needs to not catch the community by surprise. Chapter 4 of Program Management for Open Source Projects lays out a framework for building your decision process.

This post’s featured photo by krakenimages on Unsplash