Harvard Business Review has an article comparing old, crusty open source code to the Y2K ordeal. Go ahead and read it – it’s worth your time.

Joshua Gans, the author, lists open source projects that are maintained by lonely developers who don’t make much money (if any) for producing their craft. He specifically calls out ntpd:

What if I told you that the entire NTP relies on the sole effort of a 61-year-old who has pretty much volunteered his own time for the last 30 years? His name is Harlan Stenn… For a number of years Stenn has worked on a shoestring budget. He is putting in 100 hours a week to put patches on code, including requests from big corporations like Apple… And this has led to delays in fixing security issues and complaints.

Then Gans includes this bit, which is also a personal favorite of mine whenever I talk about open source product management:

…Last year we saw the consequences from this when a 28-year-old developer briefly “broke“ the internet because he deleted open-source code that he had made available. The drama occurred because the developer’s program shared a name with Kik, the popular Canadian messaging app, and there was a trademark dispute. The rest of the story is complicated but has an important takeaway: Our digital infrastructure is very fragile.

Gans then adds links and descriptions of two efforts in the code sustainability area, which are worth mentioning here: Open Collective and libraries.io. Strangely, he didn’t mention the Core Infrastructure Initiative, sponsored by the Linux Foundation, which works to address similar issues in the space.

I agree with much of what Gans writes. There is indeed a problem with unmaintained crusty code, which manifests itself in the form of security vulnerabilities and things that break more easily than they should. In fact, it’s become such a well-known issue that GitHub and others recently sponsored a conference in SF to talk about it. But in all this discussion, and in going through the non-profit organizations dedicated to working on sustainable open source code, I have to ask: where are the vendors?

As became all too apparent after reading Swapnil Bhartiya’s excellent primer on the state of IoT security (haha), this is a failure of product lifecycle management. The fact that much of the code in question is open source doesn’t really matter from a production point of view – code is code, after all. But because it is open source, this becomes a much wider scale problem, due to the ease with which it spreads from one poorly maintained repository to another. Philip DesAutels, the Linux Foundation’s IoT lead, said it best in Bhartiya’s article when he called out vendors for failing at product development basics.

On one hand, I’m glad some vendors are participating in initiatives like the CII from the Linux Foundation, but I wish there was more pressure on said vendors to collaborate on these things before it becomes a problem. This is, of course, the essence of why I created OSEN in the first place. Not enough people talk about this stuff, and I want to do my part to fix that. But I don’t think it does us much good to talk around the problem; let’s put the pressure where it should be – on the vendors. They should be working with upstream maintainers, collaborating and devoting resources where necessary, and perhaps even taking on more responsibilities with the project leadership. I know this can lead to governance issues, but the alternative is more dire.

Whether putting more effort into projects like the CII or voting with our wallets for better product development and testing, it’s time to start raising this as more of an issue. Sustainability of open source development is certainly important for future economic development, and vendors, who greatly benefit from the existence of open source code, have a responsibility to do their part.