The introduction at the top of the criteria for that initiative includes this sentence:
For example, some practices enable multi-person review before release, which can both help find otherwise hard-to-find technical vulnerabilities and help build trust and a desire for repeated interaction among developers from different organizations.
The mention of "review" is repeated in the
To enable collaborative review, the project's source repository MUST include interim versions for review between releases; it MUST NOT include only final releases.
Changes are much easier to review when they are broken down into small, individually-described, pieces. So allowing someone to view the log of changes you made to a project is an important part of leaving it open to review.
Some open source projects do not allow access to their internal development process, instead releasing each completed version along with its source code. This requirement is making clear that posting a snapshot of each release to a public repository is not sufficient, even though it would meet the
The project MUST have a version-controlled source repository that is publicly readable and has a URL.
For example, a repository which had only "final releases" might look like this:
af564c2 Snapshot version 1.0
bc459aa Snapshot version 1.1
affe00a Snapshot version 1.2
004bac2 Snapshot version 2.0
Whereas a repository which made the public development history available would have additional commits, more like this:
ab98c24 Release version 1.0
be564c3 Worker vomit now work when someone walk on the cloud
ae459af Elbows should only bend in certain, expected, ways regardless of what T-Shirt you are wearing.
29fe005 Release version 1.1
99e5bc1 Players eyes now reflect how drunk they are
664bac1 Release version 1.2
(Sample commit messages courtesy of The Strange Log)
This is more than just publishing the log of the changes, as anyone looking at the repository can check out, say, commit
ae459af. This is an "interim version" in the sense that it's a state of the application somewhere between release 1.0 and release 1.1.
This is also important to the "right to fork": if the elbow fix was controversial, someone could check out the "interim version" of the application in commit
be564c3 and create their own release. If they only had access to the 1.0 and 1.1 source code, this would be harder to do.