Why there are no stars, forks, or social features

GitHub has stars. GitLab has stars. Every git host that copies their model has stars. The assumption is that a repository's quality correlates with its popularity. A repo with 50,000 stars must be good. A repo with 3 stars must not be.

This is nonsense. A repo with 50,000 stars and a 200-second CI pipeline, no tests, and a single maintainer who burned out two years ago is worse than a repo with zero stars, 8-second CI, 90% test coverage, and a team that deploys daily. Stars measure reach, not quality. They are a marketing metric, not an engineering metric.

What we measure instead

gittan shows team metrics inspired by the DORA research: push frequency, pipeline lead time, rejection rate, and recovery time. Two map directly to DORA metrics, two measure the push gate instead of production. They tell you whether a team is shipping effectively — not whether their repo is famous.

These metrics are visible per team on the dashboard. They are not optional, not behind an analytics add-on, not an enterprise feature. Every team sees their delivery performance because that is the thing that matters.

No forks, no stars

gittan has no explore page, no social graph, no star counts. Stars, forks, and followers are features of a social network for open source. gittan is a tool for teams that ship — not a discovery platform.

Repos can be public — the world can read the code, clone it, and use it. But there is no fork button, no contribution flow from strangers, and no social features around the code. Public means readable, not social. The team owns the repo, the pipeline gates it, and if someone wants to contribute they talk to the team.

Everyone on the team has write access — you push to the repo directly. If you need to experiment, use a feature flag, not a fork. Forks create divergence. Trunk-based development eliminates it.

No activity graphs

The green contribution graph on GitHub profiles has become a proxy for developer productivity. Hiring managers look at it. Developers feel pressure to keep it green. The result is commits for the sake of commits — not for the sake of shipping.

gittan does not show individual activity. It shows team delivery. Did the team ship this week? How fast? How reliably? Those are the questions that matter. Whether one person made 47 commits and another made 3 is irrelevant — what matters is what the team delivered together.

Social features belong on social platforms

Stars, followers, trending repos, explore pages, profile READMEs, discussions, sponsors — these are social features. They make sense for GitHub because GitHub is both a development tool and a social network for developers. The social layer drives adoption, which drives the network effect, which is GitHub's moat.

gittan is not a social network. It is a tool for teams that ship software. Adding social features would not make it better at that job — it would add surface area, UI clutter, and features that distract from the thing we actually do well: fast pipelines, team ownership, and delivery metrics.

We measure what the research says matters. Everything else is noise.