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:
parent
0d901be790
commit
9339c77d28
@ -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
|
||||||
|
Loading…
Reference in New Issue
Block a user