Proposal: Just Use Github · Issue #21956 · golang/go · GitHub

Before I begin, let me say that I believe that Google and the go team (whatever we may mean by that term) really want Go to be a true open source, community project. My comments herein are intended to shine light on how the current state of Go's development process belies this fact.

There are two common complaints when it comes to the development of Go itself:

1. It's too hard to contribute (this was a whole section of Steve Francia's talk at Golang UK)
2. Go feels like it's a Google-owned-and-controlled project that is not truly "open source"

Both of these are exasperated by the fact that the technical workflow that the Go project uses is significantly different than what has become standard" for much of the open source community. The standard being - use Github. Use GitHub as the primary code storage, use GitHub for issues, use GitHub for PRs, use GitHub for reviews. The reasons for this are twofold - one, they are integrated and closely localized. Two, they're what everyone is already using, so there's zero cognitive overhead. I think most of us can create a PR in our sleep.

#18517 talks about accepting PRs... .except that it's not really accepting PRs. It's using PRs as a way to feed code into gerrit. This is going to be a terrible user experience, because it will be disconnected from the normal github workflow. Whatever features Gerrit has over GitHub obviously cannot be translated correctly to github, so the bridge necessarily must be lossy. People will expect to be able to receive comments in a different tab of the same page of their PR... but they will instead have to go to a completely different, disconnected UI on a different domain.

Not only is this a bad user experience, it is yet another signal to potential contributors that they aren't really that welcome. After all, tens of millions of developers use GitHub every day. Projects bigger than Go use GitHub a their main development process in all ways.

Things like The Go project contributing flow is currently configured to work only with Google Accounts. and Our canonical Git repository is located at https://go.googlesource.com/go send not-so-subtle signals that this is a Google project, not really a community project.

The first two lines of the contributing guide are The Go project welcomes all contributors. The process of contributing to the Go project may be different than many projects you are used to.

If the first is true, the second should not be true.

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.

Other large open source projects seem to do just fine. Look at Kubernetes. It's only 3 years old. And it already has almost 50% more contributors than the language it's written in. It uses GitHub for code reviews, issues, PRs, etc.

In my personal experience, the Juju team at Canonical was approximately 25 full time developers when we switched from using ReviewBoard (which has many of the same features as Gerrit) to GitHub reviews. It was much nicer to have the reviews available in the same page as the PR itself. It was nice that the workflow was the same we used for our side projects. It was nice that contributors didn't have to learn new tools and create new logins on external sites. It was nice not to have to maintain those external systems.

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.

Let's show the OSS world that Go really is a community-run project. Let's make GitHub the first class citizen that it ought to be in the development workflow for Go. Let's drop the barrier of entry that currently exists even for experienced developers, so that contributing to Go only requires a few clicks through an automated CLA signing process and then normal PRs, reviews, normal git tooling.