Live data from Hacker News

Python moves to GitHub

mail.python.org

31–40 of 119 posts

Re: Python moves to GitHub

#31

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

Gitlab is really nice, but the user experience isn't quite as slick as Github's. Understandable, since Github has a lot more engineers behind their infrastructure. I think Gitlab's current user base is for developers/startups who want VC backups for their private codebases. I'd probably use Gitlab if I were developing a private project that I didn't plan on releasing. Github, by design, is friendly towards people who…

Definite +1 on the italicization of 'quite'.. GitHub's UX advantage over Gitlab is marginal at best, at least as far as their web client is concerned. The desktop experience is pretty nice, but we've otherwise got SourceTree for non-developers who need a decent UI.

Gitlab is the first piece of open source I've seen in probably a decade where I haven't a single bad word to say for it, their attention to detail is superb, starting with the installation process. I'm usually by default a critic of pretty much anything I encounter (aka. "typical HN comment author") but I find myself advocating Gitlab constantly

Re: Python moves to GitHub

#33
post #7

Earlier quoted context omitted.

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.

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 mindsh…

Projects that use github merely as a mirror always run into the issue that of all features pull requests are the only one that you cannot disable, and they have to deal with closing pull requests, pointing to the real contribution process. So far github has always rejected the possibility to disable pull requests.

The problem with Sourceforge is that we now have a thousand unmaintained projects only available there as an archive and are risking to lose them if we're not careful. It seems easier to build a github-to-new_thing service as long as github cooperates (web api throttling).

If git is to be the dominant tool, it should support a wiki, tickets, code review and more complete distribution. Kinda like Fossil++. I hope git-appraisal or at least the idea gets more popular.

Re: Python moves to GitHub

#34

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

GitLab and Bitbucket are more about private companies and their private hosting for doing their actual private work.

GitHub does that too, of course. But they are also basically a social networking website for individuals and organizations in the software industry. Prominent companies put code on GitHub because that's how you maintain a public presence in the developer community today. Even though the GitHub repos are more often than not mirrors, with the code actually being developed with internally-hosted repos and tooling.

So as far public destinations for open source code, GitHub has that market pretty sewn up for now. However, there's lots of competition in the "charging money for private services" market. Atlassian is a giant in the enterprise world, and I'm sure GitLab is doing well too. GitHub sells private services too, of course. Lots of people argue that Bitbucket's tooling is better, and even the paid version of GitLab is insanely cheaper... but GitHub does have an advantage in being able to leverage everyone's familiarity with it.

Re: Python moves to GitHub

#35
post #7

Earlier quoted context omitted.

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.

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 mindsh…

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.

Re: Python moves to GitHub

#36
post #7

Earlier quoted context omitted.

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.

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 mindsh…

Because of how Git is a distributed model, hosting your project on Github shouldn't be a big deal. You could host your project privately and then just have Github mirror that private host with hooks.

Git being distributed means that you can host your project on as many different places as you want. And making the workflow to accept pull requests for Github, Gitlab, or other providers really isn't very difficult. They are all just remotes.

Re: Python moves to GitHub

#37
post #7

Earlier quoted context omitted.

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.

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 mindsh…

>What does "punished socially" even mean?

This is an interesting expression by the grandparent. I've never heard this term before, but I've definitely felt like I've been "punished socially" in some way on the Internet by not having Facebook. The most common example are the large number of apps that I can't use because they require a Facebook account to get started. (I had an FB account in the early days when it was still edu only, but ended it a few years back)

Re: Python moves to GitHub

#38

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

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/ [2] https://gitlab.com/explore [3] https://gitlab.com/gitlab-org/gitlab-ce/graphs/master

Re: Python moves to GitHub

#39
post #4

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.

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.

There are some things you simply can't do on GitHub:

* block trolls from interacting with an organization, short of filing a support ticket

* install pre-receive hooks without using the pull request infrastructure

* set up status checks (the PR equivalent of pre-receive hooks) for pull requests that require force pushes, allowing some external check to replace git's usual fast-forward check

* have status checks apply to individual commits, not trees, so that you have style or copyright or whatever checks on each commit

* disable pull requests

* enforce rules for creation of new branches or tags

I admit that none of these features are dealbreakers, but they all have legitimate use cases, and they'd all be trivial if you were using a regular UNIX-based git server.

On the other hand, the usable interface of GitHub wouldn't be available to you if you were using a regular UNIX-based git server, and that is a dealbreaker. :)

Re: Python moves to GitHub

#40
post #23
post #17

Earlier quoted context omitted.

I'd consider "single sign on that connects me to tons of projects' repos to be great UX. Personally, it (and the centralized API) are big reasons I use GitHub to interact with projects whenever possible

Centralizing the "hub" pretty much negates the distributed aspect of a dvcs, and github has no incentive to invest in extending git to be even more distributed ala fossil or bittorent, to mention two not quite fitting but conveying the point examples. Maybe git-appraisal will grow into something good.

This gets brought up pretty much every time GitHub is mentioned on here, and I've never understood it. Using a hosted service like GitHub as a remote for your git repo doesn't "negate" the distributed aspect, any more than parking your car somewhere negates its ability to drive around.

I can use GitHub as a remote and take advantage of the social and UX aspects they offer, and if GitHub vanishes (or has downtime), I can continue utilizing my git repo with all the distributed features it had before. I can (and have) continue to work while GitHub is down, I can export any of the additional data (issues, wiki, etc) that GitHub offers and store them just like I store all my backups, etc.

Centralized hosting solutions can offer value, even to distributed tools.

Where GitHub ends up conflicting with distributed workflows is when build pipelines or other systems are set up to rely on GitHub (Go dependencies, I'm looking at you). In cases like this, the user is making a choice to pin that piece of their infrastructure to a centralized service. And that's not always a bad call! If the value provided outweighs the harm done when the centralized service goes down or has other issues, it can be a good choice. It's up to the person designing their infrastructure to balance the risks and benefits, as with anything else.

Specifically speaking to GitHub's lack of incentive to invest in extending distributed git features: that seems counter to actual events. They recently worked to develop their large file storage, and rather than release a closed source / centralized system, they released an open source extension that ties in with core git (https://git-lfs.github.com/)

Post reply on HN