3rd party libraries, dangerous or the right way to go?

Question

I'm always having a hard time deciding whether or not to use 3rd party libraries in commercial applications. For some reason it scares me a bit. If I use an opensource library is there a risk of being sued because something is wrong with the license? Are there any other pitfalls? What if I think it is the best to use some library and I turns out not to be, what is the impact of removing it or changing it to another library?

I'm very curious about your experiences. Please convince me to use them or not...

Answer 1

Depends on how much you can trust the 3rd party's developer for support. Will the 3rd party help you if you need a certain feature which the library does not support? If your program crashes and its because of the 3rd library's code, will they help you in fixing the bug? Will they fix the bug?

Basically, its only worth using a 3rd party if they would add value to your program. If it does, then there's no reason not to use a 3rd party.

If you have the time (and most working programmers do not), get someone to program the feature in-house.

If I use an opensource library is there a risk of being sued because something is wrong with the license?

My advice is to read their license carefully. Your decision on this should be on a per-library basis.

Answer 2

Ok first of all you to be 100% sure of licensing, if you are not capable of determining if its appropriate or not, not many programmers feel confident they can anyways, you get a lawyer to check this for you. Most companies have a lawyer, at least the ones I've worked at. If you don't have one find a lawyer and consult his services.

Next comes the hard part, you need to evaluate the 3rd party libraries, if they seem good, stable, and IMHO you can contact the devs with little trouble, then you can incorporate it.

As a small checklist I keep for evaluation (but this is for C++):

• is it enclosed in a namespace?
• does it use defines responsibly does it?
• allow me to use my own memory?
• allocators can I turn on and off exception handling robustly?

Answer 3

If you are really concerned, it can be a good idea to minimize coupling with the library by wrapping it with your own interfaces/code. That way you can replace the library with another one (3rd party or homemade) if it turns out not to fulfill your needs later on.

Answer 4

Sometimes there is no point reinventing the wheel. If you purchase from a reputable company remeber it is their job to spend each and every day on those libraries. If you need generic tools, they will probably do a better job then you can.

If the libraries are not critical to your business, spending a small amount of money to save a lot of time will be beneficial.

If you can purchase the source-code along with the libraries, that way your not only reliant on the 3rd party to keep them up-to date.

Example: if your building internal software, buy the UI controls. Who care if they're not 100% perfect. It will save you time and you can focus more on the biz logic. You're company probably is not making more money by having a perfect UI for internal users.

Weigh out the risks.

update:
Also check out Chapter 1: Buy, Not Build in Code Leader by Patrick Cauldwell (you can actually read most of that chapter on amazon )

Answer 5

I use a lot of open source 3pplibs.

In my opinion, you can trust 3pplibs which are older than 3 years and have more than 15 releases. As more releases and passed years as better.

Code becomes better when the implementor supports his code and fixes the bugs, which were reported. You should take a look at the homepage and the release notes.

Answer 6

For any reasonably large application, and with limited development resources, using 3rd party libraries whenever possible is in my view pretty much the only way to go.

Usually it will simply not make any sense for you to try to do everything yourself; use existing libraries for everything peripheral, and focus your own development resources on your actual business problems.

Stick with libraries with common, widely-accepted licenses, and you should be fine in most cases: LGPL, ASL, BSD and derivatives, MIT, etc.

If your customers or managers are worried (or just interested), have your CTO or other senior tech person write an "Official Open Source Policy" for you dev team, which consists of "strict evaluation" of all libraries you use, as well as checking the licenses with a lawyer. As part of evaluating open-source libraries, investigate the vitality of each project, and keep a local copy of the sources for the version you use, just in case, even if you normally use the binary distribution.

---

Edit: Addendum about using commercial / closed-source libs:

The basic premise is the same: If the thing you need is peripheral enough, or time-consuming or difficult enough to build yourself, then yes, seriously consider buying it from a 3rd party vendor. (The decision of course involves a trade-off between various factors: time, your own dev resources, cash, how important it is, etc.)

But with closed-source libraries you should be extra careful about the licensing terms you're committing to. (Also, does the price you pay include support and upgrades; for how long? You don't want to find yourself stuck with an old, sucky version because upgrading would suddenly cost too much.) Specifically, if you're seriously committing to some library, make sure you will gain access to the source code of the library in case of the vendor going under. Such clauses are quite common when buying more expensive software, I believe. While googling around, I found an article talking about this; here's a quote:

[...] a licensee should attempt to include in the license agreement a provision providing the licensee with access to the underlying source code held by the licensor so long as the royalty or license fees are paid. Alternatively, the licensee can seek to include a provision that permits direct access to the source code by the licensor in the event that the licensor fails to or is unable to fulfill its affirmative obligations to debug, maintain, train, etc.

Finally, if the deal is big (financially, or if it's otherwise important to you), it will definitely help if you have people savvy in business and contracts, not just technology issues, doing the negotiations with the vendor.

Answer 7

Don't use any library that you don't have the source for: vendors go bust, open source projects wither and die!

Make sure that the license is one you know about.

Make sure that you know your platform. Java and .NET have a lot of libraries built in and you may find what you are looking for there.

Having said that - you'd be mad not to use some libraries. Who wants to write their own logging, pooling classes etc?

Answer 8

Well i would say depends on your team of developers, if you have bunch of seasoned pros at your disposal, then open source is good because you can fix/change whatever you want. Just beware of what type of license those codes are to prevent any forms of infringement problems later.

Else if you're building something and the 3rd party tool isn't your main Event, then i don't see the point of reinventing the wheel. As i prefer to find the best/affordable commercial libraries that i can get because it's have been well tested, it has some user base [good for asking or finding some weird stuff that you can do with it] and you have tech support [hopefully a good one].

And here's a good ol memory lane post from Joel on this issue for your reading [yay] reference.

Answer 9

How do you get anything done without libraries? If you implement every single piece you need, you will certainly need weeks for writing even the simplest application.

In other hand, there's choice.

It's easiest to choose open source libraries. You can just peek into the code and see whether it's ok. Playing with the API is also a good idea. Library that sucks neither has a good API.

The amount of code compared to features is a good indicator of suckiness. Larger libraries suck more. In libraries with small LOC count there's fewer lines that can be wrong. Also, if the code is really small and good, it's the indication of really good design.

Of course, mostly you just find libraries that suck. Deciding whether to use a crappy library depends about whether you can write better in time bounds you have and whether you need a better one.

Answer 10

Third-party libs are okay. If you look at a typical project from, say, S#arp Architecture, you'll see that it has dependencies on about 10 different libraries. And, amazingly enough, they all work! As for the 'being sued' aspect, just make sure you check the licensing - and if people are already using them for commercial stuff, then it's obviously OK.

Answer 11

Evaluate the use of 3rd party libraries as you would evaluate dependency on any 3rd party code: i.e. Win API, Apache Commons, JVM, CLR and the list is endless. After all, each of these is provided by a 3rd party (unless you happen to work for MS, Sun or be an active OS contributor):

• Is it an industry standard (either de jure or de facto)?
• Is there an open spec or source available?
• Are licensing terms reasonable?

The bottom line usually is the size of the 3rd party library installed based or your ability to change source. If the installed based is large enough your basic interests as long as they align with the basic interests of other users are likely to be protected.

Needless to say that if you can change source under acceptable licensing terms using 3rd party code can be a big boost to productivity, meaning better software for less.