OSPOlogy Live Event recap

In November, Stephen Kilbane, Director of ADI’s Open Source Program Office, presented a case-study in open source license compliance at the OSPOlogy.LIVE event, organised by the TODO Group, and hosted by RTE at their research and training centre in Lyon, France. The OSPOlogy.LIVE events are dedicated to sharing knowledge and developing best practices around Open Source Program Offices, to help organisations of all types and sizes improve their supply chain infrastructure with respect to open source software.  

Stephen’s presentation showed how ADI has been building its license compliance processes into CI/CD build pipelines across its development teams, so that license-compliance tooling scans software and generates associated compliance collateral as part of the normal build processes. This effort has enabled ADI to achieve organisation-wide conformance to ISO/IEC5230:2020, also known as OpenChain, the international and industry standard for open source license compliance processes in the software supply chain. 

Stephen highlighted five key takeaways. 

1. Need Executive Mandate, not just Executive Sponsorship. 

When the mandate comes from executive leadership, but development teams report to other C-Suite personnel, development teams receive conflicting information about prioritisation. By getting the mandate for compliance and conformance from the common leadership (or from all executive leadership figures), you can ensure that staff implementing process improvements have not just responsibility for improvement, but also authority to do so. 

2. Compliance Audits Help. 

It is important to audit conformance to process and standards, especially those involving certifications. Audits can be handled internally or through external auditors, and it helps to ensure that progress in clearing any non-conformance incidences are reported to the executive leadership, as that motivates internal staff to address any gaps in a timely manner. 

3. Framing the Message. 

Change is hard and comes with a cost. It is important to find ways to show how the costs are outweighed by the benefits, and to present the shift in those positive terms. For example, “there are new rules you need to follow” will be received negatively, while “we have a new tool that can automate some of what you do now – here’s some guidance ahead of its introduction, so that you can learn how you can take advantage of it sooner and hit the ground running” will be perceived more positively. 

4. Navigating Cultures. 

Companies like ADI have grown over time, bringing in talent and technology through acquisitions and new hires. This leads to a variety of internal communities of practice all working in different ways, for entirely valid reasons: how things are named, branching strategy, build or test tools,  preferred development languages or user-interface styles, and so on. It’s important to work with each culture to understand which of those differences still stand because they provide key features not available elsewhere, versus those that are “just the way we’ve always done it”. Equally, it’s important to provide assistance to teams in migrating to common processes so that teams are not left behind, and so that many teams are not attempting to solve the same migration issues individually and coming up with conflicting solutions. Providing teams with points of contact to help them discover the path forward is important. 

5. Multi-Channel Communications  

You need to get the word out, but not just once. A communications strategy should be developed that ensures that process improvements are communicated to affected teams multiple times, via multiple channels, and using multiple different wordings. Some teams pay more attention to one communication channel than another; some staff members will be out of office for some reason; some staff members will be more receptive to emails, others to training videos, and so on. Tell the affected staff, and keep on telling them, so that it successfully resonates.