If issue tracking could be distributed (yes I know about Fossil and others), and the players like github and bitbucket were compatible with such, then we would no longer have any dependence on any of these services.
The way I'd host my projects would be:
1. I have my own server where I have a git repo, the issues repo, and maybe a wiki repo.
2. My server would host semi-statically generated project browsers; source code browsers, issue browsers, etc. Unlike when I was running Trac, I'd have no need to allow people access to my server, no need to worry about spammers, pages would be low-latency/cachable so that I can allow crawlers as well even on a very small linode host.
3. all of my wiki/issues/git would mirror out to github, bitbucket, and whoever else wants to participate, and updates on those sites mirror back. I already do this now with my git repos using WSGI services and hooks.
4. when someone wants to post/update an issue, they link out to one of those services, or even run a local command line/GUI based issue system (wouldn't that be great??), and everything synchronizes back.
The only missing link is a decent distributed issue system everyone can get behind. Building out the glue to sync between services is not that hard of a task.
> If issue tracking could be distributed (yes I know about Fossil and others), and the players like github and bitbucket were compatible with such, then we would no longer have any dependence on any of these services.
This is definitely the biggest problem, there are a bunch of "distributed" trackers living inside the repository, but so far I've seen nothing which worked well (even ignoring the lack of integration with gh/bb/whatever).
There's the second issue of contribution workflow though, it's not really possible to have a dozen different places where contributions can be proposed, discussed, hashed out and possibly rejected; with the sub-problem of tools integration (e.g. integration bots or CI runs on contribution proposals)
The way I'd host my projects would be:
1. I have my own server where I have a git repo, the issues repo, and maybe a wiki repo.
2. My server would host semi-statically generated project browsers; source code browsers, issue browsers, etc. Unlike when I was running Trac, I'd have no need to allow people access to my server, no need to worry about spammers, pages would be low-latency/cachable so that I can allow crawlers as well even on a very small linode host.
3. all of my wiki/issues/git would mirror out to github, bitbucket, and whoever else wants to participate, and updates on those sites mirror back. I already do this now with my git repos using WSGI services and hooks.
4. when someone wants to post/update an issue, they link out to one of those services, or even run a local command line/GUI based issue system (wouldn't that be great??), and everything synchronizes back.
The only missing link is a decent distributed issue system everyone can get behind. Building out the glue to sync between services is not that hard of a task.