4 ms·

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”

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.

p_l 3y ago
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.
- SequoiaHope 3y ago
  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).
  - smoldesu 3y ago
    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.
    - TaylorAlexander 3y ago
      > 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.
      - smoldesu 3y ago
        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.
        PLG88 3y ago
        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.

p_l 3y ago

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.

SequoiaHope 3y ago
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).
- smoldesu 3y ago
  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.
  - TaylorAlexander 3y ago
    > 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.
    - smoldesu 3y ago
      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.
      - PLG88 3y ago
        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.