Many organisations have a wide array of open-source applications and code in use today – whether it be at the infrastructure and application layers, or in development frameworks and GitHub repositories.
However, the applications developer and infrastructure teams come under increasing pressure as 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.
Here are six things these technical leaders should consider around open-source software.
>See also: 4 reasons why people should stop associating open source with a lack of security
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.
>See also: Hybrid cloud, open source lead the cloud pack
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.
Sourced from Wai Hung Wan, EMC
