Supporting multiple version control systems means accepting the set intersection of their features as your baseline. Part of why GitHub has been able to just fl

Supporting multiple version control systems means accepting the set intersection of their features as your baseline. Part of why GitHub has been able to just fly is their laser-like focus on only those features which facilitate collaboration atop Git. (I say this from painful experience, having spent much of the last couple of months months trying with only limited success to make users of Subversion, Mercurial, and Git happy with the same UI for source code repository browsing.) Furthermore, trying to implement fork queues, pull requests, and even proper contributor attribution atop Subversion would be a ridiculous amount of work for very little gain. Regardless, if you really want to stick with Subversion, you might at least consider setting up a cron job that fetches to a local git-svn mirror and then pushes a clone to GitHub. You won't have to learn a whole new version control system, and your users will happily run circles around you with their ability to fork, branch, and merge before you can copy your source tree into a new tag.