Will Swordfish make its point?

The ECLIPSE organization has finally made its announcement of the first release ofSwordfish, the open source ESB (Enterprise Service Bus) framework.

A lot of the work for Swordfish has come from Sopera, a German open source company that has developed an offering around the DeutschePost service bus development. Sopera offers a valid and competent framework for service integration, and therefore it is assumed that Swordfish might also work.

So, will Swordfish make a successful strike at the ESB market? So far, open source ESB projects have not had a great deal of success, and as far as 2009 goes Lustratus has forecast that open source projects will suffer due to the lack of the necessary people resources to turn open source frameworks into a useful user implementation. However, Swordfish has the backing of the influential ECLIPSE organization, which has done a lot to standardize the look and feel of many software infrastructure tools.

Looking at the initial marketing thrust for Swordfish, things don’t look to good. From the announcement letter, the top functional bullet reads

Support for distributed deployment, which results in more scalable and reliable application deployments by removing a central coordinating server.

Well – duh! This is not new – it is part of the basic definition of what an ESB does! However, this initiative is still worth watching, despite the ill-fated marketing attempts so far. ECLIPSE has significant industry backing for its GUI look-and-feel stuff, and indeed most of the big industry names like IBM, Oracle and SAP are involved in the running of ECLIPSE, and provide a lot of the financial backing.

It is this that might be the source of most excitement with Swordfish. Oracle and IBM both actively market and sell their own ESBs, and SAP offers its own equivalent functionality as part of its NetWeaver set of offerings. I wonder how they feel about ECLIPSE driving an open-source ESB version that competes on functionality and is free? I would love to be a fly on the wall in internal ECLIPSE meetings about the future of Swordfish.


The onward march of Linux falters – any lessons for OSS SOA?

Linux may be reaching a natural plateau with regards to corporate adoption as a UBS survey reported that 90% of CIOs not currently using Linux will not make the leap in 2007 (this is up slightly from 87% in 2006) according to a UBS survey reported on here and here.

In effect this means that those who are open to Linux are already using it and the hold-offs are mostly not about to change their minds any time soon.  This should not be regarded as some sort of ‘peak Linux’ type event as organisations already using Linux in some places will continue to extend their usage of the OS.  The report also reinforces the point that Linux is mostly replacing Unix rather than taking market share from Microsoft which is sometimes characterised as the target of Linux.  All of which really means that Linux is coming to the edge of its natural market – UNIX shops which can easily switch – and will struggle to break into organisations which are traditionally Microsoft only.  This does not mean that Linux is not wildly successful and making a lot of money for companies selling services around it.

Turning to OSS and Service Oriented Architectures, are there any lessons to be learnt?  At one level the Linux story bears very little relationship to SOA based projects – Linux was about the commoditisation of very mature specifications and technologies while software associated with SOA is comparatively immature (when compared to Linux/UNIX) and lacking in any specifications in many cases. Also, with Linux  the old established industry giants now rule (IBM et al with the exception of Red Hat as a new giant).  In contrast, OSS SOA is still mostly the preserve of startups (such as Mule Source , Bostech and  Sopera, as well as some integration specialists (IONA) and … Sun and Red Hat.

As I said above, Linux may be plateauing but at a huge scale.  Inevitably, OSS SOA will also reach its natural extent but the risk is that it may reach it before the service providers can achieve viable scale because right now the market for OSS SOA is large enterprises with java skilled developers who are willing to even consider the risk of replacing closed source integration products.  This is a finite market with a lot of incumbent solutions.  Moreover, this is a very tough market for any new solution:  evaluation processes are becoming more and more extended and even if selected the project may well be dumped as IT budget continue to be stretched.  [One could argue that the same challenges face the ‘closed source’ vendors but in their case they are able to extract more revenue from a small pool of customers and remain financially viable.]

Am I therefore saying that OSS suppliers are doomed in SOA?  Not at all – I believe that there is an opportunity for these businesses to succeed (and become the RedHat of integration perhaps?) but it will be a tough going.  In particular, it is a lot harder than suggested by most coverage of OSS which focuses on huge download rates and arguments such “Its free, developers love it, everybody will use it” and ignoring the real world issues around adopting any enterprise integration technology (which are mostly not related to the license fees).

Of course the OSS suppliers already know this and are developing different strategies to address the problem.  For instance, Mule Source is particularly focused on promoting community based development of additional components such as application adapters and transports – thereby deeping their engagement with customers and making it easier for customers to get a ‘complete’ integration solution – and has recently launched MuleForge to support this effort. IONA has been buying OSS expertise and has relaunched its OSS efforts (now called Fuse) deliberately focusing on the most popular Apache SOA-related projects with the obvious benefits of existing customer base and large pool of developers.  RedHat is also acquiring technology to provide strong data management capabilities by open sourcing MetaMatrix which is currently closed source.  Other suppliers have different ways to crack this nut but whether any of these strategies will succeed or fail is of course more complex than can be easily covered in a blog entry of reasonable length – however we will be addressing the area in upcoming Lustratus papers.