I couldn’t find any page on dev.xwiki.org listing the rules we use when deciding to add a new dependency. I’d like to document that and thus we need to agree officially about these rules.
I can think of the following checks to perform:
Longevity of project (ideally more than 2 years)
Frequency of releases (ideally several times per year and a minimum of once per year if there’s a long track record of it happening)
Speed of support and whether questions are answered at all (ideally a question should be answered within 1 month at most)
Number of active contributors, to avoid single man efforts which is not a sign of stability as the developer can move to something else (ideally minimum of 3 active developers, and even more ideally, not all from the same company)
Quality of documentation (ideally there should be some doc)
License compatibility with XWiki’s LGPL 2.1 license
No prior unhandled security issues
All releases are versioning properly
Any more?
If one or several of these criteria is not achieved (except for the license one), and we don’t have the choice because there’s no alternative, then a VOTE can be sent to make an exception for a given dep.
Regarding the rules above, it is not clear to me when one of the criteria isn’t fulfilled. For example, if the library is only maintained by a single company, does that need a vote already? If a library is only one year old, does that need a vote?
I’m also wondering if we should introduce some rule to re-visit dependencies regularly (once per year for example) to check if they’re still meeting the conditions or if there is a risk or even a need to replace them.
Maybe we have that rule already, but it could still be good to document this more explicitly in the context of adding dependencies that types from dependencies must not be exposed in APIs (or at the very least, it should require a vote) as this makes replacing or sometimes even updating the dependency impossible.
+1 in general, to have a written list of rules on how to select a dependency
I’m honestly not sure what is the right value here, it depends a lot on the field and technology (2 years for a js library is probably a lot :)).
Might not be easy to know that.
Not sure about “all”, but sure latest versions at least should be clean.
+1, we kind of always see the same licenses, and we should ideally update that list of “tested” license every time we encounter a new one
Yeah, ideally we should, at least to create a jira issue to get rid of a dependency we don’t want anymore, as actually replacing it is not always easy. I do that from time to time for java dependencies, but it’s very far from systematic, and it’s mainly on dependencies I know well.
We have that rule, but indeed I’m not sure it’s really written anywhere. But the good news is that, AFAIR, this is actually reported by revapi these days (I think it’s java.class.externalClassExposedInAPI).
As for checks proposed by Vincent, +1 to have a guide on how to choose dependencies, but:
many times the choice is between using existing code, even if it’s not well maintained or documented, and implementing that ourselves; in this case the vote would only serve to basically let the others know that there is a new dep
you can’t use the same criteria when choosing a dependency that provides a small, secondary feature, versus one that provides a critical feature; e.g. I wouldn’t ask for a date picker library to be actively maintained by more than 3 developers (from different companies), but I’d ask that from a WYSIWYG editor library
some checks are rather subjective (e.g. quality of documentation)