Why we open-source our flight software

When Halcyon announced that it would publish the guidance, navigation and fault-management libraries used across its fleet, some people assumed we had lost our minds. Flight software is expensive to build and painstaking to certify. Why would a shipyard give away one of its most valuable assets?

The first reason is safety. Code that only one team reads is code that only one team can find bugs in. Since the libraries went public, outside contributors have filed 412 issues, and 37 of those were genuine defects we had missed. Two were in timing logic used aboard the Polaris Relay Tender's robotic arms. Those were fixed before they ever caused an incident.

The second reason is our partners. Operators who fly our ships want to integrate them with their own dispatch, maintenance and traffic systems. Before we opened the code, every integration meant a support ticket and a wait. Now a Belt logistics firm can read exactly how a Polaris plans a rendezvous and build their scheduling tools around it.

The third reason is training. The Sparrow Trainer, our 4.1-million-credit flight school craft, runs the same core libraries as our larger ships. Students learning to fly it can read the code that is flying alongside them. Several flight schools now teach a module on our autonomy stack, and graduates arrive already understanding how a Halcyon ship thinks.

What we do not publish matters too. Certification test suites, hardware security keys and the specific configuration of each customer's fleet remain private. Open code does not mean open access to anyone's ship. The libraries are released under Apache-2.0 on git.halcyon.example, and every release is signed.

There has been a commercial effect too, and we did not fully expect it. Procurement teams at partner companies tell us that open code shortens their evaluation by months. Their own engineers can audit exactly how a Halcyon ship handles a sensor fault or a communications loss before signing a contract. Transparency turned out to be one of our best sales tools, which is a strange thing for a developer advocate to admit, but there it is.

If you want to contribute, start with the navigation examples and the simulator harness. Our maintainers review pull requests weekly, and we hold an open office hour every second Thursday. You do not need to be a flight engineer. Some of our best fixes came from people who simply read the documentation carefully and asked why.