There is no such thing as "hacking" a module. Refactoring code is a normal thing. If you are nice enough to present a patch, persistent and lucky then your code or contribution can be pushed into the main branch of the module. But often this does not happen because "every man's drink is not wine". This why git and sites like github are so fantastic. You can fork, branch and merge collectively to get better code, more functionality and more flexibility in the community.
Pixeljets shows Drupal developers how to prevent the loss of refactored code through the use of the automated update system.
Okay, every honest Drupal developer knows, that hacking core is a bad thing. Hacking contributed module is not the best thing in the world, too — for obvious reasons: modules get updates , and updating module is very easy, unless you’ve applied some hacks to it.
But, sometimes, we need to apply some changes to some contrib module. If it is a big customer site, we can’t just say “Hey guys, your team can update this module and this module using drush, but don’t touch this module, please!”. That’s just ugly, that someone needs to remember such stuff — and I bet that in 2 weeks they forget and download new version of module from Drupal.org. And all our work is lost.
So, the solution here is to disable specific module updates automation.