An open letter of gratitude to GitHub
github.com
github.com
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.
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.
Is this your issue? https://github.com/dear-github/dear-github/issues/47
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.
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?
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.
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.
Well then sign this one too (:
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"?
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.
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.
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.
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.
[1] https://ipfs.io/
(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!...)
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).
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.
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.
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?
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.
What about implementing an API to let other people implement some of the needed features?
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.
> The responses are fanboy trash in a "using my serious voice" wrapper"
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.
This seems passive aggressive to me.
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.
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?
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.
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.
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.
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.
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.
The dilemma is about the sum of the parts.
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.
[1]: See Mike Gerwitz's GitHub Does Not Value Software Freedom: https://mikegerwitz.com/about/githubbub
[2]: https://github.com/search?q=stars:%3E1&s=stars&type=Reposito...
> 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.
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.
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.
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.
> The recovery process would be as simple
It's like suggesting that it's not so bad if a massive forum shuts down by pointing out how easy it is to install phpbb and run an import script.
That's a straw man. I said it would take a few months to resolve the logistical issues surrounding migration.
Instead of caricaturing my thought process, could you please specify some of the "disastrious" difficulties you and the GP are concerned about?
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.
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.
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.
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.
And when I say "a good while" take in consideration that articles/releases more than a couple month old are considered ancient these days.
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.
But they were not hubs at the GitHub level, contributing to Open Source was fragmented.
A higher level of discussion and low noise is something to shoot for on HN.
It has been, several times, but each in a much better way than the comment I was responding to did.
Someone develops an OSS platform, a corporation monetizes that platform, and it's the corporation that is now receiving all the praise.
Yeah, the irony :/
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?
>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.
[0] https://wubthecaptain.eu/articles/why-i-dont-support-github....
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.