Top Stories

The “Not Invented Here” syndrome is infamous in the software world. That’s too bad. Some things we have to write, but for many others, we’re better off choosing to use libraries, plugins or other external products.

Choosing a library involves several technical factors, including compatibility, scalability, security and robustness. But let’s talk about non-technical factors. When choosing an external solution, you should consider:

Licensing

Licensing is mostly related to cost, including the actual monetary outlay and the ramifications on your own software.

Consider the license itself first. Some restrict you from commercial use. Others require you to include notification that you’re using the software in your help guide. Still others require you to open-source any changes you make. If you have any concerns at all, this is the time to call in lawyers.

Once you know the library has a license you can work with, start looking at actual cost. What does a development license cost? Is it per user? Per CPU? Per installation? What does commercial use cost?

Your goal is to make the software’s cost match the benefit you get from it. As you use it more and more, you should get more and more benefit (read: customer revenue). For example, if the software costs per CPU and you need one more CPU per 10 customers, that’s a good match: You’ll be getting revenue from the extra customers to offset the additional cost. If the software is priced per element indexed and your first customer needs all the elements, the software is very expensive.

Support

Support is a fairly simple question: Can you get help with the level of urgency you’ll need? If this is mission-critical software, you’ll need a guaranteed fast response. If this is for an ancillary function, you can probably get away with email support or even public forums. For some software, this might mean getting support from a separate company.

Community

Community is important for two reasons: First, it will help with support. Second, it’s the pool from which you’ll draw knowledgeable implementers. A large and active community provides support during the software’s implementation, deployment and extension. It also provides a group of people who can work with you on your specific implementation, whether you hire a community member as an employee or contract with them. A smaller community means you’ll have to look harder to find knowledge and people to help. A robust community speaks to the product’s roadmap and likelihood of achieving it.

History and Roadmap

This is the most difficult (and possibly the most important) consideration in choosing an external library. In your technical evaluation, you looked at where the product is today, its features and its bugs. Now you need to determine whether it will continue to meet your needs going forward.

All of the analysis you’ve done before is relevant here. A larger community provides more hands to help keep the product going. It also increases the variety of uses for the software, so it’s more likely that your particular use case is the same as someone else’s. A support option may include guaranteed bug fixes or give you influence over the roadmap.

In addition, look at the library’s maintaining team. Do they have a public roadmap, and do they maintain it? Do they have a history of meeting their roadmap, whether it’s published or informal? Do they have a history of adding features and doing regular releases? How about fixing bugs? Has there been a major change in the makeup of the team recently? On a stable team, history generally predicts likelihood of future success. Look for past success and a direction you need the library to go in. That will rapidly increase your odds of future success.

Choosing external software is a risky business. It takes time and effort to select the right solution, and once you pick one, you’re responsible for how your users experience it. If it doesn’t work, your product won’t work, and that’s no fun for anyone involved. Look at the technical and the non-technical merits. And choose well.