|Professional Open Source Software Management|
|Written by Nikos Vaggalis|
|Thursday, 16 December 2021|
The OSS Good Governance Handbook is intended as guide for enterprises that fosters proper use of open source software as well as safeguarding businesses from technical, legal and IP threats.
The handbook is the brain child of the newly formed Open Source Program Office (OSPO) alliance, a coalition of leading European open source non-profit organizations including OW2, Eclipse Foundation, OpenForum Europe, and Foundation for Public Code, with the mission to grow awareness for open source software and promote its structured and professional management by companies and administrations.
There are two perspectives on managing an open source software project; one is that of manager/maintainer/contributor and the other that of the enterprise relying on it. I've covered the first aspect in "The Open Source Guides To Managing Open Source Software Projects" which looks at another handbook, a set of guides by Github detailing the ins and outs of launching, managing, maintaining and contributing to open source projects.
The other side of the coin is taking the software out of the hands of the makers and using it in an enterprise environment, which frequently requires integrating it with other software, especially libraries. Of course, an enterprise can play the role of the contributor too by giving back to the project and the wider community.
We all know how ubiquitous oss software is in every environment, be it at home, work or in enterprise settings. It's so pervasive that has infiltrated the collective mindset so much that the European Commission has just announced that it adopts new rules that will enable its software solutions to be open sourced and publicly accessible whenever there are potential benefits for citizens, companies or other public services. And with good reason as a study has shown that:
the investment in open source leads on average to four times higher returns to the EU economy.
The EU Commission's love with open source goes further back than the recent initiative, when it had kickstarted a state-sponsored bug bounty that showed that amongst the bureaucrats there are tech savvy people who understand the true value of OSS software to society, and as such the impact when its security goes wrong.
This bug bounty is part of the Free and Open Source Software Audit (FOSSA) project, thanks to Julia Reda MEP of the EU Pirate Party, who started the project thinking that enough is enough after severe vulnerabilities were discovered in key infrastructure components like OpenSSL. This prompted her to involve the EU Commission in contributing to the security of the Internet. More on that in "EU Bug Bounty - Software Security as a Civil Right".
So after establishing how beneficial is OSS to society, let's look into it from an enterprise setting. An enterprise has to implement professional management and juggle a lot of baggage when adopting open source software, especially when compiling code that features a mix of dependencies. The OSS Good Governance Handbook has categorized those activities into:
with the following requirements in mind:
Any type of organisation is covered: from SMEs to large companies and not-for-profit organisations, from local authorities (e. g. town councils) to large institutions (e. g. European or governmental institutions). The framework provides building blocks for a strategy and hints for its realisation, but how the activities are executed depends entirely on the program’s context and is up to the program manager.
No assumption is made about the level of technical knowledge within the organisation or the domain of activity. For example, some organisations will need to set up a complete training curriculum, while others might simply propose ad-hoc material to the teams.
Each activity stub is split into the following sections:
As an hands-on example of what each stub includes, let's provide a trimmed down sample of the Manage software vulnerabilities activity.
The ROI of vulnerabilities is little known until something bad happens. One has to consider the consequences of a major data breach or unavailability of services to estimate the true cost of vulnerabilities.
The following verification points demonstrate progress in this Activity:
Of course another thorny issue is managing the Software Dependencies. Supply chain security is all the rage right now. We've taken a look at the implications as well as the ways of mitigation in "Does Sigstore Really Secure The Supply Chain?" the Linux Foundation's answer to supply chain attacks:
To build useful software we don't reinvent the wheel but we base on work already done coming bundled in the form of libraries. The problem is that even a mediocre open source project can have loads of such dependencies which themselves depend on others, forming a lengthy chain. Not a problem per se unless malicious code or security vulnerability finds its way anywhere in this chain.
The handbook' has a good list of tools, resources and guidance. At a glance it recommends:
The first release of the GGI Handbook was published in October 2021. Other iterations are planned to improve the content and better articulate the implementation methodology.
or email your comment to: email@example.com
|Last Updated ( Thursday, 16 December 2021 )|