undefined

points

[-]

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.

by NetMageSCW19 hours ago|

prev|

[-]

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.

by Cilvic11 hours ago|

parent|

[-]

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.

by the_gipsy9 hours ago|

prev|

[-]

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

by Jtsummers3 hours ago|

parent|

[-]

> 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.

by the_gipsy2 hours ago|

parent|

[-]

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.