| Version control for a genuinely long-lived project is a problem that often outlasts: - Dominant version control and code review system(s) / paradigms. - The current configuration of institutional owners. - Users' trust in an owner / sponsor / maintainer. (Forks happen for reasons.) - The involvement of developers who remember why and how decisions were made. - The trustworthiness of the entities that control services, applications, and network real estate used for development. Some central source of truth is usually necessary, but maintainers and contributors don't benefit when that source of truth is subject to vendor lock-in or can otherwise only migrate at great cost. For all the collaborative benefit that GitHub has undeniably wrought, platform monopolies are eventually a failure mode for end users, at least as for-profit enterprises. With the exception of the dominant silo vendors, nobody in the ecosystem really benefits from being forced to choose a silo that will be hard (and lossy) to escape later. The silos are engineered to limit mobility and channel interoperability to their own ends, for business reasons that run directly contrary to the interests of their users. If the protocol at hand were actually up to the task, we'd spend less effort and anxiety on the problems of all the non-protocol platform tooling that's been built up around it. |