There are some peer reviewed academic journal available. They have in common, that the published information has a high quality and most of them have a long tradition in the classical university ecosystem. Since the advent of Open Access there is need to start new academic journals. The open question is how to combine the Open Access philosophy with a peer review pipeline.
The technical side of an Open Access journal is very easy. In most cases, it's enough to upload a pdf document to a webserver and the paper can be read by a worldwide audience. We can discuss about the details, that means which software is producing the pdf format and which sort of webspace is the right one for hosting a journal, but in general this kind of pipeline will result into a high quality journal. That means, the document can be displayed on any device, and the webserver will deliver the information to any reader in the world within seconds.
The more advanced and seldom discussed issue is how to create a peer reviewed journal. A normal Open Access journal doesn't has a peer review, but it's some sort of pdf hosting website. That means, the admin of the journal uploads the pdf file, but the paper was never read by someone before the publication. In the classical academic publication system there is some sort of prepublication peer review available which allows to increase the quality, but its unclear how to reproduce this workflow in an open Access journal.
The current situation is, that some journals are experimenting with overlay journals, open peer review system and community driven peer review. One option is that somebody is only allowed to upload a new paper if he has peer reviewed an existing one. Another option is, to ignore peer review at all and allow the normal reader to comment newly published information. This will result into some sort of arxiv website which is extended with a comment section.
A truely peer review system is working a bit different. To framework for explaining the details is located in the software industry. The git version control system has a build in peer review feature. This feature can be activated with a dual branch workflow.
But let us go a step backward. Software development with git works usually with a single branch model. In the trunk branch the changes are submitted to a remote server. A single branch workflow doesn't has a peer review. A peer review has to do with creating two branches which are out of sync. A stable branch and an unstrable branch are needed as the minimum requirement.
Peer review and merging two out of sync branches is the same. The amazing feature of merging two branches is, that it will produces a conflict in any case. This kind of conflict creates a need for the stakeholders to negotiate about the issue. This negotiation is equal to a peer review. It is very different to comment a paper from the readers perspective, because a branch merge is done in the pre-publication step.
Now it make sense to transfer this philosophy to an Open Access journal. A minimal peer reviewed open access journal contains of two sections: unstable upstream and stable downstream. In the upstream section the incoming papers are stored, very similar to the arxiv repository. In the stable downstream section, the next issue of the journal is created. The interesting point is, that the stable section doesn't referencing to the upstream section but a complete copy is created. It's the same principle like in a git version control system. The stable branch and the unstable branch can be edited independent from each other. That means, the paper in the upstream section can be modified without affecting the paper in stable section.
Peer review can be realized with a dual branch model which is out of sync. To sync the branches a negotiation is required. Negotiation means to discuss the next issue of the journal with colleagues. An interesting side effect is, that the social roles in each branches are different from each other. That means, an author is allowed to upload a paper to the upstream section, but this doesn't mean, that this paper gets published in the downstream section.
Let us create a single example. The author uploads paper1 to the upstream section of the journal. The journal editor reads the paper and comes to the conclusion that the quality is too low. He decides not to publish this paper in the next issue. It is available in the upstream section, but it doesn't get copied into the downstream section. This produces a communication conflict, because the journal editor sends a rejection notice to the original author. This sort of communication is typical for all peer reviewed journal. What is available is a conflict between different social roles of the journal. These conflicting roles are attractive for normal readers because it makes the publication system more robust against wrong information.
From a technical point of view, there are many options how to realize a dual branch system. One option is to use the github project for hosting an academic journal. A more easier to realize system is to ignore the git tool at all and store the branches in different sections of a wiki. That means, the upstream branch is section 1 and the downstream branch is section2. This allows to create a peer reviewed academic journal on a single wiki page.
Peer review
Let us describe in the context of the branch model, what peer review is about. If the Open Access journal was created with the described workflow it contains of two sections: unstable upstream and stable downstream. The interesting point is, that this outline doesn't solve problems, but it will create many new tasks. One of them is the question which of the papers should be copied into the downstream section. That means, from the perspective of the journal editor the situation is, that some papers are available in the upstream section, but it's not clear which of them will fit into the next issue of the journal.
There are more than a single option to adress this question. A naive attempt is to use a dice and decides with a random generator which of the paper fulfill the quality standards of the journal. A second more elaborated decision making strategy is, if the journal editor decides by himself which of the upstream papers is well suited. And the best practice method is, that the journal editors delegates this question to a group of peer reviewers.
Because this point is equal to peer review it make sense to describe the process in detail. The starting point is, that the journal has two sections (upstream and downstream). To copy a paper into the downstream section a decision is needed about the quality. This decision is delegated to a group of people. What the group can do in response is to peer review the paper or not. In the worst case, the journal editor doesn't find an external peer reviewer. So he has to decide by himself if the paper fulfills the need of the readers.
But even in this case, its a peer reviewed journal. Because there was a decision which was taken. The decision if a paper fulfills the standards or not is only needed in a two branch model. In a normal repository there is no need to judge about a paper.
In the software industry, the principle has a long history. In the git tool a so called branch can be created easily. Creating a branch means to copy a folder and then it's possible to edit the folder without altering the original folder. Sometimes it's called a fork. Because the same sourcecode is available at two places at the same time. The interesting point is, that after creating a branch both branches will get out of sync. That means, a user can edit branch1 and branch2 isn't affected. This principle is a very powerful one and allows to divide software development tasks into subproblems.
Branches are used in the Open Source world for many things. There are feature branches available to fix a problem, and there are stable branches available to update complete operating systems. What comes very close to a peer reviewed academic journal is a stable release linux distribution like Debian. It's the same principle. Debian is peer reviewed software, that means, the Debian ISO file is different from the debian upstream branch.
Freezing the upstream
Every open source project starts with an upstream branch. The upstream is a repository which stores the sourcecode on a server. In most cases, the upstream is equal to a github folder, but the upstream can also be located on a SVN server or a FTP server. The upstream repository allows the creator of the software to update the project. He can upload new files and alter existing one. In case of content the upstream is equal to a wordpress blog. It's a place in the internet in which information is stored.
The interesting point in open source projects is, that apart from the upstream repository a second action is needed, which is called freezing. Freezing means to convert the sourcecode in the upstream into a release which can be delivered to the normal user. The interesting point behind freezing is, that from the programmers perspective this step has a low priority. What the software authors is trying to do is to improve the software with new updates. He isn't interested in stopping this update cycles. The only one who needs a freezed stable release is the end user.
In the Linux ecosystem there is a long duration discussion available if the normal user has a need for a freeze version or if he can use a rolling release version. Rolling release means, that no freeze is available but the normal user installs the same version as provided by the upstream. The interesting point is, that rolling release was never a success for real projects. All the major software systems like Debian, Windows 10, Red Hat, Apple Mac OS and Android are delivered in a release version which is froozen. So called nightly build versions are only available as an alternative. But they are not installed on productive systems.
The reason why it make sense to analyze the Open Source development model is because the concept of freezing the upstream is available since many years and it's discussed in the literature. Its the best practice method in open source software development. The same concept can be adapted to scholarly paper writing. Freezing a paper is equal for creating a peer review. The shared principle is, that the original author of a paper isn't interested in freezing a paper. Because this is equal to loose the control over the content.
In the reality a peer review is something which is working against a paper. A peer review is desired by the readers. A peer reviewed journal communicates between authors and readers as an intermediate.