Tomorrow People

Open Source consultancy LinuxIT looks at blending IT solutions

Blog post   •   Jul 24, 2012 11:22 BST

Office politics: can proprietary and Open Source software work together in harmony?

Sometimes it appears that there is a war going on between the evangelists of proprietary and Open Source software platforms, but this needn’t be the case; they can both complement each other. Let’s nevertheless look at when Open Source IT solutions work best.

“Open Source software (OSS) tends to work best alongside Open Standards, which includes the web and its corresponding protocols and Application Programmable Interfaces (APIs), which are well documented and well understood”, said Mark Reynolds, Director of Technology at IT Professional Services consultancy LinuxIT. He points out that cost considerations have encouraged the development of a number of OSS projects.

“This is as opposed to trying to create software that will go against, instead of alongside, proprietary closed software, which may be intentionally obscure to protect the interests of the software vendor”, he explained. He commented on the challenges of going down the Open Source software route:

  1. There are pragmatic reasons for continuing to run proprietary, closed source software - including the fact that many organisations have invested in it, making them reluctant to move.
  2. IT departments have a number of years’ experience and understanding of proprietary software solutions, as do their user-bases. Organisations have also invested finance in training their staff who will need, in some instances, re-training.
  3. Concerns exist around interoperability between different systems. The problem is that many organisations have settled for a standardised platform involving a particular type of software. It’s therefore a perceived risk to adopt a new system.
  4. Organisations also feel comforted by vendor support. But you can buy support contracts for Open Source as well as proprietary software solutions.
  5. All of this can create unnecessary fear, uncertainty and doubt in organisations that wish to seek Open Source software alternatives. These issues are often exacerbated by APIs.
  6. Most of the concerns revolve around legacy systems’ issues, and it’s in the interest of proprietary vendors to discourage the adoption of Open Source solutions – even though some proprietary vendors have also gone, to a degree, down the Open Source route.  

To benefit from the best of both worlds, it’s possible to combine the two approaches. Much depends on the interfaces that are provided by the Open Source software. “For example, a proprietary database product may provide an interface that can be accessed from Open Source programming languages which could be used to extend its functionality”, said Reynolds. He explained that a common application for this is based on creating web or standards-based front ends to legacy and back-end systems.

So what does he recommend when considering the usage of APIs to allow proprietary and OSS to work together for a particular business or consumer application?

  1. Avoid APIs that are only obtainable with a licensing agreement because they can soon become unaffordable.
  2. Remember that web-based APIs can change at the whim of their owners, so be prepared to manage these amendments.
  3. Use standard libraries where possible to access popular APIs. This is because compatibility then becomes the problem of the individual or organisation that maintains them. The downsides are that this might create accountability and support issues, of which you need to be mindful.
  4. Never re-invent the wheel. Make sure you research any existing projects out there before spending time and money on developing new ones.
  5. Don’t be tempted to use undocumented or deprecated elements of an API. They might work in the current version, but problems could occur in the future.

Reynolds concludes: “IT professional services companies like LinuxIT can help you to create solutions with the most appropriate balance of proprietary and Open Source software to meet the needs of your business. Adopting strategies that are based solely on licensing models will not always lead to the most effective solutions.”

For further ideas, please take a look at our eGuide ‘The five biggest blunders you can make pushing for Open Source adoption at board level’.

Guest Post: Simon Mitchell is the executive director of LinuxIT, a UK-based Open Source specialist. He creates and delivers sales strategy heading up the field and internal sales, renewals and sales administration teams. You can read more of Simon's articles about open source software by subscribing to the LinuxIT blog here. You can also find him on Google+ and Twitter.