Software delivery on the web?

The other day I was talking to my friend Marc about software development. Marc is founder and Chief Product Officer of Wesabe a startup that, “makes it easy to better understand how you spend your money and links you to a community of people dedicated to helping each other make better financial decisions.” Wesabe is one of these new-fangled companies whose whole product is their web site, which they update, according to Marc, every day. The frequency of their updates came up when I was using version control as an example of something that developers need to understand in order to work well in groups — not just the mechanics of a particular version control system, but the how and why of things like release branches. Marc suggested that my thinking was way out of date — that because everyone is delivering their software on the web these days, release branches were an anachronism. He’s certainly right that if you release your software by updating your own web site then there’s no reason to make release branches — the point of release branches is to allow you to go back and fix bugs in old releases and if you’re delivering your software as a service there’s only one release and no direction to go but forward.

My question is: what percentage of software startups these days are planning to deliver their software as a service vs “traditional” delivery of software to be run by customers? Is Marc really right that the software-as-service model is so prevalent now that a book aimed at developers who want to learn the things they need to know to be productive members of a programming team can ignore older styles of delivering software?

Another question is, even if Marc is right that everyone is delivering their software as a service, to what extent they will be able to avoid having to support older versions of their software? It’s one thing for small companies, still in early days of fleshing out their feature sets, to continually upgrade and force their users to come along for the ride. But as they get more users and a more mature feature set, I suspect they will discover that not all their users will be willing to accept upgrades willy nilly. Presumably this will be less of an issue for companies whose real value is the social network of the users as opposed to the value being in the raw functionality of the software itself. In the former case the whole point is to have exactly one instance of the software, shared by all users while in the latter case, if the users are depending on particular functionality, they may not want it to change, even if the change is ostensibly an “upgrade”.

Have an opinion? Let me know.

Update: My former boss Bob Pasker, now a Venture Advisor and CTO-in-Residence at Azure Capital Partners, gives me this breakdown of the software delivery mechanism of companies he’s seen recently in his work at Azure:

• 50% delivered over the web, either as HTML or flash
• 25% require an install, either on server or on desktop
• 25% other (mobile, email, hardware, or both)