Recommend Establishing Dedicated Working Group for External Contributions

[ralphbsz]

I totally agree that those closed-to-reply posts need to stop. They just rub people the wrong way.

The fact that they are closed to replies is not the big problem. Opening a thread to discuss is pretty easy. It is only a small problem, as it gives us, the users, the feeling of being spoken to by authority. The bigger issue is that I'm not sure the foundation is focusing on the right problems and doing the right thing. But I'm also not sure they are doing the wrong thing, so I'm not ready to raise a ruckus about it. That's because I no longer really know what problem FreeBSD is trying to solve, and what the overall problem of computing is and how FreeBSD fits into that framework. If I had nothing useful to do, I could think about it and pontificate and lecture, but my opinion is probably not very important. Plus I have stuff to do.

Anyway, on the question of governance: We’re an anarcho-syndicalist commune. We take it in turns to act as a sort of executive officer for the week. But all the decisions of that officer have to be ratified at a special biweekly meeting. By a simple majority in the case of purely internal affairs, but by a two-thirds majority in the case of more ...
King Arthur: BE QUIET
Listen, strange women lying in ponds distributing swords is no basis for a system of government. Supreme executive power derives from a mandate from the masses, not from some farcical aquatic ceremony. Well you can’t expect to wield supreme executive power just ’cause some watery tart threw a sword at you! I mean, if I went around sayin’ I was an emperor just because some moistened bint had lobbed a scimitar at me, they’d put me away!

 

[DutchDaemon]

I will happily give the Blogs & Newsfeeds sub-forum an open reply function. It has never been considered purely based on the sub-forums description that SirDice posted earlier. The reply never gets seen by the entity that triggered the RSS import. So long as that is clear (I will change the descriptive remarks), go ahead.

 

[cracauer@]

I will happily give the Blogs & Newsfeeds sub-forum an open reply function. It has never been considered purely based on the sub-forums description that SirDice posted earlier. The reply never gets seen by the entity that triggered the RSS import. So long as that is clear (I will change the descriptive remarks), go ahead.

Quite a few of those people do have an account here, so you can @ them manually.

 

[linimon@]

I will happily give the Blogs & Newsfeeds sub-forum an open reply function. It has never been considered purely based on the sub-forums description that SirDice posted earlier. The reply never gets seen by the entity that triggered the RSS import. So long as that is clear (I will change the descriptive remarks), go ahead.

The problem, of course, is how to balance this vs. "we only want to see germane discussions". I am not familiar with the forums framework so I'm not the right person to comment.

 

[bsdimp]

Once again, I said "hey, srcmgr wants to solve this problem, please contact me or them." ykla I am very serious. I've been working on this for 5 years now and clearly haven't gotten anywhere close to solving the problem.

But to date, there have been no responses to me. So I'm reiterating: if anybody wants to legit work on this, contact srcmgr@freebsd.org or imp@freebsd.org.

But to solve the problem will require people who are willing to work on different aspects of it: tooling, culture, awareness, documentation, etc.

 

[POSIX.1]

I said "hey, srcmgr wants to solve this problem, please contact me or them."

The door could not be more open. bsdimp, thank you for being congenial.

I'd appreciate if portmgr@ would be able to descend to this place giving a similar welcoming pledge. The problems there give cause for more serious concern. Committers, maintainers and submitters are off-boarding a sinking ship.

It has come to my attention that this thread has landed at developers@. Folks over there: Don't fear a community that is willing to contribute. Your privileges are not endangered! But do not scare them away, please.

 

[bsdimp]

The door could not be more open. bsdimp, thank you for being congenial.

I'd appreciate if portmgr@ would be able to decent to this place giving a similar welcoming pledge. The problems there give cause for more serious concern. Committers, maintainers and submitters are off-boarding a sinking ship.

It has come to my attention that this thread has landed at developers@. Folks over there: Don't fear a community that is willing to contribute. Your privileges are not endangered! But do not scare them away, please.

Yea. We generally, as an abstract idea, love the idea of growing our developer base. While there is some privilege guarding, I'd suspect that the bigger problem is just a resource one: We don't have a great way, sometimes, to get the patch in front of the right person (there might not be a specific right person even). And if we do, there's no good oversight / management to find 'dropped balls' so good submissions languish. And then there's the problem that many submissions are a good hack, but aren't great for upstreaming and it can be hard to communicate that since it isn't always clear the right path forward to solve the underlying problem... This leads a lot of people to go "oh, too complicated, I'll find something easier". And sometimes the submissions are just too big: they are hard to review, touch areas of the tree that are sensitive, etc so the 'easy path' is to ignore it. It isn't really a case of we think we're better than other people... We're just busy, neglectful and shy away from the little bit of confrontation that is often required to resolve these issues.

I've been working on making things less sucky for new contributors. Things do, indeed, suck less. But not enough less, and more work is needed. Fresh ideas are useful, and collaborative, understanding attitudes help a lot.

But it's clear my organizing skills are falling short: this keeps coming up, and the progress is slow and excruciating to everyone. I'd love someone else with passion to drive something here and will volunteer to do my part to inject "inside" voices into the discussions that are keen on solving the issue. Some folks in this thread fit that bill, while others... well, it's hard to offer good criticism for the attacks when they have an element of truth to them, but are delivered in a package that won't get the best reception...

Also, please PM me if you see people (inside or out, but especially inside) trying to create a divide between the groups... I'll do what I can to, ummm, coach better attitudes and interactions.

 

[Jose]

King Arthur: BE QUIET

Are you being repressed?

Awright, enough tomfoolery, and thanks for your patience everyone.

 

[ralphbsz]

Quite a few of those people do have an account here, so you can @ them manually.

Here is a way to automate that: If the author has an account here, set the configuration that they are notified for any reply in the thread (I think that's called "watch"). And set the configuration flag that any notifications be sent out by e-mail (that's somewhere in the user control panel). The functionality might all be there already, just would have to be auto-configured when a post is created from the RSS feed. Still quite a bit of work. Which reminds me that I need to, as always, thank the moderators and admins for what they do.

 

[linimon@]

From personal experience, portmgr has traditionally been one of the most over-committed groups within FreeBSD.

I'd appreciate if portmgr@ would be able to descend to this place giving a similar welcoming pledge.

I usually try to be diplomatic but after the last 2 weeks fighting a flame war, I'm instead going to say: the passive-agressive use of the italics is counterproductive.

 

[T-Aoki]

Compared with when I've started using FreeBSD, ports have been grown far more larger, and ports framework became far more complexed to maintain, to make each ports to be easier to maintain.

When I first used FreeBSD (2.2.6 or earlier), ports framework was quite simple. There were not yet existed USES framework and so on. And there was still no ports management tools like ports-mgmt/portupgrade. IIRC, no CONFLICT keyword, as conflictiong ports are simply rejected or renamed conflicting files to be committed.

 

[POSIX.1]

linimon@ It is utterly regretful that your perception is „fighting a flame war“. Are we on the same thread?

Being able to take validly criticism is an asset for every healthy community, at least it should be.

Isn’t the flame war going on at developers@ in an in-group/out-group fashioned patterns behind closed doors? We the over-committed, out-burned enablers who unfortunately have chronically lack of time but still wanting to enjoy the ranks. If a person is that busy in work, family, and other places that a FreeBSD job makes them burning out, it’s the wrong person in FreeBSD’s administration hierarchy. Let others do the job, who have less problems.

There is a wide spread lack of understanding what „diplomacy“ does. The nice talk is the window to the public, while the hard talk is behind closed doors. But diplomats do listen intently to any shouting from outside because some adjustments may be over due.

A typo was in my text. I edited „decent“ to „descend“. You still can see the original in the cite of bsdimp and to make the difference visible I formatted it italic. What I wanted to express is the distance from administration levels to the low grounds of the FreeBSD forums that some regard as playground for end-users. In that sense imp descended and was cordially welcome here (where is the flame?), but portmgr@ still not arrived.

Do you still interpret this a counterproductive passive-agressive use of italics? I hope you do not.

 

[kpedersen]

the FreeBSD forums that some regard as playground for end-users. In that sense imp descended and was cordially welcome here (where is the flame?), but portmgr@ still not arrived.

The FreeBSD forums is great but if you do want to get involved in the development of FreeBSD itself, then just engage with the mailing lists. Its not rocket science.

The italic 'descend' was a little unfortunate if it indeed was highlighting a typo. But to be fair, the word itself and creating this concept of "higher" or "lower" is passive aggressive in its own way. Members on these forums are also very welcome in the "high up" mailing lists. The stairs really aren't steep and whilst there is a lack of time for many people, there is zero gatekeeping that I can see.

 

[Erichans]

A typo was in my text. I edited „decent“ to „descend“.

Apart from the use of the particular words "decent" or "descend" in this context, and generally speaking, if you've made an error that may be more than a simple (or obvious) spelling mistake or a minor rearrangement of your arguments—something that might change the meaning or intention—and you want to make a correction, you may want to consider:

I think this shows that the meaning of this wording in the man page is ambivalent ambiguous.

or:

I think this shows that the meaning of this wording in the man page is Edit: ambiguous.

This way, you'll leave hardly any room for misinterpretation of the changes you've made, which might otherwise lead to avoidable ambiguity or uncertainty in the reader’s mind.

 

[patmaddox]

If you're going to make changes to src or ports, you need your own reliable build and deploy infrastructure. It would be great if things got merged quickly, but that rarely happens (as others have said, it's common for things to remain unmerged for months or years). Presumably you made the change to solve a problem you had, and want to benefit from it immediately. If you do this regularly, then you're off the beaten path and can no longer stick to the defaults. All merging does (for you) is ease the maintenance burden a bit.

 

[bsdimp]

If you're going to make changes to src or ports, you need your own reliable build and deploy infrastructure. It would be great if things got merged quickly, but that rarely happens (as others have said, it's common for things to remain unmerged for months or years). Presumably you made the change to solve a problem you had, and want to benefit from it immediately. If you do this regularly, then you're off the beaten path and can no longer stick to the defaults. All merging does (for you) is ease the maintenance burden a bit.

There's two main reasons for the delays.

(1) Lack of validation. Changes need to be manually validated by a domain expert today. Some of them might be amenable to automation. But somebody with the right skills need to look at the change. It also has to be compelling enough to rise to the top of all the other contributions that person is looking at. If it's too boring, then they will decide other things are a better use of their time. The big problem is that a lot of that is silent. In large part "oh, maybe someone else will find this useful, I don't" is too easy to think.

There's a variant of this too "this change sucks." Or that's the thought. It would take too much time to make it good since it's almost useful as is, but not committable. These sorts of changes can suck up a lot of time if there's a lot of back and forth with a review. Or a lot of time trying to fix the submission. Or worse: I say 'sure' and commit it and then bug reports come in that I have to attend to since I committed it, taking time away from other things I need to do. I know I've been burned by this a dozen times in the last year, and I'm extra careful with the pull requests I land...

(2) Lack of awareness. Sometimes, the right people just don't see the change.

(3) It's stuck in the backlog from > 2yr ago... That's a big, ugly swamp.

And we've started seeing AI shit showing up and wasting our time with lots of low-quality, trivial changes. After a few of those, you lose enthusiasm for even looking.

So having a team that's dedicated might help... the bug busting team does an ok job at least checking things... how would a new team help them help the project? It's a tricky problem...

 

[patmaddox]

That makes sense. fwiw it's not a criticism on my end - rather pointing out the reality that anyone making patches is in effect acting as a developer, albeit without commit access. From what I've observed, there can be a long cycle time for committers as well. So if you want the value from your efforts, you have to build and deploy yourself. I'm sure that's obvious to committers, but I see a lot of people waiting for their contributions to be committed, and I think that just misses the point of being able to build this yourself in the first place.

One thing I am curious about: do you have committers who have interest and availability to review and commit contributions? From where I'm sitting, it appears that you're the one person who has raised their hand do this sort of work. I wonder if anyone else has? From a contributor's perspective, t would be encouraging to know the names of 3-4 people who have taken on this responsibility. There are lots of other teams, accepting contributions seems like a big enough responsibility and opportunity to warrant that kind of focus as well.

 

[ykla]

The problem is not just that PR can't be processed—in fact, the FreeBSD Foundation and the FreeBSD Journal are facing the same issues. I've always believed that even when understaffed, setting up automatic replies is a reasonable approach. The FreeBSD Foundation and the FreeBSD Journal both seriously lack a sense of time.

Years ago, I emailed the Foundation to report issues related to mirror sites and donation channels in mainland China, but I never received a response. It wasn't until I followed up multiple times this year that I finally got a brief reply—nearly six months after my last email.

Because the Foundation had long failed to respond, I even mailed a registered letter to them. But it seems USPS lost the letter—or perhaps they're also suffering from a lack of time awareness: tracking number RD664821800CN shows no updates since May 21, 2025.

The FreeBSD Journal said they would reply to me by the end of June, and now it’s nearly August. As you can see, both upstream and downstream in the FreeBSD project are showing a serious lack of time awareness.

I hadn't planned to say anything more—this is just a complaint, after all. I’ve long since stopped planning to participate in any FreeBSD project myself. The community I'm part of is in a similar state: as long as you propose a task, no one will join you—except yourself. All they can do is chat idly or oppose you. None of it is helpful, and it doesn’t solve anything. Just pretend nothing's wrong, and everything will seem fine.

Everyone loves a good story, so let me tell one last tale:

Once upon a time, a family hung a bell on their door. It was very beautiful and made a lovely sound.
One day, a man saw it and wanted to steal it. But he knew that touching the bell would make it ring loudly, alerting the owner.
He thought and thought, and finally came up with a “brilliant” idea: he reasoned that the only reason the bell gets him in trouble is because ears can hear it.
So, if he covered his ears, he wouldn’t hear the sound, and everything would be fine.
He covered his ears and reached for the bell.
But the moment he touched it, the bell rang—
And the owner heard it, caught him, and the theft failed.

Where on earth is the world full of flowers?

 

[sidetone]

There's a saying, that for every public complaint, there are several silent complaints about customer/patron service. In this case, it could be a hundred times more, bc the venue is online, and not many are dedicated enough to try for that long. That's a serious issue, which they need to address, to make some amends, and to not seriously disappoint others. That's how an otherwise great operating system can lose people. I hope they fix fundamental issues and setbacks.

I think there needs to be more working groups, more BSD conferences, and a few more non-profits independent of FreeBSD, which work with FreeBSD. I dream of starting a BSD project, which can operate independently of FreeBSD, and boost all BSD's and non-Linux OS'es including FreeBSD. Better Linuxes, by which they understand the better way, would be more than welcome to receive improvements though.

On the IRC room, NetBSD people are overly eager to help with their operating system. They're friendly as well. And the keeper of DragonFlyBSD has answered others on that mailing list himself. There's other BSD's which, if I would try HardenedBSD. I read they're active and respond to the community. There's also, GhostBSD, MidnightBSD, NomadBSD, FuguIta. For firewalls/routers: OPNsense, DynFi. For a NAS, XigmaNAS. For nonBSD, there's Haiku, and Redox, but these are primitive, and lack necessary features. There's also non-Linux OS's for Arm64 architecture, like RiscOS and AOSP. Some of those communities would be happy to have you, your dedication and your eagerness. For experiences of FreeBSD users with other BSD operating systems, as there's also helpful descriptions about their communities: https://forums.freebsd.org/tags/share-bsd-experience/

Good luck on your open source operating system and other software journey.

Also, if you choose to be anonymous, don't post the tracking number. Otherwise, keep it there.

 

[sidetone]

If you happen to read this, https://www.freebsd.org/status/report-2025-04-2025-06/#_chinese_freebsd_community_cfc has a link to https://www.bsdcn.org/ which is for Chinese FreeBSD Community (CFC):

The community currently comprises 316 members in the QQ group and 175 members in the WeChat group.

In this FreeBSD Status Report Second Quarter 2025, for the CFC, there's a subsection on: Chinese Documentation, a Chinese publication called FreeBSD-ask, and about QQ messenger.

The popular Chinese messenger net-im/qq is seemingly being revived, upstream and in ports: PR 287292, & https://github.com/FreeBSD-Ask/QQ-Port/. Correction: the PR and github page for QQ were by ykla with last activity over 3 months ago.

As of now, the quarterly status report was last modified on August 29th. 2025. It's from April to June 2025.

Apart from that, I've started Thread nature-of-bsd-operating-system-providers.99042 which is about different BSD's: how they're structured, software events/communities around them, and foundations which steward software by open source licenses.

Thread nature-of-opensource-non-bsd-non-linux-providers.99046 is not as extensive or detailed, but it shows options of operating systems which aren't BSD or Linux.

From these two threads, there are a handful of non Linux operating systems to choose from.