This final post in the series looks at tips for getting benefit from OSS implementations.

The first point to remember is that even though OSS software is ‘free’. its adoption needs to be planned carefully. This is even true forthe lowest risk area of personal productivity tools, surprisingly. Most people think this is the easiest OSS area, and are happy to let OpenOffice or Firefox or any of the multiplicity of user tools be loaded….but this can lead to trouble. Remember that one characteristic of OSS is that because it is free, there is no need for a user to gain purchasing approval, and hence adoption can be uncontrolled. If it then turns out that the new software introduces an incompatibility with other systems, this can be a nightmare. Make sure that adoption is controlled and that every employee is aware that OSS software purchasing should go through the same governance procedures as commercial software, even if it doesn;t cost anything.

This leads to the next point. In fact, OSS software is never free. The LICENSE may be free, but there are users to train, developers to educate, support to be arranged, risks to be evaluated and countless other tasks. Indeed, at the OSS infrastructure level as opposed to end-user productivity tools area, most OSS offerings are of the ‘framework’ type where the user is left having to do extensive development and customization before the software can be used productively. So, to succeed with OSS it is necessary to evaluate the business case taking all these resource and service requirements into account, even if license costs are 0.

The next tip is think ahead. Ask yourself why the software is free. Is it because the software community, out of the goodness of its heart (!), wants to share its bounties with everyone for free, or is there some other game plan at work? A number of OSS projects have come about from users wanting to find a way to defray their costs of supporting their home-developed code base. Projects such as AMQP and Swordfish srping to mind. The issue here is that if the particular project never really gets popular acceptance, then  future updates are at risk of dying off if the original authoring company changes direction. Other OSS projects are offered by vendors having a ‘full-function’, priced version of the software. Remember IONA’s Artix / Celtix ESBs? Artix was the commercial product, and Celtix the OSS version. Every time IONA added new function, it tended to put it in the commercial one first, and only backfitted it to the OSS version if it didn’t get wide acceptance. So, be aware that if you go with an OSS project you may have to take a commercial license in the future.

Watch out for projects that claim massive acceptance but which in truth are only supported and used by a small minority. A typical trick to watch for is claims of ‘Millions of donwloads’. This is really weak – remember that if something is free to download, every student in the world is likely to download it at least to play with. Only a timy fraction of these downloads would even move to a point of trying to actually use it.

The best tip of all is to wait for clear signs that a particular OSS project has gone mainstream. So, Mozilla Firefox is so well-known as a browser, with so many users, that it is a reasonably safe bet. LINUX has huge industry support, and rich backers such as IBM. There is no way it would ever be allowed to fall behind in the technology stakes, and because of its wide acceptance there are hundreds of companies in the LINUX ecosystem now offering support, services, training and other OSS LINUX add-ons. However, If you really want to be a trailblazer, then go ahead with unproven projects…but just go in with eyes wide open.

Steve

One of the defining qualities of OSS is that, at least at a basic level, the produt can be licensed at no charge. This immediately raises the question of how sustainable the model surrounding theOSS project is. The fundamental question is, who is going to keep the code base up to date? Who will apply fixes, develop new function, offer support, provide documentation, etc?

There are a number of different types of OSS project, and each has different business model implications that affect its likely success and future longevity. At its heart, the OSS movement really got under way based on an ‘anti-commercial’ theme, where programmers wanted to share their skills and use software that was developed ny them, for them. This is fine as far as it goes, but as people’s interests change, the exposure is that these developers will move on to something new and the original OSS project will wither away. In the rare situations where th problem is overcome, there is usually a viral element to the project’s success, like in the case of Firefox for example.

The next model is where a commercial company is set up around the OSS project. Usually, these companies sell services around the OSS project such as documentation and training, as well as offering commercial licenses to cover support, or verified and tested versions of the OSS code base. The success of this approach will depend on whether the OSS users are prepared to cross the ‘free software’ line and accept that there will still be costs incurred. A big problem here, however, is how extensive the support offered is. The worst threat is that OSS projects often use other OSS offerings to fill out capabilities, and therefore either the commercial support organization has to become expert in all these code bases, or there will be gaps in the support.

The most devious OSS model is where a vendor sponsors an OSS project for its own advantages, regardless of the implications on the user. Typically, a vendor might take a base level of code and make it an OSS project ‘for the good of the community’, but instead of this project attracting other development partners it remains drive by the single vendor. Now, that vendor typically produces an ‘authentic’ version of the project which DOES have a license cost and maintenance fee. The idea is to get users on board thinking the product is free, and then hook them with the professional versions.

Finally, the best OSS model of all from a user point of view is where a number of large vendors decide it is in their interests to back a particular OSS project. This is the case with LINUX, for example, where vendors such as IBM have put in millions of dollars of investment. As a result, a whole ecosystem of LINUX-oriented companies have sprung up, and all of this ensures that LINUX users can have a degree of confidence in its future.

Steve

The main risks for users to consider fall into four areas:

1. Support
2. Longevity
3. Governance and control
4. The 80/20 rule

The first is perhaps the most obvious risk of OSS. The principle behind OSS is that the code is developed by a team of interested parties, and support is often initially offered in the same light. So, problem resolution is based upon someone else giving time and effort to work out what is wrong and fixing it. Similarly with documentation, education etc – they all depend on someone else’s good will. Some proponents of OSS will point to the fact that commercial companies have sprung up that provide fee-based support for various different projects, but this has a number of big drawbacks. One is that this is fee-based and therefore impacts one of the open source advantages (free licenses), and the other is down to the nature of most OSS projects. OSS developers usually operate on a shared code mentality, and frequently use many other OSS components in their own solutions. While one of these groups might form a company to offer support contracts for the code they have developed, they usually have to rely on ‘best can do’ support for the other components they have embedded. All of this brings in a great deal of risk attached to using OSS. The one difference is where a company has decided it wants the OSS specifically because it gets the source and can now staff its own maintenance and support team.

Longevity relates to the support question. OSS projects need their driving teams of developers, and if for some reason these people decide to move onto something more exciting or interesting, the user could be left using a code-base that has noone left who is interested in it. This means future upgrades are extremely unlikely, and leaves the user stranded. A special case to watch out for here is those crafty vendors who start an Open Source project around some new area they are interested in, supplying a very basic code base, and then when enough users have bitten on the bait they announce that future development is going to be supplied int he shape of a traditional licenses software offering, while the original code base remains at a basic level.

The governance / control risk is a tricky one. The problem is that be definition anyone interested in a particular OSS project can download and use the code. A company might decide to use OSS for specific needs, only to discover that it has proliferated without control due to the ease with which people can download it. These downloaders may think they base is supported because the company has decided to use it in other places, but they may have downloaded different versions or anything. Related to this is the control of quality – as other OSS users develop updates, these are supplied back into the OSS project, but who if anyone is policing these changes to make sure they do not alter functionality or remain compatible?

The final risk area relates to the nature of people. The driving force behind any OSS project, at least in the early days, tends to be a fanatical group of developers who really enjoy making something work. However, anyone familiar with software development will be aware of the 80/20 rule – that 80% of the code takes 20% of the effort to write, and vice versa. The natural inclination for any OSS team is to do all the fun stuff (the 80%), but to tend to shy away from the really heavy-duty complicated stuff. So, areas such as high availability, fault tolerance, maintainability and documentation are the sorts of areas that may suffer, at least until the project gains some heavyweight backers. This can severely limit the attraction of open source software for commercial, mission-critical needs at least.

It is for many of the reasons given above that the area of greatest attraction for new OSS projects tends to be in the personal productivity area, where there are alternatives to mitigate the risks. So, Firefox is great, and has super usability features because it has been created more or less by users, but if something went sour with a latest level of the code the users could switch to IE without too much pain. Deciding to use OSS in a production, mission-critical environment is much more dangerous, and generally only acceptable when there is a cadre of heavyweight underwriters, such as in the case of LINUX. In this case, IBM would never let anything go wrong with LINUX because it is too reliant on its continued success.

Part 3 will look at this area more closely as it discusses the OSS project business model.

Steve

…or whether it is because users are not completely sure whether they can trust the marketing messages put forward by different OSS projects and their supporters and are looking for an independent perspective. However, I have decided to jot down a few thoughts around OSS, based on a practical and logical assessment. I have gathered these observations into four areas

• What are the user benefits of open source?
• What are the risks?
• How does the particular open source project business model work?
• What needs to be done to achieve the benefits?

This first post deals with the first area – what are the user benefits of open source?

I guess the most common one users bring up is that OSS is free! No license fees has got to be good, hasn’t it? Just one work of warning here – it is worth checking the exact terms for the specific OSS software to validate that it really IS free. Strange as it may sound, some ‘OSS software’ is NOT free of charge.

However, there are other potential benefits to consider. For example, some users find that having access to the source code is a benefit. This may be because the user can now make changes to customize the software so it is more effective for the company, or the confidence it brings that a failure can be resolved locally without having to wait for support organizations to respond. Once again, however, check the small print. Some OSS Software projects do NOT distribute the source, and others require any updates and new developments to be fed back into the project.

Another appeal of OSS is the fact that it can pool the ideas of thousands of technical minds across the globe. Hopefully this will mean that the code is usable and effective. Since these minds will also be available to check the code, it should also give a higher code quality. The caveat in this case is to make sure that the particular OSS project of interest really IS a broad community, and not just a small interest group or worse still a single vendor pretending to be pushing a widely supported OSS project.

Finally, there is the hoped for standardizing effect of OSS. That is, if an open source project takes off and gets wide industry backing, then all vendors are likely to find it easier to support because there is no hidden agenda of favouring a particular vendor. This can stimulate a much wider and more rapid acceptance of the particular code-based, resulting in it becoming at least a de facto standard if not one supported directly by standards bodies.

More to come – the next post will be about the risks of open source….

Steve

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.

Steve

The problem with Open Source has always been to my mind that the myth of Open Source slowed down the development of mature business models.

The myth is that OSS is an almost altruistic endeavour when end-users cooperate to produce the software projects they require.   In this myth, the vendor role is one of coordination, packaging and support for which the end-users willingly pay maintenance and support fees.

Unfortunately, this virtuous circle was the exception rather than the rule when it came to enterprise OSS:  Most Open source projects rely almost entirely on vendors for code contributions and vendors have found it hard to get the maintenance fees from users who struggle to justify paying for something perceived as free.  This has made the path of any business following this model extremely difficult.

Therefore, I have been pleased to see that the myth is beginning to dissipate and what has been happening behind the scenes emerge.  The451, who have an excellent blog focused on the enterprise Open Source space, have recently published a report which is interesting because it rings true to my experience when it says:

The majority of open source vendors utilize some form of commercial licensing to distribute, or generate revenue from, open source software.

And

Ad hoc support services are used by nearly 70% of the vendors assessed, but represent the primary revenue stream for fewer than 8% of open-source-related vendors.

and

Most vendors generating revenue from open source software are reliant on direct sales staff to bring in the largest proportion of revenue.

The cynics among us might say that this is starting to sound very like the closed source model that OSS was meant to kill.  However that would still be a little unfair – OSS is still different but maybe not as different from a commercial perspective as originally advertised.

Ronan

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

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

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

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