Even if you have source, you can't necessarily figure it out. Sure, you can figure out what the program does, but you can't know precisely what the program was intended to do, or how closely the current version matches that eventual goal.
Sure, you might have the specification that the original developer was given, but every developer brings their own opinions and hard-won experience to a project. Just because the specification says "outgoing messages are sent to a queue" and the program links with ZeroMQ, doesn't tell you whether that's a design goal or a temporary stop-gap proof-of-concept. Maybe the program is structured so it can use an email queue for distributed operation. Maybe the program is designed to be linked into a larger system and just push message structs onto an in-memory vector.
It's exceedingly rare that you would not be able to figure it out given the source code. The real question is whether you have the time.
I think if a project was that important, the people who needed something patched would be able to get it together even if the original maintainer went missing.
The original analogy to the challenges of knowledge transfer isn't totally applicable. Knowledge transfer is important to organizations because figuring everything out all over again would be costly, not because it would be impossible.
As long as you are relying on the software, what you do care about is what it does today, which you get from the source.
You certainly care about what it will do tomorrow too (so you can keep up, or avoid having it break stuff for you), but if it goes unmaintained, you don't have to worry about that since it does the job for you.
OTOH, I've been on projects where a dependency was chosen on the promise of what they will do in the future. That future never materialized, so we were left with a bunch of unfinished dependency code, maintained a bunch of components ourselves etc — it was a mess, in short. So I never rely on promises, only on what's there today.
What a program does at the moment is exactly what it should do, unless there's a bug report filed, or the current developers want it to do something else.
Whatever it was originally meant to do is probably either obsolete, or well known to all users, if it's been so long the original devs left.
If it's got ZeroMQ, and has for 5 years, one can probably assume someone will be upset if it suddenly does not have ZeroMQ.
Regardless of intent, for practical purposes, if people are using it, they probably want that to stay around until you do an orderly transition to some other thing.
Very much so. I've spent a lot of time trying to decipher code and the biggest questions are usually "why is it doing this" and "what's this large piece of code indended to do".
Reverse-engineering all that can be an utter nightmare even with tests. I suggest that people who disagree consider, for example, the word "reverse-engineer" as in how they might reverse-engineer a car.
Usually you have this kind of problem when it's NOT producing desired results and the problem is how to make it do something that's needed without affecting some set of usecases that you don't understand yet.
I think a better way to go about it is to state your own goals. If you want it to bridge it to ZeroMQ, you can evaluate the program and see if the way it is coded fits you. If you want another service, you evaluate how much work to retrofit it. As longs as you expect decades out of your software, you should prepare to own all your dependencies. The intention of the original developer does not matter that much.
None of us are coders as far as I know, I don't think that's a real job title. They call us programmers or developers or engineers.
We solve problems with code, or by finding ways to avoid writing code.
We translate vague requirements into things a computer can handle, or we translate between computer languages, because any spec that was complete would just be the program. That's why they keep us. The computers can do pure logic on their own.
Opinion is very much a part of it because pure logic is just a useless pile of text unless it has something to do with the real world, which is full of opinions.
Even inside the program itself, we aren't dealing with logic. Languages are designed for human minds, and compilers are meant to catch mistakes people make. Libraries are often chosen for all kinds of perfectly good nontechnical reasons, like "That one is actually maintained" or "Everyone already knows this" or "People seem to like this" or "That seems like it won't be a thing in 3 years".
Sure, you might have the specification that the original developer was given, but every developer brings their own opinions and hard-won experience to a project. Just because the specification says "outgoing messages are sent to a queue" and the program links with ZeroMQ, doesn't tell you whether that's a design goal or a temporary stop-gap proof-of-concept. Maybe the program is structured so it can use an email queue for distributed operation. Maybe the program is designed to be linked into a larger system and just push message structs onto an in-memory vector.