The solution to deadlines is usually “cut scope”

Deadlines come for all of us, even in open source projects. The deadlines are often self-imposed (individually or collectively), but that doesn’t make them any less of a deadline. As the deadline approaches and you realize you’re not going to meet it, what do you do? There are a variety of approaches, but the best is usually to do less work.

As you may recall from Program Management for Open Source Projects (or innumerable other books, articles, and manifestos), a project’s cost, scope, quality, and time are all interrelated. When you’re time bound, you can increase the cost (“cost” in an open source project is usually “contributor effort”), decrease the quality, or decrease the scope. My recommendation is to cut scope. Doing less work is both effective and least likely to upset your users.

Cutting quality by doing less testing or being more rushed just leads to more work later as you fix the bugs your users found. Users typically don’t like finding bugs; they much prefer you fix them pre-release. Increasing the cost is rarely an option — contributors are probably already giving you as much time as they can. You might be able to cajole a brief burst of extra effort, but you can’t do that repeatedly.

So that leaves cutting scope. Fewer functional features beats more half-implemented features. The great thing is that there’s always the next release. In commercial work, the scope is somewhat fixed, too. In open source projects, you’re not contractually-bound to the feature set. Users and downstream projects may be really hoping for a new feature, but you’re not obligated.

Of course, cutting scope isn’t always the answer. You can extend self-imposed deadlines and sometimes negotiate externally-imposed deadlines. When you’re truly aaalllmost there, an extension beats cutting work that’s mostly done. The downside is that while you’re waiting for feature A to be done, someone will try to get feature B ready for the release as well. When feature A is finish, feature B is almost done, so you hold on a little longer, and someone will try to get feature C ready for the release. Without sticking to a deadline, you can end up never actually releasing.

This post’s featured photo by Markus Winkler on Unsplash.