Kinda scary how de facto Github has become, that external tooling is discouraged. Github is a bad issue tracker, a bad code review tool, an ok wiki and a bad distribution platform. Still, one has to mostly use the whole package to get contributors.
One thing Github does that really bothers me is that if your paid account lapses, you must pay to get your private repos back. You don't have the option to simply set your repos to public. The only options Github gives you is pay money or lose your repos. As far as I care, that's practically extortion. So I moved to Gitlab.
Luckily, Github screwed up and temporarily unlocked my private repos, letting me grab the ones I didn't have locally and move them to Gitlab.
No opt-out option, no deal, Github. This is something that students should particularly take note of, because it applies to Github Education accounts, too.
BitBucket is plenty popular as well, I run into projects that are on there instead of GH for Python. I kind of prefer BitBucket to GitHub the only thing GitHub does right is their "Explore" section which I don't think BitBucket has (or GitLab?) but that's about it for me. I don't care where one hosts code, as long as it's not some obscure server.
If one cannot figure out how to setup a development environment (with detailed guides), how can one be expected to actually make a meaningful contribution in a much more difficult domain like compiler development? For this purpose alone I think the current approach is something that Google will not get rid of.
Moreover, why on Earth would Google want to create an external dependency for code-hosting and development like GitHub, that may go down anytime, making them lose a lot of time and money, especially since their own system is much more reliable (at least for internal usage) and they have all resources they need to maintain it?
Finally, it is somewhat really silly to think that a giant corp like Google will develop something truly free and opensource, without their own interests above anything else, which obviously will become an issue sooner or later with the truly freedom spirit.
> If one cannot figure out how to setup a development environment (with detailed guides), how can one be expected to actually make a meaningful contribution in a much more difficult domain like compiler development?
Because those are two unrelated fields, and one is distinctly not productive. From the issue:
> I ran through the contributing workshop at Gophercon 2017. I even had gone through half of it before. I still needed help from one of the guides. It was still arduous. I speak as someone who has written Go professionally 40 hours a week for over 4 years - the contribution workflow deters me from contributing to the Go project. Even after signing up. The fact that it's so different from my everyday workflow just makes the hill to climb too steep.
And comments (from current contributors no less):
> I've been writing Go for over five years and contributing in various forms, and I have to say I agree. go-contrib-init makes things better, but the barrier to contributing to Go is a lot higher and with a different workflow from almost any other project that uses Go.
> As successful as the contributor workshop at Gophercon was, it is an embarrassment to the language that we had to do it at all. Why did we need an entire seminar to teach hundreds of developers who already contribute to many other open source projects how to contribute to Go?
Also, not every contribution to Go involves mucking with the compiler.
> why on Earth would Google want to create an external dependency for code-hosting and development like GitHub
Didn't they move to Google Code to GitHub, which is the live repo, Gerrit being used for code review only? If so, the dependency is already there. If not, why is it on GitHub at all?
> Finally, it is somewhat really silly to think that a giant corp like Google will develop something truly free and opensource, without their own interests above anything else, which obviously will become an issue sooner or later with the truly freedom spirit.
I think somehow this is tackled by the issue author, and is a canary of sorts:
> Let's show the OSS world that Go really is a community-run project
>If one cannot figure out how to setup a development environment (with detailed guides), how can one be expected to actually make a meaningful contribution in a much more difficult domain like compiler development?
One can become an expert on compiler developer precisely because they have little tolerant for convoluted BS processes.
The article addresses how Google is already using GitHub with Kubernetes. Looks like Dart does too from glancing through the GitHub. If you're worried about external services going down, you make an internal mirror. You don't force the whole workflow to go through your system.
> Unfortunately the epic comment thread, very talky, none of the key stack holders involved, largely irrelevant chatter... Is a case in point of why github isn't the answer for everything.
Many of the important stakeholders, both those employed by Google and those who are not, are weighing in on the topic.
And the comment thread looks fairly similar to the mailing list discussion of any moderately controversial issue, which is not unique to Github (or even the Go project).
This is insane, considering the process before github was "send a patch by email".
Hundreds of thousands of people, including me, have started contributing patches because the Github process has a much lower barrier to entry, is standardised, and effortlessly teaches you how to do it when you browse around a project.
The "just use GitHub" mentality is harmful groupthink. How about being open to learning other tools? Locking yourself into a single ecosystem and bothering otherwise productive people who don't buy into it is how we get SourceForge.
SouceForge was never a particularly good site, and once a better one came along everyone moved off it fairly easily.
Seems like working as intended. If Github goes evil like SourceForge did I don't imagine it will be a huge amount of effort to move to another site. In fact it can probably be automated for most projects.
For high stakes projects, I feel there's an aspect of "choose your battles wisely". Is relenting in some dimension going to harm the overall goal? IIRC Go was hassled off of mercurial and onto git, so there's a bit of a fractal too.
It's true that Gerrit's workflow is a bit unusual, but even though I had no experience with it, I managed to setup the environment and create a review request for Golang in under an hour. When it comes to contributing to a programming language, I think this is pretty friction-less.
In my experience, there are no debates so fraught and vicious as those over version control platforms.
Questions of more open governance for Go really ought to be separated from Github specifically. Moving from googlesource to Gitlab or Bitbucket would achieve the same thing. Which is actually not much: just because a project is on a given commercial hosting platform doesn't portend a change in how decisions get made over project direction, as many projects hosted on Github (and Gitlab and Bitbucket) illustrate.
> When Google keeps the canonical git repo in googlesource, and uses a google-run gerrit instance for code reviews, it does not make the project feel like it's open source. It makes it feel like it's a google project that they let the rest of us look at from afar, and participate in if we're willing to hike up the mountain.
I hate to break it to ya', but I think this isn't just what it feels like.
The sooner people realize that "Open Source" is different than "Open Development", the better. That said, I think it's a stretch to assume that Go is contributor hostile just because it hasn't gone all-in on GitHub. Just off the top of my head: Ruby, Python, Javascript, Lua, Clojure, C++, and Java are all languages that haven't embraced the "GitHub Workflow". Indeed, the only language I can think of that has is Julia. Actually, I just checked, and it looks like Rust is also bought in to the GitHub Workflow. So that makes it: 2 for, 7+ against.
This has happened because the same kinds of discussions have come up with Ruby for years, especially since GitHub came out of the Ruby world, and the Ruby community overall has used GitHub longer and more than most as a result.
There are things that we in Rust find annoying about GitHub, but they're mostly addressed through things like bots; there's no significant push by anyone to move away from GitHub.
I've contributed a small patch to Go not that long ago and it was quite straightforward, I don't get why it has to be changed. Plenty of people have used the current workflow for years now...
Possibly off topic, but this prompted me to take a long overdue re-peek at git-appraise (distributed code review tool, written by google in go). I notice there is now a git-appraise-web. It looks pretty nice (exceptionally minimal :-) ), but their demo lacks any comments to see how it might work in collaborative form.
Does anybody use git-appraise (and especially a web client) and have any comments?
the proposal is cute and funny, basically the author argues that to make the contribution and governance process more open, everything has to be done on github to be more closely aligned with what project X,Y,Z are doing.
that is not open or free, that is the exact opposite of being free and open.
If one wants to see the merits or at least the experiences of a major language from a commercial entity going open source on GitHub, where all discussions, language features, issues, and code itself is in that one place, take a look at Apple's Swift.
Edit: Looks like Swift doesn't use GH for issues any more.
I wonder if Google really loves Gerrit, or if it’s just a legacy NIH attachment and some of Google’s graybeards just refuse to let it go.
Having worked with Gerrit in the past, I can say without a shadow of a doubt, it’s an abomination and I’d lop off a limb rather than voluntarily use Gerrit again.
The joy of decentralization to my mind is not a total avoidance of centers, it is resilience against those centers becoming obnoxiously or harmfully authoritative.
Because Git is already thoroughly decentralized in its architecture, I'm not particularly afraid of GitHub, though I rely on it daily. I know that I can migrate from it without any fundamental problems. Development workflows are decoupled from their servers in a robust way. Commit hashes and GPG signatures mean that GitHub is not really a trusted central point, but a useful hub.
Issue tracking is centralized on GitHub, and that's the biggest problem with it. Maybe that's a lock-in strategy from GitHub the corporation, although the APIs do allow migration.
[+] [-] maaaats|8 years ago|reply
(Github has other strengths, though)
[+] [-] blcknight|8 years ago|reply
[+] [-] sli|8 years ago|reply
Luckily, Github screwed up and temporarily unlocked my private repos, letting me grab the ones I didn't have locally and move them to Gitlab.
No opt-out option, no deal, Github. This is something that students should particularly take note of, because it applies to Github Education accounts, too.
[+] [-] giancarlostoro|8 years ago|reply
[+] [-] bmh_ca|8 years ago|reply
[+] [-] arkadiytehgraet|8 years ago|reply
Moreover, why on Earth would Google want to create an external dependency for code-hosting and development like GitHub, that may go down anytime, making them lose a lot of time and money, especially since their own system is much more reliable (at least for internal usage) and they have all resources they need to maintain it?
Finally, it is somewhat really silly to think that a giant corp like Google will develop something truly free and opensource, without their own interests above anything else, which obviously will become an issue sooner or later with the truly freedom spirit.
[+] [-] lloeki|8 years ago|reply
Because those are two unrelated fields, and one is distinctly not productive. From the issue:
> I ran through the contributing workshop at Gophercon 2017. I even had gone through half of it before. I still needed help from one of the guides. It was still arduous. I speak as someone who has written Go professionally 40 hours a week for over 4 years - the contribution workflow deters me from contributing to the Go project. Even after signing up. The fact that it's so different from my everyday workflow just makes the hill to climb too steep.
And comments (from current contributors no less):
> I've been writing Go for over five years and contributing in various forms, and I have to say I agree. go-contrib-init makes things better, but the barrier to contributing to Go is a lot higher and with a different workflow from almost any other project that uses Go.
> As successful as the contributor workshop at Gophercon was, it is an embarrassment to the language that we had to do it at all. Why did we need an entire seminar to teach hundreds of developers who already contribute to many other open source projects how to contribute to Go?
Also, not every contribution to Go involves mucking with the compiler.
> why on Earth would Google want to create an external dependency for code-hosting and development like GitHub
Didn't they move to Google Code to GitHub, which is the live repo, Gerrit being used for code review only? If so, the dependency is already there. If not, why is it on GitHub at all?
> Finally, it is somewhat really silly to think that a giant corp like Google will develop something truly free and opensource, without their own interests above anything else, which obviously will become an issue sooner or later with the truly freedom spirit.
I think somehow this is tackled by the issue author, and is a canary of sorts:
> Let's show the OSS world that Go really is a community-run project
[+] [-] coldtea|8 years ago|reply
One can become an expert on compiler developer precisely because they have little tolerant for convoluted BS processes.
[+] [-] _asummers|8 years ago|reply
[+] [-] shadowmint|8 years ago|reply
Is a case in point of why github isn't the answer for everything.
[+] [-] chimeracoder|8 years ago|reply
Many of the important stakeholders, both those employed by Google and those who are not, are weighing in on the topic.
And the comment thread looks fairly similar to the mailing list discussion of any moderately controversial issue, which is not unique to Github (or even the Go project).
[+] [-] agnivade|8 years ago|reply
Robert Griesemer, Ian Lance Taylor have put in their comments (apart from other core contributors).
So, I would say this statement is false now.
[+] [-] Tade0|8 years ago|reply
I thought the original meaning was gone.
[+] [-] gksmythe|8 years ago|reply
What people really like is:
a) The paper trail (I can show to my career manager that I've done some work).
b) The constant distractions that feel like work.
c) Minor issues seem like major contributions.
d) Self promotion.
[+] [-] matt4077|8 years ago|reply
Hundreds of thousands of people, including me, have started contributing patches because the Github process has a much lower barrier to entry, is standardised, and effortlessly teaches you how to do it when you browse around a project.
[+] [-] Sir_Cmpwn|8 years ago|reply
[+] [-] IshKebab|8 years ago|reply
SouceForge was never a particularly good site, and once a better one came along everyone moved off it fairly easily.
Seems like working as intended. If Github goes evil like SourceForge did I don't imagine it will be a huge amount of effort to move to another site. In fact it can probably be automated for most projects.
[+] [-] frou_dh|8 years ago|reply
[+] [-] hamax|8 years ago|reply
CLA was very painless too.
[+] [-] IshKebab|8 years ago|reply
[+] [-] rectang|8 years ago|reply
Questions of more open governance for Go really ought to be separated from Github specifically. Moving from googlesource to Gitlab or Bitbucket would achieve the same thing. Which is actually not much: just because a project is on a given commercial hosting platform doesn't portend a change in how decisions get made over project direction, as many projects hosted on Github (and Gitlab and Bitbucket) illustrate.
[+] [-] jballanc|8 years ago|reply
I hate to break it to ya', but I think this isn't just what it feels like.
The sooner people realize that "Open Source" is different than "Open Development", the better. That said, I think it's a stretch to assume that Go is contributor hostile just because it hasn't gone all-in on GitHub. Just off the top of my head: Ruby, Python, Javascript, Lua, Clojure, C++, and Java are all languages that haven't embraced the "GitHub Workflow". Indeed, the only language I can think of that has is Julia. Actually, I just checked, and it looks like Rust is also bought in to the GitHub Workflow. So that makes it: 2 for, 7+ against.
[+] [-] steveklabnik|8 years ago|reply
That said, https://github.com/ruby/ruby/ exists, and committers will (in my understanding) take PRs from it and merge them in, see https://github.com/ruby/ruby/pull/1661 for example.
This has happened because the same kinds of discussions have come up with Ruby for years, especially since GitHub came out of the Ruby world, and the Ruby community overall has used GitHub longer and more than most as a result.
There are things that we in Rust find annoying about GitHub, but they're mostly addressed through things like bots; there's no significant push by anyone to move away from GitHub.
[+] [-] speps|8 years ago|reply
[+] [-] mikekchar|8 years ago|reply
Does anybody use git-appraise (and especially a web client) and have any comments?
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] alenmilk|8 years ago|reply
jimmyfrasche commented
The language spec is easier to read than the contribution guidelines
[+] [-] kingmanaz|8 years ago|reply
Also, a "Comic Sans" website makeover would severely cut down on the golang community's hipster ratio.
[+] [-] dis-sys|8 years ago|reply
that is not open or free, that is the exact opposite of being free and open.
[+] [-] coldtea|8 years ago|reply
Not in the religious/GNU sense.
[+] [-] hellofunk|8 years ago|reply
Edit: Looks like Swift doesn't use GH for issues any more.
[+] [-] andrewnez|8 years ago|reply
[+] [-] Androider|8 years ago|reply
[+] [-] grabcocque|8 years ago|reply
Having worked with Gerrit in the past, I can say without a shadow of a doubt, it’s an abomination and I’d lop off a limb rather than voluntarily use Gerrit again.
[+] [-] dannyw|8 years ago|reply
The same platform where you see "GitHub is down" on HN every couple of months?
[+] [-] dmitriid|8 years ago|reply
[+] [-] mbrock|8 years ago|reply
Because Git is already thoroughly decentralized in its architecture, I'm not particularly afraid of GitHub, though I rely on it daily. I know that I can migrate from it without any fundamental problems. Development workflows are decoupled from their servers in a robust way. Commit hashes and GPG signatures mean that GitHub is not really a trusted central point, but a useful hub.
Issue tracking is centralized on GitHub, and that's the biggest problem with it. Maybe that's a lock-in strategy from GitHub the corporation, although the APIs do allow migration.
[+] [-] frou_dh|8 years ago|reply
As you mentioned, the dubious part is if it captures control of all of your "meta" processes too.
[+] [-] nascent10|8 years ago|reply
[deleted]
[+] [-] TurboHaskal|8 years ago|reply