Choosing what to depend on.
WHAT TO ASSESS
Whether it does what you need Whether it is maintained Whether the licence permits your use The security record The size of the community Dependencies it brings
WHY MAINTENANCE MATTERS MOST
Unmaintained software accumulates vulnerabilities and it will not be fixed.
HOW TO ASSESS IT
Frequency of releases Recent activity How quickly issues are addressed How many people contribute
WHAT TO BE CAUTIOUS OF
Projects with a single contributor Projects with no activity for a long period Projects with many unresolved issues Projects that recently changed ownership
WHY SINGLE-CONTRIBUTOR PROJECTS
They stop when that person does.
WHAT TO ESTABLISH ABOUT DEPENDENCIES
What the component itself depends on.
WHY
Dependencies bring their own licences, vulnerabilities and maintenance burden.
WHAT TO EXAMINE
The full dependency tree.
WHAT THAT FREQUENTLY REVEALS
Far more components than expected Licences you did not intend to accept Unmaintained components several levels down
WHAT TO ESTABLISH
Whether the benefit justifies the dependency.
WHY THAT QUESTION
Small conveniences frequently bring substantial dependencies.
WHAT TO CONSIDER
Writing it yourself, where the component is small.
WHAT TO PREFER
Fewer, well-maintained, widely used components.
WHY WIDELY USED
Problems are found and fixed faster.
WHAT TO RECORD
Every component adopted, its version and its licence.
