The use of open source technologies is increasingly common in large enterprises, not just in small or “pure dot com” businesses. But many organisations are hesitant to make the jump to open source, and struggle to develop an IT strategy that encompasses it.

Priocept has worked with large enterprises on both open source and “traditional” commercially licensed platforms such as Microsoft. Here we provide some guidance and insights into how you can take advantage of open source technologies to eliminate software licensing costs, reduce support costs, avoid “vendor lock in”, and to give you the freedom to fully customise software solutions to meet your needs, rather than waiting on “it’s coming in the next release” promises from commercial software vendors.

Why Use Open Source?

The main benefits of using open source technologies are as follows:

1. Cost – there no software licensing fees
2. Vendor independence – you are not “locked in” to a software vendor
3. Control and Flexibility – access to the source code means that you have complete control over the technology stack and the flexibility to modify, bug-fix, or improve it, independently of the release schedule.
4. Hardware and operating system independence – often, but not always, open source technologies are not tied to specific hardware or OS architectures, giving you more options when you come to deploy them in your data centre.

On the other hand, there can be disadvantages of going open source:

1. Lack of Support – open source products generally do not come with formal software support and maintenance agreements as there is no commercial entity that you can contract with for support. This is the number one barrier to adoption for business critical systems.  However, some vendors operate a dual licensing model (see below) which can provide a route to supported software.
2. Access to Skills – in some cases, it can be harder to find skilled resources that can work with open source technologies, although this is increasingly less true.

Supporting Open Source Solutions

The most common barrier to adopting open source solutions is the perceived risk of running business critical systems on unsupported software. While this risk does exist to a certain degree, it is generally overstated, especially by competing commercial software vendors!

You should assess this risk for yourself and be objective and critical about what an alternative commercial software product really gives you, over and above an intangible “comfort factor”:

1. Is it actually true that the open source software will be unsupported? There are companies that specialise in providing commercial support for certain open-source products (e.g. Apache Tomcat), in the same way that commercial vendors do for their own products. Although you will have to pay for this support in a similar way that you would have to pay, say, Microsoft, you haven’t paid for the licenses up front, so the saving is considerable.
2. Can your internal IT team, or services provider, provide this support? Priocept provides support to a number of clients for systems which were built on open source technologies. In addition to diagnosing issues, we will, if necessary, debug and patch the software. Invariably this happens quicker than a commercial software vendor providing a patch or “hotfix” for their products.
3. How active is the development community for the technology in question? Check the technology’s main website, check its previous and future release schedule to make sure the technology is still actively being developed and is not “mothballed”, and check forums to see if problems experienced by the user base are looked at and resolved promptly by the community. Often, the developer communities behind open source software are more active and more responsive than the resources that a company puts behind a competing commercial product.
4. How stable is your system’s functionality? If you need to build a system to a given spec and are unlikely to develop and evolve it continually there after, then it should quickly become mature and stable. If it is working reliably and you don’t change it, it is unlikely to stop working one day for no reason. Software doesn’t wear out like physical equipment. So if you have a stable solution that works and doesn’t need changing, why pay for commercial support that you are unlikely to need anyway? On the other hand, systems that are continually evolving, or being deployed to new platforms, are likely to be more of a support burden.
5. Does redundancy in your solution reduce the risk of using open source technologies? Depending on how your solution is architected, you may be protected against problems in the open source code even if you can’t fix them. For example, a memory leak which requires a regular application restart may not be a problem if you have a high degree of redundancy. But if you have single points of failure, more structured Service Level Agreements (SLAs) for software support become more critical.
6. How well adopted and proven is the commercial alternative? Often, the open-source technologies are actually more widely deployed and have a larger user base than the specialist “enterprise” equivalents.
7. Remember, commercial software may in theory be “supported” by the vendor, but you are still at their mercy if you need a problem diagnosed and debugged, and a patch urgently developed and tested and sent to you. With open source technologies, you are in control, and you can use any and all the expertise available both within your organisation and across the internet, to resolve your problem.

Open Source Scaling Costs Advantage

Commercial software products become particularly expensive compared to open source when you need to scale them out to large numbers of servers.

If you have one server running an internal application for 100 users, a £10,000-per-user license fee may be acceptable, especially if it works “out of the box” and is quicker and cheaper to deploy compared to an open-source alternative.

But if you have a large web farm of 16 servers, or want the option to scale to that level, 16 server licenses at £10,000 each (or an equivalent site license) become prohibitive. Even if the equivalent open source solution requires an extra 50 man days of customisation, deployment and testing compared to the commercial alternative, this could work out to be more cost effective overall, and you will have unlimited scalability going forward with only hardware costs to consider.

Dual Licensing Models

Some vendors will offer both a free, open-source version of their product, and a commercial version of their product.

For example, Apache Jackrabbit is a freely available open source Java Content Repository (JCR) implementation, but it is developed by [inlineexternalink href=”http://www.adobe.com/marketing-cloud/enterprise-content-management.html”]Day Software[/inlineexternalink], who also develop CRX, a commercial alternative based on Jackrabbit code.

This model is quite common as software vendors use the open source version for marketing purposes, using it to drive interest and adoption in the software developer community, which in turn can drive usage of the commercially supported version in production environments.

If both commercial and open-source options for the same software are available, use them to your advantage:

1. Determine if there is a straightforward migration path from open-source to commercial versions. If so, you have the option of starting out with free software on a trial basis, and spending money on software licenses only when you are sure that you need the commercial features.
2. Use the open source version in your development environments even if you use the commercial version in production. This will minimise your licensing costs.
3. Consider a hybrid solution. You may be able to use the commercial version for certain parts of the system where its features and commercial support are critical, such as a master data store or administrative interface, and combine this with a free, open-source version for read-only or “slave” systems that require simpler functionality but need to scale out to support large numbers of users.
4. Use the fact that the open source version exists to negotiate a better licensing deal! If the open source version has a specific feature missing that you need and which the commercial version supports, and if you know you could develop that feature yourself for just 20 man days of custom development, this should set the premium which you should be willing to pay for the commercial version. See if you can do a deal.

Finally: Open Source vs. Free vs. Standards Based

The term “open source” is often used to mean several subtly different things and its worth clear up the terminology:

1. Open Source – as the name suggests, this means a software product where the source code is made available (“open”) for its user base to not only use, but to modify for their own purposes.
2. Free – obviously, this means software that is available to use without paying a license fee. Although a lot of free software is also open source, and the reverse is also generally true, this not always the case.
3. Standards Based – some software is based on open standards but is neither open source nor free. For example, Apache Tomcat is a open source product built on open standards (the J2EE standard). IBM Websphere is a product built on the same open standards, but it is neither free nor open source.

Note that the Open Source Initiative has a definition of open source which clears up this confusion. But this definition is not necessarily universally adhered to or consistently used.

Sometimes you may just be looking for a cheaper software alternative, in which case free software is required, but open source may not be necessary. In other circumstances, you need software that you can modify to suit your own needs, in which case you definitely need open source. And in other scenarios you may need a product that conforms to open standards, so that you are not permanently tied in to that product, but you need it to be commercially supported and don’t actually need access to the source code.

Although these distinctions are fairly obvious, make sure you are evaluating software correctly and based on the criteria that are actually relevant to you.