What is the protocol to follow if I wish to make significant changes to software in someone else's public github repository?

Question

For example, I find myself using software X.

Software X has a github repository. I find that I can make a lot of serious refactoring changes that are not small, and reconfigure the entire repository to use a different software methodology. i.e. software X is written using procedural style non-object-oriented coding. I wish to convert it to be modular, object-oriented, more in-line with various recent industry trends.

Do I... just fork the repo and start hacking?

Do I ask software X maintainers first? I have my own ideas on where I wish to go with this, and do not particularly wish to be encumbered by the ideas of the original maintainers.

Answer 1

My impression is that you can, if you'd like, contact the author and see if they would be interested in the change. They will likely want to have an idea of what sort of changes you want to make and will probably want a small example of the refactoring. This is assuming they are even open to the idea. They may have reasons (good or bad) for doing things the way they are currently doing them, e.g. performance, essentially ideological preferences, or their own comfort with the techniques you want to use. Even if they agree with you that your changes could be beneficial, the project may be in a stable state where a "if it's not broken, don't fix it" attitude is not unreasonable. There is a chance that they will offer to add you as a maintainer, or even offer to have you become the maintainer, if they aren't particularly keen on being responsible for the code and they believe you are willing and able to take the responsibility. This likely won't happen immediately though.

The above is necessary if you want the current maintainers to take your changes into their version. It's not necessary if you don't particularly care about that. In that case, you can just make a fork and do whatever as long as the license allows it. If the fork is primarily for your own personal use, they probably won't even be aware of it. If you promote it as an alternative to the original library, then the original maintainers will probably not be happy if you didn't communicate with them beforehand, and may not be happy either way (though that will probably be obvious ahead of time if you communicated with them beforehand). That said, as long as you follow the terms of the license, they can't stop you. Third-parties may also be unhappy with unnecessary forking as it adds noise to the ecosystem making it harder to find quality, maintained libraries.

On the other hand, it's unclear why you even want to do this. It largely comes off as you just don't like the way they coded it, and you would've done it differently. I don't see why this should matter to you as a consumer. Technically, a refactoring is a semantics preserving change, and thus if your changes were really refactorings it would make no difference to any downstream consumers. However, I suspect you are using the term in a broader sense, and what you really want is a different API for the library. It may well be possible to do this as a wrapper around the existing library in which case there is no need to coordinate with the current maintainers and the maintenance burden on you for the wrapper will likely be significantly less.

Answer 2

You have actually write access to this repository?

The way to do this would be to make a change that is small enough to be reviewed, and then to post a pull request so that someone can review your change and merge it into the repository. And then you make the next change and so on.

Or you fork the repository. Take it as it is, make a copy, and that copy is yours. In theory, you do what you want. In practice, you do exactly what I said in my first paragraph, except that you can be the reviewer yourself if you don't find anyone to do it.

What is essential is that after any such change, you test enough to be sure that everything is still working the way it should. Because you plan to make big changes, so if you find two months later that some change was rather rubbish, you have a problem. Writing tests that pass before and after your changes helps.