Add "maintained" criterion

[david-a-wheeler]

This adds a new "maintained" criteria, per mailing list discussion.

We normally only add criteria after a long drawn-out time, because
we don't want people to lose their earned badges without giving them
lots time to fix things.

However, this case is diffeerent.
We have always assumed that a project actively pursuing a badge
is maintained. In this case we are simply adding a criterion we always
assumed but failed to properly document. Since we always assumed it, we can
set maintained=Met by default. With this default, existing projects will
not be at risk of losing a badge, so the reason we normally are
slow about adding criteria does not apply in this special case.
There seems to be unanimous agreement on the CII Best Practices mailing
list that it'd be appropriate to add this criterion.

In particular, it seems inappropriate that a project that is known
to be unmaintained should retain a best practices badge.
As Daniel Stenberg noted on 2021-03-24,
'Marking a project as "unmaintained" should disqualify it
from following best practices. Unmaintained is a worst practice'.

This commit does NOT automate anything. That will be handled later and
separately. There are two kinds of "unmaintained": projects that
expressly state they are unmaintained, and projects where we can
infer that they are probably unmaintained because they are large and inactive.
This automation will be handled later; currently we just want
to make sure the criterion is present. Adding this criterion
immediately allows us to mark "maintained=Unmet" on a few projects where
we know this criterion is not met.

Signed-off-by: David A. Wheeler [email protected]

Fix tests given new criterion 'maintained'

Signed-off-by: David A. Wheeler [email protected]

[david-a-wheeler]

This is a cleaned-up implementation to resolve #1591.

[codecov]

Codecov Report

Merging #1594 (9515fd2) into main (8139846) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main     #1594   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           53        53           
  Lines         2082      2082           
=========================================
  Hits          2082      2082           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8139846...9515fd2. Read the comment docs.

[kwwall]

I woke up this morning and just thought of maybe one more thing we should add to the recommendation. Most of the software that have badges have a separate independent main web page somewhere rather than solely relying on a git / Subversion / CVS / etc. code repository somewhere for all the additional information. And most of the time when you search with your favorite Internet search engine for that project, most of the first "hits" will take you to the project's main web site rather than to the source code repository. So in light of that, perhaps we should suggest that the project's main web site reflect the "unmaintained" status somehow as well.

[david-a-wheeler]

@ kwwall said:

I woke up this morning and just thought of maybe one more thing we should add to the recommendation. Most of the software that have badges have a separate independent main web page somewhere rather than solely relying on a git / Subversion / CVS / etc. code repository somewhere for all the additional information.

Beware: That's something we can actually measure :-). So I did...:

select count(*) from projects where (homepage_url=repo_url OR homepage_url='');

2229

select count(*) from projects;

3666

So 60.8% either have the same repo & home page, or don't list a separate home page. I think that makes sense, too. The projects you hear the most about are often larger projects or long-running projects that people use directly as applications, and those often have their own home pages. But a vast number of OSS projects are smaller programs that get pulled into larger works, and many of those have not seen a need to create a separate home page.

And most of the time when you search with your favorite Internet search engine for that project, most of the first "hits" will take you to the project's main web site rather than to the source code repository.

Fair enough. And while it appears those projects are not a majority, there are a lot of them & they are often important.

So in light of that, perhaps we should suggest that the project's main web site reflect the "unmaintained" status somehow as well.

Good idea. Is there any widely-used convention in use? Failing that, what would you suggest? I think we should recommend specific ways to id "unmaintained" projects, so that later automation can look for it.

[kwwall]

Widely used convention? I haven't seen any "*conventions*" except really *bad* ones, like simply abandoning one's entire web site, possibly to have them taken over by domain squatters. I would suggest keeping it simple. Suggest they had an <H1> at the beginning that announces the product (and site as well, if applicable) as DEPRECATED much like you would do with a README.md on some git repo. It doesn't have to be fancy. I just did that for an abandoned version of ESAPI (ESAPI4JS) on our OWASP Wiki site. I marked it as *DEPRECATED* everywhere it was discussed on the wiki page. Like you said, keep it simple.

…

-kevin

On Tue, Mar 30, 2021 at 11:31 AM David A. Wheeler ***@***.***> wrote: @ kwwall said: I woke up this morning and just thought of maybe one more thing we should add to the recommendation. Most of the software that have badges have a separate independent main web page somewhere rather than solely relying on a git / Subversion / CVS / etc. code repository somewhere for all the additional information. Beware: That's something we can actually measure :-). So I did...: select count(*) from projects where (homepage_url=repo_url OR homepage_url=''); 2229 select count(*) from projects; 3666 So 60.8% either have the *same* repo & home page, or don't list a separate home page. I think that makes sense, too. The projects you hear the *most* about are often larger projects or long-running projects that people use *directly* as applications, and those often have their own home pages. But a vast number of OSS projects are smaller programs that get pulled into larger works, and many of those have not seen a need to create a separate home page. And most of the time when you search with your favorite Internet search engine for that project, most of the first "hits" will take you to the project's main web site rather than to the source code repository. Fair enough. And while it appears those projects are not a majority, there are a lot of them & they are often important. So in light of that, perhaps we should suggest that the project's main web site reflect the "unmaintained" status somehow as well. Good idea. Is there any widely-used convention in use? Failing that, what would you suggest? I think we should recommend specific ways to id "unmaintained" projects, so that later automation can look for it. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1594 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAO6PGZOG3OQ2POIDL35D3DTGHVD7ANCNFSM42CIAEBQ> .

-- Blog: https://off-the-wall-security.blogspot.com/ | Twitter: @KevinWWall | OWASP ESAPI Project co-lead NSA: All your crypto bit are belong to us.

[david-a-wheeler]

Widely used convention? I haven't seen any "conventions" except really
bad ones, like simply abandoning one's entire web site, possibly to have
them taken over by domain squatters.

I agree that there are bad ways to do it :-).
I was hoping that there were some existing practices we could recommend.
I’ve searched some, and while there are certainly discussions
it's not clear that there are common conventions for it, just various ideas.
For example:
https://softwareengineering.stackexchange.com/questions/337005/whats-a-good-way-to-deprecate-your-npm-modules

I would suggest keeping it simple. Suggest they had an <H1> at the
beginning that announces the product (and site as well, if applicable) as
DEPRECATED much like you would do with a README.md on some git repo.

+1 on simple!

Fair enough, we can recommend that their website home page says it is DEPRECATED early on the page.

We could also mention deprecating it in package repos. Something like,

.... mark as deprecated in any package repository
(e.g., <a href="https://docs.npmjs.com/deprecating-and-undeprecating-packages-or-package-versions”>npm deprecate</a>).

A remarkable number of package managers don’t have a clear way to mark packages as deprecated. E.g.,
there's no clean way in PyPI to deprecate an entire package:
pypi/warehouse#345
https://stackoverflow.com/questions/24085400/how-to-formally-deprecate-a-pip-package
https://www.dampfkraft.com/code/how-to-deprecate-a-pypi-package.html
But that’s a problem for another day.

I'll try to draft a tweak to the latest text based on this.

[david-a-wheeler]

This criterion will be added no earlier than April 6, so that there will be at least 2 weeks where it has been discussed. It could be added later, especially if any concerns are raised before then. We've never done a "speedy adding" of a criterion before (we'd never contemplated it), so I want to make sure that people have time to raise any remaining issues.

So: If anyone has any concerns, please raise it here on this issue and/or on the mailing list, before we merge this. Thank you!!

[david-a-wheeler]

I'm merging this into main, with an eye to getting this into production.

We normally do not add criteria without a longer process, but as documented earlier, there are good reasons to make an exception. We must still provide opportunities for discussion and objection, but I think that's been met. It's been more than 14 days since this was first discussed in the CII Best Practices mailing list. I cross-posted to the OpenSSF Best Practices WG, and there were no objections. There have been agreements here on this issue.

So while it's quite unusual to add a criterion this quickly, especially at the passing level, there seems to be general agreement that it should be done. This was always an intended criterion, even though it wasn't stated before, and adding this criterion will not cause projects to automatically lose their earned badges.

After merging into main & staging, I intend to post a "last call" email to the CII Best Practices mailing list for any last-minute discussion, and then post to production.