Teams own everything. Individuals own nothing.

On GitHub, your profile page shows your repos, your contributions, your activity graph. Code lives under your username. You fork repos into your personal namespace. Your identity as a developer is tied to your individual output.

gittan has none of this. There are no personal namespaces. No user profiles with activity graphs. No individual contribution metrics. Every repo belongs to a team. Every push is a team activity. The individual is a member of a team, not an independent actor.

This is not an oversight. It is the core of the product.

Why team ownership produces better software

When an individual owns a repo, they become a bottleneck. They know the code best. They review all the changes. They are the person you ask when something breaks. When they go on vacation, progress stops. When they leave the company, knowledge leaves with them.

This is the "bus factor" problem, and it is not hypothetical — it happens in every organization that lets individuals own code. The owner becomes a single point of failure. The team learns to route around them instead of sharing ownership.

When a team owns a repo, knowledge is distributed by default. Multiple people push to the same codebase. Multiple people know how it works. When someone is unavailable, the team continues. There is no hero developer whose absence blocks everyone.

No individual metrics

gittan does not track individual contributions. There is no "lines of code per developer." No "commits per week." No activity heatmap on a personal profile. These metrics are not just useless — they are actively harmful.

The Accelerate research is clear: measuring individual developer productivity does not predict team performance. Worse, when managers use individual metrics to evaluate performance, developers optimize for the metric instead of for outcomes. They split commits to inflate counts. They avoid refactoring because it shows as negative lines. They push trivial changes to keep the activity graph green.

gittan tracks team metrics inspired by the DORA research: push frequency, pipeline lead time, rejection rate, recovery time. They predict team performance and they cannot be gamed by a single individual inflating their numbers. A team that pushes frequently with low rejection rates is performing well. It does not matter who wrote which line.

Permissions follow teams

Access in gittan is team-based. You are a member of a team. The team has repos. You have access to those repos. There is no per-user repo access, no individual collaborator invitations, no "give this one person write access to this one repo."

Team membership comes from your identity provider's groups claim. When your IdP says you are in the "payments" group, you get access to the payments team's repos in gittan. When you are removed from the group, access is revoked. No manual management. No access reviews. No "who has access to what" audits — your IdP is the source of truth.

This eliminates an entire category of security problems. There are no stale personal access grants. There are no repos that only one person can access. There is no scenario where someone leaves and you discover they were the only person with write access to a critical service.

Collective code ownership

Extreme Programming introduced the concept of collective code ownership: all code is owned by the whole team, and anyone on the team can change any part of it. This practice predates both the DORA research and Team Topologies, and both frameworks validate it — shared ownership reduces bottlenecks, increases knowledge distribution, and improves quality.

gittan's permission model makes collective code ownership the default, not an aspiration. You cannot set up individual ownership because the concept does not exist in the system. Every team member has the same access to every repo the team owns. The code is the team's responsibility, not any one person's.

This also changes how people think about code quality. When your name is not on the repo, you do not feel defensive about feedback. When anyone can push a fix, problems get fixed faster. When the team's metrics reflect the team's work, collaboration is the natural response — not territory.