I wrote Issues, so I've likely thought through these problems more than anyone else.<p>I really disagree with the general sentiment of this post, and very much agree with the original "Dear GitHub" letter. The product needs a lot of work, and that I couldn't address these problems while I was there really, deeply depresses me.<p>Issues hasn't been touched since I shipped the third large iteration a year and a half ago. It was never intended to be a finished product at that point; it was intended to evolve quite a bit from that initial vision. There's a lot of pain that open source developers <i>and</i> private source developers face today, and I really hope we all can start seeing that pain in our community eased soon.
If the product people at GitHub don't understand the sales/marketing impact that GitHub's free offerings have on its paid offerings, then they need to hire new product people.<p>I think it's plausible that the authors of the "Dear GitHub" open letter already realized the truth of Julian's response, which is why they posed their request in the way that they did.<p>This gives GitHub three choices. They can react positively, remain passive, or react negatively. If they react negatively, they have the risk of a PR shit-storm, which will negatively impact new customer acquisition. If they remain passive, they risk the chance that the attention to this campaign will grow and their reputation will decline. This will negatively impact new customer acquisition.<p>However, if they react positively, they show good will toward consumers of their free offering, and they show would-be paying customers their willingness to improve their services. This will positively impact new customer acquisition.<p>Were this request not made in the open, GitHub would not need worry about any of these outcomes, and would therefore not be forced to react.
This is sadly exactly what I'd expect a senseless product person to say. Obviously the reason Github is Github today is because of the OSS offerings. These OSS developers then go and set up teams of their own which bring their projects and business back to Github.<p>If people get together and write up an open letter for you to fix things, you really should take it as a warning sign as the same people could easily get frustrated and move elsewhere or someone else could come along and offer a better product. It would honestly take only a handful of high profile developers to cause a mass migration.
As someone who is:<p>* OSS user (and signee of the Dear Github letter)<p>* paid user<p>* user of an enterprise installation of Github<p>I can honestly say the problems I see in OSS land, are the same shape as those in paid, and the enterprise installation.
The difference is, due to the volume of usage the enterprise installation suffers from these same issues even more.<p>Now, we may not see +1 DOS often (on the enterprise side of this), largely because its seen as bad manners and/or the goals are already shared via some other disjoint medium. But this doesn't mean the issue isn't present.<p>Being able to enforce additional semantics (such as priority/interest, reviewers, blocked by etc.) would be a big win
It's stuff like this that gives me a bad taste in my mouth when I think about Chef.<p>Whenever I've interacted with people from Chef-the-company, I've always gotten the impression that they believe they're talking to me because (at best) they want to save me from my misbegotten ways and join the Chef Way. At worst, I've gotten the impression that they think I'm a terrible person and/or worthless for not just getting with the program and bowing to their wisdom.<p>I know from other experiences that the Chef community in general is not like that. But Chef itself has never imparted a good experience on me.<p>It doesn't help that I wholeheartedly agree with the Dear GitHub letter, and get a very bad vibe from this "Dear 'Dear GitHub'" letter.
The author jokes at projects leaving GitHub for BitbBucket.<p>I would have actually recommended GitLab! It has all the features of GitHub and more, and is actually open source (<a href="https://gitlab.com/gitlab-org/gitlab-ce/" rel="nofollow">https://gitlab.com/gitlab-org/gitlab-ce/</a>)
I'd love to agree with the author, I really would... but GitHub put quite a bit of engineering talent and resources behind Atom (and Electron), and last I checked, that hasn't made them a single dollar. It's very clear the company does not simply prioritize resources based on immediate return. If they did, we surely wouldn't have the text editor that I've been addicted to for the past year.
I don't entirely agree. As someone who works in a mid-to-large company, and who has worked in a 50,000 person company (admittedly for both companies not all employees were engineers), I feel it's worth noting that as companies get larger and teams more diverse, they tend to require the exact features open source projects need.<p>A product manager in team X who noticed a bug in product Y is not going to know what fields are necessary for that product, and as issues make their way to company-wide mailing-lists (or are linked from internal meme websites -- you know who you are), they may accumulate +1-spam if no voting system is put in place. As such, I believe GitHub's ability to move upmarket and satisfy its larger customers is actually aligned with implementing the features requested in the "Dear Github" letter.
What an incredibly passive aggressive, rude, thinly veiled 'fuck you' of a blog post. Does this guy actually work for GitHub?<p>I am sufficiently offended by the tenor of this post to consider taking my private repos off GitHub and move them to BitBucket. And, given that my employer already uses JIRA for issue tracking, I'll probably suggest we consider moving our organization's repos over to BitBucket while we're at it, too.<p>Edit: Julian doesn't work for GitHub. He works for Chef: <a href="https://github.com/juliandunn" rel="nofollow">https://github.com/juliandunn</a>, and his blog post is incredibly poorly worded. Fwiw, if this is what Chef's product people are like, I will never consider working there.
A few issues here. Filtering feature requests to "whatever makes money" seems to be overly reductionist and a bit cynical, especially given a company like GitHub which is relatively open and has a flexible policy as to what is being worked on. Sibling commenters bring up examples like Atom and Electron that GitHub pours salary money into but don't make money off of.<p>Also, it assumes that the requests don't matter for paying users – on the contrary, the features listed in the original article could be useful features that could make more projects, including paid projects, use GitHub Issues, which could in turn make more people pay for GitHub. I know that the first request, metadata for issues, would have been <i>incredibly</i> useful for when my team was using GitHub Issues.<p>Finally, the lack of features that open-source authors consider important is a pretty big deal. This article asks, where are the projects going to go if GitHub doesn't implement these features? Well, it's far from inconceivable that they'd switch to another place that had better features and supported open-source projects more fully, taking away steam from what originally pushed GitHub to be so popular and become the juggernaut in public and private source code hosting – open-source projects.<p>Remember Google Code and SourceForge?
When those developers working on open source start using a new product from a different company, then go to their own place of work and ask to use that produce instead of github it will impact their paid customers.<p>How do you think they got those paid customers in the first place? They came from the free tier. If the free tier isn't nice to use, why would you pay for it?
Surprised that a product person without data would go on record saying that an issue big enough to warrant a co-signed open letter isn't important enough for Github to address. The best product people I've worked with start by getting as much information as possible first before making decisions.
Somehow this "Product Guy" misses the fact that popular OSS devs that evangelize your product are also "Paying Customers" - they help you Grow & spread in a fashion that is next to impossible by buying advertising.<p>Please stop spreading the FUD that they adon't count
> You’re unlikely to see +1-DDoS-type behavior inside private repos, for example.<p>Maybe not, but the lack of an "Approval" system is keeping us from moving from Bitbucket to Github. The proposed fix for +1 spamming could easily serve as an approval system for us.<p>(Bitbucket, I might add, has also become incredibly stagnant, as can be seen by this long standing issue to support Markdown[0])<p>[0]: <a href="https://bitbucket.org/site/master/issues/6930/support-some-or-all-html-in-markdown-bb" rel="nofollow">https://bitbucket.org/site/master/issues/6930/support-some-o...</a>
The "thing" is... my code sits in git at the end of the day. That is portability like no other. Can I migrate issues? Sure![1] What[2] language do you prefer to work with?<p>The real "thing" is, my git repos do not care where they are hosted. All I need to change is my origin.<p>[1] <a href="https://github.com/sorich87/github-to-bitbucket-issues-migration" rel="nofollow">https://github.com/sorich87/github-to-bitbucket-issues-migra...</a><p>[2] <a href="https://github.com/jeffwidman/bitbucket-issue-migration" rel="nofollow">https://github.com/jeffwidman/bitbucket-issue-migration</a>
Dear "Dear 'Dear Github'",<p>I found your letter to be patronizing and facile. Saying "I could explain X but it should be obvious" is a good indication that your snarky post is lacking substance.
With the growing prevalence of things like GitLab, GoGs, and GitBucket I think that GitHub has to thing very long and hard before they make any official statements like this. All someone would need to do is make a central list where you could post a link to your git server and list what projects are on there to make it searchable. I that is done, I see no reason why anyone, with the needed hardware, would stick to github.<p>I think we are seeing the "end of days" for this open source power house.
Those authors presumably work at places that pay GitHub non-zero sums of money. For instance, many of them are Googlers and Facebookers. I have no idea how many private repos those orgs have, but I have a feeling large companies with a significant open-source footprint (like the ones represented on that list) tend to buy the biggest plans GitHub sells.
I'm currently working in a start up that's using a paid Github organisation. The mentioned issues are a pain for us, even though we are currently only 6 people working on the code. Because of this shortcomings we will migrate somewhere else if we grew larger. So I would say this affects the business side of Github.
Open source surely benefits the majority of GitHub’s paying customers. So the way I see it, if this improves how open source projects are run, that will result in better libraries and tools for GitHub’s paying customers.