[luso_brazilian]

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 out in this "thank you Github" open letter:

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 projects we are very far from not being fragmented.

2. Before 2007 we had, for instance, SourceForge that back then had also earned its hegemony and, for a series of reasons (one of them being too late to answer to the community wants and needs) lost its way, its hegemony and its user base.

There is time for praise and time for hard work and, IMO, the "Dear Github" open letter is a constructive way to call attention to the perceived problems while the 'Dear "Dear Github"' and this gratitude letter are dismissive to their concerns (the former) and mostly empty praise and adulation (the later).

[forgottenpass]

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 like a perfectly reasonable and polite step to try and open a channel of communication.

[stcredzero]

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.

What about implementing an API to let other people implement some of the needed features?

[forgottenpass]

Sure, that's a possible solution.

I wasn't trying to convey a position that something shouldn't be done, I'm just expressing that I understand the wide breadth of possibilities for why it hadn't been done.

[carussell]

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"

[unexpand]

You said it well my friend. Dear Github had substance and this feels shallow for its timing and content.

[shawn-furyan]

> 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 projects we are very far from not being fragmented.

All of the projects that you list began in the pre-Github era where the choices were essentially endure Sourceforge's significant shortcomings or roll your own contribution system (Linux and Apache didn't even have Sourceforge as an option for a long time).

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

So in short, Github didn't solve all of the chaos in the OSS world, but it has improved the situation going forward from its inception. It's even attracted several legacy projects that previously had more insular and opaque development processes.

Note: this is not to dismiss the issues that do exist with Github. I just don't think that criticism #1 above is very valid.

[hueving]

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

[mchahn]

Mozilla has a hard rule that they can't use closed-software for anything. I bitched about their 20-year-old-technology mailing lists and they said they had no choice. They couldn't use google-groups, et. al., because they were closed-source.

[hueving]

That's good. I think it's important to support open source rather than a closed source service with lock-in.

[shawn-furyan]

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.

[carussell]

> 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?

[jeena]

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