
Python moves to GitHub - rashoodkhan
https://mail.python.org/pipermail/core-workflow/2016-January/000345.html
======
eugenekolo2
GitHub's reign over public open source programming is a bit terrifying. But,
it's been mostly benevolent so far, but I do find it troubling to trust a
private company to keep dev's in mind, and not profit.

~~~
tw04
I'm not sure why it's a problem though. If they decide to go down that path,
it's not that hard to move off. They don't have the lock-in that would scare
me like having terabytes of data in an oracle database.

~~~
cm3
The problem is with people's mindset that everything has to be on github.
Large projects that dare to use self-hosted more fitting infrastructure like
Phabricator tend to be punished socially.

~~~
StevePerkins
What does "punished socially" even mean?

Unable to attract as many contributors? The cold reality is that most open
source projects aren't really TRYING to attract contributors. Small-time
hobbyists often don't want to play with others in their personal project
sandboxes, and big-time projects with high profile usually put up high
barriers to contribution.

Unable to attract as many end-users, or as much public mindshare? Now this
makes more sense. Many of the high-profile moves to GitHub are really about
P.R., and signaling friendless to the developer community (e.g. Microsoft's
recent image re-branding efforts). Not having a GitHub presence DOES make you
less visible and more isolated from developers today.

Either way, I would argue that GitHub is really just a sort of Facebook or
Twitter-like presence for software organizations. A way to draw attention,
publicity, or mindshare from the public... but often merely a hosting mirror,
and not even the primary toolset through which the software is actually
developed.

This being the case, who cares if GitHub is dominant? Or SourceForge ten years
ago, or whatever the next popular thing might be ten years from now? In most
cases, it's effectively about as consequential as having to shift your focus
from MySpace to Facebook when the audience moves.

~~~
zanny
This is _incredibly_ shortsighted, but the rebuttal is simple:

> This being the case, who cares if GitHub is dominant? Or SourceForge, or
> whatever the next popular thing might be.

For one, _I do_ , and for two - why was sourceforge changing their business
model to shady predation a problem? It was not because they were a website on
the Internet - there are millions of URLs of clickjackers or other malware you
could visit and harm your computer with, but you rarely see them.

The problem was that a ton of open source software had _mindshare_ on
sourceforge, that remains a problem _to this day_ , and it took years to move
_most_ projects away from that hostile environment. Plenty of very useful free
software remains hosted on sourceforge, and there are plenty of _reasons_ \-
developer inertia, community loss from switching, legacy systems in place that
aren't portable, lack of interest in learning new tools, and many more - but
the _reasons_ matter less than the result - that we have thousands of projects
staying on a website known to infect people with malware.

Most of that software remains as portable as anything on gitub - often even
moreso, because sourceforge offered many fewer developement ecosystem features
than github now does - but has no switched for _whatever_ reason. We can go
after the individual projects and heckle them until we can get them off
sourceforge, but that is a ton of effort and mental energy we could have
better used making good software.

Which is fundamentally why the decision between github and _any_ open source
alternative is so important. This is not a question of benevolence, or even
time - Github, Inc is a private company hosting a proprietary website that has
11 million accounts and 29 million source repositories today. _Any_ action
they take can destroy either trust in the platform (why exactly do you trust a
proprietary web service, again?) or its usability for whatever purpose you
depend on it for, and since it is proprietary there is no recourse. You just
have to repeat the sourceforge hell and somehow move off of it as a hosting
platform - except you might have drunk the koolaid, and now have your issues,
releases, build service, wiki, and website all bound to the github platform.
If moving just the source control, release hosting, and a forum from
Sourceforge was bad, trying to get away from Github would be much, much worse.

But all these migrating projects should _know better_. They were already
betrayed once by proprietary software they depended on, but are taking
familiarity and mindshare over the security to never have that happen again.
At least with gitlab, when Gitlab Inc jumps the shark, you - or _anyone else_
could spin up the lifeboat to easily and seamlessly save your community with.
And that collateral alone means Gitlab Inc. is _much_ less likely to betray
you for profit.

It is not a question of if. Unless Github open sources itself, and that is
impossibly unlikely considering how huge their code base must be now and how
many football fields of lawyers they would need to prune their internal code,
a proprietary software project _must_ eventually act against your interests
because you are not in control of it, no matter the intention of the creator.

If you are going to have to bite the transition bullet, you might as well only
have to do it once. Considering the parity between github and gitlab, I have
never met anyone who would literally refuse to contribute to a project because
its not on github, you just miss casual eyes that are more common there
because the platform has captured more userbase.

But that userbase control is so dangerous, and we should all care enough to
try to correct for it when we can, if it doesn't negatively impact us much.
And honestly, a project like Python would have been perfect for it - they
won't see a dearth of developer interest just because they are using the
second most popular source control web service out there.

~~~
TheCoreh
> a proprietary software project must eventually act against your interests
> because you are not in control of it

Being open source doesn't mean that won't happen. A lot of open source
projects have acted against their users' best interests. A good example is
Firefox with the whole "Pocket integration" controversy. Another example is
Wikipedia, with its editorial policies that drove away editors. You _can_ fork
Firefox, and you can host your own Wikipedia mirror with exactly the same
software setup, and in fact a lot of people have done so, but mantaining your
own fork/mirror of a project on this scale is a lot of work. Unless you have
unlimited free time (you don't) open source doesn't inherently remedy the
issue that other people will do things that you do not agree with, and that
may cause problems to you.

Platform choice is ultimately an economical decision. Github has significant
incentives not to "go rogue", i.e. they don't want to shoot themselves in the
foot. They currently provide very significant value to the community, and are
in a very comfortable position, but that could change really fast if they take
the Source forge route.

While the more code that gets open sourced the merrier, I personally don't
believe open sourcing Github would, at this point, bring a lot into the table,
especially since gitlab is so fully featured already. Their secret sauce isn't
really the software, but the service they provide.

~~~
jordigh
> open source doesn't inherently remedy the issue that other people will do
> things that you do not agree with, and that may cause problems to you.

It's not a remedy. It's just a lifeline. Some of us do take Icecat or
Iceweasel. With proprietary software, you have no recourse at all. Wouldn't
you prefer some safety net to none at all?

------
anarcat
this is pretty significant; so far the only git presence of Python was a
"semi-official readonly mirror" on github:
[https://github.com/python/cpython](https://github.com/python/cpython)

now does this mean that Python will completely switch away from Mercurial?
this was one of the _major_ projects still using hg

what does this mean for mercurial's global adoption vs git?

also, i don't understand why the free software aspect of gitlab wasn't an
important argument in the decision... that seems like a key element of the
difference between the two platforms.

~~~
jordigh
Yes. It means Python is no longer using Mercurial. We knew this was a done
deal a several weeks ago.

Mozilla, Octave, and Hedgewars are a few remaining projects that still use hg.
For them, I will continue to improve, promote, and use Mercurial.

Their reasoning for using Github have nothing to do with the technical merits
of git or hg or with the freedom of the software or platform. They want more
contributions and they figure using the popular platform is the way to obtain
them.

~~~
scanner_darkly
SDL also uses mercurial I think.

------
jacquesm
If there ever was a company that became 'too big to fail' it is github. A
major security breach at github would have earth shaking consequences and if
they ever went out of business it would take a long time before the rift was
healed.

~~~
runn1ng
I think that the fail of Amazon and their AWS would have far worse
consequences. Half of the internet would stop working (the half that's not
using Google's and Microsoft's services, anyway).

------
godzillabrennus
Everyone is moving to GitHub these days. Why doesn't Gitlab.com get more love?
Isn't their whole stack open source?

~~~
bastawhiz
I have three personal reasons for preferring Github to Gitlab. I'm not going
to talk about the community edition of Gitlab, since Github Enterprise is a
separate topic and frankly I think most individual developers couldn't be
bothered to download, run, and maintain their own Gitlab instance (as
evidenced by the fact that Github.com is so damn popular).

1\. Gitlab themselves admit that Gitlab.com is bad[1]. Making a cloud-based
software development platform is hard, and Github has some of the best
engineers working on scaling the service. Gitlab doesn't have nearly as many
resources.

2\. The community is thin[2]. Almost all of the largest projects on Gitlab.com
are Gitlab. Gitlab CE is maintained by only a handful of people. Go through
the list of top contributors on Gitlab.com and you'll find that they have
almost zero "personal projects" hosted there. If the developers of the service
don't even use it, why should I?

3\. The UX of Gitlab is honestly quite poor. At best, it's a clone of Github's
UI. At worst, it has way too much scrolling thanks to inconveniently placed
whitespace, poor performance, a confusing information architecture, and oodles
of low-contrast text. I personally find getting around Gitlab to be tiring and
confusing. Here's an easy example: from the Contributors tab of a project [3],
how can I see more about a contributor? You just can't. There's lots of little
papercuts like this scattered across Gitlab. Not to say Github is without
papercuts, but it certainly has far fewer.

[1] [https://about.gitlab.com/gitlab-com/](https://about.gitlab.com/gitlab-
com/) [2] [https://gitlab.com/explore](https://gitlab.com/explore) [3]
[https://gitlab.com/gitlab-org/gitlab-
ce/graphs/master](https://gitlab.com/gitlab-org/gitlab-ce/graphs/master)

~~~
sdesol
> At best, it's a clone of Github's UI.

What I don't understand right now is why they aren't trying to copy GitHub as
much as possible ... when it makes sense of course. I've been studying both
GitHub and GitLab's design in detail, because I want to incorporate my
technology into their branches and commits page, and I've found the user
experience between both quite striking.

When I get some time this week, I would like to submit an issue with GitLab to
let them know in more detail what I think they can do better, but here is just
a synopsis:

\- I still can't put my finger on it, but there is something off about the
font.

\- Avatars with 50% border radius is a bad design choice in my opinion. The
problem with creating circular avatars is they hide too much of the image and
they create a focal point towards the center of the image. If your avatar
doesn't have a natural center focus, it will look bad and create unnecessary
eye strain, since your mind will naturally try to fill in cropped areas. Keep
it simple and use a simple border radius of 8 or less.

\- Avatars on the commits page are too small. I'm not sure if this design
decision was the result of the Gitorious acquisition, but Gitorious had this
problem as well. Using small avatars has its place, but not on the commits
page since this page is designed to help you better understand who did what
quickly.

\- How the commit message is revealed in the commits page is too jarring. If
you click on the ellipses at

[https://gitlab.com/gitlab-org/gitlab-
ee/commits/master](https://gitlab.com/gitlab-org/gitlab-ee/commits/master)

and

[https://github.com/gitlabhq/gitlabhq/commits/master](https://github.com/gitlabhq/gitlabhq/commits/master)

you'll better understand. The problem with GitLab's implementation is the
strong focal point is the avatar and when you click on the ellipsis, your eyes
will get dragged down with it when the message is revealed. Just copy GitHub
and use a bigger avatar and have the commits message reveal below the strong
focal point (avatar)

\- The calendar icon on the commits page is visually too strong and should be
removed.

\- The clipboard and other elements on the commits rows creates an unnatural
balance/flow. If you look at GitHub's commits page, the clipboard, commit sha
and browse tree icon are equally balanced in size and weight, which creates a
natural horizontal flow. You can sweep from left to right and it won't create
any unnecessary jarring effect.

This is just some of the things that I've thought about when I was looking at
the commits page and I really don't understand why they aren't copying
GitHub's UI in a lot of places. The amount of money that GitHub is investing
in their UI vs GitLab's is quite significant, and it should be obvious that
GitHub is way more capable of producing a better user experience, so why not
copy it?

------
fforflo
It looks like the vote was not "unanimous"
[https://mail.python.org/pipermail/core-
workflow/2016-January...](https://mail.python.org/pipermail/core-
workflow/2016-January/000346.html)

------
inglor
If I were them I'd move issue tracking to GH too _in addition_ to the current
tracker. Having GH issues that are familiar to developers lowers the barrier
for feature requests and bug reports which is a huge deal for a language.

------
richerlariviere
I'm not scared of Github. If they take bad decisions for the community, we
will tell them. But I have to agree that the worst is the lack of competitors.

------
crosa
(3). Guido prefers Github ~deal with it~

Seriously, I like the idea. It will give visibility for who contribute and
might bring some new contributors.

------
stephendicato
GitHub is popular. More people will come in contact with the development of
Python by Python being on GitHub. That's a significant benefit to any open
source project; one that I believe outweighs the concerns of a private company
valuing business over developer ideals.

------
ksec
On the other side, Ruby refuse to move to Github, but are actively trying and
hoping to attract more contributors.

------
xdinomode
So is github the Google of code?

