There are many good reasons to use code written by others in your application. This post describes some best practices to optimize your re-use experience.
Library Use Gone Bad
I recently discovered that a library we use for OpenID didn’t handle every situation properly. When I checked for an update, I found that the library is no longer maintained. So I found an alternative and tried to swap that new library in, only to discover that classes from the old library were used all over the place.
This little story shows that a lot can go wrong with using third-party libraries. The remainder of this post will look at how to use libraries properly. I’m going to focus on open source projects, but most of the same considerations apply for commercial libraries.
1. Use Only Actively Maintained Libraries
Look at things like the date of the latest release, the number of developers contributing, and the sponsoring organizations.
2. Use Only Libraries With an Appropriate License
What’s appropriate for you obviously depends on your context. For instance, if you’re building and distributing a commercial, closed source application, you shouldn’t use any library that only comes with the GPL.
3. Limit the Amount of Code That Touches the Library
Use the Facade design pattern to wrap the library in your own interface. This has several advantages:
- It allows you to easily replace the library with another, should the need arise
- It documents what parts of the library you are actually using
- It allows you to add functionality that the library should have provided but doesn’t, and do so in a logical place
4. Keep the Library Up-to-date
Many developers live by the rule “if it ain’t broke, don’t fix it”. However, you may not notice some of the things that are broken. For instance, many libraries contain security vulnerabilities that are fixed in later versions. You won’t notice these problems until a hacker breaches your application.
5. Write Regression Tests For the Library
If you’re regularly going to update the library, as I suggest, then you’d better know whether they broke anything in a new release. So you need to write some tests that prove the functionality that you want to use from the library. As a bonus, these tests double as documentation on how to use the library.
6. Know What Libraries You Use
You should always be able to tell what libraries you are using at any given moment, as well as their versions and licenses. You just never know when someone from the security team is going to call you about a critical vulnerability in a specific version of a library, or when the legal department suddenly decides to forbid the use of a certain license.
7. Take Ownership of the Library
Your application provides functionality to its users. They don’t care whether you build that functionality yourself, or whether you use a library. Not should they. When there is a problem anywhere in your code, you need to be able to fix it.
So think about how you are going to do that for the libraries you plan on using. Are the developing organizations responsive to bug reports? Do you have access to the source? Are the developing organizations willing to apply your patches? Does the license permit modifying the code for private use?
Reference: Seven Tips For Using Third-Party Libraries from our JCG partner Remon Sinnema at the Secure Software Development blog.
Disagree with the tip #2. According to GPL, you may use library code in an application which will be sold on a market, but if your application code and library code are differentiated essentials and could exist independently on each other. Here is what I mean: http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem
Good read…My personal favorite is point number 3. Its really important to provide a facade so that changes can be made easily.
Thanks!