Two and a half years ago, I had a problem. My company, Stadia Maps, offered routing via an API, but the year was 2023, not 2003, and people expect to get real-time guidance through their route rather than look at a static map with lines and written directions.

Most of our users didn't have a large budget to hire a team (or two!) of mobile engineers to build the navigation experience from the ground up. But they all wanted many of the same features: a map, a line showing where you need to go, some indication of where you are, and prompts when you need to do something. Every app adds their own "special" features, but the common base is surprisingly large. And there was no SDK or even set of common components to build on!

No such open-source SDK existed. There were a smattering of vendor-locked and semi-locked SDKs, but none of them were customizable enough to support unique use cases, like golf carts or public bus drivers. Open-source wasn't just "nice to have." It was a requirement for many of our users!

That's when I decided to build Ferrostar, a next-generation navigation SDK. Building something that even our competitors could use was just the first controversial decision. The next (at the time) was the technical architecture. We decided to build all of the core decision logic in Rust, and share it among native frontends written in Swift, Kotlin, or whatever other language made the most sense for the platform.

This talk will cover the process that led to our decisions, the technical architecture we arrived at, and how it's working so far. We'll cover how we build shared libraries, where we draw API boundaries, how we test, and even how we enable extensions in native code (Swift, Kotlin, Java, etc.). You do not need to be a Rust developer to benefit from this talk. (In fact, none of the other core contributors had written a line of Rust before joining the project!). We'll cover all layers from Rust all the way up to Swift, Kotlin, and even JavaScript.

Choosing to do a project like this that's both open-source and sponsored by corporate developers has interesting tradeoffs too! Nearly every contributor working on Ferrostar has been able to do so on work time, and gets paid one way or another. So we'll also discuss how we've managed the collaboration across stakeholders over the project: both what has worked well, and the areas for improvement. We hope this will start a valuable discussion among other open-source projects. With many companies abandoning open-source in favor of more restrictive "source available" licenses, we are at a critical juncture for open-source, and we hope we can add to the conversation by highlighting ways to FOSS truly work for everyone involved.