are you thinking about opensource? I don't think it would be opensource
You do it the same way exploit writers do. Attach a debugger to the process, find the memory address of the resource you want to modify, overwrite the address with the address of the modified resource you want to execute. You could also just use the debugger to force the program to execute functions with arguments you specify, that way you don't have to worry about mucking with the memory.
Usually you'd create a dynamic library that interposes a function, so you don't have to much around with using a debugger. This way you have a persistent modification that's much more resilient to changes caused by app updates. Exploit writers generally have different goals: their thing only really needs to work once, and only with the current configuration, since usually the bug they're relying on gets patched in the next version.
Nope. There are ways to reverse engineer closed source apps and inject code into them.
Also, depending on the platform, if a native application is following the platform guidelines, then quite a lot of things you want to change might be located in data files or "resource" section of the executable.
I haven't been messing much with Windows executables for quite a while, but back in the day, I'd "improve" many programs by just editing their resources.
As someone who messes with native apps: this really isn't true, at least in my experience. Native apps tend to follow platform paradigms, which usually make them reasonably well designed and structured–sometimes more so than web applications. Usually adding functionality is simply a matter of finding the class that manages the component, rather than digging thorough a bunch of broken CSS (for IE 6 support) and minified goop.