I have to say that I see some quite unhelpful ad hominem attacks on the messenger here.
Ars Technica’s Jim Salter is not just some writer that wants to score some points here. You could argue he is not even a writer. Principally he is an IT guy, a sysadmin and consultant working in the storage space. He just happens to have a good pen too, unfortunately rare in the IT sector.
That good pen has made him able to write very compelling articles about ZFS and OpenZFS in particular that will have made thousands consider FreeBSD as their operating system.
By making complex elements of ZFS understandable to a wider audience he has done more for FreeBSD than most of us on this forum and definitely more than I ever did (or will be able to). When I read this article I read it as written by someone who cares about FreeBSD because he has to work with it on a daily basis. His favourite open source NAS,
XigmaNAS, is developed on top of FreeBSD.
I think he was just as surprised as I was to see that code that is demonstrably poor made it so far in the release process for FreeBSD 13 without any alarm bells. Many of the issues should have been filtered out in the review stage.
He could have done what many other journalists have done and just follow the narrative from one side and join in the mud slinging. Instead he chose to have the actual code checked to see if the claims were true. He spoke to many players, not only NetGate, or only Jason Donenfeld, or only Kyle Evans, or only Matt Macy. He tried to get a clear picture of what really happened.
Now, you can do two things. You can either become defensive and pretend the code wasn’t sloppy at all. Or claim that a committer shutting down parts of the review process himself is not a problem. Or deny that demonstrably bad code making it all the way into a second Release Candidate of an actual major RELEASE is a problem. Or deny that there are some unfortunate conflicts of interest between commercial parties, committers, reviewers and the community. Or deny that the FreeBSD community lacks the people, the finances or the time to do as much as it would like.
You can also try and turn this into an ‘OpenSSL moment’, a code quality disaster that became a turning point. One that will make the corporate giants that depend on FreeBSD realise that they have mostly been getting something for nothing and that it’s in their interest to make sure that the FreeBSD review process is in good health. Perhaps it requires more than just an occasional financial donation to the Foundation, perhaps donating staff time to have some of their developers do a couple of hours of ‘review service’ a month is more helpful.
I prefer to see it as the latter and hope FreeBSD comes out better from this. Hopefully a year from now we can look back and see that the project needed this crisis to come out stronger.