[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