Why I am retiring from contributing to FreeBSD

[franco]

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

[trasz@]

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.

[Greg_E]

Eventually all the other devs will leave and back something else, or fork it again.

[trasz@]

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.

[Patrick M. Hausen]

Plus the Foundation, e.g. most prominently Deb and Ed, are doing a very good job, IMHO.

[trasz@]

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.

[franco]

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

[trasz@]

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.