4 ms·

Nice blog post! I like the way this problem is approached and solved. Peeking under the "table" to see how the internals work is actually creative when trying t

Nice blog post! I like the way this problem is approached and solved. Peeking under the "table" to see how the internals work is actually creative when trying to fix things "upstream" on an upper abstraction layer. Unfortunately, I still don't love Tailscale. I do like it, a lot even. But their refusal to open-source all their clients (and the server) is baffling, especially considering that they have an employee contributing to Headscale, the community-led FOSS tailscale server. At that point just open-source the damn thing! Issues aside, it's still a great product. It actually felt like magic when I first used it in a way few technologies have.

jzelinskie 4y ago
I don't think that their choice to keep their server software proprietary is baffling. They're going to architect it so that it's easiest/best for their team to run which is not the same what's easiest/best for EVERYONE to run as is the typical goal of open source software.
- ceejayoz 4y ago
  There's two concerns: "can I run it myself", and "what does this security-critical third-party code do?" Open sourcing helps with the latter, even if the code's not very well optimized for general purpose use for the former case.
  - judge2020 4y ago
    The concern is that people will assume the OSS is for both scenarios, so even if you close issues and have a PR bot rejecting PRs, you'll still get both support tickets and (good|bad) PR from people trying to run the mainline system themselves. Supporting development on a made-for-self-hosting OSS project is the most user friendly option and allows them to avoid needing to handle the woes of public code.
    - daveidol 4y ago
      What about open sourcing the code with a README stating it is only for transparency, comes with no support, etc. and disabling GitHub issues?
      - Operyl 4y ago
        Users will still just spam the ticketing system. (Their support email).
ehPReth 4y ago
woah, they have an employee contributing to head scale now?
- skrtskrt 4y ago
  parent comment was edited, originally said "i thought they [Tailscale] hated that thing [Headscale]" they literally have on their website that they encourage people to use Headscale if they want an open source solution for the coordination server or just to learn how the internals work, they coordinate with Headscale maintainers to avoid breakages, and they don't discourage (but also don't require) employees contributing to Headscale
  - EMIRELADERO 4y ago
    > parent comment was edited, originally said "i thought they [Tailscale] hated that thing [Headscale]" I don't know where you got this from. I did not say that anywhere.
    - skrtskrt 4y ago
      you are not the parent comment to my comment - not sure if I used "parent comment" clearly
    - ehPReth 4y ago
      that was me! then i realized in the apps (except iOS?) they allow you to specify your own coordinator server... so if they hated them then they'd never build that in! so i removed that part of my comment before it had any replies that I was aware of edit: see comment below me; iOS now has that ability!
      - mihaip 4y ago
        Also possible on iOS starting in 1.38.1: https://tailscale.com/changelog/#2023-03-14-client https://tailscale.com/changelog/#2023-03-14-client
wg0 4y ago
There is some money (rightly and legitimately) to be made as well. We all are Craftsmen. We all deserve some. There's headscale[1] that fills the gap somewhat. [1] https://github.com/juanfont/headscale https://github.com/juanfont/headscale
bradfitz 4y ago
We'd planned to open source our control server but it wasn't in a good shape to release at the time we released the other stuff. Then Headscale came along and removed all need for us to do so. Headscale is _much_ easier for people to run & understand. The Tailscale closed source one is kinda a monster, built for a very different scale. We're busy enough without also helping people struggling to run our control plane. We'd rather focus the community (or the subset of the community that wants to run their own server) to use Headscale instead. And if you don't trust our server, use https://tailscale.com/blog/tailnet-lock/ https://tailscale.com/blog/tailnet-lock/ and then you don't need to trust us. Or run Headscale. :)
- EMIRELADERO 4y ago
  Thank you for your answer. Honestly I (and I suspect most here) wouldn't mind if the server was not easy to set up. The goal here would be transparency. It's true that, with lock, a user can run Tailscale without having to trust it. But it is still a good show of good faith and goodwill to have everything in your infrastructure be as transparent as possible, barring actual user data and service credentials. Same concept applies to the proprietary GUI clients. What's the rationale for not, at least, making their source code publicly available for reproducible builds (or, if those are too complicated to implement, the same goodwill and transparency I talked about)? You wouldn't even need to actually support the source releases.
  - bradfitz 4y ago
    FWIW, you can run open source Tailscale on macOS and Windows without the GUI. And you can already do reproducible builds of our Windows build: the `tailscaled.exe` service and `tailscale.exe` CLI are open source. Only the GUI systray client (tailscale-ipn.exe) is closed. For macOS and iOS, our development environment is kinda hell. It's great when it's finally working, but hard to get it set up and keep it in a happy place ... you have to get users into the right Apple teams for the right Network Extension Entitlements/notarization/etc, disable SIP to work on certain types of builds, be sure to clean up Xcode temp folders in ~/Library/ so the system doesn't pick up the wrong builds, etc, etc. Then you think things are good and in a few months a random keychain cert expires and you have to repeat the dance. Which sometimes involves a few macOS reboots for some reason. Yes, maybe we could say that the macOS/iOS/Windows GUI source releases are "not supported" but that will stop approximately nobody from asking questions anyway and consuming time. Plus I always come back to the question: if you care about open source so much, why aren't you running Linux? The common reply is: but trust! but security! but auditability! Know how many corporate/paying customers have asked for open source Windows/macOS/iOS GUIs? Zero that I've heard about. Their trust relationship is with other companies, not with codebases they don't have time to build or audit anyway. Or they trust us that all the interesting code (non-GUI wrappers) is open source anyway and read that. So, yes, we _could_ open source our GUIs. But it's not worth the resulting pain. It'd save me writing comments like this one, but then I'd be answering Xcode/mac build questions instead, and I'd much prefer writing this.

jzelinskie 4y ago

I don't think that their choice to keep their server software proprietary is baffling. They're going to architect it so that it's easiest/best for their team to run which is not the same what's easiest/best for EVERYONE to run as is the typical goal of open source software.

ceejayoz 4y ago
There's two concerns: "can I run it myself", and "what does this security-critical third-party code do?" Open sourcing helps with the latter, even if the code's not very well optimized for general purpose use for the former case.
- judge2020 4y ago
  The concern is that people will assume the OSS is for both scenarios, so even if you close issues and have a PR bot rejecting PRs, you'll still get both support tickets and (good|bad) PR from people trying to run the mainline system themselves. Supporting development on a made-for-self-hosting OSS project is the most user friendly option and allows them to avoid needing to handle the woes of public code.
  - daveidol 4y ago
    What about open sourcing the code with a README stating it is only for transparency, comes with no support, etc. and disabling GitHub issues?
    - Operyl 4y ago
      Users will still just spam the ticketing system. (Their support email).

ehPReth 4y ago

woah, they have an employee contributing to head scale now?

skrtskrt 4y ago
parent comment was edited, originally said "i thought they [Tailscale] hated that thing [Headscale]" they literally have on their website that they encourage people to use Headscale if they want an open source solution for the coordination server or just to learn how the internals work, they coordinate with Headscale maintainers to avoid breakages, and they don't discourage (but also don't require) employees contributing to Headscale
- EMIRELADERO 4y ago
  > parent comment was edited, originally said "i thought they [Tailscale] hated that thing [Headscale]" I don't know where you got this from. I did not say that anywhere.
  - skrtskrt 4y ago
    you are not the parent comment to my comment - not sure if I used "parent comment" clearly
  - ehPReth 4y ago
    that was me! then i realized in the apps (except iOS?) they allow you to specify your own coordinator server... so if they hated them then they'd never build that in! so i removed that part of my comment before it had any replies that I was aware of edit: see comment below me; iOS now has that ability!
    - mihaip 4y ago
      Also possible on iOS starting in 1.38.1: https://tailscale.com/changelog/#2023-03-14-client https://tailscale.com/changelog/#2023-03-14-client

wg0 4y ago

There is some money (rightly and legitimately) to be made as well. We all are Craftsmen. We all deserve some. There's headscale[1] that fills the gap somewhat. [1] https://github.com/juanfont/headscale https://github.com/juanfont/headscale

bradfitz 4y ago

We'd planned to open source our control server but it wasn't in a good shape to release at the time we released the other stuff. Then Headscale came along and removed all need for us to do so. Headscale is _much_ easier for people to run & understand. The Tailscale closed source one is kinda a monster, built for a very different scale. We're busy enough without also helping people struggling to run our control plane. We'd rather focus the community (or the subset of the community that wants to run their own server) to use Headscale instead. And if you don't trust our server, use https://tailscale.com/blog/tailnet-lock/ https://tailscale.com/blog/tailnet-lock/ and then you don't need to trust us. Or run Headscale. :)

EMIRELADERO 4y ago
Thank you for your answer. Honestly I (and I suspect most here) wouldn't mind if the server was not easy to set up. The goal here would be transparency. It's true that, with lock, a user can run Tailscale without having to trust it. But it is still a good show of good faith and goodwill to have everything in your infrastructure be as transparent as possible, barring actual user data and service credentials. Same concept applies to the proprietary GUI clients. What's the rationale for not, at least, making their source code publicly available for reproducible builds (or, if those are too complicated to implement, the same goodwill and transparency I talked about)? You wouldn't even need to actually support the source releases.
- bradfitz 4y ago
  FWIW, you can run open source Tailscale on macOS and Windows without the GUI. And you can already do reproducible builds of our Windows build: the `tailscaled.exe` service and `tailscale.exe` CLI are open source. Only the GUI systray client (tailscale-ipn.exe) is closed. For macOS and iOS, our development environment is kinda hell. It's great when it's finally working, but hard to get it set up and keep it in a happy place ... you have to get users into the right Apple teams for the right Network Extension Entitlements/notarization/etc, disable SIP to work on certain types of builds, be sure to clean up Xcode temp folders in ~/Library/ so the system doesn't pick up the wrong builds, etc, etc. Then you think things are good and in a few months a random keychain cert expires and you have to repeat the dance. Which sometimes involves a few macOS reboots for some reason. Yes, maybe we could say that the macOS/iOS/Windows GUI source releases are "not supported" but that will stop approximately nobody from asking questions anyway and consuming time. Plus I always come back to the question: if you care about open source so much, why aren't you running Linux? The common reply is: but trust! but security! but auditability! Know how many corporate/paying customers have asked for open source Windows/macOS/iOS GUIs? Zero that I've heard about. Their trust relationship is with other companies, not with codebases they don't have time to build or audit anyway. Or they trust us that all the interesting code (non-GUI wrappers) is open source anyway and read that. So, yes, we _could_ open source our GUIs. But it's not worth the resulting pain. It'd save me writing comments like this one, but then I'd be answering Xcode/mac build questions instead, and I'd much prefer writing this.