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: > You need bespoke code to integrate with internal infrastructure > 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 > 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 > 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 >
