« BPM for free | Main | March of the IDEs »

In my consultancy work I have seen many situations in which people who knew they could deliver real business value by utilizing open source tools found their efforts strangled by corporate insistence on lengthy evaluation processes. Apart from the time and effort involved in going through such processes, which in itself is a serious deterrent, the cost of carrying out such processes is so high that you might as well buy commercial software from a leading brand.

Consultants and lawyers are the ones who really love this kind of thing - it keeps them in work, and they can make a good case for such an approach to senior executives by stressing risks. In fact it is partly the FUD (Fear, Uncertainty and Doubt) generated in this way that holds back the adoption of open source tools. The criteria typically listed for evaluating open source tools are in fact equally applicable to commercial software, but usually not applied in anything like such force to organizations that have an "Inc" or "plc" in their name - and it's harder to anyway, not only since commercial companies are much less transparent than the open source community, but also because they may have less of an issue with honesty. Large manufacturing companies may think it normal to hire a business integrity consultant to check out a new parts supplier, but few CIOs do so with their software vendors.

As I commented in the first entry in this blog series, the hazards of open source are not those typically those voiced as objections by consultants anyway – unstable or insecure software, availability of support, and legal issues. The open source projects I have discussed, for example, are perfectly viable from all these perspectives. In general, major open source software applications are written at least as well as leading commercial products (often by the same people), enthusiastically supported by expert and helpful developers (as opposed to knowledge-free call center staff), and transparently licensed (via industry-standard agreements). More to the point, anyone with enough experience in IT knows that leading, expensive commercial products are often deeply buggy, poorly supported and legally vulnerable.

So, how should one evaluate an open source system? Is there an easier way to determine the risk?

In my own software development work, I have used many different open source products, and always go through the same 3-stage process when selecting one.

First, I evaluate my own need as clearly as possible. What is it that I am really looking for? People often work under false assumptions when evaluating new software - assuming, for instance, that they need a database when all they really need is a means of saving objects to permanent storage, or that they need Web service tools that support the full WS-* stack when all they really need is a means of enabling communication between distributed components. Conversely, you may be looking for a tool to help write HTML or XML when you would be better served by a higher-level system that generated such low-level code automatically for you, concealing all the complex details.

This step is the fundamental one if you have any interest in open source. The reason so many open source projects exist is that people start them to meet real-world needs, of which there are an infinite and varied number. Somewhere out there, there is probably someone who has had exactly the same problem as you, who has solved it by writing the tools they needed, and who has then decided they may as well make them available to others via open source. If you are considering open source at all, you may well find you can get exactly what you need, not only what is offered by a limited number of commercial vendors.

So let's assume you have applied such lateral thinking and found a set of tools that meet your needs as closely as possible. Which ones are safe for enterprise adoption?

The second step is to tick some basic boxes - those above, for software stability, availability of support and legality. This is the work of minutes, not days. A project with 1 committer who last posted an update 3 years ago, that has no stated users, and whose license consists of "use this as you wish" is not a good bet - but you can feel secure in choosing a project that:

1. Has a number of committers who post regular updates


2. Can demonstrate a user base


3. Is backed by VCs or major companies


4. Uses one of the standard open source licenses (assuming that the conditions of the license do not preclude your intended use of the software).

Having made a shortlist of tools that are both suitable and viable, the third and final step is to ask yourself a single question - and again it is the same question you should ask when evaluating commercial software. What would we do if this project ended? In other words, is it possible either to maintain the open source software in question in-house, or replace it by another product?

Most enterprises would look for the second option, since the current trend in IT is to divest oneself of responsibilities rather than incur new ones. If you are of this mind, here are the things you should bear in mind when answering the question:

• The replacement product does not have to be open source. If you eventually have to switch to a commercial product, you have simply gained some license-free time from initial use of an open source product, which should be more than enough to cover the cost of the migration.


• The replacement product does not have to work in the same way as the original product, or provide the same functionality - it just has to support the usage you intend to make of the open source product. In a simple case, a replacement for your email server only has to support the configuration you have implemented, not every possible configuration available in the product you currently use. For a more complex case, consider JBoss jBPM, for instance, recommended as a free BPM solution in the previous post to this blog. This is packaged as a Java library, that can be used standalone in any Java program or with any application server, can export suitable processes to BPEL, and though the programming model of JBoss jBPM is very powerful (see the last post) it is based on a standard Petri-net paradigm dating back to the early 1960s. So let's suppose the JBoss project ends for some reason, though this is highly unlikely. Existing jBPM processes can be supported for as long as desired in any other Java execution environment, those based on Web service orchestration can be transferred when desired to any BPEL engine, and it is essentially a matter of legwork to port other processes to another workflow system that is likewise based on Petri nets. If you are using the more advanced features of jPDL, you will have to make the odd change here and there, but in the end this is a completely conventional trade-off between functionality and portability - a trade-off that enterprises make every day when utilizing software products, whether open source or commercial.

TAKE AWAY

Open source tools represent a major source of advantage for the enterprise - not just because they are free of license charges (since it is often wise to pay for support anyway), but because in general the open source marketplace offers a range of functionality that commercial vendors struggle to match, hampered as they are by the need to support a legacy product range and provide a consistent offering. All enterprises are well-advised to consider open source when maintaining any aspect of their IT and software development infrastructure, and the good news is that you do not have to pay consultants through the nose to do so - just follow the 3 steps above, and use your own common sense to make practical decisions about the software you adopt.

Posted by keithhb in Open Source |Digg This|Add to del.icio.us