Tried to understand how different packages are built and installed? You probably noticed that different packages from different people solve this issue differently. Sometimes these solutions are so different that you might get confused when working simultaneously with the packages in question.
Tried to describe the build/installation process of a software you created yourself? If you programs are as mine where modules appear and disappear daily, you might find yourself weary of constant errors in your build scripts that no utility reveals to you automatically and such a bug manifests after a while by such a strange behavior of the program that you start believing there is something wrong with the hardware of your machine (1).
Yes I am talking about the 'makefiles' and similar files in which you need to state, what needs to be built and which modules to link together when producing resulting binaries. They are remnants from ages where programs had two or three modules with 400-600 lines total and nobody cared to put this "module gathering" job to the compiler itself.
With the OSHS you can say goodbye to these problems. For programs you simply state which module contains main() and the compiler will take care about the rest. And the libraries are similarly simple: All that is needed is to state which modules need to be exported for the "rest of the world". The compiler utilizes the common habit of almost every C/C++ coder that a module consists of a header named module.h and a source code file named module.c (or module.cpp for C++) so it is able to find all the modules used by a package (or package item) and collect them together.