[lug] can't make this stuff up, folks...

Landon Cox landon at 360vl.com
Mon Oct 19 13:20:49 MDT 2009


I have different take on the library issue than what I've hear dos  
far.  This is a general philosophical point not specifically related  
to CPAN, but could apply to CAPN and any of the myriad java or other  
libraries out there.

The point is simply this:  it's tempting to grab libraries because  
they solve 80% of your problem at the time and save you work  
immediately, but they also have the proven ability to bloat over  
time.  Besides the inevitable bloat, libraries are responsible for the  
vast majority of dependency hell we sometimes find ourselves locked in.

So, there is the bloat issue and the dependency issue that can render  
what used to be relatively svelt software completely unusable over time.

I once did an internal study at OpenLogic to measure the amount of  
code bloat over time of some of the common Java libraries.  It's truly  
stunning to the point where any of the original benefit you gained by  
incorporating the library is wiped out by the bloat and difficulty  
maintaining the software that uses it (keeping your software in sync  
with library updates, bug fixes, changes in APIs, and so on.)   Most  
of the time these things are out of your control once you decide to  
take a new library into your software.   If you fix a bug in oss  
library because the project chose not to, you have added maintenance  
issues.

The only other thing more stunning is how many open source libraries  
are abandoned.

It's very easy to get painted into a corner.   It's easy to take pot  
shots at engineers who want to write their own libraries, but there  
are valid reasons to do so.  You may still choose to ignore those  
because your calculus is that the immediate benefits outweigh the  
inevitable rot of library bloat, (and I grant many times it's truly  
the case), but you should at least consider whether it makes sense to  
keep pulling more and more libraries into your system that you do not  
have control of or are not ready to maintain by yourself if the oss  
project decides to not fix a bug or go a different way or abandon it  
entirely.

Some food for thought...

Landon



More information about the LUG mailing list