[python-uk] Reviewing third-party packages

[James Cheese]

We do similar with a checklist for the practicalities (though I for one
still have no good solution for guaranteeing the security of code beyond
reviewing it line-by-line...) - we've gone slightly more general so as to
apply to "technologies" as well as just libraries, but our process is
roughly:

Costs - ongoing/one-off
License - usually a check against http://copyfree.org/ - though it gets a
lot more complicated with certain licenses and architectures, eg: GPL'ed
standalone services can be used without worry in much wider context than
GPL'ed libraries
Check for project activity - evidenced by number of contributors, recent
commit activity and release schedules
Maturity/age of project
Number of "users" - trying to get a rough idea of how many people/companies
use a library
Details on paid support options if applicable
Check if the team expertise and scale lines up with taking maintaining the
project should the worst happen
Checking team expertise for actually using the technology - and any
training/etc required
Checking scalability of the technology

...and a few things that are only really relevant for SaaS-type
integrations, such as identifying points of failure in the provider's
infrastructure.

The other thing I try and push is to ensure that alternatives are
considered where appropriate - which is a bit more contextual, but it's
very easy to jump to "I want to use this" long before checking if there are
better alternatives around.

Thanks

James

On Fri, 28 Jul 2017 at 10:08 Patrick Morris <patrick at shimi.co.uk> wrote:

> On 28/07/2017 05:54, Steve - Gadget Barnes wrote:
> >
> >
> > On 28/07/2017 00:27, PyUK at getaroundtoit.co.uk wrote:
> >> S, (Andy and Mike)
> >>
> >> Yes, you've hit a couple of pertinent points; and it might make for an
> >> interesting project.
> >>
> >> However, I was looking for a check-list or similar which I can give to
> >> the pertinent dev.teams to ensure that they are 'covering all the bases'
> >> - whereas the question: "have you checked 'everything'?" produces a
> >> rather predictable response.
> >>
> >> I'm thinking someone wiser than I will have written these things down -
> >> just can't find such...
> >>
> >>
> >
> > As a starting point, my personal mini-checklist, for considering
> > including packages:
> >
> > 1. Licensing: Is the project only ever going to be internal? If there is
> > any chance of it's being included in a commercial deliverable then the
> > licence and all of it's dependencies must be "Apache or better" and have
> > a chart of the acceptable permissive licences vs. usage. Basically the
> > licences that we generally have green flags for are MIT, BSD, CC-BY,
> > MMS-PL & PSF. With some yellow flags on Artistic/Perl & Apache.
> > 2. A quick look at the project repository for indications of activity
> > such as recent check-ins, outstanding tickets, age of pull requests,
> > discussion levels & tone on tickets. (Call this an abandonware check).
> > 3. The reputation, on-line & off, of the authors & maintainers.
> > 4. Is it hosted on a host that hasn't announced its own demise.
> > 5. Test coverage &/or Coverity
> > 6. Do the requirements look reasonable for the nature of the package,
> > e.g. I wouldn't expect network or server type dependencies in a screen
> > shot package.
> > 7. Ditto the imports
> > 8. If there are none-Python elements are they about what I would expect,
> > i.e. things that you would expect performance issues with?
> > 9. Support for Python 3 & 2 or at least a clear statement.
> >
>
> All of the above are good
>
> You could also use the following to check for known vulnerabilities
>
> https://www.openhub.net/explore/projects
>
> Patrick
> _______________________________________________
> python-uk mailing list
> python-uk at python.org
> https://mail.python.org/mailman/listinfo/python-uk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-uk/attachments/20170728/2108afa4/attachment-0001.html>