Open source is in Tailscale’s bones. After our seed round, when we were only five people making our initial open source plans, we each already had decades of experience writing and using community software. Personally, I’m a Unix programmer only because of a Slackware CD I picked up in Hong Kong in 1995. I owe my livelihood and a big part of my identity to open source. So it was natural to me that we would open source anything where the trouble involved in doing so was worth the value of releasing the code.
Beyond our instincts to build open source software, we also couldn’t have built Tailscale without it. Tailscale is heavily dependent on open source: WireGuard®, a tunneling protocol for establishing encrypted connections between peers, is at the core of Tailscale. And, like every other company these days, the vast majority of the code we use wasn’t written by us — we have dependencies on code written by thousands of other developers, and we want to give back.
How we came to open source our client software
Avery, Carney, and I started developing Tailscale in a closed source repository, because a private place to hack is vital in those early, fragile moments of a new project’s life. But we never discussed whether we would open source our work — we already knew we would. When Brad and Dave joined the team, they announced their first project would be open sourcing the client. We didn’t debate it, they just did it. Communication around deciding to do it was probably just a thumbs-up emoji in Slack.
As time has gone on, the value of open sourcing our client code has become more clear. Tailscale is a security- and privacy-focused product. As a company, as individuals, and as users of Tailscale ourselves, we care about providing a product that doesn’t use any more of your data than it needs to. By making the Tailscale clients open, you can see that we don’t collect your private keys. And by making Tailscale’s DERP servers open, you can see that we can’t capture your encrypted traffic. We don’t see your data and we don’t want to. We hope that keeping this code open increases trust and transparency in Tailscale because anyone can review the code and see that Tailscale really works the way we claim.
After releasing the Linux client as open source, we also considered open sourcing the Windows, macOS, and iOS GUIs. The main reason we decided against it is because everything about those UIs is a huge pain. The additional effort associated with open sourcing them is too much, especially for a team our size: The thought that someone might file an issue one day asking for help setting up a paid Apple Developer account… still makes me shudder. Fixing my own setup was frustrating enough, never mind fixing someone else’s. So we skipped open sourcing the client GUIs.
Later, we formalized this policy. At Tailscale, we release open source clients for open source operating systems. (I do not want anything closed source on my Linux and BSD machines.) Our Linux and Android clients are completely open source, including the GUI for the Android client. Clients for proprietary operating systems require more work to open source successfully, and right now we are not interested in taking the time to contribute open code to a closed system. So, for closed source operating systems like Windows, macOS, or iOS, the GUI wrappers are also closed.
Why our coordination server is closed source
We also discussed open sourcing the coordination server. This one took a little more thought. It was a natural progression, but what are the consequences? Would doing so hurt the business we were hoping to build, and the product we sold, whatever that ended up being? At the time, we concluded that it wouldn’t. Yet, one of the explicit reasons we built Tailscale is to give teams a safe network so they wouldn’t have to run complex services. (A lot of us used to, and no longer, work on Kubernetes.) Complex infrastructure, especially public-facing services are — if treated with proper scrutiny — monstrous efforts to secure and maintain. The coordination server is the thinnest public service we could conceive to allow private end-to-end encrypted tailnets, but it is still a lot of work to maintain.
Just because you shouldn’t need to run an infrastructure service doesn’t mean you don’t want to. We get that. Which is why we decided that open sourcing a small coordination server for homelabs, for people who insist on running everything themselves, was reasonable. I sympathize with the desire to DIY everything — for example, I ran my own mail server for many years, and many employees at Tailscale have extensive homelabs and self-host their own services. It’s a great way to learn how computers or complex infrastructure really works. From a business perspective, we wanted to open source a coordination server for the purpose of trust and knowledge dissemination. We wanted, and still want, to be in the business of running the coordination server for Tailscale, as people shouldn’t have to run it themselves (it is much harder than it looks).
Around the same time we open sourced the clients, we investigated how we could carve out and open source a simple, easy-to-run part of our coordination server — and we were confronted by what to a critical eye might be called a mess. The coordination server has required a great deal of experimentation. Nothing quite like Tailscale existed before we made it, and we did not know beforehand exactly how it should work. The codebase was littered with forgotten experiments, feature flags, and many other intricate pieces of code for dealing with things that homelabs would never face (like certain unnamed buggy OIDC providers).
Getting the coordination server ready for open sourcing was going to be a lot of work for a small team of ~5 also working on tasks like “make DERP work” and “stop crashing on iOS”. So it went on the very long TODO list for now.
The open source coordination server
But, before we could get around to open sourcing the Tailscale coordination server, Headscale was created!
Headscale is an open source alternative to the Tailscale coordination server and can be self-hosted for a single tailnet. Headscale is a re-implemented version of the Tailscale coordination server, developed independently and completely separate from Tailscale. It’s a great way to learn about the innards of Tailscale and experiment in a homelab. We love that our open source client documentation is readable enough to make a clean-room coordination server a fun project for the community to build.
We’ve been moving quickly at Tailscale over the past few months, growing our wonderful team as we continue our work toward our vision of building a better Internet, and two weeks ago we welcomed Kristoffer Dalby as the newest Member of our Technical Staff. Kristoffer is one of the principal maintainers of Headscale.
Although Kristoffer is joining Tailscale, we don’t plan to change how Tailscale works with Headscale. We’ll continue to support Headscale as a complementary project to Tailscale — with its own community of users and developers. We’ve already enabled Android users to use Tailscale clients with Headscale, and we give the project a heads-up (or a tails-up?) if there are upcoming changes to Tailscale APIs.
A key part of Kristoffer’s work at Tailscale will be interacting with the community surrounding Headscale, though generally we don’t require or prohibit Tailscalars from contributing to Headscale. The Headscale community has built a great project that works for situations complementary to Tailscale, and we hope they continue to develop it. I am personally very thankful to the Headscale team for crossing something off our TODO list. It is the best present you can give a programmer.
We know that someone could take the Headscale code and try to compete directly with Tailscale, but we hope they won’t. Instead, we hope that by being transparent about our security practices and helping ensure that Headscale remains compatible with Tailscale, you will either use Tailscale, or host Headscale for your own personal needs.
How Tailscale supports open source today
The beauty of open source is that you can get back more than you put in. We recognize that Tailscale doesn’t just build open source, but also builds on open source. We believe that open source is the past, present and future of software development.
Here’s a non-exhaustive list of the ways Tailscale actively supports open source development:
- Developing the Tailscale client and DERP servers in open source.
- Upstreaming changes to wireguard-go that we develop in Tailscale.
- Adopting projects originally developed by the community that our customers depend on, and that we were invited to maintain, like our Synology package or Terraform provider.
- Open sourcing internal projects that other organizations might find useful, such as: depaware for managing your Go dependencies, ToBeReviewed bot for auditing emergency production changes, and our internal security policies.
- Donating to projects we rely on. This includes WireGuard®, the open source protocol that Tailscale is built on; Let’s Encrypt, which we use to issue TLS certificates; and several other projects and maintainers whose work we depend on.
- Working with the Headscale project to ensure ongoing compatibility between the Headscale coordination server and Tailscale clients.
- Providing Tailscale for free to open source projects.
- Providing Tailscale Personal Pro plan free to Tailscale contributors.
- Encouraging Tailscalars to contribute to the open source projects they use for work or are passionate about, including Go, and NixOS.
To see the more exhaustive version, and learn more about Tailscale’s open source efforts, see our open source page.
Finally, we develop out in the open because we do want your input and contributions. If you’re interested in contributing, be sure to follow Headscale’s contribution guidelines, along with Tailscale’s contribution guidelines and code of conduct.
David Crawshaw
