Revisiting Biases Against Open Source SOA Solutions

Ronald Schmelzer, a senior analyst at ZapThink revisits the common misconception/biases on the suitability of open source SOA solutions for the enterprise and asks “why is it then that so many IT organizations prematurely discard Open Source Software (OSS) from their SOA implementations?”

To make it absolutely clear, ZapThink is not advocating dumping all your vendor solutions in favor of an OSS stack, however, we believe that the current economic and technology environment are making OSS solutions more credible, feasible, cost-effective, and potent as the industry matures.

He starts out defining open source software according to Wikipedia; carefully pointing out the subtle difference between free software and open source software.

The term open source is frequently, although not always, used in conjunction with the idea of free software. In this terminology, free sometimes means that it costs nothing to acquire the license, but that’s not exactly how it’s defined by the Free Software Foundation (FSF). The FSF defines Free and open source software (F/OSS or FOSS) as the freedom to copy and re-use the software […] This means that FOSS licenses gives users the rights to copy, modify, share, redistribute, and otherwise contribute to the advancement of the technology, but doesn’t necessarily imply anything about total cost.

In addition, Open source software also comes in commercial flavors (COSS) where “the community has rights to certain aspects of modifying, sharing, and enhancing the software whereas others are reserved for the company”; contributing to the Fear, Uncertainty and Doubt (FUD) surrounding the adoption of open source solutions, let alone navigating the legalese of various open source licenses available.

Let’s start with uncertainty. From a SOA perspective, the big uncertainty on OSS rests on two main issues: are there a sufficient number of OSS offerings to cover the scope of things we need for our SOA implementations, and are those OSS projects of sufficient quality to meet our needs?

He goes on to answer the question

[I]ndividuals and companies have poured tens of thousands of hours of development time and maintenance into these [OSS] tools. […] Many open source tools build upon the experience of users who have previously used commercial offerings and thus aim to mimic or improve the functionality and performance of those solutions.

In addition he points out that, as many of the vendor tools are products of acquisitions, and in some cases a series of acquisitions; it is often the case that the commercial/vendor solution is “ill-defined” in terms of road map and integration with other products in the product portfolio. He goes on to categorize and list the various solutions available in the different parts of the solution space…

He asserts that the fear that OSS solutions may not be supported is unfounded, saying most OSS projects have commercial companies offering paid support.

While it is true that many good OSS solutions require paid support to achieve the response time and care necessary, we would argue that money is well spent. With commercial companies providing support for OSS offerings you get the best of both worlds: community development, testing, and enhancement at low or no cost, and professional support whose time and value are known quantities. Even if you chose a commercial vendor, you’re going to be paying for support anyways.

… Additionally, he suggests that OSS mitigates the risk of sun-setting products/product lines as a result of churn in the IT industry in the form of acquisitions, cost cutting, or consolidation.

OSS presents less of a risk because the code is out there in the community, available for anyone to pick up. From a SOA perspective, you want to have as few dependencies as possible on your infrastructure or a single vendor’s solutions. As such, for many, OSS makes a whole lot of sense.

He goes on to give the example of how BlueStar Energy estimates saving of $24 million over the course of five (5) years with an SOA implementation that is based entirely on OSS solutions.

If you read the case study, you can see that the design principles had a decidedly non-vendor bias. They wanted control over their environment, and this meant creating a specification that required implementation neutrality. […] Their Business Integration Suite consists of open source distributed, scalable and reliable components such as enterprise service bus, business process management system and messaging fabric.

He urges architects to define the architecture in a implementation agnostic/vendor-neutral way and evaluate the suitability of candidate solutions; be it open source or vendor solutions. He concludes his article with an endorsement of the viability of OSS for SOA implementations in the enterprise.

Check your FUD at the door. Make sure you aren’t losing an advantage by prematurely eliminating OSS from your SOA infrastructure mix.

The UltraESB from AdroitLogic is a free ESB, available for unlimited and perpetual use. Its source code is currently shared with partners of AdroitLogic and will be open sourced within 2-5 years. Its been shown to perform extremely well under load, and comes with many samples and test tools, at around 25MB to download

I'm sure the UltraESB is excellent technology given your skillset, and I wish you luck with it, but it is not an Open Source ESB. There are clear definitions of Open Source and a set of well-defined licenses from the OSI and UltraESB doesn't fit into any of them.

The UltraESB is not claimed to be an Open Source ESB.. But at the right time, it will. And AdroitLogic does not have plans to build a large platform with many bells and whistles.

Instead, we strive to do build an ESB that's really better than whats available. We design it in a way that makes it useful and simple for the users, while being much better in performance.

For example, we've re-written the functionality of Rampart/WSS4J well known to be weak in performance, to be over 4X better.. and I believe the UltraESB is the first ESB to claim non-blocking IO with Zero-Copy support when the OS and HW supports it.

May I add that Red Hat/JBoss offers a fully supported Open Source SOA-Platform for quite some time now. At the enterprise level offering 24x7 support is key. With the current level of maturity of the open source middleware, along with the tooling I think the scale has already swung in favor of open source.

I have implemented JBossESB and found it to be a great product. It has a lot of useful, feature-rich tooling and has a plethora of out-of-the-box actions. In addition I found it easy to write my own actions and the documentation is very comprehensive. Definitely worth a look.

May I suggest that you then come back when you have actually open sourced it?

In 2-5 years time, your company may be gone, Greece may be out of bankruptcy, Iceland may once again be flourishing nation, and the US may have universal health access. It is simply not interesting what your 2-5 year long-term plans may or not may be at this point.

AdroitLogic already shares the code of the UltraESB with real users! .. and I do come from a history of over 4 years of contribution to the open source Apache Synapse ESB, where I contributed over 70% of its last released codebase.

I truly believe what my company offers is better - as we share the 'real code' with 'real users' who are interested, and not using the term 'open source' for marketing reasons to bait customers. The software we provide is offered free of charge for unlimited and perpetual use.

Many companies that have 'open source' products, swiftly switch over enterprise customers to the 'commercial version's that are .. of course 'much better' ;)! .. the reality is this code is not shared with the customers in almost all instances. The customers then run versions from vendors' internal 'support branches' they have never seen or heard of!

Although the 'open source' version of the code may be available, even that may not be build-able, or understandable for an average user that easily. In 2-5 years time the open source companies maybe gone too; and along with it, the open source code repository, bug tracking and maven repositories and wikis etc holding critical artifacts.. It would certainly be an interesting situation for a customer to be in, when they finally find that they have been living on a 'support branch' of an open source project, for which they have no access anymore!

The Apache Software Foundation tries to overcome this issue by creating an open and diverse community:

"The project is considered to have a diverse community when it is not highly dependent on any single contributor (there are at least 3 legally independent committers and there is no single company or entity that is vital to the success of the project)" [1]

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.