I want to make this snappy and the TLDR is in the subject. This is not to fish for solidarity or discussion at length, but if you have questions I will try to answer them below.
On Friday, September 5 at 21:55, I got a no further signed mail from a "FreeBSD Core Team Secretary":
QuoteDue to repeated behavior that violates our community's code of conduct,
your access to FreeBSD Project services (Bugzilla, Wiki, Phabricator,
and the mailing lists) is suspended for three months, until the end of
November 2025.
It's now two weeks into December and I'm still blocked. I appreciate good rules as long as everybody also follows them, but in the many years I've contributed to FreeBSD I've seen exceptions and loopholes time and again. I don't wish to see them any longer.
According to the mail this is in direct relation to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283795 which is basically a continuation of a bug caused by https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701 where the core team made clear that proper bug reports must be raised. To me it seemed wrong that the relevant topic was then still ignored for roughly half a year until a different user and not a committer found and fixed the issue. Only then it seemed right to answer and correct users asking what is going on?
Perhaps the ban is deserved and I've gladly done my time, but I still don't know what the punishment of an external contributor is meant to do other than give me a number of sleepless nights and the cozy feeling on a Friday evening that I'm a very bad person (thanks I guess). If this is how contributors are structurally treated I don't see the point in contributing. Or maybe me throwing the towel is the goal?
I've moderately contributed to FreeBSD roughly since 2013 with very mixed success. The key was to persistently ask for committers all the time because a patch is still nothing compared to the commit it will be going into the tree which takes a couple of seconds. I've seen many committers come and go. My patches do resemble the average quality of FreeBSD committers submissions. I've studied computer science and helped run OPNsense as a volunteer for many years. My patches are now committed by people who have been on the project for much shorter periods of time if they are not being ignored. Commits being made by others don't follow standards I was trained on in the early years of my tenure in FreeBSD.
There is a lot more to tell here but I know it's a waste of time given what I've been through. At some point the self-fulfilling prophecy of me being an unlikable, unreasonable, inept and uncooperative person/coder started by FreeBSD adjacent enthusiasts around 2015 had taken a life of its own. I've told several people and core team members about a pattern of neglect and abuse towards me, but it seems that throwing me under the bus is the easiest solution for everyone involved to this day. I'm ok with that, but I am free to say that I don't very much enjoy it. A number of people from FreeBSD are actually active in the OPNsense scope these days. PfSense uses code contributed by OPNsense. We are all benefiting from each other. The situation is perfectly natural for open source efforts, so I don't understand why I am not being tolerated. I'd really like to hear the explanation for a 3 year old but upon asking I haven't gotten any answer either.
So now I'll have a lot more time to build community and code and releases in OPNsense and that's a good thing. People can look up to our standards instead. Use our patches or leave them. Be friendly and cooperative or not. It will be neat and we will know it's because we're doing great things here together. :)
Cheers,
Franco
For what it's worth: Love to have you around franco. Very much appreciate all the effort and time you invest in Opnsense (including the forum)!
Franco, I've been following a thread of a bug at FreeBSD for a while and I've seen what you are describing. If someone sometime give you an explanation it will be a 3 year one. Can't be other way.
It is sad that an open source community has to work with that tension.
Well, that's a mess happening in Linux too, many a video on the subject reading out the mailing list. Too bad, their loss, and thank you for the past work.
Will OPNsense fork BSD so that they can add in the work that's important (and being ignored), or will they continue using the main branch? Are any of the current forks worth moving towards for OPNsense?
Too bad the amount of work to move to Linux is on the scale of extremely large, moving to Debian or Alma might be worth doing as BSD will continue the slow march to obscurity. Just waiting for Broadcom to buy up all of BSD, we know where that would go. If it can be done to Redhat and Centos, it can be done to BSD, and Broadcom would do Broadcom things. Remember when Oracle did part of that? Those were the days.
I've been out of IT for a long time. Your description brought back memories from those days. Back then it was common for IT 'pros' to group together like mean girls. Sad but true. You were one of them in lockstep or you were at risk of being talked about behind your back in harmful ways and being shunned if they could get away with it. I don't know if things are still the same, only with different technology, but I hope they are better today. Their loss.
Could it be from our "friends" on another project? Wouldn't be the first time, so history might repeat itself here.
[ scratch that. I should not post out of frustration especially when I am unable to gather more info to help troubleshoot. ]
Hi guys,
Thanks for the replies! I got access back later that same day I posted this. Quite the coincidence. :)
I have confirmation now this is more about particular egos than technical matters and in my opinion I've always demonstrated a willingness to compromise even if it doesn't make sense technically. In my view making decisions solely based on group dynamics will leave FreeBSD in a place where it deprives itself of technical know how, contributions and users, but we all have to make our decisions at the end of the day.
I've asked for my Bugzilla account to be removed. I really don't see the need for it anymore.
> Will OPNsense fork BSD so that they can add in the work that's important (and being ignored)
Essentially, we have a soft fork and have had it for 10 years. It works very well. Release quality is better than any FreeBSD release out there because we fix a lot of things beyond mere errata or security advisories for our users.
> or will they continue using the main branch?
We're not using the main branch. We've always believed that actual releases are a far better starting point, also because it's cheap and easy to make these verbatim releases a lot better with a modern backport strategy. It does not appear to be compatible with the way FreeBSD wants to handle releases and user bug reports.
> Are any of the current forks worth moving towards for OPNsense?
You mean other BSDs? No, all have their ups and down. DragonFlyBSD might be the best match, but the downside is a small developer group, slower driver support, etc.
Linux is also out of the question. You can take the frontend and build a new firewall, but I reckon it's not a lot of fun in the first year or so while you slowly work towards something that looks great but is barely usable. ;)
Cheers,
Franco
You're currently the maintainer of quite a few ports, correct? Any plans on how to proceed there?
All the best!
Maurice
(Totally not qualified to comment on the situation since I'm not that deep into internal FreeBSD dynamics.)
> Any plans on how to proceed there?
Nope. I've asked FreeBSD committers, core team and even foundation for help on improving cooperation over the years. The ball was always in their court.
Not sure if it's really appropriate to kick me instead of the ball, but it is what it is. Someone clever will figure something out I guess. ;)
Cheers,
Franco
FWIW, core team is not responding to emails from FreeBSD committers anymore either. They know they screwed up badly by trying to kick me out at request of certain youtuber, then were forced to (partially) confess to developers@. I guess they have learned they can just ignore the developer community.
Thanks for your message and your mailing list thread! There seem to be a number of similar stories out there. Let me add one more that matters.
Here is my one and only 2023 code of conduct complaint that I filed after bit of a backstory of misconduct in the ports scope towards me.
QuoteFrom: Sergio Carlavilla <carlavilla@freebsd.org>
Date: Mon, 9 Oct 2023 11:06:12 +0200
Subject: Re: reporting an inappropriate mailing list reply
To: Franco Fichtner <franco@opnsense.org>
Cc: "conduct@freebsd.org" <conduct@freebsd.org>, FreeBSD Core Team <core@freebsd.org>
On Mon, 9 Oct 2023 at 11:03, Franco Fichtner <franco@opnsense.org> wrote:
>
> Hi,
>
> [REDACTED]
>
>
> Thanks,
> Franco
Hi Franco,
Okay, we've received the message.
We will contact you when we have studied the case and have a response.
Bye!
Sergio Carlavilla
Core Team Secretary.
I never got another reply on this complaint. I eventually chased down a core team member on the issue and the person assured me it would be taken care of internally. I trusted the person so there wasn't a reason to not agree to it. The email gives the offender a very lax outlook. Compared to how the core team handled the complaint against me I just think both of these instances were inappropriate and unprofessional.
QuoteDate: Wed, 6 Mar 2024 10:19:40 +0100
From: XYZ <xyz@freebsd.org>
To: Franco Fichtner <franco@opnsense.org>
Subject: Re: reporting an inappropriate mailing list reply
On Wed, Mar 06, 2024 at 10:08:26AM +0100, Franco Fichtner wrote:
> Hi [REDACTED],
>
> > On 6. Mar 2024, at 10:05, XYZ <xyz@freebsd.org> wrote:
> >
> > Yes [REDACTED] can be border sometime, at even cross dangerous roads sometimes, I do
> > talk quite a lot with him about him, to make sure he improves.
>
> If I can take your word for it I'll let this go then.
You can take my word, on this, he [REDACTED], so I feel like it is kind of my
duty, his behaviour has degraded the time he started getting more involved in
the project, due accumulating lots of frustration, as a result he ends up being
more (too much?) opinionated, and even aggressive sometime, I am trying to cool
him down, as frustration is part of high involvements and at some point we all
need to be able to deal with it, or we simply burnout.
[REDACTED]
still if you see bad interactions, don't hesitate to send me a heads u
directly, I am not tracking all his communication, so I may miss them.
[REDACTED]
Best regards,
[REDACTED]
The trust in the core team was mostly gone in that instance. What came after and anyone can look up is the core team's inability to bring people together even over technical matters.
So I think it's clear the code of conduct is dead and the core team cannot claim it to justify its decisions. The illusion here is that "words" matter and people are supposed to be friendly but actions like systematic neglect and abuse of power are much worse for the code, its users and even its developers in the long run.
Cheers,
Franco
I'm not sure it's a problem with CoC, or if it's being use by core@ as an excuse for their arbitrary decisions. In my case last summer, core first determined that I hadn't violated CoC (acc to Gleb's writeup), and then proceeded to straight out lie to me about it.
Well, the situation is simple: either the CoC stands and the core team enforces it on everyone including committers, or they let CoC violations slide for arbitrary reasons especially for committers, which means the CoC is already dead.
Looking at mailing list entries such as
https://lists.freebsd.org/archives/freebsd-ports/2023-October/004629.html
https://lists.freebsd.org/archives/freebsd-hackers/2025-December/005412.html
My greatest crime is acting like a committer and being punished for it while the core team watches its committers violate the CoC. :)
It's not hard to reply to an email and people act like nobody is entitled to responses. Which is funny, because bug reports also need responses and you don't get them either.
My biggest gripe with all of this is "haha you're so stupid for not having commit rights" which would have been the easiest way to avoid all the trouble and just let the work speak for itself. Instead asking for committers to commit something which takes 5 seconds is "entitlement" and a human response is something nobody can afford to volunteer.
I'm not buying it, because we've run a project on different core values for 10 years and it works.
And if I'm asking the release engineer to do a cherry-pick and I get lamentation about how everyone is fallible ignoring my requests for help and I should do more for the projects I have my doubts about the culture that is being curated there:
https://bsky.app/profile/fitch.bsky.social/post/3ly4n6jsocs2b
Standards are important. Morale is required. Communication is key.
Cheers,
Franco
I fully agree that CoC cannot be applied selectively; it's just that from what I've seen, it's not much better when you're a committer. Core ignored my own report couple of months ago, and I've seen two mentions of other cases like this - all from people with commit bits.
At the same time, it absolutely can be a problem to reply to an email; look up "executive dysfunction". But there's like a half dozen people on core@, and a single one would be enough to move it forward, so I don't think that's the likely cause here.
I suppose you are right. I can only give my outside perspective here. There's definitely a structural issue at play here that makes inclusion and mutual respect wishes on a paper more than anything that is lived by. I believe we can all agree on a technical patch that goes throw a review process. FreeBSD has all the tools and interested people to do it. The unspoken exercised culture, however, is one of lack of accountability and likely hard to overcome to be more goal oriented, open and collaborative. Things that nobody else cares about are not tended to even if contributions exist. This is where FreeBSD loses traction that would be an easy win.
Now at least some of my ports found no delay in maintainership which I find good and strange at the same time as if this behaviour fixes a structural problem the ports were having. I hope that incentive lasts, yet ports already start falling behind with CVEs and upstream releases out in the wild. Very happy that's not the case for our users, because there is an established process: test -> commit -> ship -> enjoy :)
Cheers,
Franco
So, FreeBSD core team hasn't bothered to release their monthly reports for half a year now. Developers have no idea what's going on and core@ behaves as if they owned the place. Questions regarding dch@'s (Dave Cottlehuber's) abuse of his position remain unanswered.
Eventually all the other devs will leave and back something else, or fork it again.
Forking is a very bad scenario for the project and should be avoided at any cost.
Especially that there's really no reason to fork - there's nothing wrong with FreeBSD source or developer base. It's a disagreement specifically about core@, which is supposed to be administration / "HR" more than anything. They don't make technical decisions, they don't maintain the infrastructure.
Plus the Foundation, e.g. most prominently Deb and Ed, are doing a very good job, IMHO.
I worked for the Foundation for a while, so I'm biased... but yeah, they are :)
I wonder if we could "fork" the problematic bits alone - like the core@ and infrastructure they can control - and then let people at FreeBSD.org choose who they prefer to work with. Especially given the current climate, and the fact that core@ has already been forced to comply U.S. shenanigans in the past.
Reading more about the purpose of the core team I've never had the pleasure to deal with them for their main purpose of wrangling commit rights ever. I'll be honest that dch@ was dangling them in 2024 Dublin but it was rather clear this wasn't really happening so there was no mutual approach to this ever and someone else confirmed to me that he appeared to not tell me the truth back then. I fundamentally disagree to leadership styles I've witnessed. Programmers rarely make good managers. Managers also not always make good managers. The problem isn't managing commit bits. The problem starts when attempting to manage people on the matter of commit bits and coming down only on either side ever and no willingness to do better.
From what I've seen in over a decade pass by on Bugzilla and mailing lists... some people have commit bits for short, small commit histories and in one instance multiple core team members could/would not answer me how a particular src-only committer would appear to commit to ports as well, ignoring maintainer timeout procedure and adding port plist issues in that same process. Luckily that person stopped committing altogether, which made that person the oddest choice to begin with. Furthermore, committers would neglect contributions, engagement and not extend trust or expertise. A "who are you" directed at an external contributor is really a question of "don't you know who I am" and the process of contributing falls flat on its face as people set up their egos to fail in the technical discussions never to be responded again. But I digress.
The core team seemed to find some bite in recent years for auxiliary topics, but that's largely directed at easy victims to cement status quo and avoid addressing structural issues. To me it seems the whole concept of the team is becoming a problem in itself with re-cycling members and declining committer pool growth. I think the protectionism is a bit misplaced which in part is a human condition although that would still not justify keeping things as they are if FreeBSD wants to start a new growth phase. The work of the core team is not boiling down to a chain of "not everyone will always like what we do" decisions. If that's the internal MO then yes we're scraping the bottom of the barrel with governance and things should really change rather than go on like this.
Between core team and foundation there has always been a lack of entity that works on cooperation and motivation or general engagement with the user side. Some would call this a "community manager". Not that one is needed, but there's also lack of FreeBSD culture around that principle also in part due to said protectionism and strict enforcement of committer/user relationships and pushing away side projects as "being on their own". None of this helps users and release quality, but I'm sure the people who feel this is necessary know the implications, but would still not change anything because that's easier for them (to have a productive year without dealing with code of conduct complaints, huh).
Cheers,
Franco
The way commit bits work is that an existing committer (anyone with FreeBSD.org email) sends core@ an email proposing someone, and then core votes on that. I guess you could describe this at "dangling". But the weird thing is - correct me if I'm wrong, but in late 2024 Dave was already a core team member, and voting on your own candidate feels kinda sus. Also, core is not supposed to do leadership - the person who proposes you for commit bit becomes your mentor, core has nothing to do with that afterwards.
Regarding src folks committing to ports or vice versa - that's acceptable as long as you make sure you know what you're doing, eg get an "ok" from your mentor or a ports committer. But you're supposed to still follow all the ports rules, like maintainer timeouts.
Wrt community manager - I think that would be the Foundation. Not sure if it was established with that in mind, but that's large part of what they do. They are also independent from core team.
As for the (rather depressing) rest - I agree, and from our internal mailing list this seems to be a fairly common view.
I can offer my 5 pence on that long bug report conversation. I apologise if anyone is offended by it.
First, my view is that the nature of the bug is pretty scary, we have had issues over the years with weird IPv6 behaviours, weird PF issues, which can be very frustrating for people operating misbehaving networks, if it also affected ICMP packet too big stuff, then it is especially nasty, and I think its clear regression testing is inadequate on FreeBSD.
Second I can see the asks's to back out the original security patch, as a end user I definitely see the logic in the request, but I very rarely see developers back out code, they usually die on that hill. I agree with dok's comment that the issues the patch was causing are far more serious than a vague low risk security bug.
Third, I think the idea to use a vanilla FreeBSD kernel on OPNsense to get the bug moving again was sound and should have been done right away after it was suggested. It doesnt matter if its felt it was wrong, just do it to satisfy all parties for democratic reasons.
Fourth was some bickering which was not a good luck on anyone.
Fifth the entire bug report makes FreeBSD look pretty bad in many areas, which its lask of regression testing as well as urgency in getting the issue fixed, even if it means backing out.
Is this still not properly fixed in FreeBSD upstream?
At least we cannot be sure of that. From time to time we stumble upon another piece of the puzzle.
And for the record: This was a (small) security problem that had been fixed in the other BSD project and ported to FreeBSD, but only in parts (that seemed to matter). It was never clearly communicated which parts where fixed, because the fixes were done incrementally and augmented via several bug reports. Some of those were simply disregarded, because they were not reported on "pure" FreeBSD, but on OpnSense, laying the burden of proof on users.
So, to answer your question, you would have to take the initial fix and compare it across all over the place in FreeBSD. Would you like to volunteer?
All we know is that there were documented missing parts of specific ICMPv6 handling that were left out and led to the exact bug sighting that were to be expected from it, all sidelined with pure denial of these facts and pointing how this must be done - with each of the missing parts tracked down according to the FreeBSD process.
Nope, cant volunteer, so basically it sounds like its still not clear if its properly resolved upstream, my view is, if it isnt regression tested, it shouldnt have been committed in the first place, which aligns with the view that Dok posted.
So another broken network path in FreeBSD potentially lasting several years and multi generations of release. At least OPNsense has backed it out.
I do feel the decision all those years ago to keep the custom multi threaded PF over keeping up with OpenBSD PF has continued to hunt FreeBSD. This situation is part of that fallout with picking specific patches from OpenBSD in the hope of fixing it on FreeBSD. A Frankenstein PF. I did mention this on reddit not that long ago and ironically the guy who responded to me quite angry is the same person making the commit's in that big report. He really did not like me mentioning that.
So you see how the cat jumps. You call it angry on the first encounter, some call it plain hostility after having experienced it multiple times. I understand your approach to cool down tempers and try to get to basics (I once did in vain), but that is an uphill battle that Franco has ceased to take. The FreeBSD folks are unwilling to change it for good, so that is that.
P.S.: "Frankenstein PF", I like that. Maybe we should call the other one "Zombie ICMPv6" (for missing parts). ;-)
I guess most of these issues are self inflicted due to the medium of internet.
If everybody would meet up on occasion and talk things out person to person, I'm sure things would go differently.
The internet is a great filter of intend and emotions, most is transmitted not via words, but via mimic, body language and subtext.
It's simpler to ignore or misinterpret something in the medium of the internet/anonymity than in real life.
But with a project that is worked on all over the world, thats mostly unfeasible I think, and so decisions will be made without taking the human aspect better into account.
Please note what I'm saying is highly simplified, I have no insight into the governance of freebsd, nor met any of their team members yet. My view on the whole thing is also filtered by the internet, reading just the reactions of the mailing list and other sources. It's just a very complex (human) issue in general.
Quote from: chrcoluk on March 31, 2026, 10:07:41 PM[...]I do feel the decision all those years ago to keep the custom multi threaded PF over keeping up with OpenBSD PF has continued to hunt FreeBSD.[...]
Improving FreeBSD's pf is an obvious goal, but pining for OpenBSD's implementation doesn't seem realistic. Unfortunately any attempts at real improvement would run straight into the politics being discussed here.
Quote from: Monviech (Cedrik) on April 01, 2026, 11:37:59 AMPlease note what I'm saying is highly simplified, I have no insight into the governance of freebsd, nor met any of their team members yet.
See you in Brussels (https://2026.eurobsdcon.org), possibly?
Quote from: Patrick M. Hausen on April 01, 2026, 03:19:40 PMSee you in Brussels (https://2026.eurobsdcon.org), possibly?
Right now I do not have any plans to go there. But if you ever want to meet in person, I am living close where you live :)
Quote from: pfry on April 01, 2026, 02:26:21 PMQuote from: chrcoluk on March 31, 2026, 10:07:41 PM[...]I do feel the decision all those years ago to keep the custom multi threaded PF over keeping up with OpenBSD PF has continued to hunt FreeBSD.[...]
Improving FreeBSD's pf is an obvious goal, but pining for OpenBSD's implementation doesn't seem realistic. Unfortunately any attempts at real improvement would run straight into the politics being discussed here.
Yep, for sure.
Quote from: Patrick M. Hausen on April 01, 2026, 03:19:40 PMSee you in Brussels (https://2026.eurobsdcon.org), possibly?
Sure. :)
Quote from: Monviech (Cedrik) on April 01, 2026, 11:37:59 AMI guess most of these issues are self inflicted due to the medium of internet.
I disagree. I think people underestimate their impact of dismissiveness in a world where we share and grow together and it's hard to back out of a corner eventually. At some point you're so locked in that any attempt of open communication seems like a neglect of your life's work.
Here are some helpful guidelines we can all benefit from:
https://blog.codinghorror.com/the-ten-commandments-of-egoless-programming/
Quote from: trasz@ on March 27, 2026, 10:42:47 AMThe way commit bits work is that an existing committer (anyone with FreeBSD.org (https://freebsd.org/) email) sends core@ an email proposing someone, and then core votes on that.
It's kind of amazing that nobody ever took the time to explain it with a single sentence in over a decade to me. It kind of makes sense things went the way they went then. Neglect only gets us so far, but it sure is the easiest thing to do.
Cheers,
Franco
Quote from: franco on April 08, 2026, 10:28:07 AMHere are some helpful guidelines we can all benefit from:
https://blog.codinghorror.com/the-ten-commandments-of-egoless-programming/
#9 applies to sysadmins too, you need to be out in the world to see what the users are experiencing so you can solve the problems they describe.
Quote from: Greg_E on April 08, 2026, 09:25:40 PMQuote from: franco on April 08, 2026, 10:28:07 AMHere are some helpful guidelines we can all benefit from:
https://blog.codinghorror.com/the-ten-commandments-of-egoless-programming/
#9 applies to sysadmins too, you need to be out in the world to see what the users are experiencing so you can solve the problems they describe.
#10 doesn't work well in my experience. Coders associate their work with their identity and any critique feels personal. In the workplace it can feel like a threat, although this is more often the case with insecure employees. The problem with coding is that "imposter syndrome" is felt often even if it's not talked about or admitted to, so I tend to believe that coders are in a kind of perpetually insecure state internally which reflects as defensiveness and/or sh!tty attitude externally. (I might be projecting a bit :P)
Agree on the rest! Very good things to keep in mind.
Well it is plain simple: #10 is a choice you have to make. If you hate the code you wrote last year it certainly helps. If you think it was the best code ever... well... there's no help wanted there. ;)
Oftentimes I find myself looking at code that looks stupid, but if there's a very particular reason that it's stupid that others complaining miss entirely that usually helps making better choices or redoing it or leaving it as is.
Also when sketching ideas in code and hating the direction deleting it and starting from scratch has been eye-opening on numerous occasions.
You're simply not your code.
Cheers,
Franco
Quote from: OPNenthu on April 09, 2026, 11:36:05 AMThe problem with coding is that "imposter syndrome" is felt often even if it's not talked about or admitted to
AFAIK that's something that's an issue across the whole IT world :)
Quote from: franco on April 09, 2026, 12:59:18 PMOftentimes I find myself looking at code that looks stupid ...
Same here. Then I look at the commit logs and it's my code from 5 years ago ;-)
Quote from: franco on April 09, 2026, 12:59:18 PMAlso when sketching ideas in code and hating the direction deleting it and starting from scratch has been eye-opening on numerous occasions.
Well, that makes me feel better. I'm often doing something while I learn, mess it up and tear it down, often going to the wipe the drives and start over phase. And none of what I do is programming.
This also happens a lot if I'm building something. The plan is only so good until you start assembling the pieces and need to rethink parts of the plan. Especially if there is a delay of years put between concept and execution. I can think of many a motorcycle mod that has been this way for one reason or another.
Not so great when they are building your house.
So, there's a (minor) update: after I've submitted a formal CoC violation report against David Cottlehuber <dch@FreeBSD.org>, the old (soon to be replaced, elections in progress) core@ now claims that CoC is actually a terrible idea and we shouldn't be enforcing it xD
Not sure if it will void their previous "findings", like banning you.
Thanks for this!
Cheers,
Franco
Quote from: trasz@ on May 07, 2026, 11:49:10 AMcore@ now claims that CoC is actually a terrible idea and we shouldn't be enforcing it xD
WOW, just WOW.
Regards,
S.
Quote from: trasz@ on May 07, 2026, 11:49:10 AMSo, there's a (minor) update: after I've submitted a formal CoC violation report against David Cottlehuber <dch@FreeBSD.org>, the old (soon to be replaced, elections in progress) core@ now claims that CoC is actually a terrible idea and we shouldn't be enforcing it xD
That's
EVIL Corp-like behaviour :(
Do they get paid? I'm just guessing there is some amount of money behind this, and them wanting to keep getting that money.
The core team? No.