...
- Avoid doing purely internal development that is then “thrown over the wall” without discussion to with 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.
...
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 PNDAONAP, whereas project refers to the individual development efforts or repositories approved as part of the Project.)
...
The real power of open source development is that many differing perspectives will generate the best outcomes. This may involve highlighting new functionality that never occured occurred to you, or uncover a different use case that your proposal cannot address. Take the community’s input to heart because when comes time to seek approval, if there is some key element that you failed to address, someone will bring that up.
...