Netgate is weirdly hostile to a lot of opensource stuff, which should be strange given what all their tech is built on top of. This has been going on for years. (see opnsense etc)
It does everything my pfSense install did and then some. Eg DNS blocking and IP blocking are built-in instead of needing a pfblockerng-style plugin.
The only thing I've found worth complaining about is the accordion sidebar UI thing makes it hard to middle-click-open new browser tabs, because it's not obvious which entries in the sidebar are actual pages and which are fake hyperlinks that just expand the accordion submenu.
No one has to be the bad guy here or end up hostile to open source.
I think, we all should be way more cool headed. Email doesn't contain the tone and it is very easy to formulate something in a bad way when exhausted or upset. Some people use very strong words that considering their usual style aren't nearly as strong in reality.
In this case, the great question is, how did such a bad code (according to Jason) land in the code base at all? Don't other people look at it? Do the FreeBSD developers ignore concerns of other fellow developers until it blows up to beyond community communication circles?
Must have: in-kernel WireGuard for NetGate products.
Nice-to-have: a general-purpose FreeBSD kernel WireGuard.
The scope crept, and a piece of code that might have been fit for some purpose (whatever limitations NetGate has for its network stack, like "no jumbo frames", etc) was recast as fit for all purposes.
I guess Colin would have some insight about the process by which a ports-grade kernel module gets put on track for release in the kernel itself.
My take on this is that absolutely no part of the development process that led up to this is Jason's problem. It is not Jason's job to understand or assist or comply with NetGate's product development process; his concern seems to have been, justifiably, exclusively the proposed FreeBSD OS feature. I get the sense that a lot of the friction here comes from pfSense-types thinking that any part of pfSense is everyone's problem.
My question basically is: "How is it possible, the code of such quality was even seriously included in a branch of FreeBSD that would have been released if nobody would step in?" (That is if I understand the whole thing correctly and Jason's assessment is correct.)
This system isn't foolproof, but it generally works very well. There have been discussions about moving to a "mandatory review" model, but there is concern that this might overly slow down development in the context of a volunteer-run project.
This was made worse by the unfortunate timing -- the final release candidate is just 3 days away. Any other time, we would have gone slower, had more discussion, et cetera; unfortunately this turned into an emergency.
Basically, all the opensource claims don't amount to a hill of beans, because you cannot compile pfsense yourself, even for their hardware.
(I'm sure someone could come up with the link)
The firewall should be the ONE place where this would be critical. You have to run their binary.
I also think it phones home.