I don't think a 25 year old paper on the topic would still hold that much relevance today. I'd also suggest that the difference is why software is created could

I don't think a 25 year old paper on the topic would still hold that much relevance today. I'd also suggest that the difference is why software is created could be having an influence over something like this. The fundamentals of the Unix design philosophy are "Make each program do one thing well" and "Expect the output of every program to become the input to another, as yet unknown, program". You could debate exactly how influential that has actually been over GNU design, but it's quite different from the typical approach taken with commercial software, which is not to write programs that perform a single function, but to write programs that solve an entire category of problems for the customer. When I think about the opensource "solution-oriented" products that I've used (Elastic stack and Zabbix come to mind), I don't get the impression that they're more reliable than their commercial counterparts. One of the things I've always thought about open source tooling in general, is that I expect to find a collection of highly reliable and performant utilities, and I expect it to be entirely my problem to turn them into a working system that's going to solve my problems. With commercial software, I would just expect it to just work off the shelf and consume much less of my time to maintain. That said, it is a fantastic feeling to find a bug or missing piece of functionality and to just write a pull request for it, rather than waiting for an account manager to get back to you saying "it's on the roadmap" or something else equally unhelpful.