A 2020 Theme: Externalization

openpilot has come a long way. From supporting 1 car with 0 tests, to supporting 63 cars with a decent test suite. From Python 2.7 to Python 3.7 + a whole lot of C/C++ to make it fast. From having no documentation, to having an onboarding tutorial. From Apple II era graphics to something that would pass for a modern smartphone app. From scattered binary blobs, to 100% open source.

With 0.7, we consider openpilot almost out of alpha and ready to move into beta. Part of this is we want to make it easier than ever for the world to contribute to openpilot. When a fire is small, it needs careful nurturing to become something. But as a fire grows, it begins to consume whether you want it to or not.

Until now, we had a private repo where comma employees developed openpilot; if you saw references to “one”, that’s what it was. Now, we are moving to a completely open style of development, baazar style, not cathedral style. We, and the rest of the world, will be developing on openpilot master.

As an openpilot user, this won’t affect you. release2 will still be where the releases live. But as a developer, you can now develop with the same workflow as us. This should allow us to merge pull requests much easier also.

This has been a change in the works for a while, with cereal, opendbc, and panda becoming standalone and self tested projects that openpilot depends on. Push to opendbc if you have a new car to decode. Push to cereal if you want to add to our messaging structs. And push to panda if you have a new car safety model to add.

We are also bringing openpilot tools back in to the openpilot repo. openpilot master is a great thing to have checked out on your computer, and now it fully builds and runs on Ubuntu 16.04

It’s time for everyone to start developing on openpilot. Improve our hardware, replace our cloud, build better models, what matters is that the future is owned by the world. We are here to witness the creation of a distributed decentralized self driving car platform.

openpilot development flow

• We will develop on master, which is stripped and minified by CI and pushed to master-ci automatically if the tests pass. You probably should not be using master on devices.
• When we are ready to start the release process, we’ll push master-ci to devel-staging and open a pull request into devel. This pull request will be the spot for comments on the new release, and hotfixes at this point will be cherry picked from master into devel-staging. Once it’s good, we merge into devel.
• devel is built by CI, and pushes the built versions to release2-staging and dashcam-staging signed with the official comma release key.
• After the -staging branches are tested by the community for a few days, we’ll push them to release2 and dashcam.