[cpcallen]

On the one hand, if you grew up in the baazzar, moving to the cathedral might feel like the "death of open source" even if it is really just a return to an earlier way of working.

On the other hand, while not accepting external code contributions will certainly improve their security posture it will also make it more difficult to identify who to invite to join the priesthood.

[Yokohiii]

Open source development has become more and more superficial aligning with modern social network characteristics. It's more important to have an contribution, a active commit history, a few stars as a proof of pixel fame than the intrinsic value of the contributions or projects.

Before the rise of github, open source projects were heavily walled gardens. Little clubs that gave you a stare when you entered the room. Github commoditized getting in touch and lowered the barrier for how much effort you have to put in or even how much you have to care before you contribute. This is gone now and you have to build trust now before you can contribute to anything.

This isn't the death of open source. It's the death of the global village were everybody can freely roam and it's easy to interact. It's the resurrection of small, social, trusted communities. I hope this spreads to all of the internet.

[appreciatorBus]

Yes. Open source existed and thrived before GitHub, before git, and before anyone had ever used the words “pull request“.

It was different, to be sure, but it was not worse. We are living through a transition, but people do that all the time and we adjust our behaviour and we find new equilibriums. We will do that with open source too, and if it ends up looking more like open source in the 80s or 90s, it’s gonna be fine.

Maybe some people who got really good at gaming their Github reputation are going to lose out, but that was never the point. Anyone who likes this kind of work and wants to get involved will find a way.

[thewebguyd]

> I hope this spreads to all of the internet.

It is. Unfortunately, its not happening with open platforms. Communities are migrating to private discord servers, and less is discussed in public/in the open.

I think we should still separate "working in the open" from "allowing or not outside contributions." Outside contributions are fine to be denied, however I think work and discussions should still more or less happen in the open for the benefit of all.

One day discord will cease to be, and there will be years of institutional knowledge and lore lost.

I much prefer the old school forum style. Forums could be locked down to be invite only to contribute, but for the most part were still world readable.

[trumpdong]

World readable has become a liability as well. How many times has some random disagreement been blown up by observers and lead to people being kicked out of groups, jobs being lost, or SWAT raids?

[bsammon]

Okay, I'll bite: How many time has that happened? I'm definitely not an avid follower of such things, but I've never heard of that happening. I'm not arguing that it doesn't happen, but I'd like to hear/read details.

I've heard of people within the argument directing SWAT raids at each other, or contacting employers, but I've not heard of it being driven by uninvolved observers.

Now... I've heard of people posting things on social media that others found offensive, and losing jobs/gigs over it, so that sorta supports what you're saying, but even in these "edgy" social media cases (which weren't "arguments" per se, in the cases I've heard about), I've not heard of SWAT/police reactions.

[krapp]

Gatekeeping doesn't work if institutional knowledge is freely given to all, the entire point is that knowledge is only available to a select few and acts as a shibboleth to keep the tourists out.

[malicka]

This kind of gatekeeping isn’t about knowledge (which is free and should be freely shared — basic hacker ethic), but about social standing.

[thewebguyd]

Knowledge isn't what should be gatekept. Participation in the community, sure, maybe, but not information/knowledge.

[qwm]

> This isn't the death of open source. It's the death of the global village were everybody can freely roam and it's easy to interact. It's the resurrection of small, social, trusted communities. I hope this spreads to all of the internet.

This is definitely a microcosm of what's happening to the entire Internet.

[Sharlin]

I’m never getting accustomed to the fact that there’s now an entire generation of coders who have never seen a world where "everything" is open-source and developed in the bazaar style (are people these days even aware of the metaphor or Raymond’s book?), a world in which the frigging Microsoft is a major OSS vendor and in charge of facilitating most of the open-source programming on the planet. Try explaining that to a time traveler from the late 90.

(Also, as a sibling comment implied, the archetypal "bazaars", like the Linux kernel project, now appear quite cathedral-like in conparison to the free-for-all GitHub model!)

[dcrazy]

I’m confused, when has “everything” been a bazaar, and when did that cease to be?

[throawayonthe]

of course not literally 'everything', but as someone that grew up in a post-git world, with github as the 'default', to me projects that don't accept (or expect!) outside contributions have been the exception; definitely aware of notable examples (sqlite? some web servers, a few internal-libraries-that-outsiders-use?) but very much used to the bazaar

i think the claim is that more projects are locking up contribution paths ~currently

[Sharlin]

Umm, I missed a negation there, sorry. I meant that the newest generation has only seen a world where there's a giant OSS ecosystem and the bazaar style is the norm for all of your tool and library needs.

[dcrazy]

Okay that makes way more sense. It seems especially applicable to web frontend, where everything seems to have been developed out in the open.

[Sharlin]

> there’s now an entire generation of coders who have never seen a world where "everything" is open-source and developed in the bazaar style

(Sorry, accidentally negated my meaning there, what I meant is that they have only seen this current world. Or never seen a world where it isn't the case, to use a confusing double negation.)

[aembleton]

> "everything" is open-source and developed in the bazaar style

A lot of stuff isn't. It may be open source, but the number of contributors is small and many large projects are cathedrals with people volunteering to lay some stones. The large projects often have core teams who organise and manage it, but then accept some contributions. It's closer to the organised Cathedral, than the chaotic Bazaar.

[cosmicriver]

I think that was a natural outcome of cheaper merges/conflict resolution in distributed version control. It became easier so there were more situations where it made sense.

Now LLM spam has made it harder, so now there are fewer situations where it makes sense, and projects are switching to a cathedral model.

[javawizard]

> it will also make it more difficult to identify who to invite to join the priesthood

The point that this announcement is trying to make is, of course, that AI has already made that particular signal approximately worthless for that purpose.

[smartmic]

There are great Open Source projects doing fine with the cathedral style, just look at Sqlite and its siblings (Fossil, …).

So I do not see a problem with Ladybirds decision, in contrary, IMHO it strengthens the human aspect of software development and puts the brakes on AI free riders

[gbalduzzi]

I still don't see solutions on how a normal person can become a mantainer though.

If all relevant open source projects close up their contributions, you can't enter the project anymore from an external point of view.

Almost all open-source public figures started by being interested in a project and submitting PR to it, until eventually either joining the project as core mantainer or creating a separate open source project. The path is now closed, and I don't see a way in, outside of creating a popular open source yourself

[appreciatorBus]

> how a normal person can become a maintainer though.

Is the goal to produce high-quality software, or is the goal to produce an apprenticeship scheme for developers who are interested in the project but not so interested that they are willing to write an email to introduce themself or otherwise engage in normal human social interactions?

Normal people will still be able to get involved if they want to, just like normal people can get jobs. You learn about the organization you’re interested in joining, you try to meet some people and introduce yourself, you gain trust and prove your worth. It can be true that a pull request once embodied some of these tasks, but it is not true that being unable to submit a request means that these tasks are no longer possible to perform. It just means you’ll have to do them differently, just like the rest of humanity does when they want to get involved in an organization.

[Barrin92]

>Normal people will still be able to get involved if they want to,

there isn't much evidence that this is happening. When you eyeball the average age of maintainers on mailing lists these days for prominent open source projects like the linux kernel, it's been steadily creeping up, to somewhere in the 50s now I'd guess. There's a complete dearth of people in their 20s or even 30s in particular in positions of responsibility, there's no next generations of leaders.

That's fatal in the long run. You need to have an apprenticeship system or something like a vocational pipeline to engage people in a structured way so that you can produce talent and also be objective and systematic. Something like a guild system you have in the DACH region where companies survive centuries, and that's not because random people write mails, it's because there's a industry wide support system and training process.

[appreciatorBus]

Yes but that predates AI & projects rejecting pull requests, so I would argue this is a separate unrelated phenomenon. If anything, the fact that despite accepting PRs, most projects have little new blood, means that PRs were rarely a significant pathway for future maintainers.

[smartmic]

The path is not closed; it must be earned through trust. It has always been this way. Also, note that "pull requests" are a GitHub invention; the concept is not native to Git or most other SCM systems. Before, you would have to submit your patch by email. It would be reviewed by the "maintainer" (or BDFL), who would then accept or reject it. If your contributions are accepted several times, you may be able to earn the rank of "maintainer."

Returning to the topic at hand, the challenge for new developers is to earn trust. I bet there are ways to do so aside from the muddy swamp of GitHub's (AI) bazaar.

[creesch]

In this case they seem to be firmly closing the path though

> There will not be a separate process for submitting patches by other means. We do not want to create a shadow contribution system through issues, comments, email, or forks. External code can of course exist under the terms of the license, but we will not treat forks or patch dumps as a review queue for upstream Ladybird.

This does raise the question on how they are going to get new maintainers. The only thing I can think of is by active outreach to people contributing to adjacent projects that are still open. But that does not seem ideal to me as that will not yield people specifically interested and caring for the project you invite them to.

[grebc]

They don’t even have an alpha product yet. This used to be called vaporware but I’ll give them the benefit of the doubt that something will come in the future and they’re just focusing on fixing their own crappy code.

[fc417fc802]

The amusing thing is that emailed patches and a listserv aren't actually all that different from github pull requests at the end of the day. In either case you're sending some code you wrote along to a group and asking them to look over it. The only real difference is the lack of a familiar web interface that's uniform across all projects and reduces friction to near zero, but emailing a patch hardly adds much friction in practice.

I think the primary difference is that it removes some of the incentive to status seek because there's no centralized network operator tracking contributions and displaying them on your profile for others to look at.

That said, the linked post explicitly says that Ladybird won't be accepting emailed patches, reviewing changes from downstream forks, or anything else. Hopefully that's not the case since entirely closing off the project would probably be an overreaction as well as jeopardize its future.

[skydhash]

It’s really different because there’s no public signal between the email and the project itself. You can maybe search the log and see your patch, but there’s no central identity where you can brag about it. At most you can get a notice in a CONTRIBUTORS text file, or in the copyright header.

[hypfer]

Just uh.. build your own thing?

Boom. Maintainer. Easy.

Why would normal people even want to become an unpaid janitor for someone else's stuff?

[justin66]

> Why would normal people even want to become an unpaid janitor for someone else's stuff?

Social validation. Or, to be slightly more generous, sort of a compulsory way to force someone more experienced to provide some mentorship, by compelling them to review your pull requests.

[cestith]

That’s the point here, though. The maintainers of Ladybird don’t want to be compelled to mentor people making throwaway contributions without a commitment to the project. It’s pretty frustrating to try to mentor an absentee mentee who isn’t actually ready to learn from you.

[justin66]

I expect they'd like to not mentor new people attempting to make real contributions as well. Sometimes you're just not in a position to do that.

[CodeCompost]

> it more difficult to identify who to invite to join the priesthood.

How about this. Somebody forks the project and submits their patches to the fork . If the fork is successful (there are users actively using it), upstream can selectively go fish for the patches themselves. The maintainer of the fork eventually gets recognized.

Not ideal, I know, but building a reputation is meant to take time.

[thewebguyd]

I think whats more likely to happen is patches & forks stop being shared. If AI continues to improve, I see a world where people are mostly no longer making software for others, but purely for themselves.

I've done it, personally. I've made all kinds of little utilities for myself kind of like a woodworker making their own jigs. While not purely "vibe coded," AI has let me actually finish a ton of personal projects that have been in my "eh, maybe I'll get to that someday" list. Now that there is very low marginal cost to make these tools, they can be highly specific, and they aren't all that useful to others unless someone else has the exact same problem as me, and well if so they can try to vibe code their own tool.

We'll get to a point where most of the open source projects are reserved for large scale infrastructure, as a cathedral not a bazaar, and then the vast majority of end-user level software will be highly personalized, custom utilities that generally aren't shared.

[InfiniteRand]

This is also an option with AI patches, if your AI contribution is good enough, let it get proven in use, and then it can be considered naturally as the developers of the original project look at what's going on with similar projects.

[anilakar]

If you grew up in a junkyard, getting adjusted to the social norms of a bazaar might feel like your way of life is being threatened.

[cassianoleal]

In your analogy, is the junkyard the development model of vibe coding?

I look forward to the book: The Cathedral, The Bazaar and The Junkyard.

[pelagicAustral]

fwiw I asked Claude to look at GP's post and write me a story titled "The Cathedral, the bazaar and the junkyard" and I have a pretty good time reading his riff.

[multjoy]

“Its riff”

[pelagicAustral]

You're absolutely right...

[nonethewiser]

How many people will ask to be a "priest" and will then violate the rules around AI?

I suspect if you exclude by default but have a manual process for requesting access and permissive standards for granting access, you can eliminate most of the bullshit without really excluding anyone.