Rolling out a product upgrade used to be a big deal. Decades ago it was about replacing boards and ICs. Twenty years ago it was about shipping stacks of floppies and hoping they survive the UPS trip. A decade ago it was about getting a CD in the mail. Since then we’ve all gotten used to downloading software. With software-as-a-service (SaaS) and platform-as-a-service (PaaS) offerings, the upgrade is rolled out in some data-center 3,000 miles away.
My point is that the cost to vendors for upgrading products has gone down substantially. First, there were the truck rolls. Then it was about provisioning and shipping the right type of media to the right customer. Then it was about posting a nicely packaged updater online. And, if you are hosting, you don’t even have to package an update–just get it to your servers anyway you can.
As upgrade costs to vendors have gone down, it has become easier to push more and more smaller upgrades. There are other factors driving this trend also, including the spread of security vulnerability exploitation tools. The net effect on customers is not necessarily positive. Just find a CIO and ask him/her about the cost of planned and unplanned outages due to upgrades. For example, several of the Blackberry outages have been pinned on upgrades.
The worst type of upgrade in the shrinkwrap world was a “forced upgrade,” an upgrade that you had to install in order to maintain support coverage or deploy any additional upgrades. As I have been thinking more about building startups that leverage online platforms and cloud computing, I’m starting to realize that almost every SaaS and PaaS upgrade is a forced upgrade.
When Facebook changed the way in which so-called “forced friend invites” were handled last February, hundreds of Facebook application vendors using the F8 platform were affected overnight. They had no control over Facebook’s choice — it was a “forced upgrade.” The only options developers had were to roll with it or get off the platform. This is much different from building applications on top of infrastructure deployed on premises (for example, if you don’t like Vista, don’t upgrade).
As someone who has hopped on a plane with a bunch of mag tapes to do on-site upgrades I can appreciate the value of the on-line upgrade model! Many have pointed out (for example Paul Graham: http://www.paulgraham.com/road.html) that web apps break the old mold of upgrades as a large and distinct activity.
The downside comes when there’s coupling amongst applications, as there is increasingly with mashups and aggregations of web services. When an interface on which I depend changes then I’m potentially screwed. I take the point that systems built on platform- and infrastructure-as-a-service offerings have this coupling problem in the extreme.
The solution is to keep systems as loosely coupled as possible and to provide backward compatibility of interfaces. I think as an ecosystem forms on top of a given platform it will be essential for platform provider to support some kind of backward compatibility. Your Vista example can be extended. Microsoft has always taken great pains to maintain backward compatibility (albeit at the expense of simplicity, performance and other important factors).
There are lots of ongoing battles to see where we will collectively define platform layers in our software stacks. History has shown that platform providers who foster the largest community of ISVs tend to win out. Stranding masses of developers on a no-longer-supported set of interfaces is not a good way to go about building that community. So over time I think you’ll see fewer ‘forced upgrades’.
It’ll be interesting to see how it all evolves…
(BTW the MHT link seems to be broken)
Tony, yes, backward compatibility is a multi-edged sword. Many of the current mashup APIs are not versioned (not even their URLs) so it’ll be interesting to see how things evolve.
Pingback: Facebook’s Terms of Service Change: A Line in The Sand « HighContrast
Pingback: Startup anti-pattern: platform risk | HighContrast