The client is completely open source on open source operating systems. The repository you linked to is 100% of the client for Linux, and there's another repository for Android.
As a bonus you can run the open source client on closed source OSs, i.e. macOS, WSL2.
We never open sourced our coordination server because Headscale beat us to it.
> We never open sourced our coordination server because Headscale beat us to it.
From what I understand, Headscale has not all the capabilities of Tailscale’s server.
Excerpt from Headscale’s README:
> Headscale's goal is to provide self-hosters and hobbyists with an open-source server they can use for their projects and labs. It implements a narrow scope, a single Tailnet, suitable for a personal use, or a small open-source organisation.
Sure, and that seems very reasonable? If you're running your own coordination server, stand one up for each tailnet you want to run. Different software has different operating requirements, and headscale is building to requirements that are better suited to someone running their own.
E.g. our internal coordination server has a bunch of goop in it for talking to a couple of AWS services we use. No-one wants that.
Personally I just feel better recommending something to people if I know the service is 100% open source. I don’t care if the code includes stuff “no one wants”. I’m a talescale user and I love it, but I do feel a bit weird using and recommending a service with important bits that are proprietary. At the same time, part of why I like the service is that it’s dead simple to use. I imagine headscale takes more effort to set up and use. So I use the proprietary client, and just kinda feel weird about it. If it were open source I wouldn’t have those reservations.
Having recently put some work to essentially sell headscale-as-a-service (to clients that for various reasons wouldn't want to pay tailscale anyway even if they found the service great), about only issues between tailscale and headscale are that headscale got a bit of cruft regarding internal models that are currently being worked on, and for practical purposes it shows up in a bit harder time handling ACLs and no tailnet-peering support.
It strikes me that if you had to build a service platform, then that shows me there is a difference in the systems from a user perspective. I am a very technical user but I do NOT want to spend my time configuring network stuff, that's the whole reason I use tailscale. The fact that headscale is self hosted immediately creates barriers that tailscale does not have. I already host several web servers and it a huge pain that I want to do less of. (Everything is fine on digitalocean until some update does something weird and I have to spend a few days debugging it).
It's a networking service. Inherently, there are things you will be able to orchestrate easier from a centralized perspective than a self-hosted one.
You're correct to nit-pick the difference between Headscale and Tailscale as software products, but I think this is splitting hairs. There are perfectly valid reasons why both are different. Given Tailscale's featureset as a product, it's not reasonable to expect it's self-hosted alternative to be a pushbutton replacement.
> Given Tailscale's featureset as a product, it's not reasonable to expect it's self-hosted alternative to be a pushbutton replacement.
Yeah, exactly. That’s why I started this thread by disagreeing with the tailscale employee who said “we don’t need to open source tailscale because headscale already exists.”
Headscale and tailscale are not the same. I want to use tailscale, and I would love it if tailscale was open source! If truly the only reason they’re not open sourcing tailscale is that headscale exists, they’re kind of missing that existing tailscale customers will not all see headscale as a replacement but might still prefer open source.
I don't think it is possible to Open Source the entirety of Tailscale, is what I'm saying. Their product is deeply intertwined with system providers, autoscalers and load balancers.
There's a world in which they "open source" Tailscale in the form of a massive K8s spec, which costs ~$400/day to operate for a single user. But... nobody would really use it. If Headscale offers most of the features with much less overhead/configuration, it's a perfectly fair (even respectable) recommendation to make. Replacing what Tailscale actually does is not entirely what most Tailscale users want.
If you are the sort of Business Grade™ user who needs access to this tech, Headscale is BSD-licensed and you can make your own solution with little effort. Or you could pay Tailscale for an enterprise license and skip this whole headache from the start.
If you look at Tailscale as a wrapper for Wireguard that sells subnet address space instead of software, it makes a lot more sense. There isn't much for them to open source, really. It's like shaking your fist at Mullvad for not releasing their Terraform scripts and bootstrapping code.
I believe the best approach is to have a completely open source core product which its own API. You can then have a propriatery multi-tenant platform (incl. hosting, mngt, patching, support, 3rd party integrations etc) which interacts with the open source API. This provides the best of both worlds.
fwiw, I work for a company with both an open source and proprietary product and this is how we do it.
> The client is completely open source on open source operating systems.
IOW it's by and large the GUI part that is not open source. Personally I prefer to run it as a system LaunchDaemon than a user LaunchAgent anyway.
> We never open sourced our coordination server because Headscale beat us to it.
I seem to recall reading that another reason was that there was intent to open source it but it made little sense as far as running it because its code was written for (and coupled to) Tailscale's heavy duty infra. So Headscale beat Tailscale to it by providing not just code but code that could work on much wider contexts.
the GUI part is also open source (I went looking recently in hope of adding support for `tailscale switch` on android). It's just in surprisingly weird toolkits :)
Their clients consist of a daemon and, optionally, a GUI. The daemon is open source. The Android and Linux GUIs are open source but the Windows, iOS, and macOS GUIs aren't.
> We never open sourced our coordination server because Headscale beat us to it.
Can you elaborate? This sentence makes no sense to me. Headscale is not tailscale, so they didn't "beat you to it", they just released a competiting product.
They’ve been really good about promoting and supporting headscale. I feel like this comment from Bradfitz gives a nice little insight into the reality of open sourcing code.
I'm a big open source advocate and would be heavily critical if the Linux and Android clients weren't open source, but I don't see how a person can complain about tailscale being closed source on an operating system like Macos or iphone or Windows, when the entire platform practically is closed. Such person clearly does not have a problem or concern about using proprietary and closed systems. I think tailscales position here makes a lot of sense, and if it bothers somebody because they see the tremendous value in open source, I hope it would cause them to consider their platform of choice.
The client is completely open source on open source operating systems. The repository you linked to is 100% of the client for Linux, and there's another repository for Android.
As a bonus you can run the open source client on closed source OSs, i.e. macOS, WSL2.
We never open sourced our coordination server because Headscale beat us to it.