Release Early, Release Often for proprietory software?

I got a copy of Real Basic via their competitive upgrade scheme for Visual Basic owners a couple of months ago. I've looked at it, and at one point thought about porting SdiDesk to it. The deal breaker is that there's no equivalent to Visual Basic's DHTML control. Nevertheless I'd like to try something using RB this year. And I'm following their "getting started" mailing list.

Currently there's a fair old discussion on that list about REAL Software's "Rapid Release Plans". RealBasic 2005 will be released with a 90 day release cycle. In other words, they plan to bring out new versions more or less every 3 months.

Some users are suspicious that there's a shift towards a "rental" model for the software, but REAL point out that if you allow your subscription to upgrades to lapse you won't lose your existing software. You just won't get any more upgrades.

So how and why are REAL Software making this shift? In their PDF white paper they point out :

In a nutshell, the amount of time a company can take to develop and release a software product has traditionally been driven by the needs of the retail distribution model rather than the needs of the software developer and its customers.

Now, naturally, the internet makes it possible to shorten that. "Live" updating to customers of existing products is often used to distribute bug fixes.

However, this introduces its own problem : if a company is developing a new version of a program, while continuously distributing fixes to the existing release, it ends up working on two versions of the code at the same time.

That adds plenty of cost. Both the dual effort and in managing and synchronizing the two versions of the code-base. The rapid release model tries to reduce this cost by making new releases smaller, more incremental improvements.

The idea is not that software is written any faster. Simply that if you intend for release 2.0 to add 6 new features over 1.0, it's better to add one feature and release it every three months, than wait and release them all after 18 months. After each three month cycle, the "current" version is refreshed, and any new bug fixes can be made to that. New development, and maintainence of existing releases is easier and cheaper to keep synchronized.

As well as reducing the cost of maintaining two versions for 18 moths, rapid release also allows the company to be more flexible if the user's requirements change. This reduces the risk of working on something that will be out-dated or unwanted when finally released.

Another point made by REAL, is that the media itself is changing. The print media are being supplemented or surpassed by the online media : mailing lists, blogs and discussion forums which are, themselves, working on shorter time-spans. The result of more, more frequent, releases, is more points to touch this fast moving online media. Every release is an opportunity for an online discussion, bringing the product to the attention of new people.

As REAL put it : In the Internet marketing game, each new
release provides a fresh opportunity to grab a fleeting moment of
coverage and online advertising can be focused on the benefits of each new release.

Having listed these benefits of pulverising the development of software into a finer granularity, REAL then have to worry about a different problem. What's the business model?

Here a new set of forces come into effect. While the company and users benefit from the faster release cycle, there remains a problem of how to charge for it. The user's perception is likely to be that she shouldn't be spending more money every three months. The last bastion of slow cycle thinking is in corporate purchasing departments. Especially when the company must think about whether the upgrade is worth it. If you need to get permission from your boss's boss.

At the limit, small payments for small pieces of value tend to fail because the cost of decision making outweighs the benefit of the purchase. Users prefer a scheme which aggrogates several cheap pieces of value into a single larger price because it's easier to reason about and decide.

REAL clearly understood this, because they're bundling several upgrades under a single price. Or rather a 12 month subscription (which should cover more or less 4 releases, though it's not clear what happens if a release slips a couple of weeks and you only get 3 in your 12 months)

Those 12 months might still be too short for people, hence the low-level kvetching on the RB mailing list. But it's in the right direction. Maybe if REAL demonstrate this working over the next year, they could make longer term subscriptions available and some customers will prefer them.

All interesting stuff. Obviously, rapid releases are a corner-stone of eXtreme Programming, and other agile methods. But the business model is another thing to think about, with wider implications than just releasing software.

Finer granularity gives more flexibility and reduced co-ordination. That's implicit in free-software and one of the reasons that weblogs are exciting. It's why loose agregations of smart, disorganized individuals; free agents, bootstrappers and microISVs can compete with larger, more structured groupings.

But there's sometimes a mismatch between the granularity and time-scales of those people, and the requirements of customers. So there's a need for a kind of adapter pattern. For encapsulating a fast spinning, high kinetic energy production, and presenting a slower moving interface to the outside world. Something like a gear box.

Smart disorganized individuals like to do a little bit of lots of things. But sometimes this needs to be packaged up as one big, consistent thing. One strategy is learn self-discipline. But self discipline isn't always cheap or desirable. A software company doesn't want to revert to 18 month release cycles just to appeal to purchasing departments. And maybe you don't want to revert to doing one thing for six months, just because the employer needs it.

But if you're going to avoid self discipline, you'll need something else : an interface, a bundling strategy, or tools which can tame the chaos.