Review Board: A Self-Hosted Review Server With a Diff Engine and an Extension API
An extensible and friendly code review tool for projects and companies of all sizes.
At a glance
- What is it?
- Review Board is a Python, MIT-licensed web application for reviewing code and documents, with a diff viewer that goes past line-by-line comparison. It suits teams that need to host review on their own infrastructure; the README leaves installation steps and the cost of the extension surface to the official guides.
- Who is it for?
- Adopt Review Board if you need a self-hosted review server that tracks documents and graphics alongside code, supports version control systems such as ClearCase, CVS or Perforce, and can be extended through its API and extension frameworks.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Hole Review Board Was Written to Fill
Review Board is a web-based code and document review tool. The README states the project began in 2006 because the authors wanted something open source that could adapt to a variety of workflows rather than force one. That framing explains most of the design decisions visible in the material: support for many version control systems, an API and extension framework so custom features can be built without forking, and review of graphics and documents, not only source diffs. The intended audience is companies, open source projects and other organizations that want review to happen on infrastructure they control. The README describes usage ranging from two-person startups to enterprises of thousands, but that is the project's own description rather than an independently verified figure. What is verifiable is the shape of the tool: a server you run, a web UI your team uses, a command line suite called RBTools, and an extension surface for everything else.
What the Diff Viewer Actually Shows
The README is specific about the diff viewer, and it is the strongest technical claim in the material. It does more than display diffs: syntax highlighting, interdiffs, moved line detection, and indentation change indicators. Interdiffs are the interesting one. They let a reviewer see what changed between two revisions of a review request rather than the full diff against the base, which matters once a change has been through several rounds of feedback. Moved line detection addresses a common annoyance in review: reordering functions or blocks produces a diff that looks like a large rewrite unless the tool recognises the lines as moved rather than added and deleted. Indentation change indicators matter for Python projects in particular, where a whitespace shift can change meaning. None of these are exotic features on their own. The combination, in an open source server you host yourself, is the reason a team would pick this over a plain pull request view. The README does not describe how the moved line detection is implemented, so treat the mechanism as undocumented in the material available.
Repository Support and the Hosted Services It Talks To
Review Board lists support for Bazaar, ClearCase, CVS, Git, Mercurial, Perforce, Plastic, and Azure DevOps. That list is unusual. Most modern review tools assume Git, and a few add Mercurial. ClearCase, CVS and Perforce support is what makes Review Board relevant to organisations with long-lived proprietary version control, where migrating the repository is not on the table. On the hosting side, the README names Assembla, Beanstalk, Bitbucket, Codebase, GitHub, GitLab, Gitorious, Kiln, and Unfuddle. The presence of Gitorious and Kiln in that list is a sign of how long the project has been maintained; both are historical services rather than current ones. The practical reading is that the integration list has accumulated over nearly two decades and should be checked against your actual host rather than assumed. The README does not state which integrations are maintained at the same level as the core, and that is worth confirming before you plan around one of the less common entries.
Getting It Running: What the README Does and Does Not Give You
The README does not contain installation commands. It points to an interactive guide at reviewboard.org/get that walks through what to download and install, and to the Administration Manual for configuration. The only concrete install path named in the material is RBTools, the command line suite, which has its own download page and documentation. RBTools is what an end user installs to post changes for review, land reviewed changes, patch a local tree with someone else's changes, and check workload. So the split is: the server comes from the official guide, the client tooling comes from the RBTools download page. If you are evaluating Review Board, the absence of a pip install line in the README is itself information. You are expected to follow the guide rather than improvise, and the guide is where Python version requirements and database setup will be stated. The README also mentions RBCommons as a hosted option where the project handles administrative work, which is the escape hatch if running the server is the part you want to avoid.
The Extension API Is the Real Product Boundary
The README says you can integrate with Review Board using its rich API and extension frameworks, allowing custom features, review UIs and data analysis to be built without forking. It links three guides for developers: the Web API Guide, Extending Review Board, and the Contributor Guide. This is the part of the project with the most long-term consequence. A review tool that cannot be extended forces either a fork or a workflow change. Review Board's answer is to expose the API and the extension points so customisation lives outside the core. The cost is that the extension surface is a second thing to learn, and the README does not describe its stability guarantees or how extensions survive major releases. The release history shows a jump from 7.0.6 to 8.0, and major versions are where extension authors usually find out. If you plan to write extensions, that question belongs in your evaluation, not after deployment. Note also that the project does not accept pull requests; patches go through reviews.reviewboard.org, which is Review Board reviewing itself.
Where Review Board Is the Wrong Tool
The clearest limitation is in the README's own Power Pack section. Report generation, PDF and Office document review, better multi-server scalability, Microsoft Azure DevOps integration, GitHub Enterprise integration, and LDAP or Active Directory user sync are listed as Power Pack features, and the README describes downloading a trial licence. LDAP and Active Directory sync is marked as coming soon. So a team that assumes directory integration or document review comes with the open source install will be surprised. Those are commercial add-ons, not core features. The second limitation is operational: this is a server you run, with a database and an upgrade path, and the README's support section implicitly acknowledges this by offering installation and upgrade assistance, emergency database repair, and backports of urgent fixes under a paid contract. A team without anyone willing to own a Python web application should read that as a signal. The third is scale: better multi-server scalability is a Power Pack feature, which suggests the open source configuration has limits that the paid tier addresses. The README does not quantify those limits.
How It Differs From Hosted Review Inside a Git Platform
The obvious alternative for most teams is the review UI built into whatever hosts their Git repository, such as GitHub or GitLab. The difference in approach is not feature-by-feature; it is where the review record lives and what it can contain. A hosted platform's review is attached to a pull or merge request and assumes Git. Review Board is a separate server that tracks changes to pending code, graphics and documents, and keeps all discussion around decisions in one place, with support for version control systems that hosted platforms do not cover. That makes it viable for a team on Perforce or ClearCase, and for a team that needs to review a design document or a screenshot in the same system as the code. The trade is administrative: you run the server, you manage upgrades, and you accept that the review record is not where your repository is. For a Git-only team already on GitHub or GitLab, the built-in review is closer to the change and requires no server. For a mixed or non-Git environment, Review Board's version control list is the deciding factor.
Licence, Maintenance and Upgrade Cost
Review Board itself is MIT licensed, which is permissive and imposes few obligations beyond preserving the licence notice. The README does not describe the licence terms of Power Pack, and the trial licence language implies it is commercial and separate. Treat the two as distinct licensing questions rather than assuming one covers the other. On maintenance, the release history shows active work: 7.0.5 and 7.0.6 in March 2026, then 8.0 in June 2026, with the most recent push to the repository in September 2026. A major version bump roughly three months after a patch release means upgrade planning is a real task, not a formality, particularly if you run extensions. The README's support section is explicit that backports of urgent fixes to older releases happen only when possible, and that priority fixes and same-day responses come with a support contract. Community support runs through a discussion list with responses generally within a couple of days, which is fine for general questions and unsuitable for a production outage. Budget for the upgrade cycle and decide early whether a support contract is part of your plan.
Editorial conclusion
Adopt Review Board if you need a self-hosted review server that tracks documents and graphics alongside code, supports version control systems such as ClearCase, CVS or Perforce, and can be extended through its API and extension frameworks. Do not adopt it if you want a hosted service with nothing to administer, or if you need PDF and Office document review, report generation, or LDAP and Active Directory user sync out of the box, since the README places those behind the separately licensed Power Pack. Before committing, verify the current supported Python versions on PyPI, confirm your repository host is on the supported list, and check whether the features you need sit in Review Board itself or in Power Pack.
Community notes