Console #121 - Interview with Ellen of Headway - a self-hostable maps stack
Featuring Maestro, ruff, and Headway
🤝 Sponsor - PostHog
With PostHog's open-source analytics platform, customer data never has to leave your infrastructure.
Featuring product analytics, session recording, feature flags, heatmaps, experimentation, and more - all available for free!
The best part is everything is seamlessly integrated, so you can spend less time configuring different tools and more time getting valuable insight into user behavior.
Maestro is the easiest way to automate UI testing for your mobile app. Works for any app on Android and iOS, with just a few lines of YAML.
An extremely fast Python linter, written in Rust. 10-100x faster than existing linters and installable via pip.
language: Rust, stars: 1429, issues: 14, last commit: Today
Headway is a maps stack in a box that makes it easy to take your location data into your own hands. With just a few commands you can bring up your own fully functional maps server. This includes a frontend, basemap, geocoder and routing engine. Over 200 different cities are currently supported.
Join thousands of other open-source enthusiasts and developers in the Open Source Hub Discord server to continue the discussion on the projects in this week's email!
Not subscribed to Console? Subscribe now to a weekly round-up of the latest in open-source software 👇
🎤 Interview With Ellen of Headway Maps
Hey Ellen! Thanks for joining us! Let us start with your background. Where are you from, where have you worked in the past, how did you learn to program, and what languages or frameworks do you like?
Hey! I grew up in California but the Pacific Northwest of the United States is home for me. I've worked at a few different places but most recently I spent 3 years working on the Google Maps Android client and nearly a year at GaiaGPS working on their Android app. I have a lot of Android experience but my heart is really in maps more generally.
I learned to program a long time ago. I'm the child of two programmers and they started me off young with a gamified programming system called Robocode, so Java was my first language. This was back in the Java 1.4 or 1.5 days (can't remember which) so it was a lot for an 8 year old Ellen to handle. I remember lots of tears and a few panic attacks about illegal operations that I had supposedly performed (I definitely asked my dad if I was going to jail).
Ellen circa 2022 is really into Rust but still struggles with the borrow checker occasionally. In general though it's easy to win over her heart with technologies that Work Every Time™.
What's an opinion you have that most people don't agree with?
I have a few! My worst opinion that's correct is probably that Java is actually a pretty good programming language for enterprise software development, followed closely by JSON being a bad way to encode data over the wire. I guess you could say my time at Google really got to me.
What’s your most controversial programming opinion?
My spiciest take is probably this one: if you write a python program that isn't permanently deleted from your hard drive within about 24 hours you've probably made a mistake.
This one isn't even true. When I teach programming I start people off in Python because I've found it's pretty forgiving and lets people focus less on syntax and more on thinking like a computer. I also understand it's the tool of choice for more than a few problem domains, but I enjoy the conversations that come up when I voice this. In my opinion there's really something to be said for limiting the size of codebases written in languages with Python-like type systems.
If you could teach every 12 year old in the world one thing, what would it be and why?
How to communicate well about their feelings. "I" statements. How to introspect. How to voice when they've been hurt without hurting others. I think the world would be a better place if everyone knew these things.
What are you currently learning?
Web frontend! It's fairly new to me, most of my professional experience is in Android development and most of my hobby development tends to either be embedded software development or backend things. Headway, being a web project, is really making me focus on this. :)
How do you separate good project ideas from bad ones?
This is a fantastic question. This is something I struggle with, but in the case of Headway specifically I try to remember why people are excited about it and ask myself if the project idea in question would make people more excited, less excited, or about the same.
Why was Headway started?
I've actually built two self-hostable web maps stacks in recent years, both called Headway. The first was built while I was working at Google. The code is lost to time. I think Google may have a copy still but I don't anymore because of a few OS reinstallations. It was mostly a set of bash scripts that you could use to preprocess geospatial data, bundled with a transit-focused frontend, all glued together with docker-compose. I started that project after de-googling my Android device and realizing OsmAnd+ didn't fit my needs because of poor transit support. I built this version of Headway mostly for personal use. Unfortunately Google decided to prevent me from releasing it, so I soon lost interest in the project and eventually ended up losing the source code.
The current iteration of Headway was started after I was laid off from GaiaGPS and found myself with unreasonable amounts of free time with no maps projects to fill that time with. I still feel there's a huge unmet need for a turn-key, batteries-included web maps stack. The OpenStreetMap ecosystem is incredible and so much work has been put into all of these tools I'm using, but I don't think anyone's put too much time into solving the user story of "I'm a vaguely technical person unfamiliar with the OpenStreetMap ecosystem of tools and I want to run my own web maps server so I can stop sending my data to $MAPS_CORPORATION". That's really the niche that Headway fills.
When I started the project I imagined it would be the kind of thing that people would run to cover a single city, but with the help of some contributors I've managed to stand up a demo server with global coverage at maps.earth. As the project progresses that will hopefully end up being more and more compelling as an alternative to other web maps apps, but for now there aren't a ton of features.
Where did the name for Headway come from?
The original iteration of Headway was very transit-focused so I picked a transit-related name that is also just a good name in its own right. The current iteration is focused less explicitly on transit but the name is still extremely good so I'm reusing it. It's probably the only thing that carried over from the project I built at Google. Nearly everything else is different.
How is maps.earth hosted right now? Can you give us a behind-the-scenes look?
I've caught some flak for this (rightly so, I feel?) but it's currently hosted behind Cloudflare. Hosting Headway at planet scale has some pretty onerous hardware requirements for someone who's between jobs (>=64GB RAM, CPU requirements depending on traffic) so I can only really afford to be on one machine in a single datacenter/region. I picked a box in Germany because it's a pretty central location and much of the OSM community is in Europe anyway, but it's unpleasant to use from North America without some kind of cache layer so I put Cloudflare in front of it, somewhat selfishly. I'm in the process of securing more permanent and privacy preserving hosting though.
Are there any overarching goals of Headway that drive design or implementation?
Ease of set-up and administration is a huge thing I strive for. It's also really important to me that Headway gets to the point where it's easy to use for a non-technical person.
What trade-offs have been made in Headway as a consequence of these goals?
For a long time the biggest cost-driver for Headway in terms of resources consumed was the geocoder, which is the piece of software that lets you search for places and addresses. It became clear at some point that we'd need to switch from Nominatim and Photon to another solution in order to affordably run Headway for the whole planet, and one of the top contenders was another geocoder named Pelias. Pelias requires data from Who's On First which is downloaded separately, by country code, unlike the rest of Headway which operates entirely on OpenStreetMap data. Headway's focus on easy set-up made this a really tricky migration because I didn't want anyone to need to even know what Who's On First is when they bring up a new instance. Requiring people to go download a different dataset would be really unfortunate. The benefits of using Pelias (namely it being much cheaper to run than Nominatim and Photon at scale) won out and I found a way to make the switch anyway.
What is the most challenging problem that’s been solved in Headway, so far (code links encouraged)?
I feel like we've really nailed the setup process, at least considering Headway being in such an early stage. Switching from bash scripts and makefiles to Earthly was a big win for repeatability. Preprocessing geospatial data using a bunch of different tools is tricky to do since the administrator shouldn't have to install any of those tools locally, so using containers simplifies things a lot from their point of view, and doing everything in a container with semantics similar to docker build allows for repeatability and cache-friendliness that's hard to get any other way.
Are there any competitors or projects similar to Headway? If so, what were they lacking that made you consider building something new?
I think competition is the wrong way to look at it, but the stack that runs Qwant Maps is probably the main open-source alternative to Headway in the web maps space. For mobile, apps like Organic Maps and OsmAnd+ are good alternatives. In terms of the feature set, most of these blow Headway out of the water, no contest, especially Qwant's stack. It's very pleasant to use, it's responsive, it's everything Headway strives to be from the end-user's perspective, but there's not very much documentation on how to administer it and I don't think it's as easy to set up as Headway is. There are a few other frontends for OpenTripPlanner and Valhalla but they don't tend to be mobile-friendly from what I've seen, and they don't tend to bundle geocoders. Both of these things are critical for the average end-user. The one I've found that is mobile-friendly is the v2 of the GraphHopper frontend. It has a ton of potential, and it's currently farther along than Headway in terms of the frontend, so it's another good project to watch. I don't think it's as easy to self-host though.
What is the release process like for Headway?
Currently we have a CI job that pushes images to ghcr.io, but in the future I'd like to make better use of tags and come up with a more coherent answer to this question. The project is only 3 months old though, so I'm going to cut myself some slack there.
Is Headway intended to eventually be monetized? If so, how?
I don't anticipate needing or wanting to monetize any part of the project once I secure better hosting for maps.earth.
What is the best way for a new developer to contribute to Headway?
First of all, I would love more contributors. I have lofty goals for this project and can't accomplish them alone. If you want to help out I'd probably recommend joining the matrix room, creating a GitHub issue or commenting on an existing issue to coordinate work. Headway is still in the early stages and I want to try and prevent duplication of work because that can be really demoralizing as a new contributor.
Where do you see the project heading next?
I want the project to be a fully functional directions and navigation solution that fully solves the problem of "I know where I want to go, and I need help getting there". After that, I'm interested in potentially tackling problems related to POI discoverability like categorical search. In other words: "I want coffee, what coffee shops are near me and how can I get to them?"
What motivates you to continue contributing to Headway?
The enthusiasm people have had for the idea of a turn-key solution for OSM-based web maps has been extremely motivating. The project has received a ton of attention which is very cool. Now I just have to deliver. :)
Are there any other projects besides Headway that you’re working on?
I occasionally contribute to the Godot game engine. I built the new audio mixing system for their 4.x branch, so if it gives you any trouble you can yell at me about it. I've been neglecting my Godot maintainer duties though, which I apologize for. Working on Godot has been pretty formative though and a lot of the values that the Godot project has have been inspiring in ways that I've tried to carry over to the rest of my work, especially around "working every time", approachability of code, simplicity of design and building something that's easy for the end-user to grok.
Do you have any other project ideas that you haven’t started?
So many. Ask any of my friends and they'll tell you how easily distracted I am by new projects, but I'm trying to stay focused on Headway for now.
Do you have any suggestions for someone trying to make their first contribution to an open-source project?
I cannot state this strongly enough: Do not underestimate the value of a high-quality bug report.
Often there will be bugs that plague open-source projects that the maintainers don't quite understand well enough to fix. Especially to someone who's new to open-source or software development in general it can be a really good experience to dive deep into one specific bug and figure out what exactly causes it (can you find a way to reproduce it every time?), what codepath that configuration or user input leads to, and what's wrong with that codepath or how it needs to be changed to work correctly without breaking other things. If you can fix the bug too, fantastic, but the value of getting 90% of the way there by submitting a high-quality bug report cannot be overstated.
A great example of the idea of debugging help being more important than code contributions is this two-line PR of mine. This is not a glamorous or impressive change by most metrics, but the work that other contributors and I did to figure out exactly what was causing the issue was immensely important to getting this bug fixed.
Want to join the conversation about one of the projects featured this week? Drop a comment, or see what others are saying!