How to evaluate dependencies
Published by marco on
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