For me it has been a revolution. No language, framework or concept has changed my development process more in the past decade.
I have been able to contribute patches (both code and documentation) to many projects where I otherwise would have not had the time or energy to bother contributing.
Sure, my previous attitude may have been selfish, but if it took an hour to fix a bug in a library that I am using for a throwaway script, I am not going to spend another hour subscribing to mailing lists, emailing developers and then persuading them that my patch is worth merging.
In GitHub I just fork, push my patch, and notify the owner of the original repo. If he chooses to pull in the patch, that is his problem. If anyone else who is having the same problem wants to use my repo, they can do so.
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.
I just fork, push my patch [...]. If he chooses to pull in the patch, that is his problem.
This attitude is dangerous. It works very well for trivial patches, but not for complicated bugfixes, because those are usually buggy themselves. Accepting a bad change is as dangrous as not acceping a good change. So you'll have to stay in touch with each other, communicating via IM, email or a tracking system, until the issue is really solved.
And yes, this process is greatly supported by DVCS.
However, it only works if the contributor comes with an attitude like "I want this bug fixed in upstream" and not with an attitude like "Here is my patch - use it or don't".
Practically, that's just not workable long term. Ideally, you want to keep using more or less the same library as everyone else, otherwise versioning becomes even more of a nightmare than it already is.
I have been able to contribute patches (both code and documentation) to many projects where I otherwise would have not had the time or energy to bother contributing.
Sure, my previous attitude may have been selfish, but if it took an hour to fix a bug in a library that I am using for a throwaway script, I am not going to spend another hour subscribing to mailing lists, emailing developers and then persuading them that my patch is worth merging.
In GitHub I just fork, push my patch, and notify the owner of the original repo. If he chooses to pull in the patch, that is his problem. If anyone else who is having the same problem wants to use my repo, they can do so.