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...
http://www.satisfice.com/blog/archives/27
http://www.satisfice.com/presentations/nobest.pdf
"Best practices are best not practiced."
Or the current complete list here: https://bestpractices.coreinfrastructure.org/en/projects?gte...
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.
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.
What's wrong with that? Do you have any comparable list of actionable things that projects can do to improve their services?
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...
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...
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/
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.
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!
https://bestpractices.coreinfrastructure.org/en/projects/34?...
This is more useful: https://github.com/coreinfrastructure/best-practices-badge
Things have happened since then, but it's still a good overview.
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...
And this is the list that gets you a gold star rating: https://github.com/coreinfrastructure/best-practices-badge/b...
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
