There are great parallels between were I started my career in the hardware world and the way software development has evolved. After last week’s Linux Collaboration Summit where I talked to a lot of people about “software supply chains,” I can’t get them off my mind.
The earliest days of digital electronics involved designing at the transistor level, in fact physically designing the transistor (basically an on/off switch). Then hardware design moved up through various levels of abstraction first to logical gates and then higher level combinations of gates. When I started in business (don’t ask), microprocessors were coming of age and represented a lot of logic in one Integrated Circuit. ICs were also referred to as components, and the job of most electrical engineers was to wire together components in clever ways to do the job.
Well the first software was microcode or machine language, down at the 1s and 0s level and the text equivalent of a transistor (loosely speaking). Then languages evolved that took programming to higher levels of abstraction. And, now we’ve entered a time where programming is component based. No one starts programming with a blank screen any more. Today, like board designers, a software developer’s job is to “wire together” components in clever ways, adding their own secret sauce here and there to create applications customized to specific needs.
And, just as in the hardware world is a supply chain that goes from gates to chips to boards to subassemblies, etc., so it goes today with software. Only the non-physical world makes it all more complex, and open source just multiplies the complexity of the problem as it promotes the sharing of code in uncontrolled ways.
The consequence is that software and systems development organizations are going crazy trying to trace the roots of the software they are building. Companies building software are trying use techniques similar to those in physical supply chain management. There are many great reasons why companies want to know what’s in their code and where it came from, but license compliance is in the fore for these organizations. One of the big challenges is that there is not a common vocabulary and way of describing code contents and the associated licenses.
I lead the Linux Foundation working group that is in the midst of defining a communication standard called SPDX® (or Software Package Data Exchange®) and, as such moderated a keynote panel at the Linux Collaboration Summit called Getting the Kinks out of the Software Supply Chain. Participating on the panel were managers from HP, Texas Instruments, Wind River and Cisco. Universally they described the “huge” (most of their choice of words, not mine) challenge for these companies to govern the wild world of software supply chains.
After that session and at the SPDX Forum we ran in San Jose a couple of days later, I talked to numerous software development managers and IP attorneys the challenges that they are facing. The idea of a standard software “Bill of Materials” (another concept from physical manufacturing) almost brought tears to the eyes of one IP attorney I spoke with from one of the biggest software companies in the world. I am more convinced than ever of the enormity of the problem and of the need for the work we are doing with SPDX. If any of this is striking a nerve, please check out spdx.org. We’d love to have your input.