I am a change agent, engineer and technologist. My career has spanned more than 20 years of which over 15 were spent working in financial institutes obsessing over topics such as open source strategy, risk engineering, enterprise collaboration and developer tooling. I have written hundreds of thousands of lines of code in my career and designed successful, large scale, highly available, distributed systems.
My biggest passion is looking at how we can help enable collaboration and sharing in all areas of technology covering everything from small companies to large enterprises. I believe there is an immense opportunity for increasing productivity, reducing wasted time (in an already short life), and getting more out of technology.
With that, I will share the first -- of what I hope to be many -- ideas and insights as we journey down this path together.
A Path to Consider
Open source has been around for donkey’s years but until recently the persuasive argument of “many eyeballs” was the guiding policy when using open source. In comes the recent industry shock wave we all know as Heartbleed and now many of us are re-evaluating the cost of free software.
But we’re not here to debate dogma over open source vs. closed source. We all realize that open source has long been here to stay in our application development practices. So, if policies for managing and maintaining open source components over time in your organization were not in place prior to Heartbleed (true for 43% of you), in fine tradition we dip quill in ink and start to sketch a new policy…
One would hope that a minimum, basic, open source policy contains some fancy wording which roughly covers the following points:
1. Thou shalt not bring in software from unknown or suspect sources
2. Thou shalt not use software with serious security vulnerabilities
3. Thou shalt not use open source software with a license which may cause nasty legal issues in the future
Seems pretty straightforward. Know where you’re getting stuff from? Make sure it’s not full of bad stuff. Make sure the license is all above board.
The Pace of Policy
Having said all that however, most policies share some unfortunate characteristics of being manual and not integrated into the development lifecycle. Which is why (and who can blame them) developers typically find a way around policies. Our recent survey revealed 41% of people think that policies cannot be enforced and workarounds are common.
So how do we solve this challenge? Let’s start by looking at where the software is sourced. When a developers tell me, the internet...I immediately know there’s more research to be done. Researching the known security vulnerabilities or license types can be a very manual time consuming process that many times leads to a workaround. I mean really, who wants to spend their time manually searching for risks (known or unknown) in their software? The developers? No. The application security team? Uh...no, too slow. The legal team? Eek...too disconnected from where the work is happening and the pace at which it is happening.
My 5-Step Approach
But all isn’t lost. There are some solutions that are automated and integrated into the development lifecycle that can in fact help those 41% of people become more confident in the software they’re using. Here’s a 5 step approach to forming a scalable developer friendly open source policy:
1. Make sure you have performed adequate research into how people will meet the policy
2. Discover what tools and solutions are required to make the right way the easy way
3. Define your enforcement points and make them clear to everyone
4. Define how you’ll measure implementation of and adherence to the policy
5. Provide clear training and documentation for how people can meet the objectives of the policy
By starting here, life can become a little easier for everyone. The business benefits from the reduced cost of using open source and developers benefit from an easier, faster (and now more secure) way for building software.