We’ve seen evidence of a transition over the last five to ten years in terms of the level of importance organizations are placing on managing their open source software. As companies continue to evolve and understand how and why managing open source gives them a better chance of realizing the key benefits open source brings to the business, there’s also a willingness and perhaps greater effort to adopt more robust governance programs.
This is true for most industries; however, chances are more newer emerging technology spaces like the IoT are most likely a little further behind. However, the “catch-up” plan is in motion as more and more devices are connected to each other. Open source will play an increasing role in making sure those devices properly intersect and to support back-end processes.
Healthcare is also a little slower to adopt due to security concerns, yet still making inroads as the methodologies could create quicker paths to cures, faster diagnostics, and more effective treatments.
For industries deeply ingrained in the integration of open source into their strategic development efforts and for those that get the importance of OSS management, there is also indication that more development teams are getting involved earlier in the purchasing process for OS management tools, such as Software Composition Analysis. Whereas at one time this was strictly a security effort, it makes sense that Engineering would have influence over which tools are the right tools. In the end they are the consumer or ultimate end-user responsible for not just using the selected solution but making sure that any software shipping with products is both license compliant and secure. It all starts with the person(s) using the tool. And let’s face it, developers and engineers have a job to do and rather than forcing a solution into their hands that may very possibly impact both their SDLC and workload, isn’t it better to bring them into the buying process and get their stamp on the best tool to work for them?
Certainly, I would argue the responsibility is broader than one team or person, reaching across multiple infrastructures such as legal, security, engineering and leadership. Perhaps the future is that more stakeholders will play an increasing role in the open source software management buying process. I suggest looking at your buying process and getting answers to these key questions:
- How mature is your business in the utilization of tools to manage your open source software use?
- Who leads the buying effort and who plays a decision-making role?
- Who influences the business drivers for selecting open source management solutions to meet needs?
- What are your most important considerations for selecting the right tools?
- Once a tool is implemented are you managing an ongoing governance process?