<div dir="ltr">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:<div><br></div><div>Costs - ongoing/one-off</div><div>License - usually a check against <a href="http://copyfree.org/" target="_blank">http://copyfree.org/</a> - 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</div><div>Check for project activity - evidenced by number of contributors, recent commit activity and release schedules</div><div>Maturity/age of project</div><div>Number of "users" - trying to get a rough idea of how many people/companies use a library</div><div>Details on paid support options if applicable</div><div>Check if the team expertise and scale lines up with taking maintaining the project should the worst happen</div><div>Checking team expertise for actually using the technology - and any training/etc required</div><div>Checking scalability of the technology</div><div><br></div><div>...and a few things that are only really relevant for SaaS-type integrations, such as identifying points of failure in the provider's infrastructure.</div><div><br></div><div>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.</div><div><br></div><div>Thanks</div><div dir="ltr"><div><br></div><div>James</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, 28 Jul 2017 at 10:08 Patrick Morris <<a href="mailto:patrick@shimi.co.uk" target="_blank">patrick@shimi.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 28/07/2017 05:54, Steve - Gadget Barnes wrote:<br>
><br>
><br>
> On 28/07/2017 00:27, <a href="mailto:PyUK@getaroundtoit.co.uk" target="_blank">PyUK@getaroundtoit.co.uk</a> wrote:<br>
>> S, (Andy and Mike)<br>
>><br>
>> Yes, you've hit a couple of pertinent points; and it might make for an<br>
>> interesting project.<br>
>><br>
>> However, I was looking for a check-list or similar which I can give to<br>
>> the pertinent dev.teams to ensure that they are 'covering all the bases'<br>
>> - whereas the question: "have you checked 'everything'?" produces a<br>
>> rather predictable response.<br>
>><br>
>> I'm thinking someone wiser than I will have written these things down -<br>
>> just can't find such...<br>
>><br>
>><br>
><br>
> As a starting point, my personal mini-checklist, for considering<br>
> including packages:<br>
><br>
> 1. Licensing: Is the project only ever going to be internal? If there is<br>
> any chance of it's being included in a commercial deliverable then the<br>
> licence and all of it's dependencies must be "Apache or better" and have<br>
> a chart of the acceptable permissive licences vs. usage. Basically the<br>
> licences that we generally have green flags for are MIT, BSD, CC-BY,<br>
> MMS-PL & PSF. With some yellow flags on Artistic/Perl & Apache.<br>
> 2. A quick look at the project repository for indications of activity<br>
> such as recent check-ins, outstanding tickets, age of pull requests,<br>
> discussion levels & tone on tickets. (Call this an abandonware check).<br>
> 3. The reputation, on-line & off, of the authors & maintainers.<br>
> 4. Is it hosted on a host that hasn't announced its own demise.<br>
> 5. Test coverage &/or Coverity<br>
> 6. Do the requirements look reasonable for the nature of the package,<br>
> e.g. I wouldn't expect network or server type dependencies in a screen<br>
> shot package.<br>
> 7. Ditto the imports<br>
> 8. If there are none-Python elements are they about what I would expect,<br>
> i.e. things that you would expect performance issues with?<br>
> 9. Support for Python 3 & 2 or at least a clear statement.<br>
><br>
<br>
All of the above are good<br>
<br>
You could also use the following to check for known vulnerabilities<br>
<br>
<a href="https://www.openhub.net/explore/projects" rel="noreferrer" target="_blank">https://www.openhub.net/explore/projects</a><br>
<br>
Patrick<br>
_______________________________________________<br>
python-uk mailing list<br>
<a href="mailto:python-uk@python.org" target="_blank">python-uk@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-uk" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-uk</a><br>
</blockquote></div></div>