[0] offers a few insights: license, habits, history, why change something that works, etc. You might also be interested in[1].
There are strong mindset differences between various software communities; it might takes a little bit of time & effort to appreciate a more frugal/conservative approach to software engineering.
The previous links highlighted some aspects of those mindset differences. [0], while unrelated to OpenBSD, is another good illustration.
That's to say, OpenBSD people probably don't care much for a more featureful experience: it won't make them more productive, even if it may look like it would from the outset.
Here's a recent example which made me laugh: 2 months ago, a "shortcut" for reverse search was implemented in acme[0], a 30 years old text-editor. It's not even qualified as a "feature" yet, rather, as an "experiment"[1].
Every little decision is carefully weighted; every square inch of the software is carefully and precisely designed. Japanese wooden planes are similarly designed: they don't look like much, especially in comparison with more modern, shinier tools, but they're surprisingly well-thought.
[0]: https://en.wikipedia.org/wiki/Acme_(text_editor)
[1]: https://github.com/9fans/plan9port/commit/0c79c32675e83ff3d8...
This is likely true for existing developers. But might discourage some fresh blood from joining. So in the long run the overall productivity might suffer from this.
That's probably more of a feature than a bug: it acts as a "natural" filter.
I have worked with CVS myself in the past and would probably have no problem getting used to again.
Some fresh out of school smart people might consider it a thing of the past. And just decide not to deal with it. Like COBOL.
This, but also: "can you make an effort to conform yourself to others instead of forcing others to conform to you;" Inexperienced people often lack the visibility of their elders, so it really makes sense to see whether they can lower their ego.
> Some fresh out of school smart people might consider it a thing of the past. And just decide not to deal with it. Like COBOL.
Are you using "smart" positively or not? Being smart is often frowned upon in SE. Then, driving smart people away still is a good thing.
If you meant positively... considering things of the past to be useless by mere virtue of being of the past, is definitely not a positive character trait, so we'd have a contradiction.
Side note, but the problem with COBOL is not that it's old; to quote wikipedia:
> COBOL has been criticized for its verbosity, design process, and poor support for structured programming. These weaknesses result in monolithic programs that are hard to comprehend as a whole, despite their local readability.