The little legacy code that could: a fable of software ownership

I think its very interesting to think about this article in the context on the open source projects that relied upon by the vast majority of major applications and companies. Specifically OpenSSL comes to mind here. That library has been used/leveraged in so many ways to build empires. Yet it's currently struggling to find dedicated engineers that will work on its core logic. It's an unfortunate situation and while yes there is LibreSSL and BoringSSL its non-trivial to move to their implementations (I have tried, its wrought with peril). OpenSSL isn't on its own either, there are many open source libraries/applications that are struggling to find "owners". None of which can be "easily" replaced by any means.

I think the comments about "heroic" culture being fostered by the lack of ownership is spot on, but it isn't a bad thing unless those heroic actors aren't actively trying to get attention put on said pieces of legendary software. Imo its better to have heroic actors than nothing, and especially in the context of an opensource application/library that is used worldwide, I hope we can find more to generate more interest in working on them.

I read this article and I have to disagree with one of the major premises that "no one wants to own legacy code" -- it's more that in a lot of organizations, you're not ALLOWED to own legacy code.

What I mean is that you may want to take "ownership" in the sense of learning it and improving it but because it's not new development, large barriers to paying down technical debt and updating to newer development methodologies is disallowed.

So it stays, untouched, bit-rotted, and inflexible.

> Legacy means it might be working, depending on your CURRENT needs. Your current needs change, even when the code does not.

No working should mean "It fulfills the requirements". If the requirements change then the code should change.

The other things you have mentioned are important but they aren't necessarily requirements e.g. Uptime / Reliability / Performance might be requirements but without stating what they should be you can't say that a piece of code doesn't work if it "slow".

This sort of stuff is real basic software engineering.

> Unfortunately there's just not a lot of value to being able to put on your resume that you're an expert at an older language that nobody has heard of...

Depends on where you live I suppose. My city has more COBOL jobs than Rust/Elixir/Go/Haskel/Erlang/Ruby jobs combined. It’s still mostly C#/JAVA/PHP, but those hyped languages we read about all day on HN never actually become a thing around here. Node.js is the only exception I can think of. Python has certainly picked up, but most python jobs here require a degree in math or statistics.

I guess it’s probably very different in Silicon Valley and other tech hubs, but it’s my impression that most of the world still runs on something old.

Author here.

Code doesn't become legacy if it didn't fulfill some purpose. If it didn't work, it wouldn't be legacy, it'd be source code in somebody's home directory that was never deployed.

All working software is not legacy software. All legacy software (still running) works, for some definitions of works.

That's not to say your points aren't also really correct. Software is built with current requirements and knowledge in mind. Best decisions with info we have..etc.