Read the article again, substituting "Apache" for "Subversion", and "web hosting" for "Subversion on demand". The only difference here is that Apache org isn't doing web hosting. By this argument, there's even less "traditional" support for the web server people use most.

Sure it's differently risky. You're paying a service provider to insulate you from any in-house failures they may suffer - on systems which to them are mission-critical. The risk of a service provider failing isn't new or frightening, on the contrary it's a matter of commercial, rather than technical, risk. Everyone in the boardroom can understand that.

Alt0n

I am sorry, but this article smells of FUD (Fear Uncertainty Doubt), targeted both at Subversion and at Open Source in general. Why is using an external code repository hosting company like CallabNet any more risky using an internal one, where "the risk of a service provider failing is new and frightening"? Can you provide an example of this, or at least flesh out your argument?

External hosting companies, like any other service provider, are bound by their service level agreements (SLAs) with their users. Furthermore most quality repository hosters should offer daily offsite back-ups of your code and extensive redundancy features. If they don't then shop elsewhere.

As for using Subversion internally, my company does this and we are very happy with it, both technical and from a support point of view, where the Subversion community and online documentation are second to none. We are actively moving all of our repositories from a commercial source control package to Subversion, which we believe is vastly superior.

I would like to conclude by saying that I really do not understand the main point that you are trying to make with this article, as your argument is weak. Are you trying to imply that relying on open source products is inherently more risky than relying on commercial ones? If so, FUD.

Having seen some pending comments, I must empahsise that "differently risky" is not "more risky" - but everything has some risk associated with it, which must be managed. This isn't FUD, it's being realistic. If you want an example of new risks being overstated, look at how worried we are about bird flu and how complacent about crossing the road - road traffic accidents are a far bigger risk than catching bird flu, at the moment, anyway.

I didn't say that anyone was right to be frightened by apparently new risks.

And the point of my blog is to promote discussion, so I like comments. And, in this case, perhaps to point out that "one size doesn't fit all". Are Open Source enthiusiasts perhaps a little defensive sometimes?

At the risk of sounding like one with pointy hair, I just can't imagine a company making an informed decision to use Subversion on Demand compared with other commercial alternatives.

I am every bit the open-source zealot - I shit you not, I'm wearing a GNU baseball cap right now - but even I would not choose Subversion over, for example, Perforce.

See: http://www.perforce.com/perforce/price.html

For an organization with only 20 users, your talking about an extra 11$ per month per user for a more stable, better supported system.

In my experience, perforce outperforms subversion in every way, especially stability and scalability (though neither is particularly scaleable). Pretty much the only advantage of subversion is that it is open and non-proprietary.

Now take an organization with over 100 users - your actually paying the same for Perforce versus Subversion. In my mind, this is a no-brainer. If CollabNet wishes this to be successful, they might want to rethink their pricing (yes, I realize that the cost of hosting is figured in there too, but the cost to buy a machine and set up on the local network for the perforce case is amortized).

I like the cost/benefit approach - this is how we should choose software, not because of some religious belief in the merits of opensource or demonisation of a particular vendor.

Mind you, the detailed cost/benefit analysis for a hosted solution may not be trivial....