Current Articles | RSS Feed RSS Feed

Should SaaS companies offer a "stable" version?

Posted by Andy Singleton on Tue, Mar 15, 2011 @ 10:43 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.

Tags: ,

COMMENTS

I think in a lot of ways - the space you are in is different than most SaaS offerings. As a "tool" for development teams - some of the things you might change will just offer options for how your clients' teams work, some might present process changes that could impact productivity, and I suppose - it is conceivable that a change might "break" a development project.  
 
There are two obvious ways SaaS companies are approaching this problem - one is "sandboxing" new features by using rights tags and first releasing them to a pool of clients who willingly participate in both the evaluation of new feature ideas and the implementations that follow. Controlling this pool allows you to pick a profile of participants and to reward them in some way for their participation (even if it is only the ability to influence new feature development).  
 
The other is to have a higher price offering that has a more deliberate version change. The downside of this is it is easy for the lower price offering to be painted as less reliable and for it to implact the perception of your entire service. Depending on how you do it - it can also lead to development branching and having to maintain two (or more) versions - and NO ONE in development enjoys that idea.  
 
I think the willing participant idea - with the carrot of closer involvement in feature development - has the most promise. I have even heard from SaaS companies that successfully charge more for this option and clients who agree to pay for development of features they see as critical which are then rolled out to everyone. Lots of ways to slice it....

posted @ Wednesday, March 16, 2011 10:30 AM by Mike Dunham


I did get bitten by the change to ticket statuses. When it was launched, the API started returning the text of a status instead of a number, and my project status page that used the API no longer worked. I made changes to my code, and it was fine, until two days later when you guys changed your API back to how it was, and it broke again!

posted @ Wednesday, March 16, 2011 11:24 AM by Amy Worrall


I love SaaS but always wonder how larger and more regulated companies have to deal with all the administrative and documentation updates they have to do to stay compliant with internal standards and government regulations when a new release comes out. And since many SaaS companies are agile shops, the frequency of these updates becomes pretty onerous.

posted @ Thursday, March 17, 2011 9:51 AM by topsprout


Agree that many SaaS companies are getting to the point where they're offering "private" versions, but that defeats a huge operational benefit for companies going SaaS. I've worked at one company where they were basically managing over 100 "private" versions, which completely destroyed the benefits to them of being an on-demand company.

posted @ Thursday, March 17, 2011 11:49 AM by topsprout


Comments have been closed for this article.

Follow Assembla

twitter facebook youtube linkedin googleplus

Subscribe by Email

Your email: