3 minute read

Open source software (OSS) is a foundational part of the modern software delivery lifecycle. Enterprise teams with DevOps aspirations face unique challenges in compliance, security, reliability, and sustainability of OSS components. Organizations-in-transformation must have a complete picture of risk when integrating open source components.

This article explores how to continuously factor in community and ecosystem health into OSS risk analysis strategy.

The Acquisition Process for Open Source Software

Developers need to build on the successes and contributions of others. Having the flexibility to integrate new open source components and new versions of existing dependencies enables teams to go fast, but external code must be checked and validated before becoming part of the trusted stack.

Including someone else's software is an important moment of engagement. Enterprises typically wrap a formal 'acquisition' process around this process, where the 'supplier' (the entity who provides the software/service) and the 'acquirer' (the entity who wants to integrate the software/service) contractualize.

Though there are already commercial approaches to introducing software packages safely by companies like Sonatype, Black Duck, and others, my question extends beyond the tools conversation to encompass the longer-term picture of identifying and managing risk in software delivery.

Enterprises care deeply about risk. Without addressing this concern, engineering teams will never actualize the benefits of DevOps.

This is a tangible application of the need for DevOps to not only apply at an individual team level, but in the broader organization as well. It takes alignment between a team who needs software and teams providing compliance and legal services to all do so in an expedient manner that matches the clock speed of software delivery.

Communities Empower Enterprises to Address this Gap

Today in a Global Open Source Governance Group Chat, I asked the question:

"What are some methods for determining how significant a supplier/vendor OSS and community contributions are, relative to acquirer confidence?"

This question stems from my involvement with the IEEE 2675 working group, particularly because I see:

  • Prolific use of OSS use in DevOps and in enterprise contexts
  • Reluctance and concern (rightly so) around integration of OSS in enterprise software development and operation in production
  • The convergence of compliance and automation considerations
  • How important transparency and collaboration is to the health of OSS, but also to the supply and acquisition processes in a DevOps lifecycle

The group, expertly facilitated by Lauri Apple, also included key insights from Paul Burt and Jamie Allen. A log of the conversation can be found on Twitter.

As open source projects (like Swagger/OADF for instance) become increasingly important to enterprise software delivery, health and ecosystem tracking also becomes equally important to any new components being introduced.

My point-of-view is that organizations should prepare a checklist for software teams to construct a complete picture of risk introduced by OSS (not to mention proprietary) components. This checklist must include not only static analysis metrics but support, engagement, funding, and contribution considerations.

Measuring OSS Project + Community Health

The group had many suggestions that I wouldn't have otherwise thought about, another reason for more people getting involved in dialogs like this.

There are already providers of aggregate information on open source community health and contribution metrics such as CHAOSS, a Linux Foundation project, and Bitergia. This data can be integrated easily into dependency management scripts in Groovy, npm, Ant, Maven, etc. and at the very least written in to a delivery pipeline as part of pre-build validation (BVT is too late).

And there is honest, hard-hitting research on open source software...which you should take the time to read....from Nadia Eghbal under the Ford Foundation in a report called 'Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure'. If you don't have time to read it, buy some text-to-speech software and listen to it when you're in transit.

The group also identified some key characteristics of OSS community health not necessarily tracked by established services, such as:

  • Same day response on reported issues, even if it's simply acknowledgement
  • PRs under the "magic number" of 400 lines of code...tends to be the limit for # of bugs and useful feedback
  • Outage response, sandbox availability
  • Distribution of component versions across multiple central repositories

More to Come...From YOU

As I integrate both my own learnings and other voices from the community into the larger Enterprise DevOps conversation, the one thing that will be missed is YOUR THOUGHTS, whether your in a large organization or simply in a small team.

Please share your thoughts in the comments section below! Or ping me up on Twitter@paulsbruce or LinkedIn.

More reading:

You may also enjoy