# Adopting an Ecosystem Component Inherits Its Maintenance Risk ## Claim Choosing to assemble a platform from existing ecosystem components instead of building from scratch does not eliminate the build cost — it defers it to whoever has to take over maintenance if the component goes unmaintained. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Applies specifically to load-bearing dependencies — components a platform's core function relies on, not incidental tooling that's cheap to replace. - The risk is contingent on upstream project health, which is knowable in advance (commit activity, maintainer count, archive status) but frequently isn't checked before the dependency is adopted. - Doesn't argue against assembling from an ecosystem — only that "we don't build from scratch" is true at adoption time and can become false later, and the team should budget for that possibility rather than treat assembly as a one-time cost. - Breaks where the component is genuinely interchangeable — if an archived project can simply be swapped for a maintained alternative without forking, the inherited cost is much lower. ## Evidence Preferred Networks frames their platform philosophy as "we no longer have to build everything from scratch — we can assemble the platform our use case needs." In the same talk, without connecting the two: the Hierarchical Namespace Controller they depend on for tenant structure was archived upstream, and they now maintain their own fork; separately, their gang scheduler is a custom plugin because upstream Kubernetes support isn't ready. Two of the platform's load-bearing pieces required building or adopting orphaned work — the exact activity the "assemble, don't build" framing was stated to avoid. ## Links - [[3. Resources/Permanent Notes/Cheap Generation Raises the Total Maintenance Bill]] — because extends; a different mechanism (AI-cheapened code generation vs. ecosystem adoption) converging on the same structural point — the cost that looks avoided at creation time reappears at maintenance time - [[3. Resources/Permanent Notes/Maintenance Is Most of the Work but Gets No Prestige]] — because applies-in; the fork-maintenance work this team now owns is exactly the invisible, unglamorous labor that pattern describes - [[3. Resources/MOCs/Open Source Governance MOC]] — because applies-in; evaluating upstream project health before depending on it is a governance practice, not just a technical one ## Tests / falsifiers - Check whether teams that evaluate upstream project health (commit recency, maintainer count, archive risk) before adopting a component experience lower rates of inherited-fork maintenance than teams that don't — this would show the risk is manageable with due diligence, not just unavoidable. - Find a case where an archived dependency was cleanly swapped for an actively maintained alternative with no fork required — this would bound the claim to cases where no substitute exists. ## Maintenance - Last tended: 2026-08-16 - Next review: 2026-11-16 ## Source - [[3. Resources/Literature Notes/Building a Multi-Tenant AI Platform with the CNCF Ecosystem]] — reports the HNC fork and custom gang-scheduler as unacknowledged counterexamples to the talk's own "assemble, don't build" thesis.