Out source or open source?

On demand-applications (aka SaaS) and open-source software are both rising stars of the tech world at the moment. Is one of them going to end up being bigger than the other, or are they going to co-exist?

When I talked with CollabNet CTO and Apache legend Brian Behlendorf the other week, I was intrigued to find that he believes open source is the more durable model — even though CollabNet delivers its flagship application as a service.

To make the case for open source, he cited the example of the Open Source Geospatial Foundation,Open source and on-demand are just two different degrees of outsourcing which is developing tools for web-based spatial applications, with the help of code donated by Autodesk. You might ask, what's the point of an open-source iniative like that when you can tap into all the power and market reach of Google Maps? His answer: "If you can build something like that using open-source technology, you've built something that outlasts Google or Yahoo!" Open source, in other words, gives you the security of knowing you can never be left in the lurch by a provider's unexpected change of strategic direction or even disappearance.

So why deliver CollabNet's own application as a service rather than as open source? (Background note: CollabNet does in fact sponsor Subversion, an open source version management tool — and putative successor to CVS — that it supports as a way of seeding its technology in the market, but its flagship application lifecycle management platform is delivered as a service).  Behlendorf said that since the application needs that CollabNet Enterprise Edition meets are so inherently collaborative and distributed, it doesn't make any sense to deliver it as anything other than a networked service.

That line of argument introduces the possibility that applications will migrate more towards the services model the more collaborative and distributed they become — which is more or less an inevitability anyway in a networked world.

But really when you think about it, open source and on-demand are just two different degrees of outsourcing (or do I mean connecting to the network?). With on-demand you outsource the development, implementation and operation, whereas open source is a means of outsourcing just the core development. This was a theme I heard JP Rangaswami, CIO of global investment bank Dresdner Kleinwort Wasserstein, exploring at a software architecture forum last December. Here's what I wrote up at the time:

"'The vendor community is now an open-source community,' he declared. Instead of having to hand over huge license and maintenance fees to proprietary software vendors every year, enterprises now have the option of turning to open-source alternatives, or even clubbing together within an industry to fund their own open-source project (as, for example, a number of banks are said to have done in the AMQ message queuing project). This applies a form of utility model to the software infrastructure stack, he said, in which users collectively outsource the development of the stack to vendor-neutral open-source projects."

AMQ, which has been masterminded by John O'Hara, a senior architect at banking giant JPMorgan Chase, looks like it will be an excellent demonstration of collective outsourcing in action. The project aims to establish a cross-platform wire-level messaging protocol as an alternative to proprietary messaging stacks. But although the project is said to be on track, work remains frustratingly under wraps until all the participants are confident that it's ready to be unveiled in public.

Behlendorf told me about another example: a group of companies in Minnesota who use CollabNet's development community platform to share development of custom business software, in a project known as Avalanche. "The CIOs got together and said, let's build a private collaboration community where companies share code."

There's no reason, though, why on-demand vendors can't also participate in and benefit from projects like these. Most of them already base their application infrastructure on open-source code anyway. Let's throw one more ingredient into the mix that blurs the boundaries even more: web services and SOA. The principle of standardized published interfaces co-operating in a shared services architecture helps mute the issue of abandoned APIs that Behlendorf cites as a disadvantage of the on-demand model. If the APIs are standardized then consumers aren't tied into specific providers; they can migrate from one to another.

Perhaps the error is to imagine that out sourcing and open sourcing are two opposing models rather than complementary aspects of a single model. Both tap into collaboration and network effects. They are part of something bigger: I'm tempted to call it 'shared sourcing' because sharing is the single constant factor across open source, on-demand and SOA.