I think there is one more more version for people to run their own fork, which is "I can land fix/improvements to my internal fork faster than having it accepted/landed in the open-source, so I will land it locally and then upstream it." Over the period of time, the maintenar will lose track of the upstream tickets because internally it got already landed/working. Eventually, the fork will end up with many more custom patches and then people are forced to continue with the private fork forever.
Jaydeep On Mon, Oct 20, 2025 at 12:37 PM Jeff Jirsa <[email protected]> wrote: > There’s a variant of (1) I’ve seen at multiple past employers, which is > “we have a problem right now and we’re not sure what the long term fix is, > but we’re addressing it internally and may do something different long term > in the public repo.” It’s not actually about bespoke integration, it’s more > about nascent ideas that get tested and deployed and iterated on. For > example, early TWCS started out as a DTCS patch that used an alternative > timestamp in the sstable metadata with the old DTCS tiering logic before > the approach changed into avoiding the tiering and using the existing > timestamp. > > > > > > On Oct 20, 2025, at 12:24 PM, Josh McKenzie <[email protected]> wrote: > > We had a long conversation about the potential of piloting a supported > backport release branch here: > https://lists.apache.org/thread/xbxt21rttsqvhmh8ds9vs2cr7fx27w3k > > When I tried to summarize the thread and identify next steps, one > observation stood out: I think we did a good job establishing the shape > of the challenge we'd like to address (people want to work on OSS, not > maintain private forks), but I don't think we got to the root of why this > challenge exists. If we take action now we run the risk of having the wrong > solution to the right problem. > > So: why are people running forks? Some reasons I've seen brought up: > > 1. You need bespoke code to integrate with internal infrastructure > 2. You've written a new feature targeting your internal version, > upstreamed the code, and have to wait for the feature to be in a GA release > 3. Someone else has contributed a feature to trunk that's attractive > and it's less work or more palatable to back-port it to your private fork > and maintain the diff than to qualify a custom release off trunk > 4. You have stability concerns with GA releases or running a release > based off trunk > > The backport branch we discussed in the previous thread would primarily > address #4 (stability concerns) and secondarily #2 and #3 (feature > availability). All four motivations could be addressed in other > ways—ideally by reducing the pressure to fork in the first place, rather > than accommodating forks as inevitable. > > If you're running a fork and open to sharing your experience, do these > reasons match yours, or is something else at play? The more detail we can > gather, the better we can target improvements where they'll actually help. > > I know these conversations take time and can be hard; I appreciate > everyone taking the time and energy to help us collectively improve. > > ~Josh > > >
