Hacker News Reader

> I understand that [Headscale] is (unofficially?) supported by Tailscale these days

I'm not sure if it clears the bar of official, but it seems to be not-unofficial. They were planning on open-sourcing a coordination server once they cleaned the code up, but then decided that there was no point in doing so due to Headscale. On top of that, one of the primary maintainers of Headscale works at Tailscale now.

Source: https://tailscale.com/blog/opensource/

Sounds like someone may have thought the code for Headscale "coordination" server was higher quality than the code for Tailscale "coordination" server. If the later needed to be "cleaned up". Maybe there were things in that code Tailscale did not want the public to see.

Funny how Wireguard's original pitch was that it was smaller and simpler than OpenVPN or other alternatives. Now people are commercialising some complex GUI on top of it. More "features" on a steady basis. Some of them might be closed source but pay no mind. "Worse is better".

There's absolutely nothing stopping you from just using WireGuard if you want to. I don't understand the mentality of complaining about a completely separate entity offering extra features just because you don't personally have a need/want for them.

I don't get the issue with having a tight secure underlying vpn protocol, and others building on top of it to improve deployment and setup/management side of it.

Agreed. I don't think people recognize how much of a pain cert management/orchestration can be, and Tailscale's value adds like MagicDNS and managing/creating SSH keys for logging into servers are significant QoL improvements. Sure, you can do that stuff on your own, but I simply don't want to.

I do run my own Wireguard VPN at home. It’s not terrible for a few clients with a set home dyndns or static IP.

It has basically taught me how the small building blocks for Wireguard work. And how for anything remotely more difficult or multi-user I’d absolutely want something more robust handling the orchestration and management of the network. It is very hard to get right and can be very complicated to keep everything in sync. There is definitely value to what Tailscale, et al deliver.

I’m happy that I can run a simple version myself, but only after doing that can you really appreciate where the dragons be.

I don’t really think your comment is a fair take. While it very well may be “actually what happened”, there are a lot of other reasons to hire from and foster your community rather than try to compete with them. It’s possible Headscale just does a better job at capturing a clean boundary between a public open source tool and a proprietary backend and Tailscale might have just liked what they saw, said well this is essentially how we’d do it, and made the smart decision to put the person on payroll instead of taking advantage of the community.

Furthermore IDK what your gripe is about management tools popping up on top of Wireguard. That’s what Jason wanted, for one. The downstream application use cases are kept out of the secure and simple core. Two just use vanilla Wireguard if you don’t need Tailscale. Are you an OpenVPN shill?

> Maybe there were things in that code Tailscale did not want the public to see.

There are a ton of things you do in closed source “only my small team touches it” vs open source.

Even if it’s just comments, notes files and stuff like that. For example I often leave project notes in comments and address people etc.

(Tailscalar)

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.

(emphasis mine)

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.

Source: https://tailscale.com/opensource/

By gui i think the above posts meant the tailscale web UI for auth and account management.

Nope I meant the macOS and iOS UI (possibly more)

> 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.

https://news.ycombinator.com/item?id=32470615

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.

> even though I understand that it is (unofficially?) supported by Tailscale these days.

https://tailscale.com/blog/opensource/

I was drawing attention to this line in your README:

> This project is not associated with Tailscale Inc.

:)

Ah, I was not stating anything else than linking their blog post :)

I am pretty sure they would have eventually published a control server.

We just happened to be quicker (and come up with a great name, IMHO).

Tailscale hired the guy who wrote Headscale, for him to work on software, so they're sponsoring the programmer who's working it, but it's not "Tailscale" software, and they have no warranty, express or implied, because it's not theirs. It's its own project.

Reverse nit, there is a UI for headscale:

https://github.com/gurucomputing/headscale-ui

Granted, that's also not tailscale.

> Granted, that's also not tailscale.

I take your point, but they're technically not Headscale either!

Yes there are a few third-party UIs for Headscale but now we are 3 times removed from Tailscale :)

Ah, looks like there are several! And they're all third-(third-)party...

> https://headscale.net/web-ui/

> Tailscale isn't really "open source" ...

As you would have read a few paragraphs further on in TFA they describe the situation with much more clarity:

"Tailscale uses the open source WireGuard protocol, and its client apps are open source, but the coordination services are proprietary."

> significant part of the value proposition of Tailscale is their very well designed web UI which makes managing their Wireguard based networks very user friendly.

I think this is an opinion. I don't use the tags/rules, and I literally only use their website to complete the oauth flow to auth a new client. Headscale is a perfectly functional replacement of Tailscale for me.

I interviewed there and asked about this and they said their coordination server and (and other UI features UI) are almost completely about satisfying very demanding enterprise customers, with one of the major concerns being the performance particularly of applying ACL rules across huge complex networks.

They said there would be a lot of code cleanup to open source the coordination server, and it's not been completely ruled out but Headscale is such a nice alternative for those that care about an open source coordination server that it doesn't seem to be a big motivation.

I don't mean to downplay the value of Headscale, but only to make the point that it's quite a different beast to the Tailscale SaaS experience.

For the record I think Headscale is an impressive project.

Perhaps narrowlink doesn't want to draw attention to this: https://github.com/narrowlink/narrowlink/blob/main/LICENSE.m...

What’s to draw attention to there? MPL and AGPL are both Open Source licenses.

> For companies or organizations whose policies are not compatible with the AGPL-3.0 license, we offer a separate business license. To inquire about the business license or discuss licensing options, please contact us at opensource@narrowlink.com.

Perfectly fine, and perfectly open source.

I know, I'm just suggesting what GGP might have been referring to

One's not usable in any corporate context, especially one that's so low level in the network stack. The doc post is a content marketing post (in this case, for SEO hacking specifically) disguised as a technical comparison, so they clearly have monetisation in mind.

In other words, disingenuous advertising.

Why isn’t AGPL usable?

It isn't usable if your goal is to take the open source project and turn it into a component of your own commercial product that is for sale and is closed-source.

But I think more than half of the people in this thread have the opposite opinion (that if it isn't open source, it isn't usable) and I tend to agree with that.

AFAIK if you are the owner of the copyright / original author you can use it however you see fit. The license applies to third parties.

How would applying patches from the AGPL version affect your code?

To me the AGPL thing feels like all or nothing.

it's also isn't usable if you're going to need to modify it, even if something trivial like patches to work on your internal historically complicated stack, then due to legal bugs in AGPL you might find yourself never compliant with the license.

That they're licensed under two different open source licenses?