...
- Avoid doing purely internal development that is then “thrown over the wall” without discussion to an upstream community, with the expectation that it will be implemented in its entirety. Large patches merged without iterative feedback, especially if developed by people within the same company, will raise red flags and instill a sense of community mistrust for that company that may take a very long time to overcome. Always ensure that large features are planned publicly, with community input.
- Don’t limit yourself to maintaining downstream-only changes. Because open source projects are often the consumers of other projects, a downstream-only focus can result in costly refactoring of code to consume new upstream changes. Make sure to maintain changes upstream and keep your downstream (proprietary) work aligned with upstream releases.
Steps to Upstreaming - “I have a great idea for a feature... now what?”
The engagement model for contributing new code may vary slightly from Project to Project. (For clarity, typically Project refers to the collective platform, such as ODL or PNDA, whereas project refers to the individual development efforts or repositories approved as part of the Project.)
...