How the dependency formed
A longitudinal note. Dependency rarely arrives in a single decision.
Adoption typically begins with source hosting. Actions absorbs CI within a year or two, Packages absorbs artifact storage, and GitHub identity becomes the access layer for engineering tooling.
By the time issues, projects, and code review are also authored on the platform, the engineering operating model is GitHub-shaped.
The platform read through the five frameworks
Each section applies one of the System Drift frameworks to GitHub.
Dependency Concentration
Concentration spans source, CI, artifact storage, identity for developer tooling, and a growing share of project workflow. The dependency is wide within engineering and increasingly extends into security tooling.
Concentration is reinforced by tight integration between surfaces, which is also what makes the platform productive.
Observed indicators- —CI logic is expressed in Actions workflow files.
- —Identity for developer tools federates through GitHub.
- —Issues and project boards are the engineering plan of record.
Reversibility
Reversibility is moderate. Repositories are portable; Actions workflows, GitHub-specific permission models, and the issue/PR history are less so.
Reversibility decreases as the platform absorbs more adjacent surfaces.
Governance Surface
Governance lives in branch protection rules, required reviews, environments, and code scanning policies. Change control is increasingly expressed inside the platform.
Where this is the case, GitHub is the governance surface for code change.
Operational Capture
Capture is highest in CI and release engineering. Workflows are written against GitHub-specific runners, actions, and secrets handling. The release process is the platform's release process.
Capture also extends into issue triage and project planning when those move on-platform.
Exit Complexity
Exit complexity is dominated by CI rewrites, the loss of GitHub-specific PR and issue history as a navigable artifact, and the re-federation of developer tooling.
Institutional memory of why a workflow is shaped as it is rarely survives a migration intact.
What separation would involve
A description, not a recommendation.
Separation would require migrating repositories, rewriting CI against a portable runner model, reconstructing issue history in a replacement system, and re-federating developer tooling identity. The dominant cost is CI and review history, not source.
Editorial note
This profile is a dependency study, not a product review. It is not a buyer's guide, a feature comparison, or a recommendation. It does not argue that GitHub is good or bad. It documents how the platform shapes organizational behavior, where concentration accumulates, and what separation would involve.
The framework readings are revised on the transparent methodology cadence. The indices are analytical signal, not procurement advice.