[xerxes901]

> Which means your changes have to go through the Ruby team first. Any additional changes would also need to go through them …

I do want to pick on this specifically - people can and should be patching open source projects they depend on and deploying them to production (exactly as described in the article). Something being in the language vs in “user” code should be no barrier to improving it.

[simonask]

There's a pretty huge difference between implementing a performance optimization that works in your use case, and upstreaming that optimization to be generally usable.

The latter is often orders of magnitude more work, and the existing solution is probably chosen to be well suited in general.

[gmueckl]

Patching a dependency comes with significant downstream costs. You need to carry the patch forward to new upstream versions . This implies remembering that the dependency was patched, extracting a patch from the existing changed code, and reapplying the patch, fixing comflicts, recompiling the now special version of that dependency and running tests, checking/updating required license notices accordingly.

This is in essence another form of technical dept.