Unless you are doing it wrong.
And sadly I`m seeing more and more people doing it wrong.
To a lot of people Open Source means that they have a piece of software that does almost what they want and which they can modify to their best wishes and use internally.
So they fork locally,, they don't redistribute their code , but they aren't contributing their changes back upstream, chances are these changes wouldn't be accepted upstream anyhow as they are really customizing the code for their specific cases. At first sight this doesn't look so bad , at second sight ..
When weeks or months later the upstream project releases an urgent security fix, the local fork has deviated soo much that it can't upgrade anymore and stays with an insecure version.
Often it's worse.. a feature that could have been accepted upstream has been implemented slightly different in the local fork, the result being that newer features depending on the first one also can't be integrated anymore
Some projects are prepared for local contributions, they have a modular framework that allows you to build on top of the project while not having to touch the core of a project, Drupal and openQRM are great examples of those, but not all projects are that smart. Needless to say that when you have such a modular framework you really shouldn't be modifying the core part of the platform, unless you are fixing a real bug.
But the general rule of thumb is that when you fix bugs, make sure they are inserted upstream , or implement new features.
Now sometimes there is no easy way to get your code accepted upstream, in which case you should announce clearly that you want to contribute but you are blocked and publish the patches somewhere else ...
Don't let the community work for you, but work with the community !
