What is the general workflow when I want to add a feature to an open source application I didn't originally write? How do I get to know the code? How do I find the spot that needs to be changed or added? How do I actually make the change without breaking anything else? How do I test that everything is still working?
What are the general guidelines on such a project?

  • 2
    You should also submit your changes to the project, typically as a patch, so that others can benefit.
    – Mechanical snail
    Aug 22, 2011 at 1:10

2 Answers 2


There's some protocol, everybody more or less desumes it with time, but here it is, unrolled.

  • You download the distributed source.
  • You start navigating the code by yourself a little

    • If it's a compiled program, you learn now how to compile it.
    • If you fail compiling it, you report to the author / mailing list and ask directions
  • If you don't really understand a thing about the code...

    • Well, no, you don't ask them nigh.
    • You drop that, as you're probably not up to par and cannot be of any real help.
    • You submit a feature if the author(s) accepts feature requests.
  • Else

    • You find the spot you want to change.

    • If you wonder about some minor detail, you ask the author / mailing list , and explain your intentions.

    • You cd to the main directory of the distribution (the top one coming out of the untarring/unzipping)

    • You diff -ur . > mypatch.path

    • You send mypatch.patch to the author explaining what you did, why you did it, and (as you're already there) you state clearly that you waiver the rights on the patch to them.

  • if the author(s) doesn't like your contribution

    • you check if there's a way to release your modification as a plugin of some kind

      • in that case, now you're on your way to become a plugin mantainer.
    • else

      • you flame about the situation on your blog and release the patch there, free to download and try with your explanation and your rants,

      • you haunt now and then the bug system / mailing list trying to buy support for your patch. Avoid getting banned.

    • in none of these cases you fork the code, as it's a very tiring and unrewarding process you will hardly be able to keep up with time: that will leave users sad and confused. Forks shoud really only happen when a big corporation is trying to bully his decisions on a piece of OSS.

  • else

    • you receive further instructions from that author(s)

On the side: there is a recent alternative to the diff -ur . patch and is the github way.

  • You "fork" their code on github under your name,
    (now you have a copy of their code on your account)
  • connect your git to that personal copy of yours,
  • make your modifications on that, check them in,
  • and tell the main author(s) to look at your github project.

  • If they like it, they will syncronize.

  • Otherwise, you can link your "gitfork" on your blog.
  • All good until you suggest the OP flames the product authors for not embracing the new feature patch, it's unclear if this was supposed to be funny or serious, either way, it's VERY bad form to effectively cry like a little kid to the whole world because a product team don't like/want your new feature patch. By all means, post it up but always be magnanimous if it wasn't accepted, regardless of how illogical the decision seems to be. -1 - FYI, I'll happily reverse my vote, if you remove that.
    – ocodo
    Aug 22, 2011 at 4:19
  • The application I want to change is following a strict standard which with my changes will break the standard. I think I'm not even in position to ask my patch to be applied.
    – Daniel
    Aug 22, 2011 at 4:27
  • @Slomojo OSS is full of immature people, and that kind of thing happens all of the time, everybody should be prepared to work like a mule and then be rejected on basis that sometimes are solid and sometimes are moot. And then, at least, you always have the chance of ranting about it and find people that feel you maybe are right. Now, forking out of spite, that would be the wrong and very kiddish step to take.
    – ZJR
    Aug 22, 2011 at 4:30
  • @Dani lol, you'll really have to take the share a patch and rant about it way. Avoid forking as it will consume your life, it feels like refactoring continuosly without a paycheck. ...anyway, check with the mailing list and the bug report system if there's one, to see if anyone would be interested in such kind of extension, maybe you're not alone. Aaaand the best would be of they had some API to extend or a plugin-thing to plug your changes into. That is always the best option in such cases: mantaining a plugin. ...will edit that in.
    – ZJR
    Aug 22, 2011 at 4:34
  • 2
    if there are automated test cases, run them before you submit the patch.
    – Rommudoh
    Aug 22, 2011 at 7:49


If it was a random OS project, you would most likely fix minor bugs here and there.

Eventually you would submit a a bunch of changes, as a "patch".

Usually you would get commit rights if your stuff is good.

I'm talking generally and as vague and nonspecific as possible due to the question

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.