Critique Is Going Open Source

That distinction matters. The main Critique repo contains the current hosted platform, internal docs, growth systems, and product surfaces that do not belong in a first public release. Open source is not a checkbox you flip on a production monorepo. If you want the public repo to be usable, you have to decide what the product is first.

So the first public cut is not “all of Critique.” It is the self-hosted review system: GitHub App install, webhook-driven PR review, review runs, findings, reruns, exports, and the supporting dashboard pages required to operate that flow on your own infrastructure.

What Opens First

That is the deliberate tradeoff. We would rather ship a coherent self-hosted review product than dump a larger but muddier codebase into a public repo and call that openness. The public repo should make it easier to run Critique yourself, not harder to understand where the real product boundary is.

Why A Separate Repo

We are using a separate public repository because git history matters. Once internal planning docs, operational scripts, or hosted-only platform assumptions are in a public history, cleaning the working tree is not enough. A fresh community-edition repo lets us publish the right thing with the right shape from day one.

The new public home is critique-community. It starts with the public landing page, scope docs, and migration roadmap. The next waves move the actual review product into that repo in controlled slices: first the retained review routes and dashboard surfaces, then self-host setup hardening, then optional adjacent features like Remedy or Checkpoint if they survive the boundary review.

What Happens Next

There is still real work ahead. Open source is easy to announce and harder to execute well. The standard we care about is whether a team can clone the public repo, configure GitHub App credentials, Postgres, and model access, and actually run PR review without depending on the hosted Critique platform.