Peer Review is an experimental scientific and academic publishing platform. It uses a reputation system to match reviewers to papers and provides a clean interface for reviewing. It is open source and diamond open access. It is currently in open beta and being maintained by a single developer as a side project. The hope is for it to become a non-profit governed and funded by its community.

Follow us on Twitter.

Join us on Slack.


View the roadmap.

Contribute to the source.

Discuss the project.

Crowd Sourced Review Probably Can't Replace the Journals

posted on Feb 12th, 2024

Two years ago, I started a journey into academic publishing. I imagined using a reputation system to replace the journals with crowd sourcing. The reputation system would match reviewers to papers, incentivize good faith review, and identify bad actors. It wasn’t clear whether it would work in practice, but I wanted to find out.

I spent a year doing user research, building a beta (, and working to get people to give it a shot.

I am now convinced that it’s not going to work.

While some of the reasons are specific to the reputation based approach, most impact any attempt to crowd source peer review. There’s a brick wall standing in the way of any attempt to move academic publishing outside of the journals.

A photo of stacked journals.

What is crowd sourcing in an academic review context?

Before we dive into the reasons why crowd sourcing probably won’t work, let’s get some definitions in place.

In traditional academic publishing, the journal editors act as the organizers, moderators, and facilitators.

Crowd sourcing is any system where technology provides everything needed for scholars to self-organize. It is any system of academic review where the reviewers self-select and self-organize using technology without needing a faciliator, organizer, or editor.

What is it that we’re trying to replace with crowd sourcing?

Journal’s editorial teams are doing quite a bit of manual labor, some of which is very difficult to replace with technology.

The work of journal editorial teams includes:

  • Filtering spam and amateur work.
  • Facilitating multiple rounds of review and feedback, which requires:
    • Identifying and recruiting reviewers for papers.
    • Moderating the reviews.
  • Technical support for authors and reviewers in using the journal’s software.

Why can’t we replace that?

On the surface, most of that seems like work that a crowd sourcing system could potentially handle. I certainly thought the reputation system could handle a lot of it.

But I didn’t fully understand exactly what was happening with two items in particular.

Identifying and recruiting reviewers for papers… and convincing them to do the review.

This is a huge piece of the labor of editorial teams.

Scholars are constantly operating at the edge of burn out, with work coming at them from all directions. They don’t actually have the time or bandwidth to do review and are barely squeezing it in. Because of this, they aren’t seeking opportunities to do review. Editors have to work hard to find reviewers who can and will find bandwidth to do a review for them, often leaning on personal relationships or the prestige of their journals.

Editors I’ve spoken to sometimes have to ask 20 people before they find 2 or 3 willing to do a review. And even then, it’s not uncommon for people to commit and drop out.

I definitely didn’t understand just how bad this was when I started out. I was hoping a crowd sourcing system could fix this by building review into the natural process of reading the literature. And it’s still unclear whether that would help, if a system that made review easy and natural became the default publishing system. But it presents a chicken and egg problem. Reviewers aren’t going to review on that system until it’s the default, and it can’t become the default with out the reviewers.

Moderating the reviews.

Journal editors are doing an enormous amount of moderation. And not just your standard internet discussion moderation. They’re doing a lot of a very specific kind of ego management.

Crowd sourced systems generally work as long as the average actor is a good actor.

A good actor in the context of academic publishing is someone who is willing to put aside their own ego in the pursuit of the best work possible. This is someone capable of recognizing when they’re wrong and letting their own ideas go. A good actor would see a paper that invalidated their work and be able to assess it purely on the merits.

It is unclear whether the average academic is a good actor in this sense. And its editors who keep that from tearing the whole system apart.

Most academics seem to intuitively suspect that there are enough bad actors in academia to make crowd sourcing non-viable. One of the biggest pieces of feedback I got was concerns about abuse, manipulation, gaming, or just plain old bad faith reviews from people with competing ideas.

If the average actor is a good actor, a well designed reputation system would be able to flush those behaviors out over time. If not, it breaks the system. This breaks just about any other attempt to crowd source review as well.

Any attempt to replace the journals has to contend with these two issues and has to have a really solid, convincing answer for them. doesn’t.

The Other Shoe

There’s another reason why outright replacing the journals with a crowd sourced system - or any other system - is unlikely to succeed.

Lock in.

Authors simply aren’t free to try other systems. Their career advancement is wholly dependent on publishing in a limited set of journals chosen by their departments. In some cases those are chosen by committees of their peers, in other cases by university administrators.

Authors are not going to risk publishing a worthwhile paper in a new system. And reviewers aren’t going to go anywhere authors aren’t.

I had hoped focusing on file drawered papers might provide an in. But it’s unclear just how much of an issue file drawered papers are. It seems likely many of the papers aren’t easily shareable. Many academics question whether their file drawered papers should be shared. Often, ones that they want to share have already been shared on preprint servers.

There’s very little room for movement in the system where authors and reviewers are concerned. And you can see that in the massive graveyard of attempts to build something different, to which is now being added.

Is there hope for change?

Crowd sourcing probably won’t work, but there is still hope. We just have to change how we think about the system.

There are various attempts to reform the journal structure itself, like eLife’s move to reviewed preprints with a no rejection model. There are attempts to overlay a journal-like structure on top of preprints, like Peer Community In. In some cases, previous attempts to crowdsource are gradually evolving back towards something that looks like a journal form, like PREreview which started out pure crowd sourced and is gradually evolving back towards journalish with their review communities.

It remains to be seen whether any of these attempts will be able to get enough traction to make systematic change in the long run, but they all have the potential to.

But there’s another path as well.

If we admit that the journal structure, defined as an editorial team manually organizing and moderating review, is unlikely to change and redefine our goal from “crowd source review” to “escape the commercial publishers” and “enable experimentation with the journal structure”, then there’s a path with a ton of promise: flipping journals.

But that’s a story for another post.

A Pivot for Peer Review

posted on Nov 1st, 2023

Release 0.1.0

posted on Jun 28th, 2023

Today we released version 0.1.0. This is a beta release of Peer Review that contains several major features that had already been pushed out to production, along with a large number of bug fixes that hadn’t been.

This is the first major batch of bug fixes to the public beta. There will be more to come.

The list of bugs fixed includes:

  • Review “drafts” screen jumps to the top with every comment
  • Performance Degrades on Large PDFS
  • Anchor Links (Jump Links) fail to Jump on page refresh
  • Comments slow to load on large papers
  • Email Validation Token Succeeds, but Reports Failure
  • Cancelling a comment edit deletes the comment

You can find the complete release notes here.

Ready for Alpha Testing

posted on Oct 21st, 2022

Peer Review is ready for alpha testing to begin in earnest. If you’re interested in helping out, here’s what you can do.

You can find the alpha on the staging infrastructure.

We need people to put it through its paces. We need feedback on how intuitive the UX is and where we need to add more explanation and documentation, or redo the UX to be clearer. And, of course, we need help testing it thoroughly to spot any remaining bugs.

Once you have an account and initial reputation, you can try publishing a paper, posting some reviews, and posting some responses. If you aren’t able to generate enough reputation from your ORCID iD, reach out ( email, twitter ) and we can generate fake reputation for you so that you can interact with the rest of the platform.

In addition to feedback on the UX, we’re looking for any bugs that crop up. If you find a bug you can let us know in one of several ways:

Choose the method that works best for you!

We’re aiming to begin a initial semi-closed beta in early November. For the initial beta period, we’re going to increase the reputation required to publish to be 2x the average reputation per paper in each field. Anyone will still be able to read the site, but to participate you will need to have initial reputation. When we go from initial, semi-closed beta to open beta the reputation required to publish will be set back to zero.

We’re generating initial reputation from OpenAlex using ORCID iD to confirm identity. OpenAlex has a lot of data, but they don’t have all of it. So we’re working on additional ways to generate initial reputation.

Provided alpha testing goes smoothly, the beta should begin in early November. So stay tuned!

A Possible Fix For Scientific (and Academic) Publishing

posted on Aug 3rd, 2022

Scientific and academic publishing is broken. The vast majority of the journals have been privatized by publishers who charge astronomical fees for access to the literature.

The fees have gotten so high that even well funded universities have started to walk away from negotiations. Universities with less funding have long been unable to afford them. The average citizen has no hope of affording them.

With the results of the scientific process locked away behind paywalls, science is no longer an open and transparent process. Worse, the ultimate deciders of policy in a democracy, average citizens, are being denied access to the primary source materials necessary to make good policy decisions.

The Open Access movement has been trying to solve this problem, but it has mostly stuck to the existing model of hiring editors to manually match reviewers to papers, creating high overhead. To fund their operations, most Open Access journals have flipped the business model from fee for access to fee for publish. This has created a whole host of new problems, including the rise of predatory journals that are willing to publish almost anything by anyone who can pay.

The ultimate effect of pay-to-play is that the traditional peer review and refereeing process has broken down. If a dishonest researcher gets rejected from a reputable journal, they can take their paper to a pay-to-play journal and have it published there. With over 10,000 academic journals, it’s impossible for the lay public to track which journals are reputable and which are not. As far as the public is concerned, a published paper is a valid paper.

This is a proposal for a software platform that may help the academic community solve these problems, and more.

Peer Review - A Proposed Publishing Platform

Peer Review is a diamond open access (free to publish, free to access) academic publishing platform with the potential to replace the entire journal system.

A screenshot of a scientific publishing platform.

Peer Review allows scholars, scientists, academics, and researchers to self organize their own peer review and refereeing, without needing journal editors to manually mediate it. The platform allows review and refereeing to be crowdsourced, using a reputation system tied to academic fields to determine who should be able to offer review and to referee.

The platform splits pre-publish peer review from post-publish refereeing. Pre-publish review then becomes completely about helping authors polish their work and decide if their articles are ready to publish. Refereeing happens post-publish, and in a way which is easily understandable to the lay reader, helping the general public sort solid studies from shakey ones.

Peer Review is being developed open source. The hope is to form a non-profit to develop it which would be governed by the community of academics who use the platform in collaboration with the team of software professionals who build it (a multi-stakeholder cooperative).

Since the platform crowdsources the work of review and refereeing, and because it can potentially handle all academic and scientific fields on a single platform, we could eliminate most of the overhead of academic publishing. Meaning Peer Review could be initially funded with small donations from the scholars using it. If the platform were to eventually replace the entire journal system, it could be funded by the universities for a tiny fraction (1% or less) of what they are paying for publishing now.

Peer Review is currently at the alpha stage of development, most of the core features are functional in a proof of concept. They need testing and hardening, and a number of functionality gaps need to be filled in. I hope to reach a closed beta in the next few months. And an open beta several months after that. I’m seeking academics to give feedback on the concept, help test the alpha, and help us prioritize the roadmap for the closed and open betas.

If Peer Review succeeds, there are any number of ways we could take it. It could potentially solve the file drawer problem from the beginning, by simply giving scholars a place to submit, get immediate feedback on, and publish file drawered papers. We could explore building systems to help incentivize and highlight replications - linking replications to the studies they are replicating and giving replications a reputation bonus. We could build systems to assist with data sharing and funding transparency. We could even explore automating some of the grunt work of maintaining the academic literature - such as generating automated literature reviews. And we could work to make the academic literature more accessible and understandable to general public.

How It Works - The Overview

Here’s how the platform works in detail. When you have a draft of a paper you’re ready to get feedback on, you submit it to the platform. You give it a title, add your co-authors, and tag it with up to five fields or disciplines (eg. “biology”, “biochemistry”, “economics”, etc).

A screenshot of a submission screen.

The fields exist in a hierarchical graph, which is intended to be evolutionary. Each field may have multiple parents and many children - eg. “biochemistry” which is a child of both “biology” and “chemistry”. The hierarchy can go as deep as it needs to. We’re initializing the field hierarchy using Wikipedia’s outlines of academic disciplines, but the intention is for the 1.0 version to include the ability for scholars to propose new fields or edits to existing fields, along with a proposed place in the hierarchy, and for their peers to confirm the proposals.

A screenshot showing field tags.

When reputation is gained in a child field, it is also gained in all of that field’s parents. So a paper tagged “astrophysics” also gives reputation in “physics” and “space-science”. Reputation is primarily gained through publishing and receiving positive feedback from your peers during post publish-refereeing - more on that later.

When you hit submit, the draft goes into the review queue. Here other scholars who have enough reputation in any of the fields you tagged the paper with can see the draft and offer feedback on it.

A screenshot showing the review queue.

This system gives scholars an enormous amount of control over who they solicit feedback from. By choosing how high up the field tree they go, they choose how wide to cast their net. Because they can add up to five fields (which don’t have to be related) they can easily request interdisciplinary feedback.

Reviewers can click anywhere on the document to leave comments.

A screenshot of review comments.

When they are ready, reviewers submit their review with a summary and a recommendation. The possible recommendations are:

  • “Recommend Approval” meaning that this draft is ready to publish.
  • “Recommend Changes” meaning that they think it’ll be ready to publish after the recommended changes are made.
  • “Recommend Rejection” meaning that they don’t think this paper is worthy of publishing, or could be made publishable.
  • “Commentary” which is just a way to offer feedback and commentary with out a specific recommendation.

A screenshot of the review screen.

Authors can then mark reviews as “accepted”, indicating that they found them helpful, or “rejected” indicating that they were not helpful. Reviews that are “accepted” grant the reviewer reputation in the fields the paper is tagged with (and their parents). Reviews that are “rejected” grant no reputation, but don’t remove it either.

As the review process goes along, authors may upload additional versions of their paper and request new rounds of review feedback for each version uploaded. Reviewers may offer as many reviews to each version as needed, but only gain reputation for a single accepted review on each version.

When the authors are ready, they hit “Publish” and their paper is published and live to the world.

This puts the pre-publish review process entirely in the hands of the authors. It gives reviewers an incentive to give solid, constructive review feedback - and rewards good reviewers for their efforts with recognition of their contributions. It treats review work as a valuable contribution to an academic field alongside publishing.

Refereeing begins once the work is published.

At that point, peer scholars with enough reputation in the fields the paper is tagged with can vote the paper up or down. Up votes increase the paper’s score and grant the authors reputation in the tagged fields. Down votes decrease the paper’s score and the author’s reputation in the tagged fields.

A screenshot of a published paper.

Up votes should be given based on an objective assessment of the paper’s quality. Is this good science? A well constructed argument? Much of the same criteria currently used to determine whether a paper should be published in a well refereed journal, should be used to determine whether a paper should be upvoted, downvoted, or simply left with no score. Instead of that judgment being passed by a handful of reviewers selected by a journal’s editor, it will be collected from the entire community of the fields the paper was submitted in.

Peers can also post a single response to each paper, outlining their feedback and reasons for voting how they did (or not voting at all) in public. Down voters will be strongly encouraged to post a response explaining their downvote.

A screenshot of the responses section of the publish screen.

In this way, the refereeing process is made transparent and easy for the public to follow. A down voted paper should be treated with skepticism. An up voted one is trustworthy. The responses help add context and clarity.

All papers submitted to Peer Review are published under the Creative Commons Attribution License, meaning the work can be freely distributed, remixed, and reused as long as the authors of the original work are attributed.

It’s important to emphasize: Peer Review is intended to be the final publish step. It is not a pre-print server. It is an attempt to replace the journal system with something open to its core, scholar lead, and collectively managed by the scholar community.

Who Are You?

My name is Daniel Bingham and I’m the developer of Peer Review. I grew up in an academic family (my mother and father are both professors and my brother got his PhD), but went into software engineering. I taught myself to code at age 12 and have been in professional software development for well over a decade.

My most recent role was Director of DevOps at Ceros, a mid-sized software company. I built and lead the department which developed and maintained the cloud infrastructure and deployment pipelines for the Ceros Studio and MarkUp. Before building the DevOps team, I was a full stack developer at Ceros helping to build the Ceros Studio.

When I’m not writing code, I’m very involved in local policy. I’ve worked closely with representatives of Bloomington, Indiana’s municipal government on climate, transportation, and housing policy. I’ve served on government task forces and on the boards of local non-profits, including a three year term as president of the board of our local 501(c)3 affordable housing cooperative.

I’ve been dreaming about Peer Review for years. In my role as a policy advocate, I needed access to the research literature, but struggled to get it. As I pondered potential solutions to the problem of open access, the tools I used on a daily basis as a software engineer inspired the concept that became Peer Review.

I have a deep commitment to democracy, and I am as excited about the potential to build a scholar and worker governed organization around the platform as I am to build the platform.

Where Do Things Stand and Where Are They Going?

I am currently the only developer working on Peer Review full time. There are a small handful of volunteers who’ve offered part time help.

I have the alpha version of Peer Review up on a staging server. I’m looking for scientists, researchers, scholars, and academics from all disciplines who are interested in exploring the alpha and giving me feedback on the concept and where to go next.

Could this work the way I think it might? Are there things I’m not thinking of? Problems I haven’t foreseen? Aspects of the academic publishing system I am unaware of and that Peer Review doesn’t account for? Broadly speaking, am I going in the right direction?

I have a roadmap of features I need to put in place before we can begin a closed beta, and a significant amount of hardening and bug fixing to do as well. I hope to reach a closed beta in the next couple months. I’m also soliciting sign ups for the closed beta. Peer Review will only be as good as the community that forms around it, so - if the direction I’m exploring does indeed hold promise - I’m hoping we can start building that community now.

After the closed beta period I intend to do an open beta, where the platform is opened to any who would like to use it (while still understanding that it is not completely finished or polished).

You can view the roadmap on GitHub. If you’re unfamiliar with the process of software development, please keep in mind that the roadmap is a very rough estimate and that it is constantly in flux.

I’m also looking for feedback on that roadmap, are there features which aren’t currently included that should be considered for the closed beta? For the open beta?

If you’re interested in exploring the alpha and giving feedback, want to participate in the closed beta, or want to be notified when we reach open beta, please fill out this form! You can also use that form to give feedback on the initial concept with out signing up for anything.

If you think I’m on to something and you want to see Peer Review grow, please consider supporting the development effort! Right now my family (my wife, my daughter, and I) are living on savings. I’m hoping to raise enough through donations to be able to commit to working on it full time, indefinitely.

I need to raise $8000 / month to make that commitment: $5500 of monthly living expenses, $1500 to cover health care, and $1000 to cover the initial cloud infrastructure costs for site hosting.

You can support me on GitHub Sponsors. You’ll need to make a GitHub Account, but it’s free.

If we successfully raise that much, I will form the non-profit. If we raise substantially more than that I will hire additional engineers, designers, product managers, devops, and QE to help with development. I will also be pursuing grant funding once we reach the closed beta period. Any leads in that direction would be much appreciated.

If you have questions, ideas, suggestions, criticisms, feedback of any kind, grant leads, or offers of help that don’t fit into the form linked above, you can contact me at