[Jtsummers]

> I’ve always believed there should be way more forks, both personal and maintained ones.

There aren't more forks because once you fork something you take on the burden of synchronization, or you forfeit the benefit of future upstream work. To focus on Ghostty, Mitchell has taken on the effort of maintaining cross-platform support. If I want one specific feature (or even a bunch of features) and create a custom fork, but then GTK changes, now I have to support that change myself (assuming it is relevant to me or my community of users), or figure out a way to integrate Mitchell's changes into my fork, or I risk losing my customizations by having to rollback to baseline if the differences between my fork and baseline are too great.

If the system is well-engineered (the work on libghostty helps here) then you can keep that common core without forking, and fork just things on the periphery of the system. But well-engineered is not common.

[tecoholic]

By making “upstreaming” the core of OS contribution, we have also failed to build tooling around downstream synchronisation. There are dedicated browser forks (a very highly complex software) that are maintained by a few volunteers. So maintaining 1 or 2 additional features depending on personal choices (or a specific company’s) shouldn’t be that hard. If we have a world where that’s normal, we will have a bigger talent pool in core tech, cloud vendors would have a hard time selling hosted solutions of open source software..etc., I think we left a good chunk of net positive impact on the table by what Mitchell mentions as the “open source project as a product” approach.

[NetMageSCW]

Perhaps this is one place AI could prove very helpful - automating the synchronization of forks with their parents while keeping the changes that constitute the actual fork. Or perhaps something other than forking is needed that is more diff based so you have a view of the source overlaid with the fork and the parts unchanged flow through. At least until something like Bun’s change from Zig to Rust blows your fork up completely.

[Cilvic]

I've been thinking about this as well. How can people "AI federate" their forks, without relying on a single maintainer.

Mostly because in the pi.dev ecosystem there are so many similar extensions and usually everyone wants their own little special something, but then everyone could benefit from maintenance updates/bug fixes.

[the_gipsy]

You should address the point Mitchell made: maintaining a fork is roughly the same as maintaining a feature flag.

[Jtsummers]

> maintaining a fork is roughly the same as maintaining a feature flag.

He didn't say that in the interview. Or, he didn't make nearly as broad a claim as you have made. He said:

>> If you want me to maintain a flag to remove it, I can ask you to maintain a fork removing it. Telling people to “fork it” often upsets them.

The context of his statement was people wanting a feature (search as one example) removed (or removable, via feature flag). In that case, the fork is about as hard to maintain as the feature flag, assuming the software is reasonably well organized.

But in general, your claim is not true, and it's not what he wrote.

> You should address the point Mitchell made

No, I have no obligation to respond to something that he didn't say.

[the_gipsy]

You're right, he said the request is equivalent.

Also, take it easy, it was merely a suggestion. The interesting part was comparing a feature/flag/branch to a fork, to me.