
The Only Linux Foundation CII Gold Rated Project Is a .. PHP Markdown Parser - reindeerer
https://bestpractices.coreinfrastructure.org/en/projects?gteq=300
======
dwheeler
I am the technical lead of the CII best practices badge, so ask me anything!

I'm not sure what the point of the poster was. You can see the projects with
"passing" or better here, and there are over 200:
[https://bestpractices.coreinfrastructure.org/en/projects?gte...](https://bestpractices.coreinfrastructure.org/en/projects?gteq=100)

There are very few projects with gold, sure, but gold is a more recent badge
level and it's pretty hard to get. In addition, we've been emphasizing helping
projects get the "passing" badge, and we have so far spent less time
encouraging projects to work on higher level badges (silver or gold). Most
projects working on higher level badges tend to work on them slowly, instead
of trying to get it all at once anyway.

I think a more telling chart is the steady increase in the number of
participating projects:
[https://bestpractices.coreinfrastructure.org/en/project_stat...](https://bestpractices.coreinfrastructure.org/en/project_stats)

If you are involved in an open source project, I would encourage you to get a
badge. Go here for more:
[https://bestpractices.coreinfrastructure.org/](https://bestpractices.coreinfrastructure.org/)

~~~
reindeerer
> I'm not sure what the point of the poster was.

Certainly not knocking on the badge or the practices.

I just found it amusing that PHP often gets a bad rap, but then shows up at
the top of the listed projects for objectively good development practices.

~~~
dwheeler
Ah! Thanks for clarifying that.

We intentionally created the badge criteria so that you could meet them
regardless of the language you used. And if someone's doing the right things,
then they should get a badge!

------
otriv
To be honest I don't find this completely surprising. PHP is widely used and
the code can be just as clean as any other language.

------
thisacctforreal
Looks like the Linux kernel would have a gold rating if kernel.org set
X-Content-Type-Options to "nosniff".

[https://bestpractices.coreinfrastructure.org/en/projects/34?...](https://bestpractices.coreinfrastructure.org/en/projects/34?criteria_level=2#security)

------
gtirloni
Whats the point being made?

This is more useful: [https://github.com/coreinfrastructure/best-practices-
badge](https://github.com/coreinfrastructure/best-practices-badge)

------
dwheeler
You can read an article I wrote about the badging project on LWN.net: "Core
Infrastructure Initiative best-practices badge"
[https://lwn.net/Articles/690169/](https://lwn.net/Articles/690169/)

Things have happened since then, but it's still a good overview.

------
dwheeler
By the way, the title is wrong. The badging application itself also gets a
gold badge. In addition, there are other projects that are close.

------
exikyut
I just found and read through the criteria list. It's mind-bogglingly
exhaustive, but in a very good way, and an excellent catalyst for
maintainable, secure software.

I'd regard it as universally applicable to any and all code.

This list gets you in the door: [https://github.com/coreinfrastructure/best-
practices-badge/b...](https://github.com/coreinfrastructure/best-practices-
badge/blob/master/doc/criteria.md)

And this is the list that gets you a gold star rating:
[https://github.com/coreinfrastructure/best-practices-
badge/b...](https://github.com/coreinfrastructure/best-practices-
badge/blob/master/doc/other.md)

Prepare to have your eyes glaze over.

\---

I had a go at summarizing the criteria. This is not an accurate reduction of
the essence of the two lists; it comes close (I have no reason to misrepresent
the criteria), but I've paraphrased here and there where I think it was
editorially safe to do so (including slightly rearranging/renaming the major
headings a little and swapping the ordering of points).

The following is NOT a substitute for reading the criteria. I wrote this to
give a good idea of why you'd want to take the time to click the above links.

>> _The following is the criteria to get a _minimally_ passing score._ <<

Website(s)

\- <Must> succinctly describe the project with a minimum of domain-specific
language or siloed knowledge

\- <Must> explain how to obtain, provide feedback and contribute

\- <Must> use HTTPS+TLS

Project

\- <Must> use an OSS license (OSI, FSF, or liked by Debian or Fedora); <may>
be dual-commercially-licensed

\- <Must> provide basic documentation in 99% of circumstances

\- <Must> use a URL-addressable, searchable discussion system for unilateral
participation (IRC or mailinglists with URL-accessible logging is acceptable)

\- <Should> use English

Source version control

\- URL-addressable version control <must> be used

\- System <must> track who changed what, and when

\- <Must> list all interim releases, for accountability

\- Unique version numbers <must> be used for all user-facing releases; commit
IDs are listed as acceptable version "numbers", as is use of SemVer, and use
of other version representations

\- Release notes <must> accompany all releases

Bug reporting

\- Project <must> provide bug reporting process; use of an issue tracker is
recommended

\- Project <must> at least respond to (if not fix) issues after 2-12 months,
and <should> acknowledge more than half of submitted enhancement requests in
the same timeframe

Vulnerability reporting

\- Project <must> provide a vulnerability reporting mechanism; HTTPS or email
(possibly with PGP) are suggested

\- All reports submitted within the last 6 months <must> be responded to
within 14 days

Building

\- IF project must be built in order to function, automatic rebuild mechanism
must be provided

\- Automated OSS test suite <must> be used

\- Tests for new functionality <must> be added to automated test suite

Code warnings

\- Project <must> use compiler warnings, language strict/safe modes, or
linting tools

Security

\- Project <must> be built by at least one developer who knows how to design
secure software (the 8 principles from Saltzer and Schroeder are noted)

\- At least one developer <must> have domain knowledge of common
vulnerability-introducing errors relevant to the software, and how to mitigate
against them

\- Project <must> use established and reviewed security algorithms/protocols

\- Project <must> use keylengths that meet minimum NIST requirements through
2030 (certain keylengths are noted)

\- Project <must not> use known-broken crypto

\- Security mechanisms <should> use perfect forward secrecy

\- Stored passwords <must> be iterated/key-stretched hashes with per-$user
salt

\- Keys and nonces must come from a cryptographically secure RNG

\- Project delivery mechanism <must> be MITM-resilient (HTTPS and SSH+SCP are
listed as acceptable)

\- Checksums <must not> be delivered over HTTP

\- Medium- to high-severity vulnerabilities <must> be fixed if they are public
knowledge for more than 60 days

\- Project <must not> leak security credentials (sample credentials are
exempted)

Code analysis

\- Project <must> use a static code analyser, if one exists for the given
project language(s) and is OSS; it is <suggested> that the tool be
configured/used to look for vulnerabilities, if possible; it is also
<suggested> that code analysis be rerun every commit or at least daily

\- Project <must> fix medium/high severity (CVSS 2.0 or higher) exploitable
issues found by static analysis in a timely manner

\- The use of a dynamic code analyzer to major production releases is
<suggested>, if an OSS tool exists for the project language(s)

\- If the software is written in C/C++ or another memory-unsafe language, it
is <suggested> that a dynamic analyser (fuzzer, web application scanner) be
used to look for things like buffer overflows/overwrites

\- It is <suggested> that the project make heavy use of run-time assertions
that are checked by dynamic analysis tools

------
userbinator
...showing just how useful "best practices" actually are.

I associate that phrase with dogmatic cargo-cult "don't think just follow" and
the horrible results thereof. Lots of self-proclaimed "experts" love to say
"do X and Y and Z and you will be successful because these are _best_
practices", but it's all a bunch of snake oil.

[https://agilepainrelief.com/notesfromatooluser/2010/03/there...](https://agilepainrelief.com/notesfromatooluser/2010/03/there-
are-no-best-practices.html)

[http://www.satisfice.com/blog/archives/27](http://www.satisfice.com/blog/archives/27)

[http://www.satisfice.com/presentations/nobest.pdf](http://www.satisfice.com/presentations/nobest.pdf)

"Best practices are best not practiced."

~~~
dwheeler
You probably use every day at least one of the projects with a badge. That
includes the Linux kernel, Kubernetes, Node.js, curl, GitLab, LibreOffice, and
many others. See a short list here:
[https://bestpractices.coreinfrastructure.org/en](https://bestpractices.coreinfrastructure.org/en)

Or the current complete list here:
[https://bestpractices.coreinfrastructure.org/en/projects?gte...](https://bestpractices.coreinfrastructure.org/en/projects?gteq=100)

As far as being not practiced, that's absurd. We worked to capture the
practices already being used by successful open source software projects. Are
you seriously arguing that projects should not use Version Control? Are you
arguing that projects should not have automated tests? Are you arguing that
projects should not have licenses? In short, have you even looked at the
criteria?

Also, snake oil salesmen made all sorts of claims because they were going to
earn money by selling you a product. Earning a badge requires $0, so the
badging process is not a sham to earn money.

~~~
userbinator
_You probably use every day at least one of the projects with a badge._

Yes, but it doesn't factor one bit in evaluating whether I use a project.

 _In short, have you even looked at the criteria?_

Yes, and it doesn't matter --- whether or not a project does X is not
necessarily an indicator of its success. You're essentially saying "all
successful projects do X, so if you do X you'll be successful" \--- where
success is, in this case, earning a badge.

I've seen far too much software that happens to tick all the "best practices"
boxes, yet is a horrific failure at doing what it needs to do.

 _Also, snake oil salesmen made all sorts of claims because they were going to
earn money by selling you a product. Earning a badge requires $0, so the
badging process is not a sham to earn money._

It's not free in terms of the time expense.

~~~
dwheeler
The best practices badge criteria are focused on increasing the likelihood of
developing good software. Neither it nor anything else can guarantee success.

In particular, you can develop high-quality software that does not solve a
problem that anyone else wants to solve, in which case it will not be a
success.

Guarantees are hard to find. That said, I think it is wise to look at the
practices of successful projects and try to copy them where they make sense.
That's what this set of criteria does. If you want something that absolutely
guarantees success of your project no matter what, then I'm sorry, I don't
know where you can get that.

You're right that doing this requires time. In particular, if you don't have a
test suite, picking a test framework and using it to create a test Suite takes
time. I think it is time well spent.

~~~
reindeerer
Best practices are a bit like good genes. By no means a guarantee of success,
fame, glory and riches, but damn if they don't make things easier.

