Daily Archives: July 13, 2015

6 Things to consider implementing open-source software

Published by:

As open source becomes popular many organisations employ wide array of open-source applications, APIs and code in use today – be it infrastructure and application layers, or in development frameworks and simply the GitHub repositories.

As a applications developer and infrastructure teams you can come under increasing pressure due to organisations rush to develop new services for customers, comply with growing amounts of industry regulation, or simply strive to meet the needs of the information generation.

open-source

Here are six things these technical leaders should consider around open-source software.

1. New governance frameworks and policies are required for open-source platforms

Unlike traditional app/dev environments, open-source platforms move at a greater pace and with a very different model for iteration and improvement. Traditional governance and security for these environments would limit the benefits of agility you might hope to get from going down this path.

From security, to support, to indemnity, the challenges of managing open-source code in an enterprise context requires a different set of considerations.

2. The ‘packaged’ open-source model deserves consideration

Whilst a packaged version of an open-source platform from a vendor brings significant benefits – of documentation, versioning, integration points, feature road-maps, support and beyond – there is a trade-off in terms of lag between new community releases and new packaged releases that technical leaders are wary of.

Proper evaluation is needed – with true open-source projects there is total visibility (and community engagement in) resolving bugs and adding functionality. Once a vendor puts its wrap on a set of code, this transparency is lost to some degree.

3. The culture and mindset of the app/dev team must be hungry

The mindset for open-source development is one of entrepreneurial hunger. It’s one of identifying problems and building solutions. More conventional teams might live in denial of these possibilities and prefer to look at the limitations and capabilities of traditional environments, rather than see those limitations as problems that can be solved with code in an open-source context.

4. A greater context of collaboration is required within the app/dev, security and infrastructure teams

With technical delivery for what might be classified within the ‘open source’ umbrella split across a potentially diverse set of teams – like desktop, servers, applications, analytics and security – greater collaboration between the teams is needed to ensure the security and effectiveness of the approach.

If the cost of short-term agility is a long-term cost burden for maintenance, the books may not balance. By working together, however, a more complete set of benefits can be delivered.

5. There is more external consulting support for open source emerging every year

As open-source platforms from the likes of Linux, Cassandra and Hadoop grow in sophistication – and as potential applications grow in data-rich, application-hungry businesses – more traditional outsourcers and IT consultancies are developing specialist propositions around supporting businesses with their apps in these environments. This provides a degree of assurance and resilience to those who need it.

6. Open-source community contributions and the talent conundrum

To attract talent to the developer pool, organisations need to be contributing to the open-source community. But some organisations can’t allow their developers to do this, due to concerns about giving away intellectual property or exposing the possibility of breach that may emerge if they write up code that is potentially vulnerable.

This is the challenge for technology leaders – to find the best way to contribute to the community whilst maintaining integrity and compliance, such that they can win the best talent.

Courtesy from Wai Hung Wan, EMC edited by Jamal Panhwar