How to Become an OSS Champion

July 26, 2019
By Katie McCaskey

Open source software components yield a competitive marketplace advantage. So, why do some development teams resist and rebel?

Fernando Cremer, a Customer Success Engineer at Sonatype, works with organizations to optimize their use of open source software. He shows leaders how to champion open source use in production.

He recently shared his perspective at the Nexus User Conference.

To start, Fernando outlines the importance of open source governance. He defines governance as dominion over the libraries, frameworks, and dependencies in components. How an organization tracks component use and policy compliance impacts everything from costs to software security.

A common obstacle is a lack of planning beyond implementation. Fernando points to DJ Schleen's chapter in Epic Failures in DevSecOps as illustrating a somewhat typical problem: lots of planning to implement open source components, followed by far lesser investment in maintaining systems to support this awesome resource. When developers are disrupted, or their builds are broken without explanation, the pitchforks come out.

How to avoid this? Consider your production process. Fernando outlines the software production stages:

Discovery - How does our team build/deploy/write software?
Inventory - How many applications/dependencies are there? What is the scope? ("Nobody ever knows," says Fernando. This common pitfall is fixed once a full inventory is performed and automated systems are put in place.)
Policy - What is the organization's policy for OSS components? Notably: who is the person signing off and accepting the risk?
Mitigation - What are the organization’s plans to address policy violations?
Enforcement - How will the organization tackle ongoing review?

Looking at this process, leadership must excel in three distinct areas to unleash the most productive software development.

#1 Communication Prowess: Communicate Regularly

Communication is key. Disruption and disillusionment come from a lack of clarity. Identify what your organization is trying to achieve and what is at stake. Invite stakeholders to the table to develop the process.

Support adoption by setting up a wiki that everyone can access. Include:

The benefits of adopting these requirements.
The importance of the tools, and how they'll assist the process.
Instructions to participate (e.g., server URL, how to log in, how to integrate, who to contact).
The policy reference document, so anyone can find it.

Set expectations early and communicate regularly. For example, who can fail a build? When should the team be notified? Earlier notifications give developers more time to research, fix, or request waivers. Communicate the resolution process, too. All this should be documented in the wiki.

Ideally, says Fernando, "waivers should be the exception, not the expectation."

#2 Clearly Define Steps: Present Actionable Findings

As Helen Beale of Ranger4 reminds us, our brain biology influences how we prioritize information. Too much information, from a component scan with too many false positives, promotes tool apathy, not action.

Define your organization's threat threshold. For example, "don't use any components Nexus Firewall flags with red or orange violations." Communicate default actions to take, too. For example, "fix everything but blue items." This limits action to mandatory issues. This, in turn, works down technical debt.

#3 Build an Organizational Philosophy (DevOps Culture)

"Last, but definitely not least," says Fernando, "is culture." Be honest about how your organization operates. Is it "scan and scold," waiting until the end to fix problems? Or is it more a more proactive "support and guide" approach?

Work to create a "support and guide" culture. Core tenants include:

Providing objective information to all parties across the project life cycle.
Assigning people to perform the task(s) based on interest, aptitude, and skill.
Supporting faster selection of components and issue resolution through the toolchain (this helps with compliance, and fosters a "warn early/enforce early" environment).

The goal should be to develop a single, flexible framework. As our CEO Wayne Jackson said at the Nexus User Conference keynote: there's no need, and is likely counterproductive, to have more than one operational framework.

Finally, a bonus recommendation: Automate Where Appropriate. Don't become the bottleneck in your organization. Prevent long wait times. Otherwise, developers will work around the process to deliver software.

When everyone on the team knows the expectations and processes, managing open source software components is not disruptive. In fact, it will make your development process more resilient and robust.

Written by Katie McCaskey

Katie is an experienced technology writer and entrepreneur. At Sonatype, she's focused on creating and finding great content.