And that's basically it (and I agree with him)
Do you have a problem with Github? All the information you need is in your clone of the Git repository.
(Ok, there are bug reports, wiki entries, but apparently those can be obtained using their API as well)
Cannon writes:
> GitHub is not a walled garden [...] GitHub is going to be used for repository hosting and code reviews
The clincher is in the latter statement. Even though you may have the full repo history on your own disk, that doesn't do anything to help you get your changes back to the maintainers. In that case, GitHub is a walled garden in the same way that people talk about Facebook being one. That is, it's fine and all if, say, your friend chooses to use it, but it makes some heavy-handed choices about how you can communicate/collaborate with them; it puts up barriers–deliberately–to make it onerous/impossible to use unless you're using it, too.
GitHub gets by on providing some free services to those working in open source and getting their goodwill in return. But GitHub's wall-y nature doesn't get called out enough, and indeed, people often act like it doesn't exist.
But only if you're used to creating patches. New developers are more likely to know how to create a quick PR than they are to know about creating and submitting patches. I'm not a Python developer either but I know this was one of the considerations after reading the mailing list thread.
It was also addressed in the discussion that developers who prefer to submit patches should still be able to do so, just as they are now. To me, this is the best of both worlds and removes the whole "walled garden" thing.
Github also provides a well documented API and there are multiple services that already plug into it. If they removed that then yes, I would have an issue with the development staying on github. As it stands right now, there's no reason github specific information can't be linked up to external systems, or even integrated with them nicely.
No
The Linux Kernel is on Github and only takes patches, not pull requests
That's an important statement to make, as their end-user in this model isn't the person who is going to make snap judgements on hacker news, but the core developer who is going to have a (hopefully) easier time reviewing changes.
git clone https://github.com/YOUR_USERNAME/YOUR_REPOSITORY.wiki.git
I mean, if you are honest about it: I can copy all my primary data off Facebook. I know how to do that. You know how to do that as well. But you know what I get when I do that? A copy. I will never escape Facebook without horribly devaluing my own content.
Is that the correct decision for friends-only stuff about me? Sure, as that content doesn't get publicly linked anyway. For my local political movement? Probably, because that content gets dated quickly and my consumers are effectively being advertised to.
Is it the correct decision for a project I expect to be relevant in 20 years? No. I find myself reading things from old mailing lists and issue trackers constantly. Open source projects that have been able to keep a coherent history of their project around long enough that hyperlinks to their issues and posts continue to work 10 or even 20 years later is super important.
GitHub is at the top of their game right now. But they honestly add way way way less value than either Sourceforge or Google Code did. Mostly they trick people into using git as if it was Subversion (git isn't really designed to ever have two people pushing to the same repository on a common basis) and then "solving" the problem they created (by providing an account manager). They don't even model git networks correctly and require the fork chain to be some silly explicit tree.
Something is going to come with a good issue tracker that scales to public projects and provides valuable code analysis, and all the really large projects are going to switch. Maybe GitHub will finally decide to solve these problems (though the quick response I saw to that "open letter" yesterday makes me doubtful), but then there will be more problems. Maybe in 20 years git will feel as dumb to people as Subversion, as I remember when Subversion was insanely awesome ;P.
If GitHub had a "bring your own domain" option, and preferably some kind of URL router mechanism (for someone migrating from a previous solution) it would look a lot less weird to do important things on GitHub, but otherwise, being able to make a copy of your data is a red herring... of course you can make a copy: no programmer would ever question that :/.
In an open letter recently group of open source developers raised and highlighted pitfalls of using such closed source for profit infrastructure without community oversight. Also it shows the opaque nature of such services. It's not wise to rely on goodwill of investors of github looking for profits. Also from ethical point of view it's really bad moving to a non community for profit infrastructure for a community driven project.
This is same mistake like moving from Python 2 to 3.
Also GitHub is another sourceforge, when Python did not move to sourceforge when 80-90% of developers were using it. I don't see why they want to move to GitHub just for source code management now when roundup will still be self hosted by Python. This is one of the reason I like gnu and gpl they not just build open source but continue to uphold the principals.
At least you're forward-thinking.
This really is the crux of the argument and for the GitLab guys is really what they should think hard about.