On a hot summer day in 2015, my manager came to me to discuss IBM’s vision for Open Technologies. She outlined the reality of the high cost of maintaining open source legal and security compliance. Then she asked me, “How would you like to solve this problem?” I have been traveling on this journey ever since, trying to find the solutions.
To developers, using open source components is not an option, it’s a must. Open source means not just the code, libraries, and solutions, but also tooling, frameworks, and practices. Rarely can you ship a software product without including open source components. Developers are hurt by the paradox of legal and security compliance vs. the “open technologies first” movement.
Compliance for Open Source Software, Challenges
The challenge of open source compliance is not to answer a one-time yes-or-no question. The challenge of compliance is to answer the question continuously. Modern software deliveries are continuous. Compliance requirements are on-going. Thus the answers on compliance have to be continuous as software changes are made. And the goal of such continuous compliance is clear: set developers free from unnecessary restrictions and legal concerns so they can stay creative, productive, and effective.
The goal is clear, but the problem is multifold. Some of the hurdles include:
- Streamlining compliance into the development pipeline. Is it possible to “code the compliance” – to automate continuous checking for compliance when the changes are made?
- Development and operations usually use very different process and tools. Given the compliance results, how do you provide compliance services that can integrate into discrete processes? Can this be solved in a low cost way so Operations do not get additional overhead?
- Compliance tooling is needed. How do you reliably identify the usage of open source licenses and dependencies for which industry specifications are lacking?
Compliance for Open Source Software, Solutions
Collaborating with the IBM Open Source Steering Committee led by Steve Gerdt, my engineering team and I have engaged in this challenging but rewarding journey. Using our system, users have reported 90% cost savings from previous manual practices for legal compliance checking. There are still more exciting changes and innovations opportunities ahead of us.
At OSCON 2017 Austin and blogs to follow, I will share with you what we’ve learned from this journey. I will share the technology, architecture, methodology, and practices that are most rewarding to us, as well as a fresh perspective on compliance requirements. Specifically, I will take a deeper dive into how building a cloud-centric system and adopting DevOps best practices are paying off. I’ll reveal how leveraging microservices architecture and serverless technology allowed options for Low Ops or even No Ops
Until next time.
Date: Tuesday, May 11, 2017Time:
Location: Meeting Room 19
Bianca Jiang and Steve Gerdt explore the paradox of open source compliance and continuous delivery with open source, sharing their experiences, lessons learned, and the best of DevOps principles. Along the way, Bianca and Steve outline a microservices-based architecture and offer a refresh perspective of the compliance requirements.