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.

2 Answers 2


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.

  • 1
    Reading OP' question, looks like he's more worried about copying the "idea" than really refactoring the code. I would pay attention to the licence and possible patents (if any).
    – Laiv
    Commented Sep 19, 2017 at 6:26
  • I'm more concerned about using the software. For example, if original maintainers or someone else make the existing software perform in such a way that I can do composer install software_x, which installs the software for me, and there is a example skeleton app showing me how to integrate that software into my own existing app architecture, then I will do just that, without any refactoring or copying. My interest is in using functionality provided by the software as a library. In its current form, it is not a library and there is no easy way to integrate it with any existing architecture.
    – Dennis
    Commented Sep 19, 2017 at 17:34
  • 1
    @Dennis Then you should make the minimum changes to support that and submit them as a pull request. The maintainers may consider those internal APIs to be private and not want to commit to maintaining backwards compatibility for them. In that case or if the "minimum changes" are extensive, you should just fork the project and make the changes you like (again, following the license). It's less of an issue if the result is less of a substitute for the original and specific added functionality warrants the extensive changes. Commented Sep 19, 2017 at 21:32

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.

  • Thanks. I do not have write access to the repository. But I can fork it and have write access to my copy of the repository. I can do the small change as you describe in your first paragraph but there will likely be a lot of those small changes, tens if not hundreds, since I do plan to make significant refactorings, and if changes are to be small, there will be a lot of them, putting burden on original maintainers who might naturally push back on such changes. The rest makes sense. Making my own fork is likely the course to take.
    – Dennis
    Commented Sep 18, 2017 at 20:52
  • I guess then it becomes more of a social graces question where do I notify original maintainers of my plans or just have my actions show them what is happening. They might care or might not care, either way
    – Dennis
    Commented Sep 18, 2017 at 20:52
  • @Dennis: Small changes are manageable. 100 small changes are much easier to review than 1 huge change. It's also much easier to keep everything working with one small change after the other.
    – gnasher729
    Commented Sep 19, 2017 at 20:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.