We spoke in an earlier article about why organisations that use FOSS projects might choose to contribute any changes they make back upstream.

If you become involved in such a situation, there are a few things to consider. The requirements vary between projects, but there are a few general things to keep in mind.

Your code is not a gift, it is a burden.

Unless both you and the maintainer of the FOSS project happen to want a feature that the maintainer of the FOSS project simply hasn't gotten around to implementing yet, your code is an unwelcome increase to their maintenance burden.

Adding a feature is adding more code that may have bugs hiding in it, more code to compile, more code to test, more code to distribute in releases, more code to change when requirements inevitably change etc.

Nobody likes surprise code.

Make yourself known to upstream.

Let them know what you intend to change, along with your reasoning and your goals where possible. Upstream maintainers can possibly tell you about better ways to make the change; if the relevant part of the code is going to be changed by someone else soon then you would get to know whether you need to throw all your changes away in a week, or even if they won't accept such a change and suggest an alternative.

When the time comes to submit patches it will have been a collaborative effort, so nobody will be surprised, and upstream will be pre-disposed to considering your code for inclusion.

Particularly, it gives some confidence that you will be around, to ask questions of, should bugs be found.

Build up some good will.

Your aim should always be: to have a net positive benefit to the project.

A feature every project wants is simply to be "Not buggy", so if in the process of adding your required feature, you find and fix some bugs, then the rest of your patches are much more welcome.

If a project has a TODO list, then doing a few items on it is also valuable, since it shows an awareness of the needs of the project in line with your own needs.

Continue to participate.

Code needs to change, and it helps if you can continue to test the changes you contributed.

A test suite including test cases greatly helps reduce the maintenance burden, but if the interface changes sufficiently, then the tests may need to change, so it helps if you are around to be asked if it still works for you.

If you are not actively participating in a project's community, then you could find your code removed simply due to a lack of support.

If you are successful in interacting with upstream then you have benefitted by having your code included, and so upstream continues to support your desired feature in all its future versions.

As an added benefit you may have some amount of say in the future direction of the project. Furthermore if you found yourself needing to change the project for one reason, then you may find yourself needing to make further changes for another. After the first hurdle, future changes are easier.

From a personal development point of view, participating properly grants both some job security and an increase in your marketability, since this relationship with a FOSS project has value for an organisation which wishes to make changes.