Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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



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.


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


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.


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


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?


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.


Here's what I posted to our blog when this question came up:

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.


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


Presumably there’s still overhead involved in being part of the WireGuard organization, no? If there wasn’t, then the only difference between being in it and not is branding.

More importantly, without having already tried it, it’s hard to predict how much overhead there will be.

Since CloudFlare had a (self-imposed) deadline, working fast had to take priority over optics. After all, the project can always be folded into the WireGuard organization later.


Oh, I missed that comment, thank you. That makes sense.



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.


No worries; thanks for letting me know.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: