Bad idea not contributing back local changes

Add a paragraph about how it's a bad long-term strategy to
hold to local changes and not contributing them back upstream.
This commit is contained in:
Thierry Carrez 2018-11-10 13:50:55 +01:00
parent 0d901be790
commit 9339c77d28

View File

@ -95,6 +95,15 @@ successfully demonstrate compatibility by passing a suite of interoperability
tests, run against the public API of the product. In this way, the scope of tests, run against the public API of the product. In this way, the scope of
modifications is limited. modifications is limited.
Furthermore, in the case of fast-evolving infrastructure software, it's worth
noting that keeping local changes private is not a great long-term strategy.
Maintaining a delta between code running in production and fast-evolving
upstream open source code is very costly, and gets more difficult as time
passes. Technical debt adds up quickly to a point where paying it back is
impossible. Engaging upstream to propose your local improvements and finally
getting most of them in the open source project itself is the only sane
way forward over the long run.
References References
---------- ----------
.. [#OSI] https://opensource.org/licenses/alphabetical .. [#OSI] https://opensource.org/licenses/alphabetical