[raverbashing]

> But to me, the development process is more important than worrying whether a cloud-based service publishes its source code

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)

[carussell]

I'm not a Python developer, so I'm only a bystander here, but Python is moving from Mercurial and uses a patch-based workflow. Getting your changes into a project that relies on patches is trivial; you just send them the patch. GitHub doesn't support patches, however. The only way to get your changes integrated upstream through GitHub is to file GitHub's version of a pull request. And the only way to file a GitHub-style pull request is if it's coming from another repo on GitHub.

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.

[scaryclam]

> Getting your changes into a project that relies on patches is trivial; you just send them the patch

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.

[carussell]

Take somebody who has never done a pull request (GitHub-style, not Git style) and has also never created a patch, and then try to teach them how to do both. Which is easier? Creating a patch will win every time.

[saurik]

Yeah. And the same is actually true for teaching a college student who has ssh/web access to their university file server how to make a distributed git repository setup with real "pull requests" (where I tell you my URL and a branch) vs. teaching someone how to make an account on GitHub and use their web interface to make a repository and then use their pull request user interface to get data between forks. I know this as I teach lectures on git, and it is seriously two console commands on your server to set up a fully working git setup in the way git was designed to be used.

GitHub has managed to cause a culture around git that there exist problems that don't exist that they can solve, and then their solutions are one-off specific solutions that only work so well if you are willing to use all their other features and you get all your developers and users to use the service as well. You are correct that GitHub is every bit as much a walled garden as Facebook.

[chishaku]

We're talking about Python core development. I just can't see the minor nuances of GitHub-style pull requests being a significant barrier to entry for new contributors.

It seems the familiarity of GitHub was actually a primary selling point.

> There were multiple reasons as to why I made that decision. One was that GitHub has basically built a social network of open source contributors. That led to various core developers telling me that they were comfortable with GitHub already and they were hoping it would win.

> Lastly, our BDFL prefers GitHub. Since the beginning of this whole decision process, Guido let it be known that he thought GitHub was the best choice.

[jguegant]

I have no clue on how to generate a patch. But I did a fair amount of pull requests... It might be a generation problem.

[snuxoll]

git format-patch --to=[e-mail] HEAD^ - send the generated email, done.

[raverbashing]

> The only way to get your changes integrated upstream through GitHub is to file GitHub's version of a pull request

No

The Linux Kernel is on Github and only takes patches, not pull requests

[grayclhn]

Isn't the kernel's repository just mirrored on GitHub, though? That's a bit different than hosting Python primarily on github.

[Spivak]

Correct, but no part of the Linux kernel development is done on GitHub. It's nothing more than a republishing of the patch-based authoritative repository hosed somewhere else. The issue is that if you want GH to be your authoritative repository you're locked into GH's way of doing things -- which isn't necessarily bad, but a valid complaint is that you have to be a user of GH to contribute to projects hosted there.

[raverbashing]

> The issue is that if you want GH to be your authoritative repository you're locked into GH's way of doing things

You just push from your (private) authoritative repository to Github, and you're free from "GH's way of doing things"

[josegonzalez]

> I'm not a Python developer, so I'm only a bystander here

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.

[carussell]

Geez.

The comment I responded to said anyone who has problems with GitHub always has a local copy of the repo. I'm participating in a discussion about the problems with GitHub in the abstract. I'm not trying to change the minds of the Python community, and I'm not even complaining about their choice. Nothing I wrote past the opening sentence was specific to this particular decision or community, and I have no dog in the fight either way. That was the entire point of prefacing my comment with that disclaimer.

Why has the level of discussion on HN turned to such a nasty one lately?

> their end-user in this model is [...] the core developer who is going to have a (hopefully) easier time reviewing changes

The point is, anyone who decides to go the GitHub-only route is going to have a worse time reviewing changes of those who choose to stay away from GitHub for similar reasons for choosing to stay away from something like Facebook—because those contributors either won't embark on making those changes to begin with, or will be unable to send them in after the fact.

[c17r]

A repos wiki pages are stored in another publicly accessible git repo.

    git clone https://github.com/YOUR_USERNAME/YOUR_REPOSITORY.wiki.git

Shame that issues/PRs aren't as accessible as the wiki is.

[embik]

I'm not sure why we would need GitHub's source code either. It's their business model and they're able to run this behemoth of a service with that. For free. I think that's amazing and shouldn't be taken for granted.

[saurik]

This would mean a lot more if GitHub didn't own the URL, which means until the end of time references to the history of the project will be partially owned by GitHub. This was the important reason for them, and everyone, to escape SourceForge.

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 :/.

[radarsat1]

Your comment made me wonder if there is a tool or service that provides backups or clones of github-only information such as issues etc. Lo and behold: https://github.com/joeyh/github-backup

[acdha]

I've also used https://github.com/josegonzalez/python-github-backup to backup private organizations.

[ywecur]

If they aren't interested in the network effect alone, then why not use GitLab?

[cremno]

That blog post contains three paragraphs discussing that: http://www.snarky.ca/the-history-behind-the-decision-to-move...