OpenAssistant: the README says the project is finished and the last release was one afternoon of alphas

The first line of the README says the project is finished

Before the table of contents, before the badges, there is a note stating that OpenAssistant is completed and the project is now finished, thanking contributors and pointing at a blog post for the story. The same note names the surviving artefact: the final published oasst2 dataset, hosted on HuggingFace as OpenAssistant/oasst2.

The dates back that up. The last push to the repository is 2024-08-17, and the repository is not marked archived. The three most recent releases are v0.0.4-alpha0, v0.0.4-alpha1, and v0.0.4-alpha2, all three tagged on the same afternoon, 2023-11-25, an hour and a half apart.

The consequence is that this is a finished archive with a dataset attached, not a product with a slower release cadence. Three alpha tags in one afternoon is not a shipping pattern, it is a batch cut on a 0.0.4 version, and it sits about nine months before the final commit. Anyone reading the repository to judge whether to adopt the assistant should start from the note at the top rather than from the vision section further down, because the vision describes a goal the project itself has closed.

Nothing starts without a compose profile, including the documented command

The local stack is one command, run in the root of the repository:

docker compose --profile ci up --build --attach-dependencies

The compose file is where the reason is visible. Every service carries a profiles list, and the file's own comments map them out: backend-dev starts a database and the backend, frontend-dev starts what is needed to work on the frontend, a second inference profile argument adds the inference services, and the ci profile is described as the one used by CI automations, that is, end to end testing.

The consequence is that a plain docker compose up brings up almost nothing, and the command the README tells you to run uses the profile reserved for automated end to end tests rather than the one reserved for development. Both other modes are documented only in comments inside the compose file, so the profile you want for interactive work is the part of the instructions that is hardest to find. A contributor who follows the README literally gets a test environment and has to work out the difference.

The stack publishes Postgres and Redis on the host with default credentials

The database service is not the stock image. It pulls ghcr.io/laion-ai/open-assistant/oasst-postgres with a pull policy of always, restarts always, and publishes 5432 on the host, with POSTGRES_USER, POSTGRES_PASSWORD, and POSTGRES_DB all set to postgres. Its healthcheck runs pg_isready every two seconds and retries ten times. Redis is the stock image on 6379, with a healthcheck that pipes redis-cli into a grep for PONG, and it is started with redis-server pointed at a redis.conf mounted from the repository root. A third service, redislabs/redisinsight:latest, sits on port 8001 and belongs to the backend-dev profile alone.

The consequence is that the development stack claims two ports that most machines with a database already use, and it will fail to bind rather than fall back to another port. The credentials are the defaults, written into the file, which is normal for a development stack and wrong the moment a real database happens to be reachable on the same port. The pull policy of always means every start re-pulls the image, so a first run is slower than a second one and an offline run is slower still.

Apple Silicon has to be told to emulate, on every invocation

There is a note for MacOS with an M1 chip, and it changes the command rather than the configuration:

DB_PLATFORM=linux/x86_64 docker compose ...

The hook is in the compose file, where the database service sets platform to the value of an environment variable with an empty default. An unset value leaves the platform to Docker, a set value forces it.

The consequence is that on Apple silicon the database runs as an emulated x86 image, which is slower than native, and the override has to be typed on every command because the default is empty rather than being written into a local configuration file. The same set of notes explains that after starting you go to http://localhost:3000 and that it may take some time to boot, and that when logging in by email the magic login link goes to http://localhost:1080, a second local port that exists purely to catch the login mail. A devcontainer is provided for VS Code and Codespaces if you would rather not manage the ports yourself.

The root pyproject.toml is lint configuration and nothing more

The file has no project table, no build system table, and no dependencies. What it does have is three overlapping tool configurations. isort runs with the black profile, a line length of 120, multi-line output 3, and trailing commas. black uses the same line length of 120 and targets py310. ruff uses a line length of 120 and selects only E and W from pycodestyle and F from pyflakes, ignoring E501, E731, E741, and E999, with a McCabe complexity ceiling of 10. A .pre-commit-config.yaml sits at the root to enforce it.

The consequence is that nothing here is installable. There is no package to pip install from this repository, and there is no dependency list, so the Python components are importable only inside the compose stack where the images already resolved them. The other consequence is the overlap: three tools touching the same lines, with isort explicitly deferring to black's profile and ruff restricted to error and pyflakes classes so that style stays with the formatter. That arrangement is deliberate and it is documented nowhere except the file itself.

Twenty directories for a whole product rather than a library

The root is a map of an entire system. There is a website and a separate text-frontend, a backend, an inference folder, a model folder, notebooks, data, oasst-data, oasst-shared, safety, discord-bots, copilot, deploy, ansible, docker, scripts, docs, and assets, alongside a .devcontainer, a .python-version, a CODEOWNERS file, a redis.conf, and an inlang configuration file for translations.

The consequence is that adopting one piece means extracting a directory rather than depending on a release. There is no published interface between the parts that a downstream project can pin, and no changelog to read, so the practical options are to run the whole stack or to copy the code you need. The directories also show how much of the effort sat outside the assistant itself: safety tooling, discord bots, deployment with ansible, and a copilot directory, none of which the README mentions in its closing sections.

The plan was a fifty thousand sample MVP with a swag leaderboard

The plan section is written as a research document rather than a roadmap. It aims at an initial MVP as fast as possible by following the three steps outlined in the InstructGPT paper. Step one is collecting high-quality human generated instruction and fulfillment pairs with a stated goal of more than 50k, collected and reviewed by a crowdsourced process, with an explicit decision not to train on flooding, toxic, spam, junk, or personal information data, plus a leaderboard and swag for the top contributors. Step two is sampling several completions per prompt and showing them to users to rank, acknowledging that this has to survive unreliable and potentially malicious users, and requiring multiple votes by independent users to measure agreement, with the rankings feeding a reward model. Step three is the RLHF phase.

The vision section adds the constraint that never appears resolved: the assistant should be small and efficient enough to run on consumer hardware.

The consequence is a mismatch a reader should see clearly. The plan is written in the vocabulary of a volunteer data project with a numbers target and a reward of swag, the vision asks for a consumer device assistant, and the README then states that the local setup is only for development and is not meant to be used as a local chatbot. The dataset survived. The consumer hardware assistant did not arrive in this repository.

Editorial conclusion

OpenAssistant fits someone looking for the oasst2 dataset or for a reference implementation of a crowdsourced annotation pipeline, both of which are still there and are the parts that outlived the project. It does not fit someone who wants a maintained chat assistant, because the project states it is finished and the code has not moved since 2024-08-17, and it does not fit someone who wants to pip install it, because there is no package metadata in the repository at all. Before you build on any of it, treat the compose stack as an era artefact rather than a deployment path, read the FAQ the README points at for the Docker problems it anticipates, and check the inference folder directly since the local setup was never meant to be a local chatbot.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes