I assume this is a response to the "Dear Github" letter. I'm fairly certain that everyone involved in that letter (including myself), is very appreciative of Github and its impact on OSS. That letter didn't feel ungrateful or malicious at all to me, but I sure hope it didn't come off that way to others.
What I do frequently see with Github, is that they've managed to work their way into almost being beyond reproach. This letter feels like an example of that...Almost like Github needs someone to stand up for it in light of some meanies picking on it.
It's a good product. We should give credit where credit is due, just don't forget it's a product. A (by all indications), very profitable product that wants to make money off you. That is its goal and purpose in life, and OSS furthers it. For the record, I think this is a good and healthy relationship, but we shouldn't pretend it's some FOSS group or non-profit out struggling to provide us with Git hosting.
> they've managed to work their way into almost being beyond reproach
Yep. It's annoying as hell when I tell someone I use Bitbucket and they try to get me to change to Github. And I'm not talking about for FOSS repos, they want me to convert my free Bitbucket repos to paid Github repos, because Github.
> A (by all indications), very profitable product that wants to make money off you. That is its goal and purpose in life, and OSS furthers it.
I'd go a little further than that. Their strategy, while good for some FOSS projects, is a common marketing tool. I can use Wunderlist, Evernote, and Dropbox for free in a limited capacity as well. The thing about those strategies is that they last as long as it's in the interest of the company to provide them.
> I'd go a little further than that. Their strategy, while good for some FOSS projects, is a common marketing tool. I can use Wunderlist, Evernote, and Dropbox for free in a limited capacity as well. The thing about those strategies is that they last as long as it's in the interest of the company to provide them.
It seems to me like the solution to that is for the git protocol to extend to encompass the Github tools FOSS projects have come to rely on, so Github can never hold open source projects hostage (not that they would, but as the saying goes, "Trust but verify")
Git + IPFS [1] + GPG = distributed Github. The hard part is someone building the tooling.
Also remember about Sourceforge. I guess some people could have been in the mood to write gratitude letters to them at some point in the past.
(Does not mean that GitHub is "bad" or be useful for some free software projects right now, just that from where I am I don't think there should be a special reason to thank such a company in the name of "Open Source" -- at least also thank Linus Torvalds to begin with!...)
When I read the "Dear GitHub" repo my first thought was, I agree with some of this, but my overall attitude toward GitHub is gratitude and the flexibility to create whatever repo standards you want to. I then saw the "Thank You GitHub" repo and think it's a great way to express that gratitude!
I personally do not view these as rival repos. They just express different sentiment and serve two purposes (again not apposing each other).
Does this have to be viewed as a polar opposite response to "Dear GitHub"?
> Does this have to be viewed as a polar opposite response to "Dear GitHub"?
I can't see how it isn't. I thought the original was quite clear that they appreciated Github, but this undercuts it.
Imagine any scene where you're talking to the manager of some establishment. You say "Hey guys, this is great, but can you fix the blinds, we've been waiting an hour to not be blinded?" Someone next to you pops in with "Hey guys, I love it here!"
They've just undercut your argument without even addressing it. It is, frankly, rude.
> Does this have to be viewed as a polar opposite response to "Dear GitHub"?
Certainly not. My comment was in all seriousness. I expect that pretty much anyone signing the Dear Github letter would also feel comfortable signing this one.
> That letter didn't feel ungrateful or malicious at all to me, but I sure hope it didn't come off that way to others.
It might have; software engineering is a big tent, and people who touch Github (in at least someway) no doubt comprise a huge part of it. Full disclaimer, I'm biased, as I opened an issue attempting to address some potential editorial/tone issues, and the initial response was not good (a big part of that may be questions of who exactly is "involved" with the letter. How should others become involved and contribute in a way the OPs feel is constructive?)
As another commenter pointed out, not everything is so black and white. In this case, no one should be "beyond reproach", but what seem like simple issues to Issues may indeed be representative of strong product/technical decisions from an opinionated vendor. IMO it's not inherently clear that the people behind dear-github entirely recognized the nuance here. No one is looking to pick fights or troll anyone, because no, not everyone who is passionate about this issue is a meanie. That said, the original letter and the immediate response could be interpreted as brash, and to that end, I wouldn't be surprised that someone responded with thank-you-github as an opposite reaction.
If so, the way you've written your issue is almost incomprehensible and your point is seriously irrelevant to the requests made by the project creators.
> 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 constructive.
> 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.
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).
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.
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.
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"
> 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.
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.
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.
> 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?
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 at odds with how it has shifted the equation from discuss to throw code at the problem, which generates extra code review and often, angry committers when their patches are not immediately merged or unwanted, or have to be reworked.
GitHub has done some GREAT things because it has built up critical mass, but because it has gotten critical mass and has become a defacto standard, does have some obligation to keep up with demand.
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.
> 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.
> And it shouldn't be. If it is, people submit stupid bugs.
I strongly disagree. You're conflating easy to enter a bug with a pleasure to use. There's no reason to throw both out.
Also, you're thinking of a public tracker. Where it's used within a team, having it easy and a joy to report issues is hugely beneficial, so they get logged without nagging and moaning.
A repro steps field is a must. If I was a contributor (and I am!) then I would look at the thousands of bugs coming through and focus on only those with those that have that filled in.
Popular bug trackers suffer particularly from a curse all popular software faces: a constant barrage of criticism from a variety of user bases with disparate needs.
Appeasing any one of these alleviates a tiny portion of that pressure, while permanently ratcheting up complexity, which leads to accusations of bloat, steep learning curves, and eventual abandonment. Faced with that fact, it's understandable why GitHub wouldn't just throw in new feature requests wantonly.
I think if they communicated that consistently and clearly, people would be disappointed, but they would understand. After all, Github's users are developers who probably struggle with these same product trade-offs. The biggest problem is the lack of transparency or feedback in the product process.
The motivation behind this letter is embarrassing.
It's as if they were talking to GitHub the thankless FOSS maintainer. Quit mirroring guys. It's a for-profit enterprise that would do well to listen to the concerns of its userbase.
> It's a for-profit enterprise that would do well to listen to the concerns of its userbase.
Very true, and I'm surprised this is the first comment that points this out. GitHub doesn't need our thanks -- it gets our money. You could easily argue that the OSS/social aspects are excellent marketing tactics, not anything remotely like altruism.
I'm also starting to become concerned that GitHub, a for-profit, has locked in so much of our industry. In my opinion, they need to be responsible stewards of all that lock-in. Look at what happened when SourceForge stagnated and then started to spread malware. There's no reason the same thing couldn't happen to GitHub.
I agree - there's nothing wrong with the original Dear Github letter - github is a big company with lots of inertia, being called out on failing to support the growth of their OSS community isn't going to hurt their feelings but it may spur some change.
This letter just feels sycophantic and obsequious to me. And sucking up to billion-dollar companies doesn't feel like its in the hacker spirit, if you'll allow me to posit that such a thing still exists.
The controversy isn't black-and-white and I'm not sure why this letter is painting it that way. GitHub can be a major boon to open source and have core issues which make it incredibly frustrating to work with the service.
Completely agree, also this post makes it appear like GH did all it has done out of the goodness of their heart... Sure it's great what they did for OS but to pretend that wasn't rooted in making money is just ignorant.
> 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.
And it was much better IMO. Now we have a centralized website, in the hands of a single corporation, which requires nonfree JavaScript for much of the basic functionality[1]. Git was designed to work well with email and has commands built-in to format, send and apply patches. I think anyone who used email for patches seriously will agree that they are largely superior to GitHub's pull requests.
The free software movement being fragmented is a good thing. GitHub is the land of trends: web developers using Mac OS X who make apps with the latest trendy frameworks like React and Angular (if you think that's a misportrayal, look at the first three pages of the most starred repositories on GitHub[2]). These people don't care about the free software movement, they're just following the current trends, one of which is "Open Source". But if they really cared about free software, they would not be using Mac OS X or GitHub, which requires you to run nonfree JavaScript code in your browser to report issues, open pull requests, etc.
The serious projects that do care about free software don't use GitHub.
As someone who sometimes feels like the only one who remembers both the world before GitHub-style pull requests and the benefits that patches have over them, I can appreciate your ode to patches and the way that Git was designed to handle them. Not really excited about your no-true-Scotsman-ing, though.
Github makes millions of dollars per year and has a huge amount of users so the product is proven good. While I understand the need to be appreciative of Github, giving the organization a bit of user feedback is not going to hurt them very much. The response assumes that this is written because of the "Dear Github" letter.
While GitHub makes millions per year, it's important to keep in mind that "GitHub" and every other company is really just a collection of people like you and me. I'm sure their engineers are paid well, but money isn't everything, and it's nice (and motivating) to show up at the office and know there's people out there who appreciate the work you put in regardless of what you're being paid.
There's nothing wrong with showing gratitude from time to time, even if it's for a for-profit corporation if you truly appreciate what they do.
every other company is really just a collection of people like you and me
That's cool and all, but wasn't the motivation for the first letter the lack of humanity from GitHub in communication with the userbase?
I don't think they deserve a cooing public letter to reassure them on the basis of humanity after they've decided to give "empty response or even no response at all" to what read like perfectly reasonable attempts to communicate with them.
I'm entirely willing to use person-to-person social standards for a company. I'll start with a trust-but-verity attitude, because leveraging a double standard in customer facing business is often a way for companies to take advantage of customers. Once they show they're not interested: fuck 'em.
Constructive feedback is fine, but "I have told you, you know that, but you are ignoring me, what's wrong" is a different story. My reaction to that is 1) it shows you already sent the feedback, what you want is to complain in public, and 2) I own you no shit.
That's a rather wild insinuation of the "Dear GitHub" authors' motivation. If your constructive feedback is ignored you have to start a public discussion to get the thing rolling again. That's not necessarily as selfish as you imply. There are a lot of people who would benefit from the addressed issues being resolved.
> I own you no shit
GitHub might owe them nothing, but it's in their own interest to address and resolve those issues and not just stash them away somewhere. Their biggest selling point is the great UI and the userbase. If the later becomes frustrated because issues with the former don't get resolved, that might be a huge problem for GitHub in the future. Today, there are viable alternatives after all.
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 Bitbucket or private solutions, sort of an OSS incastellation.
> 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.
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.
If everyone went to another solution like Bitbucket, yes, it would be quick. But if I were maintaining anything significant, after such event, I'd never consider a private solution again. In Turkish we have a saying, "he whose mouth is burnt by milk, eats yoghurt blowingly".
That's a huge mistake you're making there. Recovery time would be in the years because github is a hub. It became a focal point for a very large amount of activity, losing that hub would be an absolute disaster.
Not really. I agree GitHub is a great for open source, but its not essential. It would be a shame to lose the community, central location, user activity history, etc... but actively maintained projects would not suffer much.
The recovery process would be as simple as pushing to a new remote and emailing the core developers. It would probably take a few months to properly set up a JIRA or other bug tracker and for everyone to settle into the new work flow.
The genius of git (or should I say BitKeeper) is that its distributed, so having a hub isn't really important.
You entirely fail to appreciate the word 'community'. That's fine with me, I don't care one way or another whether I can convince you that losing github would be a disaster for open source but just for a minute consider why all these open source projects that were formerly hosted in different places migrate to github. The community has achieved critical mass and that is what drives this, the technology is entirely secondary to that.
If you lose github you lose the community and a user / contributer to say 'apache spark' will not automatically be a user / contributor of all the other open source projects hosted on github. Single sign on for contribution to any open source project and a consistent user interface are also big pluses (but those are technical), and would be hard to achieve as well.
So in my opinion github (and several other services) are now really too big to fail.
Thank you for the substantive reply. I love github and I do appreciate the macro level of community it provides. If no other community platform sprung up it's demise would certainly be a regression for open source. In that sense, I agree with what your saying.
The last line is where we fundamentally disagree, but that's ok. I think open source would be able to recover from the death of github without much long-term difficulty. It would be a painful transition, like all transitions, but I don't think it would be an overwhelming problem or disaster. Maybe I'm just optimistic.
The "community" model of github is like that of an online strategy game, it's based on bragging about numbers. Stars, commits, followers. It is the illness that all modern things have... So, while I hold that a demise of Github would have a huge impact on the community, I am not holding that such impact would end up bad for it. In fact, if the communities switched away from such technology, it'd be better for the open source. We'd focus better on developing our projects and wouldn't be distracted by the stargazing etc.
> The "community" model of github is like that of an online strategy game, it's based on bragging about numbers. Stars, commits, followers.
I don't care about any of those things and I think that that goes for the majority of contributors to github open source projects. What does matter is the number of contributors to a project and how involved they are, that's a useful metric.
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.
I agree with the sentiment of your comment, but I don't think it was necessary. There are better ways to put it, and several of them have already been made.
A higher level of discussion and low noise is something to shoot for on HN.
I disagree. The passive aggressive nature of the post needed to be pointed out. It is at the heart of what is wrong with this post. This was not just another letter that "pretty much anyone signing the Dear Github letter would also feel comfortable signing" as the OP would now like you to believe, but a passive aggressive response to the constructive criticism of the original, as evidenced by its tone, timing, and context.
I just want to point out accepting pull requests for signatures is a bad idea -- someone is going to lose the race and rebase over and over if unlucky, assuming many people are going to sign this. :-)
> 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.
Don't you still have to figure out every project's rules? Being on Github does not impose coding guidelines, testing requirements, documentation requirements, contributor license agreement policies, project management and governance system, code review process, dispute resolution process, and so on.
> Nowadays doing Open Source is infinitely easier thanks to you, GitHub. You've provided the tools and the social conventions to make those days a thing of the past.
Nearly every time over the past 30+ years that I've wanted to fix a bug or add a feature to some open source thing I've been using, and been thwarted, it was never figuring out the workflow, or patch procedure, or issue reporting that did me in, or figuring out the project's rules.
The big problem has usually been one or both of (1) the project has a bazillion files and it is not at all clear from the meager documentation and haphazard directory organization which are for the thing itself and which are for ancillary tools, and (2) it gets build errors that I can't resolve.
Shouldn't we (the OSS community) have an open source, roll-your-own version of something like GitHub? Like, the repo-management equivalent to a phpBB or a Wiki or a Wordpress.
We do have the separate components, though maybe the hard part is to glue them together. But still, it is something what would be worth the time and effort, wouldn't it?
Sorry, but as a free software advocate, this really bugs me.
>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.
And now we have a monoculture. Monoculture is bad, folks.
This letter paints pre-2007 as something bad because everyone used their own infrastructure for their projects, but this is actually a really great thing. It meant that more projects had autonomy over the infrastructure that they rely on. So, rather than needing to beg a for-profit corporation for features that they want, they could actually change the software they used to work for them. Monoculture is more convenient for the masses, but trading freedom for convenience is a bad deal in the long-term.
The web is becoming more centralized every day, to the detriment of all Internet users whether they know it or not, and when SaaS apologists thank GitHub for helping it makes me upset. A federated, free software source code hosting tool could solve the barrier to entry problem without relinquishing control to a company who ultimately does not care about you.
And how about GitHub's ToS? Has anyone read it? Probably not. I didn't when I signed up. Did you know that changes to the ToS can happen any time and without notice? Even if you did read the terms, by agreeing to them, you agree that they can completely change them. Who would reasonably agree to that if it were not buried in legalese? You also surrender your rights to a fair trial by defending and indemnifying GitHub. For further reading, see "Why I don't support or contribute to GitHub repositories" [0] or read the ToS for yourself.
Now, on a technical note: GitHub encourages bad development practices via hooking people on their web interface. The Pull Request interface is the biggest offender. It encourages unclean commit history because it's scary to rewrite the patch set of a pull request. If you rebase fixup commits, you have to force push the changes. You cannot even do the safer route of deleting the remote branch and pushing the new branch because GitHub will automatically close the pull request with no way to re-open it. So, most people just pile on fixup commits that never get squashed into decent patches. And that's not all! The Pull Request interface makes it difficult to comment on individual patches by encouraging reviewers to look only at the aggregate diff of all patches. This leads to lower patch quality because it leads to a bunch of terrible patches that look okay squashed together to enter the Git repository. When your patch history sucks, it reduces the utility of blaming and bisecting to find issues or otherwise learn about the code. Reviewing patch sets on a mailing list is, despite being "low tech", a much better experience for me. I'm not forced to use a web interface, I can just use the email client of my choosing, and Git already knows how to do an email-based workflow. There's a reason why a huge project like Linux still does patch review via email.
In conclusion, GitHub is a company that receives almost nothing but praise. Most criticism is dismissed because they have a nice UX for a certain group of users (not me). I think GitHub has harmed the free and open source software community both ethically, legally, and technically. I no longer use GitHub for hosting my personal projects. I write all of this in the hopes that more people will recognize this and work on real replacements for GitHub.
One time an Atom user posted a question on the Atom editor forum. He said he loved Atom and wanted to donate. It was a bit complex to explain that they would be contributing to a large corporation, GitHub. I thought this was symbolic of the confusing relationship GitHub has with open software.
I'm not totally agree with both letters, just for personal reasons, but this is not the point.
Overall GitHub is a cultural place where anyone can improve his personal skills, expecially in computer programming, thanks to the huge code present on it.
I have romantic vision of Github.
For instance, guys from poor parts of the world can study great code with this site.
Yes it is a company with investors and probably it made some wrong decisions, and if we want we can choose other services, but today sorry for the repetition Github represents an open and huge cultural Hub.
I recommend, dont send any pull requests. On of the useless project on Github. How he gonna merge 1000s of PR - and PR to just add a name - seriously? This is just waste of time & resources.
When GitHub came along it was an improvement over what was available back then. But that doesn't mean it's perfect or that it can stop evolving. Yes, thank you GitHub for what you achieved in our community so far, but dear GitHub don't stop and keep moving forward.
If you want to thank them, just be a customer. This is unnecessary and seems like it devalues any criticism, especially considering the other recent letter. They are not some sacred thing to be protected.
Hmm so the response of the GitHub is to post a single generic response of "we will look into it" and then spend time and resources arranging this marvel of a letter.
What I do frequently see with Github, is that they've managed to work their way into almost being beyond reproach. This letter feels like an example of that...Almost like Github needs someone to stand up for it in light of some meanies picking on it.
It's a good product. We should give credit where credit is due, just don't forget it's a product. A (by all indications), very profitable product that wants to make money off you. That is its goal and purpose in life, and OSS furthers it. For the record, I think this is a good and healthy relationship, but we shouldn't pretend it's some FOSS group or non-profit out struggling to provide us with Git hosting.