However, a monolithic reuse library can quickly become a victim of its own success -- the more you use it (on various projects) and improve it (by adding new components and fixing bugs), the more effort that is consumed in maintaining and improving it. Let me explain:
The slow death of the monolithic reuse libraryA monolithic reuse library is one where all components of the library are released at the same time as a single unit. There are two main problems with monolithic reuse libraries:
- As the monolithic library grows large in size, it becomes hard to distribute -- it consumes large amounts of disk space and network bandwidth
- Users must choose a single version of the entire monolithic library for use in their projects -- it's all or nothing
- Users fork the reuse library -- Users make a copy of the library locally in their project and modify it. They possibly only copy subsets of the reuse library, breaking the monolith.
- Users stop upgrading to newer versions of the reuse library -- Users forever stick with an out-of-date, stagnant version of the reuse library, even though they might be able to take advantage of improvements made to some parts of the library. The cost of upgrading, due to the possibility of breaking code is not worth the possible benefits of the new features and fixes.
- Improvements to the library stop, because nobody ever upgrades to newer versions of the library.
- Improvements to the library happen in project forks. Either these changes never make their way into the main reuse library or are copied between projects adding tremendous uncertainty and ambiguity as to which versions of library components are being used.
Enter the modular reuse libraryThe modular reuse library is one where several individual libraries are released at different times, independently as separate and distinct units. One of the primary benefits of a modular reuse library is that users can choose which versions of each component they want, independently. This provides the following benefits:
- downloads are faster and less project disk space is consumed
- upgrades can be done on a per-component basis, minimizing the risk of upgrades and the amount of testing required to re-validate code
- there are more software products for library developers to manage -- each has its own life-cycle
- there are more components for users to obtain -- these have to be found and downloaded, and if one component depends other components, these have to be identified and obtained, too