Should Companies Audit Their Software Stacks for Critical Open Source Dependencies?
Early 2022 has brought with it an unusually high level of commotion in the open-source community, largely focused on the economics of who — and how we — should pay for “free” software. But this isn’t just some geeky flame war. What’s at stake is critical for vast swaths of the business world….
We know of many open-source enthusiasts who maintain their software personally while leading busy professional lives — the last thing they want is the responsibility of a service-level agreement because someone paid them for their creation. So, is this the end of the road for the open-source dream? Certainly, many of the open-source naysayers will view the recent upheavals as proof of a failed approach. They couldn’t be more wrong. What we’re seeing today is a direct result of the success of open-source software. That success means there isn’t a one-size-fits-all description to define open-source software, nor one economic model for how it can succeed.
For internet giants like Facebook or Netflix, the popularity, or otherwise, of their respective JavaScript library and software tool — React and Chaos Monkey — is beside the point. For such companies, open-source releases are almost a matter of employer branding — a way to show off their engineering chops to potential employees. The likelihood of them altering licensing models to create new revenue streams is small enough that most enterprises need not lose sleep over it. Nonetheless, if these open-source tools form a critical part of your software stack or development process, you might want some form of contingency plan — you’re likely to have very little sway over future developments, so understanding your risks helps.
For companies that have built platforms containing open-source software, the risks are more uncertain. This is in line with Thoughtworks’ view that all businesses can benefit from a greater awareness of what software is running in their various systems. In such cases, we advise companies to consider the extent to which they’re reliant on that piece of software: are there viable alternatives? In extreme circumstances, could you fork the code and maintain it internally?
Once you start looking at crucial parts of your software stack where you’re reliant on hobbyists, your choices begin to dwindle. But if Log4J’s case has taught us anything, it’s this: auditing what goes into the software that runs your business puts you in a better place than being completely caught by surprise.
Read more of this story at Slashdot.