LiteBytes from Lustratus Research

Jitterbit kick-starts an OSS solution marketplace

An article in ebizq alerted me to Jitterbit's just launched "Trading Post" for integration-specific solutions.  Jitterbit claims to the "World's most popular Open Source integration platform" - which surprised me as I had not heard of them before.

The idea of setting up sites to enable the selling of software components is hardly new (although rarely successful) and of course sharing is precisely what an OSS community is supposed to be about. What is more interesting about the "Trading Post" idea is that

- It focuses on solutions: i.e. not just source code for the bits of the puzzle but also the patterns and knowledge essential to deliverying the complete solution.  And directs potential users to the services provided by "Trading Post" providers who can help to deliver the solution and

- It focuses on both application specific solutions (such as JD Edwards) and industry specific solutions.  Again moving the emphasis away from raw technology towards problem solving.

- It provides an interesting revenue opportunity for OSS service providers/vendors who often struggle to drive revenue from support/maintenance alone.  This is because it crisply defines the value they (as Trading Post providers) can give around specific solutions.

While just launched, it is already 'pre-stocked' with 50 solutions which demonstrates a certain amount of apparent momentum.  Perhaps it is a model other OSS vendors should take a look at...

Ronan   

Beware of the OSS Trojan Horse

Open source software (OSS) seems a great idea, particularly for segments of the market like SOA where there are lots of standards - some would even say too many. After all, the software is free isn't it? Of course, in reality,the decision whether to go with an open source approach to SOA is a lot more complicated than that. The key thing when considering SOA is to be realistic about the business case, as discussed by Ronan in his recent post. Evaluating the value proposition for open source SOA is a non-trivial exercise. This is a subject that Ronan goes into in much greater detail in his recent Lustratus Report, "The open source value proposition for SOA", available from the Lustratus web store, where he considers a wide range of factors affecting the final decision.

One point that jumped out at me from the report related to the need to be sure that the chosen OSS solution is not a trojan horse. The problem is that some open source projects are actually being used as test-beds by commercial vendors, as a way of gaining valuable input and experience that can then be used as part of a future commercial offering. On the one hand, this can be attractive - after all, if a vendor is driving the project then it is likely that skilled resources will be available to ensure its vitality. But on the other hand, if the vendor plans a commercial offering then what functions will be reserved for the 'full function' offering? Will these be needed in the future? As Ronan states in the report,

"It is common with the larger vendors in particular to promote OSS as a light weight alternative to their full strength closed source products.  For these vendors, it is essential that due diligence verifies that the OSS solution will be sufficient for all current and future requirements.  If this is not the case, the cost of the closed source product must be factored into the business case."

This doesn't mean to say that these projects should be avoided - just that it is wise to consider the gifts the Greeks are bringing, and what's in it for them....

Steve

Building a realistic business case for OSS

Some proponents of Open Source Software can be their own worst enemies in the efforts to distance themselves from the traditional software license based vendor.  For instance I read in a recent article that two of the benefits of OSS were: 

“Never again will you fear the BSA (Business Software Alliance, not the Boy Scouts!) knocking on your door wanting to perform a software audit.  The BSA even takes out advertisements on Google search pages for and up to $200,000 reward a disgruntled ex-employee can receive for reporting your company to the BSA! That's quite a powerful motivator.”

And

“In the world of Open Source Software, if you can't wait on someone else's schedule for a new feature, then you add that feature yourself. What? You don't have programmers on staff? You can always outsource to a programming company and have them do it for you.”

To translate OSS is really great because you won’t get nailed for breach of licensing agreements and you can always write your own software.  Not exactly compelling arguments for any business case!

While there really are arguments for ”going OSS”, most firms will not take such a strategic move.  In most cases, OSS is used to solve specific problems – just like any other piece of software – not change the world.  And the business case covers the same territory as for closed source: a combination of technical evaluation and assessment of cost and business risk.  The second point is challenging only in that we are less familiar with evaluating OSS in this way - and isn't helped by over enthusiastic promoters of the OSS religon.

Ronan

Open Source SOA - Are we there yet?

I am often asked whether open source (OSS) SOA is a reality yet - whether it is ready for prime-time, as they say. The answer, as is often the case, is 'It depends'. There are many OSS projects in the marketplace around ESBs, Integration and SOA, but just having a project in place is a long way from having production-ready software. For a start, there are the questions of maintenance, support and even indemnification against possible future legal activities. The most useful projects are those that have an associated commercial company addressing these types of areas.

However, the other aspect to consider is that most opern source projects are started and driven by technically adept programmers, so they tend to be oriented towards programmer usage. In SOA, this may be acceptable, depending on requirements, but it may also be desirable to have a solution more oriented to business analysts. They key is to be clear on what you want, and on what is being offered.

For a longer discussion on this topic, Lustratus has just published a free assessment of one particular OSS integration vendor, MuleSource, and its open source offering Mule. This paper considers a number of these types of key questions over OSS SOA, but of course in the MuleSource context.

Steve

Is Open Source the next enterprise software giant?

Guy Nirpaz commented on my post about Oracle's potential BEA acquisition stating that he believed that OSS should be on my list of the big 4 (IBM, Oracle, SAP and Microsoft) if you consider middleware in particular.  I would agree that middleware is certainly an area which OSS is playing an increasingly important role. 

However, OSS does not necessarily represent the increase in choice you might expect as in many cases the big players either dominate or can dominate if they choose to (the investment in OSS by big players is excellently covered in a Harvard Business School working paper referred to here).  In those cases, there is a potential risk that the OSS becomes positioned as the entry level offering with the pay-per-license version containing the features required for serious use or used to reduce the level of choice available by putting pressure on smaller vendors. 

For smaller backers of middleware OSS, historically it has proven difficult to create a sustainable and scalable business model.  However, I believe that is a market maturity issue rather than an underlying weakness in OSS approach.  Already, we are seeing the emergence of some interesting business strategies which seem capable of sustaining a growing business.  If one or more of these work out, then OSS enterprise middleware players may emerge (or existing vendors successfully transition to Open Source business) which will challenge the hegemony of the big 4.

Ronan

Open Source and risk

The focus of debate on Open Source is too often focused on "its free" and sometimes overstated claims about software quality.  As everybody knows, the cost and risk associated with bringing anything into an enterprise go far beyond the license costs.  For OSS, a big problem is that by its nature it can bypass the controls imposed by procurement and the legal departments.  This can lead to a range of potential risks from IP infringement to plain old version control.  Of almost equal importance to the actual risk is the fact that the risk associated with OSS can be invisible  (as the OSS use will often not be tracked as licensed software would be) and therefore undermine the whole of IT risk management.

This article covers one approach to dealing with issue:  specialist software to analyse the Open Source software.  There are of course more straight forward alternatives:  Any vendor supplying OSS as part of a licensed product should be held to account to provide support and 'handle' the risk issues.  For 'pure' OSS, there are plenty of commercial organisations who will provide a degree of quality assurance and service guarantees around projects.  It may take away from the "Its free and I won't need to talk to legal and prodcurement" but do we really want staff bringing software straight from the web into deployment?

Ronan

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.

Ronan

Red Hat: The last ESB start-up?

As part of my work prior to updating of “Best of breed ESB” paper, I was recently briefed by Red Hat about their current ESB and SOA related projects which will become a supported ‘product’ called JBOSS Enterprise SOA Platform towards the end of the year.  This puts them rather late in the game when compared to both open source and closed source offerings.  Combined with the focus of the briefing on functionality over value, it felt very much like I was talking to the last ESB start-up to appear. 

As a characterisation this should not be taken a wholly negative:  For a company the size of Red Hat with its strong JBoss application server franchise, it would not have been surprising if they had simply done a me-too ESB to match that available from other stack vendors.  Instead they are putting together a much more interesting set of capabilities but lack some others that will required for most serious enterprise use.  On the positive, they seem to have a good grasp on the importance of data within SOA including both their MetaMatrix acquisition– once it has been open sourced - and pipeline based transformation (allowing complex manipulation of messages in-flight often required within deployed SOAs).  Counter-balancing this, there is still much to do around service life-cycle and in particular how to support service reuse.  I won’t attempt to go into much more detail at this time until the report is completed.

Ronan

Be fair to OSS - lay off the sauce

Open source software has come on by leaps and bounds over the last ten years or so. There are more and more examples of credible OSS (Open Source Software) solutions available today, including well-known brands such as Firefox and LINUX. However, OSS seems to me to face a major enemy - itself.

The problem is that, deep down, the OSS community can sometimes see itself as a bastion of freedom against the evil commercial ISVs - certainly some of the more vocal supporters of OSS are guilty of making more and more outlandish claims about their own projects, really pouring on the sauce. Some of this is to be expected, of course, but there comes a point when fanatical over-statement of the facts can so offend credibility that prospective OSS users are turned away.

I was reminded of this problem by a recent article by Dennis Byron, writing for ebizQ. While I found the article both interesting and informative, the section on enterprise service buses (ESBs) illustrated my point. In the article, Dennis states

"ESBs are especially interesting because they may turn out to be the first category of software code that was OSS from the get go." And later, "The OSS movement in turn blocked those early non-OSS ESB market leaders before they could gain a lot of traction."

The 'early non-OSS ESBs' phrase refers to companies such as Progress, Cape Clear and Fiorano, according to the article. This is the type of hyperbole that in my view causes the OSS movement to weaken its own credibility. The implication is that OSS has ruled the ESB market from the start, apart from some minor incursions by early ESB vendors such as those listed.

Now, I will agree that OSS ESBs are maturing nicely - the Mule OSS ESB, for example, already lists a substantial number of production implementations on its website. I think that as time goes on, these OSS offerings will become more and more competitive to the commercial offerings. However, to state that ESBs were 'OSS from the get go' is just ridiculous. For the first three years of the ESB market's life, the only serious usage was with commercial offerings. While it may be true that some of the early players failed to gain much traction, there are now commercial ESBs available from all the major vendors such as IBM, Oracle, SUN and BEA, and some of these are performing strongly in the market.

I believe the OSS cause is best served by a more realistic assessment, without all the sauce. We are now at a stage where OSS ESBs are a viable choice alongside commercial offerings. There are references for successful usage of OSS ESBs, and the future appears to be bright - for example, OSS solutions with a supportive community could result in pools of less common adapters being available to satisfy a wide range of needs, something less likely to happen in a commercial world. But to state that commercial ESBs never made it, and OSS ESBs ruled the roost from the start, is in my opinion a wild exaggeration.

To be fair to Dennis, later in the article, while discussing message-oriented middleware and the impact of OSS offerings here, he states

"But it will be well into the period 2011-2020 before commodity MOMs/ESBs significantly displace IBM MQSeries and like products."

This comes across as more realistic, and hence makes a far more credible claim. MOM (Message-Oriented Middleware) products like MQSeries are much more extensively deployed that ESBs, with many thousands of users, and therefore even if there were attractive OSS alternatives (and this is definitely arguable today) it would take some years for any significant displacement to happen.

Steve 

Open Source = Community = Japanese documentation

As the OSS movement grows. companies are spending more time thinking about open source and whether it might be an option for use in their solutions. I have always believed that the holy grail for open source is to achieve an active community, contributing and assisting the growth. In this way, requirements can be met that a commercial offering might struggle to satisfy in an acceptable timeframe.

This was brought home to me when I came across a contribution to MuleForge, the community repository for the Mule open source SOA offering. I noticed that someone had contributed Japanese documentation for the Mule ESB. This is a perfect example of my point - even the largest vendors struggle to deliver such things as multi-language documentation. at least until quite late. The issue is justifying and prioritising the necessary resource based on the relatively small market potential addressed by some developments.

But when a community is leveraged, it can contribute many things, even if they are only going to be of interest to a small number of people. So here, one assumes a Japanese user has picked up Mule and decided to write some documentation, presumably for internal use. This has then been contributed to MuleForge, and the result is anyone can benefit from it immediately.

If the power of a worldwide community can truly be unleashed, OSS becomes a highly attractive candidate for product selection shortlists.

  Steve