Impacts

Here are some of the OSS projects that have made improvements so that they could get a badge. Since one of the purposes of the badge is to encourage improvements to projects if they are lacking, this is fantastic. We're very grateful to the projects who were willing to make those changes and tell us about them. This is not a complete list; projects aren't required to tell us what they changed, and we might not have recorded the changes here.

OWASP ZAP

OWASP ZAP is a widely-used tool for scanning web applications to look for security vulnerabilities. I use it myself, and it was used to develop our BadgeApp application. You can see the details here: https://bestpractices.coreinfrastructure.org/projects/24

ZAP refers to the badge on its github page https://github.com/zaproxy/zaproxy/blob/develop/README.md and have tweeted about it as well: https://twitter.com/zaproxy/status/763273810149769217. They currently can't add the badge reference to the OWASP wiki page, as it doesn't allow external images, but they've asked if this can be changed: http://lists.owasp.org/pipermail/owasp-wiki-editors/2016-August/000440.html.

The OWASP ZAP project lead, Simon Bennetts (a.k.a. Psiinon), had some really nice things to say (quoted with permission): "I can definitely confirm that the badging project has helped us improve ZAP quality. It allowed us to see where we were doing well and where we were falling short, and that has helped us focus on the areas that needed most improvement. For us it has definitely not been a 'box ticking' excercise. We want to follow the best practices, and have made sure that we have changed our development processes so that we are doing all we can to make ZAP into a high quality project. I'm a big fan of the badging project, and will be very happy to be quoted as being a strong supporter of it :)."

For example, before they started pursuing the badge, the project had relatively limited automated testing. Limited testing turns out to be a widespread problem for this kind of tool. Users of these tools are looking for problems they don't know about, and these kinds of tools use a lot of heuristics, so users typically don't notice when a tool fails to detect what it should detect. Naturally, without user feedback about failures, it's easy to skip creating automated tests (users aren't complaining!). This isn't a guess; Shay Chen's "WAVSEP Web Application Scanner Benchmark 2014" reported in benchmarking these kinds of tools that, "More than a few tools that got high results in the previous benchmarks categories, got lesser results in this one – in the same categories, although nothing in the test environment has changed... The overall problem is related to product testing and maintenance... software bugs may cause a variety of crucial features not to function for long periods of time, without anyone being aware of them." http://sectooladdict.blogspot.com/2014/02/wavsep-web-application-scanner.html.

I'm delighted to report that the ZAP folks have made great strides in their automated testing, and that was the last criteria they needed to meet to get a badge. This is exactly the sort of thing that a best practices badge can point out - it can identify things that should be done, even if it's not immediately obvious to users.

CommonMark

league/commonmark (a CommonMark implementation) got a badge.

Colin O'Dell reported, "thank you for your work on the CII Best Practices program! Having a concrete list of best practices was a huge help in finding and fixing the gaps in my project. I'm looking forward to seeing more and more projects get their badges."

MediaWiki

MediaWiki is working on a badge. MediaWiki has a separate wiki page detailing progress.

Xen

The Xen project is making changes based on the badge criteria; to my knowledge the details are not yet public.

vim-metamath

vim-metamath has a badge.

To get a badge, the project made changes:

• An automated test suite was added.
• Text was added to meet "The information on how to contribute SHOULD include the requirements for acceptable contributions (e.g., a reference to any required coding standard). (URL required) [contribution_requirements]"
• It was modified to meet, "The project MUST have a unique version number for each release intended to be used by users. [version_unique]
• It was modified to meet, "The project MUST provide, in each release, release notes that are a human-readable summary of major changes in that release. (URL required) [release_notes]"