Release Early, Release Often for proprietory software?<\/p>\n
I got a copy of Real Basic<\/a> 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<\/em> using RB this year. And I’m following their “getting started” mailing list.<\/p>\n Currently there’s a fair old discussion on that list about REAL Software’s “Rapid Release Plans”<\/a>. 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.<\/p>\n 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.<\/p>\n So how and why are REAL Software making this shift? In their PDF white paper<\/a> they point out :<\/p>\n 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.<\/em><\/p>\n Now, naturally, the internet makes it possible to shorten that. “Live” updating to customers of existing products is often used to distribute bug fixes.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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<\/em> this fast moving online media. Every release is an opportunity for an online discussion, bringing the product to the attention of new people.<\/p>\n As REAL put it : In the Internet marketing game, each new 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?<\/p>\n 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<\/em> cycle thinking is in corporate purchasing departments. Especially when the company must think<\/em> about whether the upgrade is worth it. If you need to get permission from your boss’s boss.<\/p>\n
\n
release provides a fresh opportunity to grab a fleeting moment of
\n
coverage and online advertising can be focused on the benefits of each new release.<\/em><\/p>\n