
GitHub responds to Dear GitHub letter - joshmanders
https://github.com/dear-github/dear-github/pull/115
======
thejameskyle
Some of the responses here are kinda obnoxious. I helped kickstart the
original letter and I'm very happy about this response.

GitHub more than anything has been a blackbox, and this was a very notable
first step towards opening up. It should be encouraged, not shut down.

Privately (and some publicly), in the past few days, a lot of major open
source projects were discussing a coordinated move away from GitHub. This
likely puts that all on hold, but we'll see what changes GitHub makes and how
people want to respond to it.

Again, I'm very happy about this response, as should everyone in this thread.
We'll see in the coming weeks what it really means though.

~~~
bovermyer
Where would those projects move to? There's no real alternative to GitHub, at
least none that combines the social side of it with the Gittiness of it.

That I know of, anyway.

~~~
scrollaway
Gitlab is a worthy alternative. It's only missing critical mass, which gives
Github the upper hand in considerations such as "all my foss contributions are
on there in one place and that's what companies look at when they offer me a
job".

Hey, sytse - I know you're reading this. Have you guys thought about a way of
including, in gitlab profiles, user info from Github in a non-intrusive way?

~~~
zyxley
> It's only missing critical mass

As somebody who loves Gitlab... no, what it's missing is Github's reputation
of lasting uptime reliability. If they get it to the point where people trust
it to always be up to the same extent as Github, the rest will follow.

~~~
scrollaway
That's one of the definitions of critical mass. Reputation is built up over
time and usage. Gitlab's uptime reliability isn't particularly known or
unknown, mostly because, compared to Github, it's not used enough for those
issues to come up.

Try talking to a dev, ask them why they use Github instead of Gitlab. Are they
going to tell you "Oh I absolutely would use Gitlab but their _uptime is such
a problem_ "? Or are they going to tell you their stuff's already on Github?
Their friends/coworkers are on Github? Their employers look for their Github
profile?

As a sidenote I would totally use MySpace instead of Facebook if not for their
notable history of extended downtime...

~~~
dandelany
I partly agree, but those that have done the research or already use Gitlab
know that Gitlab's uptime _has_ been problematic compared to Github's, which
is a bigger issue for most companies than the community. As sytse correctly
notes below, it's a lot better than it was a few months ago - but the
pessimistic/risk-averse way to say that is "as recently as two months ago they
were having major uptime issues". I have high hopes for Gitlab and I think
they're doing great things, it's always great to see new competition in the
space. And I applaud their transparency, it's refreshing! But it'll require
some more "burn in" time before I consider it a reliable Github replacement,
all questions of critical mass aside.

~~~
sfilipov
On the plus side, if the manage to fix their problems at some point people
will start trusting them to be up. It is not set in stone that they have worse
uptime.

~~~
dandelany
Absolutely, and I do think most of their problems have been fixed. So it's
just a matter of time - the longer they are stable, the better their
reputation will become.

------
rogerbinns
I complain every 6 months about their "releases" page - eg this one for my
project
[https://github.com/rogerbinns/apsw/releases](https://github.com/rogerbinns/apsw/releases)

They unhelpfully add a "Source Code" link, which would be great if that is
what it was. Instead it is actually just a zip file of the repository at that
tag. But the repository is in a maintainer state, so the "Source Code" isn't
useful to an end user because various tools need to be run (eg building help,
automake/autoconf, dependencies). The people mislead by Github due to this
"Source Code" contact me, not github.

Every six months for several years, I send the email explaining how this
doesn't serve anyone's interest, how it hurts, and that I am happy with any
solution (eg don't auto add, change the name to make it clear, be able to
label an existing file as the "Source Code" etc). I get the usual response of
understanding and sympathy, and vague suggestion that it may be addressed.
Three years and counting ...

~~~
speg
> They unhelpfully add a "Source Code" link, which would be great if that is
> what it was. Instead it is actually just a zip file of the repository at
> that tag.

Huh, if all the files of the repository at that tag aren't the "source code"
of that release what is?

~~~
maaku
Any reasonably complicated project has some pre-processing that has to be done
for a source release. e.g. creating the configure script for autotools repos,
or building the documentation. These steps can and should be automated, but
github is not providing hooks to perform these automated tasks.

~~~
IshKebab
Yeah but those steps should be part of the normal build process. If you have
to use weird tools (e.g. autotools) to generate your "real" source code, I'd
say the problem is those tools. Also. Seriously. Autotools? In 2016?

~~~
adrusi
So what would you suggest in lieu of autotools? The only real mature
alternative is cmake, and cmake's main advantage is that it is a cross
platform build system. Basically that means it works on windows without cygwin
or its equivalents.

If you use something other than cmake or autotools, you're going to end up
making the lives of packagers more difficult. If they have to change anything,
as they usually do, they're going to have to know how the build system works,
and they dont necessarily want to deal with whatever new-fangled build system
you're using.

Usually projects using cmake distribute their source code with cmake build
scripts because they're taking advantage of cmake's cross plaform features,
and cmake generates different source distributions for different platforms.
But this does place a burden on the user to have cmake installed. There's a
good argument to be made that that's no longer much of a burden, after all,
it's just one package manager invocation away. But you have to think about
who's downloading a source distribution (as opposed to binaries or checking
out the repository). They're people who are compiling from source for esoteric
platforms, perhaps and embedded system, where a cmake package might not
already exist. They're people like me who are writing their own pkgbuild
script because they like to keep their system well organized and not have too
many useless packages (like cmake) lying around. They are people creating a
new linux distribution who haven't yet packaged cmake but want to package your
software.

And in terms of software design, cmake isn't very good, at least in the eyes
of many people writing unix systems software, which as far as mature open
source software projects written in C/C++ go, is a lot. Don't get me wrong,
cmake certainly has the cross platform advantage, and if you're making
software that you want to compile on windows, you'd be remiss to not at least
seriously look into using cmake (not that it's the only option, you could also
opt to lean on cross-compiliation from a unix platform to windows,
distributing binaries only, or requiring users to install cygwin, which isn't
worse than having to install visual studio if you don't already use it).

But if you're _not_ taking advantage of the cross-platform features, I'd say
cmake is pretty awful. Precisely because it's cross-platform, cmake rejects
the typical design principles of unix software, instead offering a monolithic
build system that requires special scripts to be written for any different
tools you want to use, or even any complicated dependencies (for example:
SDL). This is necessary because cmake needs to establish a consistent internal
interface that can work for both the windows and unix tools. As a result,
everyone has to learn how to use the monolithic cmake system from the ground
up, and those skills won't be useful for anything else.

In contrast, autotools, known for having a high learning curve, is really not
that bad for people who already _know unix_. If you understand how to use a
unix system, you can figure out autotools faster than you can cmake. And you
can _really_ know it, to the extent that you feel confident diving in and
messing with its defaults, much sooner than you would with cmake.

But of course, ease of learning isn't the only factor autotools integrates
with external tools using their standard interface while cmake demands you
essentially write a wrapper for them. Autotools is simply more flexible.

I don't like autotools, for the record, but given the options available, I'd
probably choose it over any other build system in almost all the places it's
used currently and more.

~~~
GFK_of_xmaspast
> In contrast, autotools, known for having a high learning curve, is really
> not that bad for people who already know unix. If you understand how to use
> a unix system, you can figure out autotools faster than you can cmake. And
> you can really know it, to the extent that you feel confident diving in and
> messing with its defaults, much sooner than you would with cmake.

I've been using unix since 1992 and find the entire autotools suite to be
almost incomprehensible. The low point was in 2014 when I was trying to
compile a package that intentionally did not ship a configure file and made
the user explicitly call autoconf. This would have been ok except that in the
3 or so years between when the code was released and I was trying to build it,
autotools made some backward-incompatible changes and autoconf/automake
errored out, with no indication of how to fix those. Eventually I just gave up
and used a different package.

Conversely, when I started using cmake (motivated by clion using it as a build
system) I was able to get it up and running basically immediately, and 12
months later I appear to have become the cmake guru for my company.

~~~
mcguire
" _The low point was in 2014 when I was trying to compile a package that
intentionally did not ship a configure file and made the user explicitly call
autoconf._ "

At the risk of having to admit I've had my share of bad experiences with
autotools, _don 't ever do that._ That is a big sign with flashing lights and
sirens, saying that you should put that package down and leave it alone.
Because...

" _This would have been ok except that in the 3 or so years between when the
code was released and I was trying to build it, autotools made some backward-
incompatible changes and autoconf /automake errored out, with no indication of
how to fix those._"

The version of autotools someone was using when they wrote the scripts is very
closely tied to the scripts. It's not at all a good idea to use a different
version of the autotools.

~~~
cdcarter
> _At the risk of having to admit I 've had my share of bad experiences with
> autotools, don't ever do that. That is a big sign with flashing lights and
> sirens, saying that you should put that package down and leave it alone.
> Because..._

And indeed, the exact issue the OP is complaining about is how the zipfile
automatically created by GitHub has NOT had autotools run on it yet, and the
maintainer cannot even manually overwrite that file!

------
greggman
I don't have any giant opens source projects so I guess I don't get bothered
by the +1s and cries for help. Chromium gets those on their non-github issues.
So does Firefox. I'm guessing WebKit does too.

My biggest issue, which I guess is a non-issue for most others?, is I hate
when reviewing a PR that every single line comment generates a message/email.

Maybe it's because I'm used to Rietveld but my normal workflow is to start
reading the patch and adding comments. I might have made 10 separate line
comments before I get to a part of the patch that invalidates all those
comments. Therefore I don't want them sent until I'm ready. I want to be able
to make line comments across all files in the PR and only when I'm ready, send
them as one coherent message.

As it is now, AFAICT, the only way to do this is to write line comments in
some other file on my computer and then later manually find the lines again in
github and add them one at a time. Rietveld also lets you respond to line
comments inline and mark them as "done".

is there anything for github that does the same? Maybe one of their offline
tools?

~~~
bradfitz
I've been working on a bot to copy Github Pull Requests into Gerrit reviews,
using the Google-hosted Gerrit servers.

My bot isn't running publicly yet, but you can see the start of it working at:

[https://github.com/grpc/grpc-go/pull/546](https://github.com/grpc/grpc-
go/pull/546) or [https://github.com/grpc/grpc-
go/pull/545](https://github.com/grpc/grpc-go/pull/545)

(Code is at
[https://github.com/LetsUseGerrit/gerritbot](https://github.com/LetsUseGerrit/gerritbot)
for now, but I don't imagine anybody would use the code themselves... they'd
only interact with it via the Github bot)

~~~
jeblair
Gerrit has an excellent REST API, and because I like working with code in a
terminal, I wrote Gertty -- a terminal based interface to Gerrit. It should
work with the Google hosted servers.

[https://pypi.python.org/pypi/gertty](https://pypi.python.org/pypi/gertty)

~~~
hueving
Gertty is the greatest greatness ever. Doing code reviews on a plane and
syncing up when back online is so cool. Thank you for your work on this.

------
eibrahim
Wow, It took them 29 days to say "we hear you stay tuned"

~~~
drinchev
Some other companies usually don't reply at all. E.g. Apple, Microsoft, etc.

~~~
bhouston
Apple responded to antennagate and other hardware issues pretty quickly
actually. 2 weeks for Antennagate:

[http://www.pcworld.com/article/201297/apples_iphone_4_antenn...](http://www.pcworld.com/article/201297/apples_iphone_4_antenna_gate_timeline.html)

~~~
drinchev
Yep, i guess that was an exception

[https://en.m.wikipedia.org/wiki/Criticism_of_Apple_Inc.#Qual...](https://en.m.wikipedia.org/wiki/Criticism_of_Apple_Inc.#Quality_control_and_customer_service_issues)

------
bhouston
Brutal delay in responding to their most important constituent? What the hell?
This wasn't a minor user's feature request, it was an open letter signed by a
ton of major open source leaders. If I was an investor in GitHub I would fire
the CEO.

~~~
bryanlarsen
That's the problem. GitHub brass thinks their most important constituent is
the people paying thousands of dollars to buy GitHub Enterprise. The only
reason they have the enterprise customers is because they got popular with
open source first. However, at this point their enterprise popularity may be
big enough that success there is self-sustaining -- enterprises make decisions
based more on what other enterprises do rather than on what open source and
small companies do.

That being said, I bet that enterprises are screaming about Issues too.
Enterprise loves their custom fields.

~~~
mietek
_> The only reason they have the enterprise customers is because they got
popular with open source first._

I have absolutely no idea how GitHub could have lost sight of this simple
fact.

~~~
kuschku
Didn't they just replace their complete management?

That'd explain it.

------
Siecje
I wonder if this has more to do with ESLint[1] than the letter.

[1]:[https://github.com/eslint/eslint/issues/5205](https://github.com/eslint/eslint/issues/5205)

~~~
jglovier
Nope. We'd been working on our response ever since Dear GitHub was published.
It just took a little time because we wanted to think long and hard about our
response - beyond just the words we used to respond – and actually consider
how we are interacting with the community, and where we can make demonstrable
improvements. It is just coincidence that the ESLint thread happened this
week, and our response came out today.

~~~
chris_wot
You really should consider _telling_ those who filed the letter that you were
at least working on it. Did you expect them to know?!?

~~~
stronglikedan
Did they who filed the letter ask? If they asked and didn't get a reply to the
effect of "we're working on it", then I can see your point. If they didn't
ask, well then that's on them. I not finding any stories about them asking
about what's going on and not receiving a reply, so I'll assume the latter,
since I'm sure the former would have been posted about.

~~~
chris_wot
Who, precisely, were they meant to ask?

Perhaps you should reread that letter:

 _However, many of us are frustrated. Those of us who run some of the most
popular projects on GitHub feel completely ignored by you. We’ve gone through
the only support channel that you have given us either to receive an empty
response or even no response at all. We have no visibility into what has
happened with our requests, or whether GitHub is working on them._

~~~
nicky0
It's a statement. There's no question there.

~~~
chris_wot
It's a statement that said that they asked them to address some critical
issues via their regular support channel. The statement said they have already
reached out, and they had nowhere else to go so hence the open letter.

Or in other words, to answer the question _I_ was asked (which was "Did they
who filed the letter ask?"), yes, they did ask. Apparently repeatedly.

------
mirashii
Now, if only we could get a movement behind a "merge" button that does fast-
forward only commits.

~~~
scrollaway
Agreed, and here's a git alias I made for the occasion:

    
    
      merge-pr = "!f() { git fetch $1 $2; git branch _FETCH_HEAD FETCH_HEAD && git rebase HEAD _FETCH_HEAD && git checkout master && git merge --ff-only _FETCH_HEAD; git branch -d _FETCH_HEAD; }; f"
    

Syntax: `git merge-pr <remote> <branch>`. You can copypaste url + branch from
github's UI above the merge button.

Note: This merges only to master, no way to specify another merge target. Feel
free to suggest improvements.

~~~
danielsamuels
I have these for merging a PR into develop and master respectively. Usage is
`git pr <#>`

    
    
      pr  = "!f() { git checkout develop && git fetch -fu ${2:-origin} refs/pull/$1/head:pr/$1 && git checkout pr/$1 && git rebase -i origin/develop && git checkout develop && git merge - && git push; }; f"
      prm  = "!f() { git checkout master && git fetch -fu ${2:-origin} refs/pull/$1/head:pr/$1 && git checkout pr/$1 && git rebase -i origin/master && git checkout master && git merge - && git push; }; f"

~~~
scrollaway
I remember trying and failing to get exactly that working. I'll give yours a
shot, thanks!

------
tptacek
From reading the comments on this thread, one could get the impression that HN
Github users would have been happier had Github not responded at all.

~~~
striking
I think some people are miffed that it took them almost a month to just
respond to the letter. Maybe you don't care as much about certain software,
but some people are _really passionate_ about it.

Perhaps HNers would have appreciated some more substantive action by now,
rather than just a response.

~~~
tptacek
I'm confused by what these people are asking for. Should Github acquire a time
machine? If so, instead of asking for an earlier response to this later, maybe
they could just do things differently from the beginning so the letter was
never necessary!

~~~
striking
Being flippant is really unhelpful, and kind of insulting.

People really care about software.

Instead of just responding to us now with a letter that's totally sparse on
details, what if GitHub gave us an idea of what they're actually going to do?
"We're sorry" is really annoying to hear almost a month after the fact.

~~~
cortesoft
Maybe they are still trying to figure out what to do? There isn't an easy
solution to some of these problems, and it is not like they have NOTHING else
to do than solve this issue.

~~~
striking
They could be as transparent as possible and tell us what they have. This
seems like just a stopgap to prevent leakage of the more popular OS repos.

Damage control is not a replacement for answers.

------
devonoel
Github is a large bloated organization that's slow to move, more news at 6.

I don't see how it should shock anyone that its taken Github 29 days to
respond. Github can't move at the speed of say, an open source project with a
hand full of contributors. They're a company of 100s of people. And the larger
an organization is, the harder it gets to make a decision about anything,
because more people have to agree. In this case, they have to agree about how
to respond to open criticism while saving PR face, which is a difficult task.

I'm fairly confident that the stink this whole Dear Github thing has raised
will result in positive changes of some kind, but let's be real, Github is
still just a corporation that faces a lot of the same problems other
corporations face. They're probably scrambling to get a whole bunch of people
to agree on what it is they should do.

------
punnerud
"Issues haven't gotten much attention from GitHub these past few years and
that was a mistake, but we've never stopped thinking about or caring about you
and your communities."

A lot of thinking but no action. Github, what have you been up to these
years??

~~~
oldmanjay
Keeping a gigantic software application running, mainly. The ease of your role
as a bystander and critic in no way reflects the work they have to do to keep
the system up.

------
rafael-rinaldi
I would love to know what the reasonable approach would be ideal from the
people talking bad things about GitHub. If they responded to issues right away
people would complain too.

It's not easy to come up with a solid plan for new features and improvements,
specially in a company this big (that has a lot going on as we all know).
What? You think they're going to get that list of complaints and start
smashing some code? That letter is not even 1 month old. I can kinda
understand the frustration but keep in mind that there's a lot of other things
to handle, it's more complicated than that.

In the meantime if you're really struggling, there are other great options
available out there like BitBucket and GitLab.

~~~
forgottenpass
_I would love to know what the reasonable approach would be ideal from the
people talking bad things about GitHub._

Treat their software development savvy usebase as stakeholders in their
ongoing project rather than unwashed masses consuming a loss leader?

A mutually-agreeable reasonable approach probably doesn't exist. Limited
visibility into the project may be considered exposing too much of the
business for GitHub's tastes. So it will continue to be a one-way
relationship, with all the baggage that comes with a one-way relationship
(incl "talking bad things").

~~~
rafael-rinaldi
Well they used to be open about their future plans on their blog[1]. It hasn't
been even a month after that letter and we _finally_ have a response from
them. It really doesn't seem to be that big of a deal IMO.

[1] [https://github.com/blog](https://github.com/blog)

------
chappi42
Quite nice answer. - Googled for some background and stumbled upon the
following:

[Danilo Campos, has been known to tweet similarly strong views about
diversity. Campos joined in August]: "don't think we'll succeed teaching
white, male middle managers empathie and compassion anytime soon so let's
limit their scope of damage"

Such a rubbish. I think GitHub has their priorities / focus wrong. - Glad I'm
using Gitlab.

~~~
robalfonso
A couple of thoughts come up, I'm not a white guy and I'm offended by that
guys statement, its prejudiced and I'd be embarrassed if that came out of my
mouth.

Second if a company is going to trade on being a meritocracy, then be a
meritocracy. Why have a diversity council, why be concerned over a bunch of
"white guys" and what they can't learn. If they are the best at what they do
and if github considers good management traits include compassion and empathy,
then whats it matter what color they are the best people would rise up
regardless.

This is just prejudice plain and simple.

~~~
hga
_Second if a company is going to trade on being a meritocracy...._

They haven't for some time:
[https://www.google.com/search?q=github+meritocracy+rug](https://www.google.com/search?q=github+meritocracy+rug)

~~~
kuschku
What GitHub did is the worst possible response.

We women get worse education, so the solution is to lower hiring standards for
us?

Seriously?

Lobby for better women education, sponsor groups and events engaging in that,
but don't hire less qualified people just for their genitals or their skin
color.

~~~
hga
Except that, in all but the most intangible possible metrics, at least in the
US women _officially_ get better educations, as measured by graduation rates,
grades, and sanctions including most especially medical interventions (for
ADD), for both K-12 and college. And in the former most of their teachers are
women.

~~~
kuschku
Well, that makes it even more ridiculous.

But even if women get worse education, the answer can’t be to reduce hiring
standards.

------
progx
Thank you GitHub, to know that you need 29 days to reply, let my OpenSource
GitHub Project look not soooo bad. :-)

~~~
r3bl
It took GitHub's support exactly 82 days to respond to my issue[1]. In the
end, I literally had to ask a GitHub employee on his AMA to look up what the
hell is going on.

[1] [https://blog.r3bl.me/en/worst-support-experience-
ever/](https://blog.r3bl.me/en/worst-support-experience-ever/)

------
lhnz
If they take 29 days to respond to this, I wonder how long they might take to
respond to the fairly shocking allegations within the recent Business Insider
article [0]?

In fact I wonder if this response was ever going to happen on its own? Perhaps
the cause of the response was their recent string of bad press - dear github,
business insider, eslint, etc.

It strikes me as strange that a company that has so many people focused on
community and social impact doesn't have time to talk to its users.

I hope they manage to sort themselves out as it's getting embarrassing.

[0]
[https://news.ycombinator.com/item?id=11049067](https://news.ycombinator.com/item?id=11049067)

~~~
the_mitsuhiko
Why do they have to respond at all to that article? I fail to see how that
article is relevant for anyone who has projects on GitHub.

~~~
lhnz
They're not being forced into responding.

But it was unsettling to hear an anonymous source say they were avoiding
interviews on racial grounds. That sounds illegal if it's true - and even if
it's not true, surely it's something you should be open about? People care
about fairness.

------
VeejayRampay
Reading the reactions to their addressing the complaints, I really don't envy
the folks at Github. A lot of folks in the "Yeah that's nice but what about
X/Y/Z" range (and same here on HN).

There's simply no winning.

~~~
ohitsdom
It'd be a little easier to identify key requests if they implemented voting to
solve the "+1" comments, as identified in the "Dear Github" letter.

------
tacos
I wish more companies would take more time to respond to these sorts of
situations. Perhaps this was excessive (I see conflicting reports of where
they responded and when). But...

Let things cool off, take a hard look at things internally, get the
stakeholders committed to actual change, _then_ provide an update. I'm far
more likely to believe that then even a perfectly executed PR play. I've
watched even the most pathological and idiotic tech people get good at those
the past 10 years. Beware people with good haircuts who say nothing and only
appear during times of trouble.

~~~
sangnoir
> Let things cool off, take a hard look at things internally, get the
> stakeholders committed to actual change, then provide an update.

This is _not_ an update - this is "we're looking into it", which should
precede the internal soul-searching and actual change. They should have
released this the moment they decided they were going to look into it - to
outsiders, that moment seemed to be 29 days after the open letter was
published.

------
miseg
That's a great question on the page by EGreg:

> I wonder if GitHub itself can use its own issues system for prioritizing
> feature requests and bugs :-)

------
elliotpage
I just hope they also add new features centering around depreciation of repos
and the ability to add a "THIS IS NO LONGER BEING MAINTAINED" flag or an
equivalent.

Finding a repo that appears to solve my problems only to find a mass of issues
and an absent maintainer is a pretty big time sink, for both me and likely the
maintainer too!

~~~
Blahah
It's pretty easy right now to just change the header of the README, and/or the
project description to indicate deprecation. What added benefit would making
it a feature provide?

~~~
RichieAHB
It requires the maintainer to do this. Often if the maintainer isn't
maintaining the codebase then they won't be updating the readme either.

~~~
Karunamon
Wouldn't it be up to the maintainer to toggle the "no longer maintained" flag?

Sometimes a project that hasn't seen commits in a long time isn't orphaned,
but just doesn't need changes...

------
ageofwant
Great, but please resist the urge and goading to build another JIRA in github.
The second best thing about github is its simplicity.

~~~
joshrowley
In an ideal world, the Issues team would develop and support a plugin
ecosystem for the tracker. Users can customize and add the features they see
fit and even create their own custom plugins. Allows flexibility and power for
those who want it while keeping the core simple and clean

~~~
tomschlick
This is the best idea.

While some features like +1s and contributing guidelines should be baked in,
other features like extra fields, requiring people to sign a disclosure, etc
would be best left to plugins that can hook into issues much like CI services
hook into pull requests.

------
camhenlin
Has anyone else made the decision to switch due to github's internal racism
and sexism rather than technical reasons? That's my biggest reason for looking
at alternatives lately (although I haven't made the move yet, but plan to as
soon as I have some spare time)

~~~
Revisor
We haven't switched an existing project, but we're looking around for a place
for a new library we're going to publish in a few weeks. It will most probably
be on Assembla or Gitlab.

------
redsymbol
To any githubbers reading this:

A lot of people posting here are being unreasonable, demanding, and childish.
Recognize that for what it is, don't let it affect you, and just continue
moving forward based on the constructive part of the feedback.

~~~
hueving
Yes, continue to ignore feedback from the community and enjoy your market lead
because once you have that users will never leave for another product.

------
enknamel
This is rather a nonresponse. It basically says GitHub read the letter. It
makes no promises, proposes no solutions and no timeline. After working in
gaming for years we would post responses just like this all the time and get
something scheduled 6 months to a year out knowing that just responding with
general affirmations would placate customers without having to do actually fix
anything.

------
sotojuan
I'll be more optimistic and be happy they replied and very interested in what
they have in store. They say "next week" and it's Friday so it won't take that
long.

------
shadowmint
Can't wait to see what actually _tangible_ outcome this will have.

I think that's far more interesting than that they took 29 days to respond;
ok, they did. Deal with it. They have responded now.

What's important is what happens next.

A public issue tracker?

A rust style RFC process? ([https://github.com/rust-
lang/rfcs](https://github.com/rust-lang/rfcs))

Just please, whatever you do, do it fast, and stop people from doing what
babel did and migrating to phabricator. :P

------
erikb
Businesses are ridiculously slow. What I can tell you about a business that is
a blackbox to you which will surprise you: It's a blackbox to them as well.
They just don't know how to manage so many people and ideas. And the sad part
is most managers don't. So I don't think it will change. The solution would be
to educate the manager about how to find out what's not working and how to
resolve such problems, or switch the manager with one that is willing to
constantly work on getting things to work instead of just keeping the head
above the water. It's a really hard problem though, since as an employee you
don't gain much by resolving true systematic problems, and you even may lose
some value with your coworkers by changing their daily processes that they are
used to so well. It's really something that must come from the top, but if
there is nobody to do that then it won't happen.

------
avitzurel
I think a lot of the disappointed comments are understandable here. (obnoxious
or not).

I know I personally expected one of either to happen

1\. Github responds in 2-3 days with the EXACT response they made.

2\. Github responds in 1-2 weeks with a concrete plans that addresses at least
some of the concerns the original letter addressed.

They basically did the bad combination of both.

One of the things that frustrates me the most about companies responding to
feedback is "We have it planned" and "we don't have an exact timeline".

More than anything I really dislike the "stay tuned". I don't want to stay
tuned, you should either tell me when to expect it or I will tune out (and I
think that's what most people think).

To me, this is a non-response.

I like Github, I use it every day. I don't have any plans to move away from
Github. If I had a project that I felt wasn't fit for Github, this response
would not change anything for me, I would still likely research for
alternatives.

------
nv-vn
Ironic that most of the replies were '+1's

------
quadrangle
Right, this is typical for proprietary software. Everyone has to beg and
petition and then if a company isn't _awful_ , they'll respond and do
something. Meanwhile, you still can't adapt things to your needs or submit
pull requests or otherwise do what you could with free/libre/open tools. And
if GitHub does a good job addressing these requests, it will encourage
everyone to stay with GitHub… where we're still helpless serfs.

If we all demand software freedom, then we won't be so helpless in the future
with whatever issues come up.

------
chris_wot
That took a long _long_ time for them to respond. It's day 29 now. In fact,
they could have communicated something after even a week - probably something
similar to what they have actually written, only more 'We're looking at your
list and we'll try to get back to you as soon as possible'.

Where is Jono Bacon in all of this?

 _edit:_ OK, I feel kind of bad for mentioning Jono because I've watched him
do awesome things over the years. I've sent him an email out of the blue
asking him to respond - hopefully he gets it.

~~~
joshmanders
I agree with you, and when Jono made his post on the original Hacker News
thread, I immediately followed him on twitter and even CC'd him on tweets that
had people talking about things hoping that he'd respond to them, at least
post a public post outside of the HN thread saying that they're working on
things... But he was more worried about promoting the community leadership
summit.

Kind of sad honestly. Not very good community leadership by ignoring your own
community to promote a community leadership conference.

~~~
chris_wot
To be fair, he was flying into linux.conf.au all the way in Geelong - that's a
_long_ flight. It could well have been that he's recovering - I notice that
his last blog post was February 1st.

And of course I'm kicking myself that I missed the conference entirely. Sigh.
Next year I guess.

~~~
jonobacon
You are not kidding about the long flight. I wish someone could move Australia
a little closer to California. :-)

Hope to see you at linux.conf.au next year, chris_wot! :-)

~~~
chris_wot
Thanks Jono :-)

------
jcoffland
Next we need to figure out how to light this same fire under Docker. In
someways they're even worse. They often close issues because they won't be
addressed in the next release. I've tried to explain that this is exactly the
case where you want to leave an issue open. They said they would think about
that but still leave issues they don't want to work on right now closed.

------
lutorm
The fact that this discussion is being made by committing to a README.md file
seems to point to a serious lack of tools for interaction...

------
dreamdu5t
Remember it took _years_ just to get them to properly display code that uses
tabs (and we still didn't get a simple ui setting).

------
alexandrerond
Oh wow, that's all they have to say after weeks? Funny enough Gitlab responded
in hours. Opportunistic or not, that is why people are taking it seriously.

------
trengrj
Not sure why they did this on a Friday. I know the standard PR playbook says
to release bad news on Friday but I wouldn't call a response to this bad news.

------
aledalgrande
Well, even if quality is declining I wouldn't know where else to go for now.
Gerrit doesn't cut it and neither does Bitbucket. Guess we will see.

------
Etheryte
What's the point of "we're going to reply next week" post on a Friday? Just
make a statement next week.

------
ptio
GitHub should consider "open sourcing" GitHub itself so the community can
submit PRs and RFPs.

~~~
BinaryIdiot
But if they did that it might hurt their enterprise, non-SaaS, offering
considering people could then install it on their own.

~~~
ptio
True, but that's GitLab's business strategy anyway.

------
shade23
this would be a better link : [https://github.com/bkeepers/dear-
github](https://github.com/bkeepers/dear-github)

------
barely_stubbell
What I want, more than anything, is to search on commit hashes.

------
smoyer
Since they only offered a "receipt" for the original letter, why did it take
two months? They could have put this response out the same day the "Dear
GitHub" letter was posted.

------
donretag
So tempted to add a +1 comment...

(This is a joke, please do not do it)

------
programminggeek
TLDR; We've been busy making piles of money in Enterprise land and forgot that
we acquire customers via FOSS. Oops.

------
gerbilly
And the first response to their letter was a:

:+1:

------
SFjulie1
I complain every day more about how we organize our works and need the
insanely complex git to collaborate because we have insane ways of producing
code.

An industry that requires increased insane level of complexity for simple task
to "progress" amaze me at failing to get the problem is not in the tools.

I can guarantee that for 10 weeks work with "old" technologies (python +
whatever static HTML server) I can make a one size fits all website for all
restaurant that can be customized without security holes. Make it in a free
license so that people make money with my second creation ... on purpose. And
we would all win. All the economy from having something simple and well
thought.

But I can't do it. I am not an influent trend maker so no one will bet a kopek
on my business.

And you know, these tools cognitive load on the brain, is a load that should
be spent on business problems, where cost efficiency matters.

Where operational expenses are better kept low whatever the initial investment
is.

The fact we all use at least git (+ a ticket tracker) that are heavyweight,
should tell us that we are dangerously inflating the cost of building
software. Hence, contradicting our very primary reason to be : which is to
diminish operational expenses the most we can.

And we still have not proven anything about how much money this increased
expenses due to complexity finally create value anywhere... In decreased
price, decreased incidents, higher quality, better jobs, better economical
growth ... saved lives...business values true SLA (and not the one measured by
the editors/operators)...

So, well, github may not be the problem.

