While I sympathise with some of the complaints the developer has, the idea that every software component should live as an isolated stack that duplicates its entire set of dependencies is misguided.

OS administrators want a maintainable, supportable system that minimises the number of security vulnerabilities they're exposed to and packages software in a consistent fashion. They also want deterministic, repeatable results across systems when performing installations or updates.

Likewise, keeping various components from loading multiple copies of the same libraries in memory saves memory, which helps the overall performance of the system.

Also, statements like this aren't particularly helpful and are factually inaccurate:

So package maintainers, I know you have your particular
package manager’s bible codified in 1992 by some grand
old hacker beard, and that’s cool. However, that was
twenty years ago, software has changed, hardware has
changed and maybe it is time to think about these choices
again. At least grant us, the developers of the software,
the benefit of the doubt. We know how our software works
and how it should be packaged. Honest.

Some packaging systems are actually fairly new (< 10 years old), and the rules determined for packaging software with that system have actually been determined in the last five years, not twenty years ago as the author claims. Nor are the people working on them grand, old, bearded hackers.

OS designers are tasked with providing administrators and the users of the administrated systems with an integrated stack of components tailored and optimised for that OS platform. So developers, by definition, are generally not the ones that know how to best package their software for a given platform.

As for documentation not being installed by default? Many people would be surprised at how many administrators care a great deal about not having to install the documentation, header files, or unused locale support on their systems.

Every software project has its own view of how its software should be packaged, and while many OS vendors try to respect that, consistency is key to supportability and satisfaction for administrators.

So, in summary:

* preventing shipping duplicate versions of dependencies
can significantly reduce:

- maintenance costs (packaging isn't free)

- support provision costs (think technical support)

- potential exposure to security vulnerabilities

- disk space usage (which does actually matter on
high multi-tenancy systems)

- downtime (less to download and install during updates
means system is up and running faster)

- potential memory usage (important for multi-tenancy
environments or virtualised systems)

* administrators expect software to be packaged
consistently regardless of the component being packaged

* some distributors make packaging choices due to lack of
functionality in their packaging system (e.g. -dev and
-doc packaging splits)

* administrators actually really care about having unused
components on their systems, whether that's header files,
documentation, or locales

* in high multi-tenancy environments (think virtualisation),
a 100MB of documentation doesn't sound like much, until
you realise that 10 tenants mean 10 copies of docs which
is a wasted gigabyte; then consider thousands of
virtualised hosts on the same system and now it's suddenly
a bit more important

* stability and compatibility guarantees may require
certain choices that developer may not agree with

* supportability requirements may cause differences in
build choices developers do not agree with (e.g.
compiling with -fno-omit-frame-pointer to guarantee
useful core files at minor cost in perf. for 32-bit)

I'd like to see the author post a more reasoned blog entry with specific technical concerns that are actually addressable.