I agree with you - my experience has been the same. In the past you'd have had to work out a patch by hand and then perhaps publish it somewhere, which was a pa

I agree with you - my experience has been the same. In the past you'd have had to work out a patch by hand and then perhaps publish it somewhere, which was a pain to do and so didn't happen often. Now the tools have improved making this much easier and so is happening much more everywhere. I have personal branches of the Linux kernel and a dozen or more libraries, and can keep them up to date easily. But the process remains the same. Your fork is no doubt invaluable to you, but unless the original maintainer pulls your patch, your fork is likely to be a dead end in terms of development - except perhaps for the odd person who needs to fix the same bug and finds your patch. My point is that the development model has not changed. The maintainer can still optionally pull in your patch, or not. Most users will continue using the maintainer's releases. If the maintainer drops the ball then there will be a fork - but that would have happened in the past anyway. Distributed version control has been a revolution - but a revolution in tooling, not of the centralised release model.