Big picture

Oh, that I'd agree with.

I spend most of my time available on IRC and I actively tell new people working on the code "ask me if you're blocked on something, it's my job to get you unblocked". There does have to be a way for new people to get involved and learn.

And maintainers need mentorship, too...

> The longstanding story that NASA lost or destroyed the Saturn 5 plans quickly falls to pieces when one learns about the F-1 Production Knowledge Retention Program. This was a project at Rocketdyne, the company that built the F-1 engine, to preserve as much technical documentation and knowledge about the engine as was possible. According to an inventory of records, this produced twenty volumes of material on topics such as the engine’s injector ring set, valves, engine assembly, and checkout and thermal insulation and electrical cables, among others.
>
> But the project went beyond simply preserving documentation. Rocketdyne actually sought to preserve the knowledge inside the heads of the people who designed and manufactured the engines. They conducted tape-recorded interviews with them, asking about parts that were difficult to produce and manufacturing tricks that they had learned in the process of building multiple engines.
(https://www.thespacereview.com/article/588/1)

Engines are probably the most complex part of a rocket, and they can often be reused in new rocket designs, so they're worth preserving. A lot of the rest of a rocket probably isn't worth it; the original blueprints depend on 1960s components that are no longer available, they use 1960s materials that are inferior to modern ones, the tooling is too bulky to store unused for decades, the launch pads and assembly buildings have been repurposed, etc, and most parts aren't that hard to design anyway (compared to engines), so even if you had perfect documentation it would probably be cheaper to redesign the rocket from scratch.

So I think the reason they didn't keep perfect documentation is because they knew it wasn't going to be needed, not because their engineers just didn't want to bother writing it down.

In my experience, the opposite of "retention" is deliberately practiced, with documentation being automatically shredded as a matter of routine, solely because doing so means you can't ever be accused of willfully destroying evidence in hypothetical future lawsuits.

This pathology is combined with a propensity to cull experienced technical staff, outsource work, and never promote from within (the excuses invariably distill down to "too expensive") to produce what is effectively a sort of institutional anti-memory.

(...I've seen this occur while a product is still being actively produced and sold, in businesses with product support cycles that are measured in decades.)

tl;dr: "Retention" has guaranteed costs, with completely unquantifiable benefits in at some point in the distant future. (where "distant" is anything beyond the current fiscal year)