Comment by gorgoiler

12 hours ago

In my experience it’s extremely difficult for a highly resourced corporate engineering team to get married to an open source project run by volunteers, consensus, or both. It is possible but you need to have a first class relationship with an upstream who will take your patches.

Every patch delay puts more pressure on you and your team to fork the codebase and go it alone. You and your team sit down and promise you’ll rebase over upstream releases and everyone nods wisely. Then you skip a release, and another, and presto: you now you have Bank Redis or Bank Selenium or Bank Hadoop trapped on the last version of upstream before the fork but to which you can patch changes as fast as you like. I’d liken this to crossing an event horizon except the astronaut sees the universe freeze and fade away instead of the outside observer.

It’s possible to make it work if the upstream project either gives you a majority vote (or at least a substantial share of the vote) on project direction, or you’re working on a project large enough to have lots of corporate (ie funded, high velocity) stakeholders already.

Yes, agreed. And it's not just delays - when the upstream decides that they actively don't want to take a patch that you have a burning need for (and maybe you already have systems in production depending on it), that can accelerate the process to Bank Redis a lot.

I've rolled with the "we'll keep a local patch against upstream" for small changes before, which helps keep on track with upgrades, but depends how feasible that is.