Not really. Notice that grandparent said &quot;the situation is even wilder in the closed gardens&quot;. It still exists in open source. Rolling back a set of packages to some older state isn&#x27;t a trivial operation, and rewrites are incredibly expensive no matter who&#x27;s doing them.<p>Open source is a prerequisite, but this isn&#x27;t a solved technical problem. The challenge is to make codebases <i>rewrite friendly</i>. The bottleneck isn&#x27;t the rewrite itself, it&#x27;s all the risk due to the regressions that rewrites tend to cause, and all the stress from trying to catch these regressions before a release. I&#x27;ve been working on ways to express more tests than our current (c 1970) unix stack can support. The goal: to be able to certify a release to production just by running its automated tests. No large projects today meet this standard. Once we do I think we&#x27;ll be in much better shape to undertake dramatic rewrites, and to reuse code between projects&#x2F;rewrites.<p>(More info on my project: <a href="https:&#x2F;&#x2F;github.com&#x2F;akkartik&#x2F;mu" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;akkartik&#x2F;mu</a>)