Why I won’t depend on your pre-release software
I’m sure your pre-release software is more fun than heroin, but experience has taught me to consider it off-limits.
It’s for your own good.
Trust me, you don’t want me to depend on your unfinished work. Do you know what will happen if I do that? I can tell you, because I’ve seen it many times before.
Excitement about an upcoming release is contagious. It spreads through user communities, with little correlation to the actual release schedule. For example, at a conference there is naturally great interest in what’s coming next. Out with the old, in with the not-quite-here-yet! Attendees are often left with the impression that the good things are just a few months away, whatever the schedule says or doesn’t say.
So if I’m working on a related project, why not build for the next big thing that seems to be around the corner instead of wasting time on “throwaway code” built for last year’s big thing? My educated guess could be that the next release is about 3 months away. If I start now I could have my release ready to go in tandem with yours.
But skip ahead to 6 months later. My guess was wrong and your software is still not released. In the mean time I may have helped you find some bugs or identify unworkable interfaces. But for the most part, my interests have been to pressure you in two conflicting ways: prioritize the bugs and feature gaps that matter to me, and release this damn thing already. In other words, I have been a bad influence.
However many people you have lured onto your pre-release crazytrain, they’ll have their own special demands. You may try to please all of them, but this will only delay your release further. In the end, all crazytrain passengers are unhappy. And crazy.
There’s just no better way to convert your biggest fans into loudmouthed grumpy-pants than inviting them to upgrade to your “snapshot”.
It’s for my own good.
Programming is uncertain enough without importing the uncertainties of your unreleased software into mine.
I spend some time contributing to open source software, and I would like to spend it as efficiently as possible. The more time I spend diagnosing build problems, broken interfaces, and buggy libraries, the less I want to spend at all. If I’m not careful this cycle will reach an equilibrium state of me contributing nothing.
It’s also bad for my projects. In the hypothetical scenario where I expected your release three months ago, I’ve split my efforts between a maintenance branch and a cool-new-features-branch to be released on a schedule that is outside my control. As a result nobody can benefit from my work and I can’t even tell them when they can.
So instead of doing that, consistently and for a number of years now I just haven’t built anything with pre-release software. I’ll use a beta on occasion if I have reason to believe the interface is stable and if the beta shares distribution channels and build characteristics with releases. In other words, I won’t work with anything that that would impede me releasing my own work today.
As a result I can appreciate your final software releases without suffering the battle scars, the bitter arguments, and inevitable disappointments it took to get there. Not that I’m lazy: I walk that same road in my personal projects. I release my software, and people start to use it Yours is developed over a longer time and released whenever, without holding up mine or those that depend on mine. It’s pretty cool.
You see, non-blocking behavior is useful at this scale, too.
Release early and often.
Far be it from me to tell you how to manage your project, but the easiest way to slip into a pre-release coma is to corrupt naturally arising release cycles—the heartbeat of your software—with marketing. This is not 1995 and you are not Microsoft.
All I need is a versioned release that does what it says and doesn’t take my build process into a new circle of hell. When you have that, you can “ship” it.
See you at the next release!