openpilot needs four things before it will run, and one of them is a car

Four things stand between you and a running openpilot

The requirements are enumerated as four items, and none of them is a Python environment. You need a supported device, which the project names as the comma four, and the software, which the comma four setup reaches through a URL field where you enter openpilot.comma.ai to get the release build. You need a supported car, drawn from the list of more than 300 kept in docs/CARS.md. And you need a car harness, a separate purchase, to connect the device to the car. Running on other hardware is described as possible and explicitly not plug-and-play. That distinction is the whole adoption question: this is a program that fits a specific car, not a library that fits a specific machine, so the reader with a general-purpose Linux box and a spare weekend has the wrong problem.

The branch table is the upgrade policy

There is one entry point, and which software you get depends entirely on the URL you type into the device:

bash <(curl -fsSL openpilot.comma.ai)

Beyond that, a table maps branch names to URLs and the choice is a real risk decision. The release branch is release-mici on the comma four and release-tizi on the comma 3X, both served from openpilot.comma.ai. A staging branch exists alongside it, release-mici-staging and release-tizi-staging at openpilot-test.comma.ai, for getting a release slightly early. The nightly branches are served from openpilot-nightly.comma.ai and the project says plainly not to expect them to be stable, with nightly-dev adding experimental features for some cars. A separate device, chestnut, has its own four URLs under installer.comma.ai/commaai. Running master directly is supported but the project recommends a prebuilt branch instead.

pycapnp is pinned at 2.1.0 because 2.2 leaks

The dependency list is where this project states its engineering philosophy most plainly. A comment at the top of pyproject.toml says Linux and Python is all it needs, otherwise the team writes and owns the lines itself, and the list follows that through with eight vendored comma-deps packages covering capnproto, acados, ffmpeg, zstd, zeromq, json11, git-lfs and gcc-arm-none-eabi. One pin carries its own explanation: pycapnp is held at 2.1.0 because 2.2 introduces a memory leak through cyclic references, and a second comment marks zstandard as removable once the project reaches Python 3.14. The interpreter window is narrow, requires-python is >= 3.12.3, < 3.13, and three submodules named msgq, opendbc and pandacan are tracked alongside. For a contributor this means a locked toolchain, uv.lock and SConstruct for the build, and dependency bumps that need a stated reason.

The safety model is C code in another repository

The safety argument does not live in the Python tree, and that is the point worth understanding. openpilot states that it observes ISO26262 guidelines, with the detail in SAFETY.md, but the code enforcing the safety model lives in panda and is written in C. The testing story is layered to match. Software-in-the-loop tests run on every commit through the tests.yaml workflow, panda carries its own software-in-the-loop safety tests, and a hardware-in-the-loop Jenkins suite builds and unit tests the various processes internally. Panda also has its own hardware-in-the-loop tests. The final layer is physical: a testing closet holding 10 comma devices continuously replaying routes. Contributors wanting that rig read the contributing docs and the openpilot tools directory rather than any of it from the README.

Driving data is uploaded to comma servers by default

A section on user data and the comma account states that openpilot uploads driving data to comma servers by default, that the data is reachable afterwards through comma connect, and that it is used to train better models. Default-on telemetry from a vehicle is a different proposition from default-on crash reporting in a desktop application, and the reader evaluating this needs to know the setting is the default rather than an opt-in. The same section is where the account relationship is established, which matters because the data path and the account path are the same path. The project does not document in the README how to run with uploads disabled, so anyone who needs that behaviour is going past what is written here and should establish it before fitting the harness.

MIT, with an indemnity clause naming comma's directors

The licence is MIT and the repository confirms it, but the grant as published is not stock MIT. Immediately under the MIT summary sits a paragraph obliging any user to indemnify and hold harmless Comma.ai, Inc. and its directors, officers, employees, agents, stockholders, affiliates, subcontractors and customers against claims arising from use of the software. A second line says some parts are released under other licences as specified, so a given component may differ from the root. A licence file at the repository root and a SECURITY.md sit beside the code. Nobody should take a view on whether that indemnity is enforceable in their jurisdiction from this paragraph, but a reader who needs plain permissive terms for a commercial or safety-critical context has to read LICENSE before assuming MIT means what it usually means.

Alpha quality, and explicitly not a product

Three sentences sit in capitals under the licence heading and they govern everything else on the page: THIS IS ALPHA QUALITY SOFTWARE FOR RESEARCH PURPOSES ONLY, THIS IS NOT A PRODUCT, and NO WARRANTY EXPRESSED OR IMPLIED, with a line putting compliance with local laws and regulations on the user. That is the project's own characterisation, not a reviewer's inference, and it narrows the audience sharply. It also sits oddly beside the claim that the software upgrades the driver assistance system in more than 300 supported cars, which is a real deployment footprint for something that disclaims product status. A reader who wants assisted driving on a road rather than a research platform should read that disclaimer as the operative fact about the project, whatever the supported-car count implies.

Forks move the support burden, they do not remove it

openpilot has forks, and the most widely used is sunnypilot, which continues from the same codebase independently of comma's release branch. The difference in approach is where supported hardware comes from. Comma publishes a branch table, a supported-car list in docs/CARS.md and its own device, so the question is which of those channels you point a comma four at. A fork substitutes its own hardware, its own car list and its own release cadence, which helps a reader whose car is not in comma's list and leaves a reader who already owns a comma four with a second question about which branch is right. Nothing in this repository compares the two, so the choice comes down to whose hardware you have, not to a feature table.

Editorial conclusion

Adopt openpilot if you own one of the supported cars, can source the comma four and a harness, and want to read the model that steers the car. Do not adopt it as a fleet product, a research shortcut on generic hardware, or anything covered by a compliance regime, because the project calls itself alpha quality research software and disclaims warranty outright. Verify first which branch URL you are pointing the device at, since the release and nightly channels differ in stability and the comma three X device takes a different URL from the comma four.

Frequently asked questions

Official sources

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