Almost 20 years have passed since the corporate world woke up to long-term problems in computer code, which became known as Y2K. Over the previous decades, software developers had used the date 01-01-00 (January 1, 2000) as a convenient hack to make it easier to debug software. The problem was that it wasn’t taken out. So as 2000 loomed, there was a realization that, when the clocks hit midnight, software all over the world could simply stop running. Thankfully, at a cost of a few billion dollars, the software was audited and patched, and businesses went back to worrying about other things.
Could Open-Source Code Make Our Y2K Fears Finally Come True?
Open source code resides everywhere. If you’ve hired a software developer, their work mostly likely contained code from the open source community. The same goes for software programs. In many ways, this is great: It has, arguably, saved billions in development expenses by reducing duplicative effort and allowing complementary innovation without requirement permission or payment.
All this makes Y2K look like a picnic, especially since the magnitude of these issues is unknown. Individual companies have no idea how vulnerable they might be. And it may be slow moving — slowly corrupting systems without causing crashes that are visible. Finally, since open-source platforms have been built by a community that has relished its independence, it won’t be easy to fix using traditional commercial or governmental approaches.
But it’s extremely vulnerable and fragile. For example, there are people maintaining code, who, if hit by a bus, would cause the internet to break (computer security folks literally call this the ‘bus factor’). They are well meaning, but tired and underfunded. And hard to maintain code is precisely where security vulnerabilities reside (just ask Ukraine).
When Y2K emerged, publicly listed companies were told to list their vulnerabilities and plans. The time has come again for markets (and perhaps regulators) to demand similar audits as a first step to working out the magnitude of the problem.