{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreif7kpbiq6yq2vtfezrefym2gfxgh2d5axzwigjtszxdyb4namvrhy",
    "uri": "at://did:plc:bqma3dxvtfkv542aaek7xf6c/app.bsky.feed.post/3miir25eynev2"
  },
  "path": "/2026/04/drm-subsystem-contributor-numbers.html",
  "publishedAt": "2026-05-07T12:27:57.548Z",
  "site": "https://airlied.blogspot.com",
  "textContent": "I'm doing a podcast recording this week, so I wanted to run some numbers so I could have some facts rather than feels. It turns out my feels were off by a factor of 3 or so.\n\nIf asked, I've always said the contributor count to the drm subsystem is probably in the 100 or so developers per release cycle.\n\nDid the simplest:\n\n**git log --format='%aN' v6.14..v6.15 drivers/gpu/drm/ include/uapi/drm/ include/drm/ | sort -u | wc -l**\n\nIterated over a few kernel releases\n\nv6.15 326\nv6.16 322\nv6.17 300\nv6.18 334\nv6.19 332\nv7.0-rc6 346\n\nThe number for the complete kernel in those scenarios are ~2000 usually, which means drm subsystem has around 15-16% of the kernel contributors.\n\nI'm a bit spun out, that's quite a lot of people. I think I'll blame Sima for it. This also explains why I'm a bit out of touch with the process problems other maintainers have, and when I say stuff like a lot of workflows don't scale, this is what I mean.",
  "title": "drm subsystem contributor numbers",
  "updatedAt": "2026-04-01T20:59:25.000Z"
}