@jaredwhite well… I have opinions.

Strap in, long post.

BDFL/core team model came about way before forges. For example SourceForge started in 1999. Ruby in 1995, Linux and Python in 1991, Perl in 1987, and GNU itself started in early 1980s, to name a few. And that’s only the formal governance. Pretty much everything before that followed the informal BDFL model: someone made something, published it (with or without a license), people used it, some contributed patches back.

This is a very natural model if you accept any kind of ownership right. And that's everywhere nowadays. If you made something—it's yours. It's dishonourable to take a thing from someone else and tell everyone it's yours. It's acceptable, though, to pick up abandoned things and make them yours. That's how forking came about. In the early days of the internet there were examples of some programs being initially made by one person and over time replaced by the version changed by someone else. And they were usually named after the new developer. This practice was used both for forks and rewrites so it's a bit hard to get stats on which was more prevalent.

Anyway, since the early days of programming it was obvious to almost everyone that expertise is essential. Be it the domain knowledge of the problem solved by any specific program or "just" familiarity with the program code, language, tools, and systems it runs on. Either way it wasn't common and, in practical terms, BDFL/core team wasn't exactly easily replaceable.

Meanwhile at MIT, AI-bro Stallman was miffed that software stopped coming with its source code. He framed it as "ma freedom" argument, for two years tried to copy a competitor product. The product was a Lisp machine. It turned out there wasn't much market for that.

At the time a few things were happening in parallel. Personal computers were becoming affordable. I don't mean IBM PC but a small desktop computer a person could have at home. And these computers were becoming more powerful rapidly so they could do more things. All these computers required software. So absolute number of customers grew very fast. Proportion of regular people to businesses also shifted rapidly. With that piracy grew. And with the changes to Copyright Act (it classified software as literary works, and consequently made it copyrightable) vendors started restricting their software in an attempt to capture more profits. Software stopped coming with source code, copy protection was introduced, etc.

All this miffed Stallman quite a bit. His railing against proprietary software seemed to resonate with people at the time. So Stallman, in a true AI-bro style, pivoted. His new thing was software freedom absolutism, and his new product was a copy of Unix, and the new brand was GNU, of course. Internet memes weren't invented yet and it didn't seem appropriate to just say "all your code are belong to us" and Stallman thought he was very clever so he took this new software copyright thing and turned it inside out and made it a license. I have to admit, it is funny to use copyright to force people to release their code.

GNU license reflects Stallman's software freedom absolutism in terms of user rights in relation to software. It kinda has to because from the legal point of view software doesn't have agency, users do. One notable thing about GNU licenses (and by extension whole of Free Software) is that users lump in both regular software consumers and developers. There's no distinction in there. I assume, Stallman being a massive nerd didn't conceive of a person who might want to use software and can't write their own OS and a list interpreter to actually run it.

This consumer-developer unification has never been addressed by Stallman or Free Software Foundation. You can read all of the internet and the only mention of "maintainer" from official FSF-affiliated sources you'll find is GNU maintainer guide. And even that is not helpful at all on the governance model question. As far as I can tell Free Software expect every user to be a maintainer of their own fork. It doesn't matter whether the user maintains their own collection of patches by other users, write their own patches, or just uses a version provided by someone else–the user is essentially responsible for the software they use.

All this might've nice and dandy for idealistic hacker-types it didn't impress regular customers much. You see, non-developers couldn't do much with this software. There was no one to demand a refund or a fix from, no support either. Businesses wouldn't touch it with a 10 feet pole in fear that they might have to give up their strategic advantage. Political angle wan't very attractive to businesses either.

This didn't go unnoticed for too long. Open Source Initiative forked off Free software to "reframe the discourse to reflect a more commercially minded position". They recognised the issues with free software adoption and wanted to fix it. They though that Free Software is too restrictive to thrive in the business environment so they relaxed some restrictions. Particularly, they remove the infectious nature of GNU licenses in their own licenses. In commercial interest's eyes Free Software looks like "some commie shit" and Open Source is more of a "do whatever". This, of course, worked. While it took some time to prove it legally, "do whatever" is what businesses like and Open Source adoption is very popular now.

One thing Open Source didn't fix is consumer-developer unification. Open Source being a relaxed version of Free Software dropped all requirements to what users have to do (e.g. release their changes) and mostly focused on what they can't do (expect quality, lay blame, etc.). Regular software users (consumers) are of no little consequence to FLOSS because they can not violate terms of any GNU or OSI license.

Like in Free Software, Open Source is not concerned with how software actually comes to be. Governance model is strictly outside of sphere of concern of both Open Source and Free Software.

So… This is why "fork off" and "patches are welcome" are common In FLOSS. In a sense, FLOSS has implicit expectation of universal expertise because of consumer-developer unification and because it doesn't acknowledge existence of expertise at all.

By the way, I think, this is the source of all the sustainability issue of FLOSS but this I'll leave it for another time.

Free Software has a lot of political baggage but doesn't address cultural aspects of software at all. Open Source, by extension, doesn't either. This includes relationships between different kinds of actors in FLOSS (consumers, maintainers, developers, businesses, etc.). Governance models are exactly that: different arrangements of those relationships. And since FLOSS doesn't specifically address the cultural aspect we fallback to general cultural background.

As I said at the very beginning, BDFL is a natural default. We, customary accept that the person who made a thing owns the thing. We respect that ownership and on the honorary basis we strive to maintain that ownership. We contribute back instead of forking because it's generally seen as not good to take a thing from someone else claim for ourselves.

This is where FLOSS clashes with the cultural background. FLOSS says that copyright is all there's. You write some code, it's yours forever. From the legal point of view it's true. But code is not all there is. Software is not just a bunch of patches floating around. Someone has to put them in the right order and make sure that it's minimally functional. Someone has to compile it and put in a package that users can install to use the software. Someone has to write release notes. There's a lot of work outside of writing code that goes into software. We, collectively, respect all that work. Not only in software but in general. Almost everyone agrees that it's respectable to do hones useful work for the benefit of the broader collective.

BDFL is also a natural expertise focus. They probably have some domain expertise if they write software to solve those problems. They also have the most exposure to the source code of the program and know it through and through. This makes them the most qualified person to solve any issue with the software or to add new features.

Here FLOSS drops the ball too. Is I said, it doesn't acknowledge existence of expertise one bit. But in the cultural background we had respect for people who know things since before they actually knew them. Even at the dawn of civilisation the most respected people in a tribe were elders and shamans. Elders lived for a while and saw a bunch (empirical experts) and shamans communed with gods, spirits, and forces of nature (theoretical experts). Since then expertise was recognised and respected in every society.

BTW, core team is more or less an extension of BDFL. Or alternatively, you can view BDFL as a special case of one-person core team.

This natural default of BDFL/core team was not invented by forges. It was just recognised as the most popular and just codified by forges. Be it SorceForge, GNU Savannah, or GitHub the default of BDFL/core team governance model is not invented by them. It might be reinforced by them but I don't think it's their duty to change it.

I have to say that I'm kinda excited about federated forges (e.g. Forgejo and F3 initiative) but I don't think it has any bearing on the BDFL/core team model. I see it more as a solution to centralisation and commercial vendor lock in (think de-Googling equivalent for GitHub/GitLab).

I don't think any particular forge, or any different piece of software can address cultural aspects of software development (FLOSS or otherwise). And I don't see FLOSS itself—as in FSF or OCI—will ever address them.