Should SaaS companies offer a "stable" version?

Posted by Andy Singleton on Mar 15, 2011 11:43:00 PM

We make dozens of unannounced changes in every release, and I'm constantly worried that one of them is going to start a flame war.  Google, apparently bitten by this problem, is now offering a "scheduled Release track" for Google Apps which will delay the release of features until they have been tested in the "Rapid release track."  Is this a trend for SaaS?  Is this something we need to do at Assembla?

In the 90's, Netscape changed the software release process forever by offering a "beta" version of their browser that had the latest features, and less testing. This would get picked up by early adopters (most Netscape users) who would exercise it.

Before that time, software releases were a big deal, they took a long time, and they were pitched as stable. That's important because big companies, who provided most of the money for software, have other, more important things to do than file bug reports.  They want stable.  They often refuse to upgrade. They may go so far as to keep horrible software like IE6 alive for a decade past its natural lifespan in order to avoid the work of making changes.  But actual users are different.  They apparently have more free time, and they want software that has ... more of the stuff they want.

If you want leading edge software, even in this age of the customer always being right, you have to do some work for the developers.  As long as they are trying out new recipes, you have to be ready to taste the result, whether it smells good or not.

With hosted products, developers did away with the stable release idea and just started pushing out changes to their lab rats valued customers, and watched to see what the reaction was.

Once big companies get the upper hand again, they aren't going to accept random changes in their apps.  Google is selling Apps for Domains to bigger companies, so they are going back and resurrecting the concept of a stable version with a published roadmap.

When you think about how many changes go into an iteratively developed product, almost any Web product, it's amazing how infrequently a change goes wrong.  We have made thousands of changes in Assembla.  I can only remember a few changes that were complete bombs. For example, when we added the google docs attachments, we changed the sequence for attaching a file, and the resulting clickfest was so annoying that we had to roll it back. Statistically, though, developers seem to have a good feeling for what is an acceptable change. 

What Google is doing is potentially quite complicated to implement.  SaaS apps are easy to upgrade because everybody gets the same code.  Ideally, the user would get a choice of the "rapid" and "stable" apps running on the same database, which is a difficult trick to arrange.  Google has compromised, by asking you to test the "rapid" features on different domain from the "stable".

If you look at their calendar, you will see that it doesn't give you much warning.  As I see the calendar on March 15, they only have one feature predicted for the future - a new "Document list interface" for March 22.  They obviously have a lot more in the pipeline that they won't put a date to.  So, they are still basically dropping bombs on the unsuspecting.

So, the technology for providing a stable track is not perfect, but the big customers will demand it.  At the same time, they want a product with rapidly improving quality.  I'm curious to see how this plays out.

We have been cranking up the development velocity here at Assembla.  Our own project is a great laboratory for testing ways to accelerate software development.  The result is that next week's release, originally an innocuous bug-fix release to help us recover from the last month of big releases, has become a fat pack of new improvements.  I'm ridiculously overconfident that people will like these changes (and statistics back me up).  However, there might be a way to get some advice in advance of release.  We could post screenshots on the blog and ask for comments, but we seem to get more comments when we post on Facebook.  It's easier to comment there.  So, look out for some new feature images over there, and let us know what you think.

Topics: development process, software business

Written by Andy Singleton

Working on Continuous Agile and Accelerating Innovation, Assembla CEO and startup founder

Follow Assembla

Get Started

blog-CTA-button

Subscribe to Email Updates