5 ms·

You've built a product (warp) based on Wireguard and refused to work with the upstream project - so saying that you're pushing standards is far more nuanced tha

by tw04 8y ago

You've built a product (warp) based on Wireguard and refused to work with the upstream project - so saying that you're pushing standards is far more nuanced than you make it seem - at best. https://news.ycombinator.com/item?id=19500725 https://news.ycombinator.com/item?id=19500725

floatingatoll 8y ago
Forking an upstream project to implement decisions without upstream’s consent is a tried and true open source software process, implemented by thousands of projects over the years. Claiming that they don’t support standards, solely because they don’t support another implementation of those standards, is incorrect and inflammatory.
- tw04 8y ago
  > Forking an upstream project to implement decisions without upstream’s consent is a tried and true open source software process, implemented by thousands of projects over the years. Claiming that they don’t support standards, solely because they don’t support another implementation of those standards, is incorrect and inflammatory. If upstream is doing something you don't like and refusing to work with you, sure. When upstream actively petitions you to not fork, asks you politely to work together, and you refuse to work with them, that is far, far from a "tried and true open source software process". That creates a fissure in the community and it generally ends up poorly for everyone involved. My comment is far from inflammatory, it's a statement of fact, and something cloudflare has refused to acknowledge or respond to. Which just further drives the point home that they aren't acting in good faith.
  - StavrosK 8y ago
    Can/has anyone from CloudFlare commented? This refusal to work with WireGuard has left a bitter taste in my mouth from a company that I otherwise like.
    - jgrahamc 8y ago
      https://news.ycombinator.com/item?id=19500725 https://news.ycombinator.com/item?id=19500725
      - StavrosK 8y ago
        Hmm, I have seen that post, do you mean a specific comment? The only relevant one I can see is the license one, which has a reply from Jason. EDIT: eastdakota filled me in, thanks John.
        jgrahamc 8y ago
        No worries; thanks for letting me know.
    - eastdakota 8y ago
      Here's what I posted to our blog when this question came up: https://blog.cloudflare.com/boringtun-userspace-wireguard-rust/#comment-4401651800 https://blog.cloudflare.com/boringtun-userspace-wireguard-ru... We communicated with Jason throughout the process and have a ton of respect for him and the entire WireGuard community. In the short term, we need the flexibility to quickly update BoringTun's code base to support the project we built it for. That's harder when you need to coordinate with people outside Cloudflare and when we need to move as fast as we plan to. However, we really believe in Open Source and want the WireGuard community to thrive. We licensed the code very openly (3-paragraph BSD) and WireGuard may choose to fork it. If they do, we'll support it and plan to contribute any improvements in our own fork back. Over the long term, I think we're very open to merging this back into the upstream project.
      - StavrosK 8y ago
        Oh, I missed that comment, thank you. That makes sense.
      - tw04 8y ago
        I guess that doesn't make sense to me. If Jason offered you your own sub-project to run with, why can't you "move fast"? >I thought the invitation to put their engineers as the head of a WireGuard subproject was a cool invitation, but alas. https://lists.zx2c4.com/pipermail/wireguard/2019-March/004048.html https://lists.zx2c4.com/pipermail/wireguard/2019-March/00404... I mean no offense, but the response comes off as corporate approved PR. "We need to move fast" when you haven't actually even tried engaging with the parent project and have no idea whether or not it would prohibit "moving fast" is disingenuous IMO.
  - floatingatoll 8y ago
    While the fissure you describe as a guaranteed outcome is certainly likely in many such scenarios, you're missing the point: Implementing a standard without regard for the beliefs of other implementors is an action that supports a standard. Refusing to work with others does not implicitly harm a standard. You assert that refusing to cooperate with another implementor is guaranteed to harm a standard. It is not guaranteed at all. DJB has not destroyed DNS. BoringSSL has not destroyed TLS. A thousand reimplementations of standards in Rust have not destroyed a thousand standards. You clearly believe that Cloudflare is acting in bad faith, and are constructing a worldview out of assumptions that you declare instead are facts. While I respect your right to hold those views, I do not respect your declaration of future outcomes as fact.
    - tw04 8y ago
      >DJB has not destroyed DNS. DJB didn't fork Bind and then refuse to work with them. >BoringSSL has not destroyed TLS BoringSSL didn't fork OpenSSL and then refuse to work with them. About the closest modern comparison would be OpenOffice vs. LibreOffice - which created a complete mess like I mentioned before. Except even THAT is a bad comparison because LibreOffice only forked when they were FORCED to fork.
      - floatingatoll 8y ago
        I was unable to parse this reply in the context of "do forks harm standards?" as we're discussing in this thread. What standard came to harm as a result of LibreOffice forking from OpenOffice?
mr_toad 8y ago
From what I can see (correct me if I’m wrong) this is an implementation of the WireGuard protocol in Rust. WireGuard is written as Kernel Module in C, with a GPL licence; BoringTun is a user space program written in Rust with an MIT licence. So it’s not really even a fork.

by tw04 8y ago

floatingatoll 8y ago

Forking an upstream project to implement decisions without upstream’s consent is a tried and true open source software process, implemented by thousands of projects over the years. Claiming that they don’t support standards, solely because they don’t support another implementation of those standards, is incorrect and inflammatory.

tw04 8y ago
> Forking an upstream project to implement decisions without upstream’s consent is a tried and true open source software process, implemented by thousands of projects over the years. Claiming that they don’t support standards, solely because they don’t support another implementation of those standards, is incorrect and inflammatory. If upstream is doing something you don't like and refusing to work with you, sure. When upstream actively petitions you to not fork, asks you politely to work together, and you refuse to work with them, that is far, far from a "tried and true open source software process". That creates a fissure in the community and it generally ends up poorly for everyone involved. My comment is far from inflammatory, it's a statement of fact, and something cloudflare has refused to acknowledge or respond to. Which just further drives the point home that they aren't acting in good faith.
- StavrosK 8y ago
  Can/has anyone from CloudFlare commented? This refusal to work with WireGuard has left a bitter taste in my mouth from a company that I otherwise like.
  - jgrahamc 8y ago
    https://news.ycombinator.com/item?id=19500725 https://news.ycombinator.com/item?id=19500725
    - StavrosK 8y ago
      Hmm, I have seen that post, do you mean a specific comment? The only relevant one I can see is the license one, which has a reply from Jason. EDIT: eastdakota filled me in, thanks John.
      - jgrahamc 8y ago
        No worries; thanks for letting me know.
  - eastdakota 8y ago
    Here's what I posted to our blog when this question came up: https://blog.cloudflare.com/boringtun-userspace-wireguard-rust/#comment-4401651800 https://blog.cloudflare.com/boringtun-userspace-wireguard-ru... We communicated with Jason throughout the process and have a ton of respect for him and the entire WireGuard community. In the short term, we need the flexibility to quickly update BoringTun's code base to support the project we built it for. That's harder when you need to coordinate with people outside Cloudflare and when we need to move as fast as we plan to. However, we really believe in Open Source and want the WireGuard community to thrive. We licensed the code very openly (3-paragraph BSD) and WireGuard may choose to fork it. If they do, we'll support it and plan to contribute any improvements in our own fork back. Over the long term, I think we're very open to merging this back into the upstream project.
    - StavrosK 8y ago
      Oh, I missed that comment, thank you. That makes sense.
    - tw04 8y ago
      I guess that doesn't make sense to me. If Jason offered you your own sub-project to run with, why can't you "move fast"? >I thought the invitation to put their engineers as the head of a WireGuard subproject was a cool invitation, but alas. https://lists.zx2c4.com/pipermail/wireguard/2019-March/004048.html https://lists.zx2c4.com/pipermail/wireguard/2019-March/00404... I mean no offense, but the response comes off as corporate approved PR. "We need to move fast" when you haven't actually even tried engaging with the parent project and have no idea whether or not it would prohibit "moving fast" is disingenuous IMO.
- floatingatoll 8y ago
  While the fissure you describe as a guaranteed outcome is certainly likely in many such scenarios, you're missing the point: Implementing a standard without regard for the beliefs of other implementors is an action that supports a standard. Refusing to work with others does not implicitly harm a standard. You assert that refusing to cooperate with another implementor is guaranteed to harm a standard. It is not guaranteed at all. DJB has not destroyed DNS. BoringSSL has not destroyed TLS. A thousand reimplementations of standards in Rust have not destroyed a thousand standards. You clearly believe that Cloudflare is acting in bad faith, and are constructing a worldview out of assumptions that you declare instead are facts. While I respect your right to hold those views, I do not respect your declaration of future outcomes as fact.
  - tw04 8y ago
    >DJB has not destroyed DNS. DJB didn't fork Bind and then refuse to work with them. >BoringSSL has not destroyed TLS BoringSSL didn't fork OpenSSL and then refuse to work with them. About the closest modern comparison would be OpenOffice vs. LibreOffice - which created a complete mess like I mentioned before. Except even THAT is a bad comparison because LibreOffice only forked when they were FORCED to fork.
    - floatingatoll 8y ago
      I was unable to parse this reply in the context of "do forks harm standards?" as we're discussing in this thread. What standard came to harm as a result of LibreOffice forking from OpenOffice?

mr_toad 8y ago

From what I can see (correct me if I’m wrong) this is an implementation of the WireGuard protocol in Rust. WireGuard is written as Kernel Module in C, with a GPL licence; BoringTun is a user space program written in Rust with an MIT licence. So it’s not really even a fork.