How to evaluate dependencies

As software developers, we are constantly making the decision between make or buy.

Deciding to make something carries with it the obligation to design, develop, test, document, and support it. You’ll have everything under your control, but you’ll also have to do everything yourself.

If a component is not part of your project’s core functionality, then it’s often a good idea to look around and see if you can find someone who’s already built that functionality. Optimally, the component you find will be free and open-source and will have been built by a team whose aim was to provide exactly that functionality.

Because they’ve focused on their task, it’s more likely to be a robust solution to your problem that what you would write yourself (focused, as you hopefully are, on your task). Their solution might go a bit too far (see “Size/Focus”), but that might be fine too (see “Extensibility”).

Is the component good, though? What do we mean by “good”? How can we tell? How do we go about sizing up a dependency?

Facets

The following table outlines various facets to consider.

Legal

License

See the Uster OSSPolicy for compliance information

Cost

Free? One-time fee? Per-seat license?

Organizational

Maturity

How long has the product been around?

Activity

When was the last commit? The last release?

Maintenance Status

Is the project actively maintained? How long is the issue list? Are bugs addressed?

Popularity

How many stars? Is it widely used?

Community

Do questions get answered? Is there help on StackOverflow?

Reputation

Are there known issues with the product or maintainers?

Technical

Documentation

Is it sufficient? Are there good examples or tutorials?

Configuration

Can you just include the package? How is the configuration? Does it follow platform standards?

Size / Focus

Does it do one thing well? Or many other things you don’t need?

Extensibility

How easy is it to extend the package for additional use cases? Will that matter to your project?

Efficiency / Performance

For this you have to know your non-functional requirement

Portability

Does it work on all target platforms and run-times? Are there unreasonable restrictions?

Transitive Dependencies

What are its dependencies? Are those reasonable?

Quality

What sort of impression does the project make overall? How does the code look?

References

• A Dependency Checklist by Justin Howard in April 2021
• How to Choose the Right Dependencies for Your Project by Jamie Bullock in January 2020