What Volunteer Open Source Taught Me About Remote Teams

For the past year, I’ve been leading the development of Maglev, a complete rewrite of the OneBusAway server. The original system was built in Java over a decade ago, and while it still works, it’s showing its age. Maglev is a greenfield project in Go that will eventually replace it entirely.

The challenge isn’t the technology. The challenge is that my team is almost entirely volunteers, scattered across time zones from Seattle to Europe to Asia. Nobody is getting paid. Nobody has guaranteed availability. Any volunteer could disappear tomorrow because their day job got busy or they just lost interest. This is not how you’d staff a project if you had the choice.

But you work with what you have, and over the past year I’ve learned some things about making distributed volunteer teams productive that I think apply to remote work more broadly.

Daily standups don’t work when half your team is asleep and the other half has day jobs. I tried async standups for a while, but participation was inconsistent. What actually works is a dedicated Slack channel where everyone posts what they’re working on, and where I’m relentless about asking for updates. Not aggressive, just persistent. When someone goes quiet for a few days, I check in. When progress stalls, I ask what’s blocking them. The channel becomes a running log of project activity that anyone can catch up on.

Critical path work must be held for core team members. Everyone on the project is a volunteer, but there’s a difference between the handful of people who’ve been around for years and have proven their reliability, and new contributors who are still figuring out the codebase. If a task is blocking other scheduled work, it needs to be owned by someone with a track record. New contributors are a force multiplier for parallel work, but they can’t be the bottleneck. Let them prove their skill and reliability on non-blocking tasks before putting them on the critical path.

A rigorously defined vision pays dividends with distributed teams. When everyone can’t be in the same room hashing out requirements, having a written vision document that everyone has read and bought into becomes essential. Early volunteer efforts need to align with where the project is going, or you end up with throwaway work that demoralizes the contributor and wastes everyone’s time. The vision doc isn’t a straitjacket, but it’s the shared understanding that keeps a dozen people in different time zones pulling in the same direction.

Getting to a dogfoodable state as fast as possible changes everything. Theory is cheap. Running software reveals assumptions. Once we had a version of Maglev that could actually power a real transit app, testing became concrete. Every pull request gets tested against real GTFS feeds. Hidden bugs surface. Integration problems become obvious. Contributors can see their work doing something real, which is vastly more motivating than watching test suites pass.

Write down every decision. In-person teams can rely on hallway conversations and shared context. Distributed teams can’t. Every meaningful decision needs to end up in a GitHub issue or a wiki page, not buried in a Slack thread that nobody will scroll back to find. This means backfilling documentation after real-time discussions, which feels tedious but pays off constantly. Six months from now, when someone asks “why did we do it this way?”, the answer is a link instead of tribal knowledge that may have left the project.

Accept a certain loss of control. This is the hardest one. A distributed team of volunteers will make mistakes that an in-person team of full-time employees wouldn’t. Requirements will be misunderstood. PRs will miss edge cases. Documentation will lag. You can minimize this, but you can’t eliminate it. When it happens, treat it as a learning experience and ask yourself what you failed to communicate clearly. If a volunteer misunderstood the requirements, that’s your failure as the maintainer, not theirs as a contributor.

The interesting thing is that most of these lessons apply to remote work generally, not just volunteer projects. The volunteer context just makes the failure modes more obvious. When you can’t rely on someone’s contractual obligation to show up and do work, you have to be more intentional about communication, documentation, and task allocation. When time zones make synchronous communication expensive, you have to write things down.

Maglev is now at the point where we’re dogfooding it for real users. We got here with an almost entirely volunteer team, no corporate backing, and no funding. It took longer than it would have with a full-time team, but it’s happening. And the practices we’ve developed to make it work are ones I’d use on any distributed team, paid or not.