There are alternatives, such as Bitbucket, GitLab, and Kiln. It's hard to see any of these usurping GitHub anytime soon, though. Of course, thanks to the nature of Git, moving between the systems isn't that hard. You can, for example, benefit from the free private repositories of Bitbucket. GitHub's pricing starts to hurt pretty fast, especially if you have a lot of private work. GitLab is nice if want something self-hosted. And Kiln has Spolsky behind it so that goes some way.
I have several gripes with GitHub. Some are minor and likely very fast for GitHub to resolve should they want to. There are also some structural issues I'm not particularly happy about. I'll try to illustrate my problems next and show existing solutions where they exist.
Starring is Too Limited
I like to mark interesting repositories with a star (1.7k stars given so far). Obviously, once you have starred enough projects, it becomes counter-productive. Ideally you should be able to filter based on project meta information. GitHub allows you to attach only project site and description to a project. No tags are supported. Of course you could say it's better to deal with this within the repository itself (i.e., package.json). That feels too low-level, though, and cannot be used for queries trivially.
There are solutions, such as Astral, that address this problem. I do wish GitHub allowed people to attach more meta information to their projects, though. This brings me to my next gripe.
Limited Control Over Your Portfolio
Once you hit a certain amount of projects under your personal account, it starts to work against you. Just look at my listing of repositories. How can you tell which repositories have good stuff in them? If there was more metadata available, it would be possible to filter better at least. I know GitHub tracks repository language automatically. Having a language filter would be a start.
A good next step would be to allow more control over the way you display your repositories to the public. Perhaps you might want to hide some of them altogether. At the very least it would be nice to mark a select few so that they stand out more.
Given your GitHub account works often as your code portfolio, having more control over it would seem like a no-brainer to me. Obviously you could develop something custom on top of the GitHub API. Perhaps there's something like Astral but for portfolios.
One way to deal with the problem is to push bigger projects below organizations and deal with it there. This won't work always, but when it does, it's a nice way to split up your work and collaborate with other people.
No Pull Requests for Wikis
It is nice that GitHub provides free wikis for projects. In fact, I built jswiki on top of this idea. To allow people to contribute I made it open for modifications. Of course this means some joker might mess up the wiki content somehow given there are no controls against this. Ideally you should be able to accept pull requests against wikis.
It is possible to work around this issue by maintaining your wiki content at your project repository, keeping the wiki closed, and setting up a script that copies the content there. It's not ideal but it works.
No Revision History for Issues
Even though GitHub's issue tracker works amicably well for many purposes, there are a couple of major flaws. Most importantly it doesn't keep track of changes made to the issues. Sometimes it is important to see what the issue description looked like in the past. You can of course dig this information from your email provided you have subscribed to the issue. It's not ideal, though.
The ideal solution for me would be to have the issues available as a Git repository. This is the way the wiki works after all. The repository would track issues and associated comments in some simple format (JSON/YAML?). Besides providing revision history, this would make it possible to maintain the issues through a CLI without having to jump through hoops.
Issues Can Be Removed from a Project Without a Warning
Project issues are behind a checkbox at project settings. Simply unchecking that you will deny access to your project issues. I don't approve with this design decision as it can be quite perilous for open source projects. At the worst you are losing hundreds of hours of effort just like that. Only the parent project retains references to the issues and once they are gone, they are gone.
There's not a clear solution for this. I suppose someone could whip up a service that would backup issues over GitHub's API. Of course, I would rather see this resolved on GitHub's side somehow.
Issues Can Devolve Into +1's
Often people like to drop by issues of popular projects and do a little "me too" kind of reply. As a result you end up with quite long threads sometime with low signal to noise ratio. In addition you end up annoying the project maintainers. Ideally GitHub should allow people to +1 an issue simply by hitting a button somewhere. That would allow the maintainers to see where to put their efforts clearer.
Github +1s Chrome plugin solves this issue partially. It will collapse the +1 comments and show them on top of an issue. The issue subscribers will still receive mail when someone +1's an issue, though.
No Clear Way to Find the Living Fork
As projects develop, sometimes the originating repository simply stops developing and a fork will pick up the torch. Currently there's no easy way to find it. Ideally GitHub would show the most notable forks at the root project page. I know there's network information but I feel it's a little hidden.
Conclusion
I still like GitHub as a service and it's hard to imagine developing without it. I believe it could become significantly better with a little TLC here and there. Not all of these gripes are easy to fix. I do hope GitHub will continue improving as that would be in everyone's interest.