Pre-Github, projects would need to fire-up their own Bugzilla or Fogbugz instances, set-up all the project tracking criteria (areas, iterations, severity, etc).
But unstructured label tags seem to work surprisingly well in practice: projects that would have otherwise demanded 20+ fields for work-item tracking now seem fine with issue labels.
Bingo. It surprises a lot of people how little you need to be successful if everyone's on the same page. I've worked places that had thousands (yeah, thousands) of apps, dozens or hundreds of millions line of code, and had little to no issues with collaboration (oh, they thought they did, but compared to almost any other company, they really didn't), and process/tooling involved github issues, markdown files for docs and little else. Sometimes they'd toss in trello in the mix and that's about it.
You definitely can do better, but as a baseline, it's more than enough.
So a ready-made setup at an existing service open to multiple projects would work. I guess that's what Sourceforge was.
Sourceforge could have been github, but when a company turns on its users while failing to deliver value it won’t last.
Because git is decentralised it means all the git-hosting services become commodity, and we’ve learned that having the best UX keeps people around - even if your service is commodity, so I expect this basis will ensure GitHub (now part of Microsoft) will stay in the community’s good-graces.