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
