OpenCollective's main repository is an issue tracker, not the platform

An issue tracker wearing the platform name

OpenCollective describes itself as an online funding platform for open and transparent communities, with tools for raising money and sharing finances in full transparency. The repository you are looking at is none of that software. Its description says the team tracks all its Issues, RFCs and a few other documents in this repository, and the README repeats the instruction to raise all issues in the repo, which it calls an overview for the project. Read it as an inbox and a decision log rather than a deployable system. An engineer evaluating OpenCollective as a codebase has to start in one of the 5 sibling repositories instead. An engineer who stops at this README will not find a runtime, a dependency list, a database schema or a single environment variable, and that absence is by design rather than an oversight.

Five repositories split along the request path

The platform is split across five repositories, and the split follows the request path rather than the feature list. `opencollective-api` holds the main GraphQL APIs, `opencollective-frontend` is the main website, `opencollective-pdf` is the PDF export service, `opencollective-rest` is the REST API service, and `opencollective-images` handles image processing. Two API surfaces sit side by side, so an integration has to pick a GraphQL contract or a REST contract rather than one shared interface, while document generation and image handling become deployables that change on their own schedule. For anyone operating the platform, that is five codebases, five dependency sets and five deployment decisions. The addresses the README gives are:

https://github.com/opencollective/opencollective-api
https://github.com/opencollective/opencollective-frontend
https://github.com/opencollective/opencollective-pdf
https://github.com/opencollective/opencollective-rest
https://github.com/opencollective/opencollective-images

Each of those five is a full project with its own history, and this repository keeps none of their code.

Issue quality is delegated to three outside guides

Issue quality is not defined here, it is delegated off-site. Before you file, the README sends you to 3 external guides: GitHub Guides: Mastering Issues, a Wiredcraft piece on how the team writes its GitHub issues, and an NYC Planning Digital article on writing useful GitHub issues. That is an unusual default for a project this size, and it has a practical effect on a first-time reporter: the format rules arrive from outside the repository, so a badly shaped issue reaches the tracker without a local template to catch it first. A `.github/` directory does sit at the top level, yet the README never says what templates, workflows or forms live inside it. Anyone migrating a batch of tickets should open that directory rather than assume a template exists.

rfcs/ and postmortem/ hold what the services cannot show

Two directories carry history the five code repositories do not: `rfcs/` and `postmortem/`. The repository description names RFCs explicitly as one of the tracked document types, which places design proposals upstream of the code instead of inside any single service repo. Postmortems sit beside them, so a failure write-up for the API, the frontend or the PDF service is expected to land in the same place as forward-looking proposals. That pairing is the actual value of this repository. Neither directory is described in the README, which says nothing about how an RFC travels from draft to accepted, who signs it off, or whether an accepted proposal is linked from the repository that implements it. Reading `rfcs/` is the only way to recover the reasoning behind a change after the commit history has flattened it.

Support bypasses the tracker through Discord and email

Support does not travel through the issue queue. The README sends questions to the Discord server and to [email protected], which means an issue is for reporting and tracking while a plain question is pushed into chat or email where no public thread is created. The split has a cost for anyone auditing the project later: answers given in Discord leave no searchable record in the repository, and questions misfiled as issues sit open because nobody triages them into a support channel. The README also says the repository is the main issue tracker and asks that issues follow common guidelines, yet it documents no maintainer response time and no triage policy, so an open issue carries no promise about age or closure.

Hosted at opencollective.com versus five services you run

There are two ways to obtain OpenCollective, and the difference is larger than a hosting toggle. The homepage recorded in the repository metadata is https://opencollective.com, the hosted service where communities actually raise money. Self-hosting means standing up the five repositories listed earlier: the GraphQL API, the REST service, the frontend, the PDF exporter and the image processor, then wiring them together. Nothing in this repository explains how those five are connected. There are no service URLs, no port map, no queue description and no database instructions, and the README does not document deployment at all. So the real comparison is between a hosted platform whose code you never run and five services for which this repository provides no assembly instructions whatsoever.

No install path, no rollback, no build to pin

Start with the gap that will cost you an afternoon. The README contains no installation command: no clone line, no package manager, no container file and no environment variable list. It sends developers to documentation.opencollective.com, which is stated to hold the user guide, guidance on how to contribute and the developer docs, so every operational detail sits on a page outside this repository. The repository has no GitHub releases, which means there is no tagged build to pin and no published change record to diff when an upgrade misbehaves. The last push was on 2026-09-15. Rollback for a self-hosted deployment is a question the code repositories have to answer, and this one cannot.

Editorial conclusion

Judge OpenCollective as software from opencollective-api and opencollective-frontend, not from this tracker. Teams planning to run the platform themselves must assemble five services with no deployment notes here, so verify against documentation.opencollective.com before budgeting a self-hosted install. File bugs here, but read rfcs/ and postmortem/ first: that pair explains why a change exists, which no single service repository does. Confirm that a pinned build exists in those repos before you rely on one.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. opencollective/opencollective on GitHub
4. Project website
5. README