“Finished” and “no longer developed” aren’t the same

Later on in the thread that sparked “Combinatorial releases won’t help,” Kurt Seifried said

We used to have finished code. It shipped on a CD installed it used it for a year and then you got a new CD at some point later. We don’t live in that world anymore. Why are we using the same software processes from 30 years ago?

Kurt Seyfried

That’s not really the word to use, though. The software wasn’t finished, it just had to ship at some point so they stopped working on it. The software was delivered on a CD (or floppy disks or tape or …) and it wasn’t trivial to ship updates. So there had to be a “this is good enough” point in order to put the bits on media. Otherwise, you’d end up with Duke Nukem Forever.

So what does it mean for software to be finished? Software is finished when it reliably does what it’s intended to. Many basic Unix commands are like this. ls doesn’t need any new features. cal is pretty solid at this point. Of course, there may still be bugs to fix and maybe the occasional new feature to implement (for example: adding support for SELinux contexts to ls), but by and large the work is mostly done. You just need someone to keep the proverbial lights on.

That’s a much different case from “this is enough to call version 1. Let’s ship it and start working on version 2.” It’s also different from abandoned software. That’s where development stops because no one is around to do it anymore.

Which variation your project ends up in will have a big impact on how you manage it. If the project is abandoned, all you have to do is turn the lights off on your way out. (Which you should read to mean “mark it as abandoned in the README, etc”.) If it’s the “we need to ship eventually” sort, then I have a whole book for you (particularly the chapter “Ship the Release”, which covers how you decide it’s good enough to ship). Ultimately, though, the “it does all it needs to do” option is the real goal. That’s what success looks like.

How do you determine if the project does all it needs to do? The simplest way is to define what you want it to do. What contribution does your project make to the world? Which things are great, but best left to another project to handle? If you’ve clearly defined your project’s vision and mission, these questions become easier to answer.

This post’s featured photo by chris robert on Unsplash.

Ben formerly led open source messaging at Docker and was the Fedora Program Manager. He is the author of Program Management for Open Source Projects. Ben is an Open Organization Ambassador and frequent conference speaker. His personal website is Funnel Fiasco.

Share