Live data from Hacker News

An open letter of gratitude to GitHub

github.com

81–90 of 113 posts

Re: An open letter of gratitude to GitHub

#81
post #73
post #11

I find the current situation with Github very unhealthy, because, even though very unlikely, someone can literally pull off the plug of open-source. Not all, but a great part. If such thing happened, be it with government intervention or some crazy attack towards github, it would make us lose a lot time migrating to other solutions. It would be like a Great Barbaric Invasion of Open Source, where everyone migrated to…

> I find the current situation with Github very unhealthy, because, even though very unlikely, someone can literally pull off the plug of open-source. It's not very unlikely; it's something that will definitely happen at some point (in the case of SourceForge, well over a decade). Most projects will migrate away, but there will be losses.

Though note that SF did not die overnight, it is still lingering. However I, too, believe that most stuff will survive, but I think that it'd take a good while to adapt.

And when I say "a good while" take in consideration that articles/releases more than a couple month old are considered ancient these days.

Re: An open letter of gratitude to GitHub

#82
post #78

Earlier quoted context omitted.

The bug tracking data might be tough to replicate, but everything else is stored on each contributor's machine. I think recovery time wouldn't be so bad.

In projects that are community-based, it would be a matter of recreating this community too. This involves humans and isn't as simple as restoring a backup, there would be much inertia.

Every git commit most usually contains the committer's email, so that would ease things up a bit.

Re: An open letter of gratitude to GitHub

#83
post #43

Earlier quoted context omitted.

> 1. While the situation improved tremendously in certain areas the way to participate in Open Source is still very much fragmented. Most of the major open source projects (like Linux, Mozilla, Apache and nginx, to name a few) still have their own workflows, patches are still circulated in emails and issues are still being reported in a myriad ways. Despite of the big visibility GitHub has among the new open source p…

No, there are still newer projects that refuse to use github because it's a closed source system (e.g openstack).

That's a better example. Thanks for the addition.

At first blush (having just looked at their contribution system for the first time, and not having actually followed through with a contribution), I would say that open stack has built a commendably low friction contribution system. Their documentation seems clear, and the source is conspicuously located on their site. There are minor barriers, but nothing that would limit anything besides drive-by pull requests, which are of dubious value anyway.

I would tend to say that Openstack was somewhat anomalously well supported (and funded) early on. Github has enabled a lot of one-person-show projects to grow into projects with many contributors (Ansible and Cookiecutter jump immediately to my mind for whatever reason). It may be the case that larger projects that are desired by large institutions have the flexibility to build their own contribution systems that neither cede control nor introduce undue friction. It does however seem to me that Github, Bitbucket, et. al. have lowered the friction of open source projects that get actual external contributions (where the project, if not the contribution system is open source) to much smaller groups of developers, all the way down to one-person projects.

Projects that have multiple large organizations on board early on have a large incentive to implement a relatively comprehensible contribution system, as well as additional resources to bring such a system into existence. Small team or one-person projects have less incentive early on, and have less resources to implement such a system. Having Github/Bitbucket as a default for small projects means that small projects likely have much less chaotic contribution methods early on.

Since quite a few of these small projects have become strong opens source projects with many contributors, where it seems unlikely that some of them would have outside of the existence of such contribution organization options, it still seems safe to say that Github has on the whole lowered the overall level of chaos in open source contribution. It has apparently done so through its influence on small open source projects, and through it's role in raising the standards regarding the level of friction that would be OSS contributors see as reasonable, i.e. by competing with other contribution systems, it has forced other systems to lower the amount of friction in their contribution processes. So while there are still disparate contribution systems, Github has influenced things toward a lower friction state by being a strong leader in the space. And this has resulted in more coherent contribution processes on the whole despite the existence of projects that exist outside of Github.

Re: An open letter of gratitude to GitHub

#84
post #71

Posting this right after some good suggestions for the service was given feels like this is saying it is wrong to make suggestions for GitHub because they have done good things. This to me, itself, is wrong. The GitHub issue tracker does need to change. While it's great for OSS that projects can get a leg up SOONER, GitHub does introduce it's own problems by having some watered down tooling in some areas. I'm STILL a…

> The GitHub issue tracker does need to change. Does anyone like any bugtracker? That's a serious question. I've never used one that was a joy to use as a submitter (GH's issue tracker is one of the better ones, as it's so simple) or as a maintainer. As a maintainer I've found them really frustrating in general; JIRA has been one of the better ones for me. Any consensus on 'decent' trackers?

> I've never used [a bug tracker] that was a joy to use as a submitter [...]

And it shouldn't be. If it is, people submit stupid bugs. When you get a notification of a bug, and you go read the bug, and try to reproduce it, you'll spend at least about five-ten minutes. The submitter then is obliged to spend at least about that much to report a proper bug report to an open source project where even the licence revokes the responsibility of the maintainer to respond to the submitter. And if good will and conventions can't force this, the bug tracker should.

Re: An open letter of gratitude to GitHub

#86
post #76

Earlier quoted context omitted.

> a big part of that may be questions of who exactly is "involved" with the letter. Being someone who's helping with the `dear-github` repo, why does WHO is behind the repo matter? Does it change the reflections of the community who've come out to support it and sign it?

We agree, I don't think it matters. I initially believed based on the "petition" nature of the letter and adding signatories that it was going to be an inclusive effort. Which is why I've asked and received absolutely no answer as to why one of the dear-github organizational "owners" (as labeled on Github) responses to my issue inquiry was to tell me who he was, then use that to determine my issue was not constructiv…

> one of the dear-github organizational "owners" (as labeled on Github) responses to my issue inquiry was to tell me who he was, then use that to determine my issue was not constructive.

Based on the issue linked above, it doesn't look like this is what happened. Although it may have happened through some other channel.

What it looks like happened is that neither one of you were able to understand what the other's point was.

Re: An open letter of gratitude to GitHub

#87

Before 2007, the way to participate in Open Source was fragmented. Each project had their own workflow, patches circulated in emails, issues were reported in a myriad ways, and if anyone wanted to contribute they had to figure out every project's rules. Then, a handful of guys took the challenge to build an awesome platform and as a consequence of their hard work, their platform earned its hegemony. Two things stand…

IMO, the "Dear Github" open letter is a constructive way to call attention to the perceived problems I agree entirety. The responses are fanboy trash in a "using my serious voice" wrapper. I don't use github enough to share the gripes in "Dear GitHub." They seemed kinda minor and I understand why they wouldn't be in the product. But in light of the poor communication from GitHub explained in the letter, it seemed lik…

I agree with the point, too, but statements like this are not conducive to good discussion and are not the kind of thing I look forward to reading on HN:

> The responses are fanboy trash in a "using my serious voice" wrapper"

Re: An open letter of gratitude to GitHub

#88

Before 2007, the way to participate in Open Source was fragmented. Each project had their own workflow, patches circulated in emails, issues were reported in a myriad ways, and if anyone wanted to contribute they had to figure out every project's rules. Then, a handful of guys took the challenge to build an awesome platform and as a consequence of their hard work, their platform earned its hegemony. Two things stand…

In my opinion this fragmentation is a good thing. Monopoly is a terrible thing, especially in the hands of a private company.

Re: An open letter of gratitude to GitHub

#89

> Before 2007, the way to participate in Open Source was fragmented. Um...ever hear of Source Forge ? Yeah, before 2007 there was another OSS hegemony. It failed to meet its users needs. It was replaced. So it goes.

The Internet has a VERY short memory.

The author of the post had projects in SourceForge, also listed in Freshmeat.

But they were not hubs at the GitHub level, contributing to Open Source was fragmented.

Re: An open letter of gratitude to GitHub

#90

Before 2007, the way to participate in Open Source was fragmented. Each project had their own workflow, patches circulated in emails, issues were reported in a myriad ways, and if anyone wanted to contribute they had to figure out every project's rules. Then, a handful of guys took the challenge to build an awesome platform and as a consequence of their hard work, their platform earned its hegemony. Two things stand…

> 1. While the situation improved tremendously in certain areas the way to participate in Open Source is still very much fragmented. Most of the major open source projects (like Linux, Mozilla, Apache and nginx, to name a few) still have their own workflows, patches are still circulated in emails and issues are still being reported in a myriad ways. Despite of the big visibility GitHub has among the new open source p…

> OSS Projects that have begun in the Github era have a much higher probability of having an approachable contribution workflow.

This is essentially an empty statement, because it has no backing. Would the claim stand up under scrutiny? How would you go about measuring it to see for yourself?

Post reply on HN