Understanding the Importance of Release Early, Release Often

The FuzzyBlog! : Understanding the Importance of Release Early, Release Often The FuzzyBlog!

Marketing 101. Consulting 101. PHP Consulting. Random geeky stuff. I Blog Therefore I Am.

What Often Happens when Commercial Source Developers "Go Open"

This is a pretty common tenet in the Open Source world and where commercial developers often go wrong. If you are an ex-commercial developer then you want desperately to reach a "1.0" stage or a "near functional", "mostly baked" stage before going live. You wouldn't want to release something piece meal, would you? After all – that's the way it's done.

Actually no. In the Open Source world, that's not how it's done. The best Open Source projects tend to start small, release early, release often (RERO) – even if it's only a little bit of functional (but useful) code. Projects can release anything as long as it stands on it's own feet and is at least minimally useful to someone beyond the initial developer. Open Source projects tend to evolve as much or more than they are developed. Most projects are an ever changing, ever morphing response to the constant customer input that "release early, release often" brings.

The practice of release early, release often benefits you as follows:

Testing. It gets your code into immediate testing. Given the ever growing complexity of today's IT universe, getting code out early generally forces bad assumptions to be found early. And this means that they get fixed early before cascading into the rest of the system.
Shame. As any good catholic (I'm not) knows, shame is a powerful motivating force. Let's be brutally honest here – most of our code isn't all that good. RERO Forces developers to NEVER let their code be something they are ashamed of. Or if they are going to be ashamed of it, they have to be man enough (or woman enough) to stand up and say "I wrote that dreck".

Side Comment: I think one of the best things about the movement to Open Source is that the fear of public shame means that all of us don't do egregious hacks as we do all too often. I've heard it said, although never confirmed it, that one of the biggest impediments to Microsoft opening the kimono on their source is that it's just plain embarassing to them.

Feedback. Gets immediate feedback from users and potential users. True it can be too much feedback but this is one of the ways that users "compensate" you for the "product".
Involvement. Gets the community involved early. Look at how long the Mozilla project took initially and the paucity of external developers for a long, long time. The insistence on a near complete product meant that no one other than the core AOL / Netscape developers worked on it for a long time.
Avoids Second System Syndrome. Anyone who has ever built a system and then had the chance to go back and do it again tends to load on the features and the architecture since they are confident that they can (of course) do
it right this time. Putting your work out early minimizes this impact (note – I don't have any real evidence of this but it seems to work logically).
Happy, Shiny Developers or "Builds Happiness and Confidence". Nothing tends to makes developers
happier and more confident than to know that what they've built is being used. Release Early, Release Often builds these feelings which are key in motivating Open Source projects. When people are telling you "Great but can it do X" there is a real incentive to keep working on the project.
Scratch Your Own Niche. It forces you, if it's something that you yourself use regularly, to "scratch your own niche". If you use release early, release often and actually use it yourself (since you followed RERO then you can actually use it). This tends to make the software more practical and user centric – if the developers don't go off course – which can easily happen. An eye towards general applicability needs to be kept not the "I had this problem 1 time in 3 years".

For more on Release Early, Release Often, see this Google link [Go]

Notes from Personal Experience

Now bear in mind that I am an ex-commercial developer and product manager. And not following RERO has definitely impacted my own work. I started writing some Open Source software this past summer and the project quickly bloated into a mass of 1/2 done elements. Yes I kept it usable regularly but I didn't have the driving force that comes from being Happy and Shiny from user feedback. This meant that when I hit a snag I didn't get have the incentive to get back to it. Even when you aren't being paid, knowing that someone out there wants what you are doing is a huge motivator.

Since that point I've cut the project down, refocused it and I can see a release in sight. Sure it won't work right in all circumstances but getting that input from Release Early, Release Often will keep me and the project on track.

This Page was last update: 4/6/2003; 3:14:00 AM

Theme Design by Bryan Bell