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.
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!
...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.
I see absolutely nothing dogmatic or cargo cult about the recommendations they make. They are completely sensible, and a decent guideline for improving the technical support infrastructure of a project.
What's wrong with that? Do you have any comparable list of actionable things that projects can do to improve their services?
That resonates. If living in a universe of one then personal best practices are whatever suit your fancy. But in this world apps must interact with a community of apps and be maintained within that context plus without suitable protocols inconsistent results will appear across apps. Some of Kaner, Bach and Pettichord work seems contrarian for its own sake. As in your ego is just as good as purported expert egos
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
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.
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.
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.
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/
Things have happened since then, but it's still a good overview.
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.
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)
17 comments
[ 4.7 ms ] story [ 25.2 ms ] threadhttps://bestpractices.coreinfrastructure.org/en/projects/34?...
This is more useful: https://github.com/coreinfrastructure/best-practices-badge
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!
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."
What's wrong with that? Do you have any comparable list of actionable things that projects can do to improve their services?
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.
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.
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...