I wrote Issues, so I've likely thought through these problems more than anyone else.
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.
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 and private source developers face today, and I really hope we all can start seeing that pain in our community eased soon.
This is no knock on you, since you aren't there to develop the Issues platform anymore. But I don't know how much private repo developers are hurt by the points made about Issues because they probably don't use it.
I mean, Issues is not really a full-featured issue tracker. It could have been, and maybe would have become one when you were still there, but right now, it's not. And if you do need something more, and you have some resources within the organization, you're not going to stew over Issues...you're just going to use something else. Jira...Pivotal...whatever.
I'm sure GitHub doesn't feel that Issues is where they make their money. And/or that developing Issues further either won't make them anymore money, or not enough to matter. People don't choose to use GitHub for its issue tracker, and even if they had a great one, people still probably wouldn't choose to use GitHub because of it. And so Issues languishes in its current state.
But Julian Dunn has a point to make--maybe this press burns enough for GitHub make changes after all.
In a lot of ways, GitHub Issues is to Issue Trackers what Google Reader was to RSS Readers.
It's good enough and "cheap/free/low-friction" enough to use once you are using GitHub, that for a smaller organization, it's a total no-brainer.
But as your team grows, as your org grows, you really start to hit the weak points very quickly.
The benign neglect that GitHub shows Issues is, as a paying customer, incredibly frustrating. It's also a real head scratcher, considering how much they are leaving on the table in terms of opportunities to create additional revenue.
Personally, I'd love to see GitHub add a KV-store type feature to Issues (so you can associate arbitrary meta-data with issues) and then an "app store" for "plugins" or "extensions" that different companies can provide and customers can pay for as part of their GH subscription (a la ZenHub).
If Issues hasn't been touched for over a year and a half, what exactly are the priorities at GitHub? Has GitHub reached a point where they no longer care about free users as they've served their purpose of creating a network effect that is now driving in enterprise customers?
Agreed. You should never, ever publicly confront a set of publicly notable and popular customers to tell them what they are asking for is wrong because the company you are trying to defend doesn't need to do those things for their paying customers.
I love GitHub and use it everyday. But I have a feeling this post with result in a talk with the "product guy" to tell him how this attempt at "putting customers in their place" backfired, even if he doesn't work for GitHub.
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.
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.
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.
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.
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.
Github's life blood is not just the enterprise side, but its free offering, the community and the huge network effect it has over the open source community.
No one is sticking with Github because it has particularly good UI or functionality. Github raw functionality is completely undifferentiable from its competitors such as gitlab and bitbucket. People stay on github because of the number of developers who uses it, star counts, fork counts and reputation system it has built over time.
You can't search the code inside a repository, and the back and forward buttons on the browser don't even work correctly. Can't view a single file history either and it is probably missing a lot more.
And this fact is why Github can't afford not to prioritize "Dear Github." If there's one thing we've learned from social media, it's that network effect makes you strong as an incumbent, but it doesn't make you immortal. All it takes is one upstart that just feels "perfect" in terms of UX to cut into your bottom line. (Though I suppose you can acquire them...)
Furthermore, I work for a company that both pays for closed source repos and uses open source ones heavily. There are a large # of hybrid OSS/paid companies out there these days. The original author sounds like a pretty out of touch PM if you ask me.
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.
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.
This. Github's enterprise base is at least partially a subset of their open source population. If Github doesn't keep OSS momentum for their product, they lose the perceived "default client" status to git repositories. OSS and eventually enterprise starts looking elsewhere.
This is getting more and more relvent since solid competition is starting to crop up everywhere. Gitlab, Bitbucket, GOGs, Gitolite, Gerrit. Not apples to apples of course, but Enterprise has a lot of decisions when it comes to git control.
Even the things that could be considered Github "lockins" aren't really so: Google's git-appraise[0] could make pull-requests portable, Github's wikis are portable by their very nature[1], software like git-issues[2] could make issues portable. Not in the immediate, but decentralize-everything is a rising sentiment.
The only real lockins I see are Github's work-flow and social community. If either become toxic, developers will start to look elsewhere. Like Microsoft, I'm sure Github can ride the majority-player wave for years before it starts really hurting them, but simply saying a community-centric company only has to look out for their paying community's interests is short-sighted.
Why was SourceForge generally abandoned? Because it stopped caring for open source developers, for example by not hosting git repositories.
If Github appears to go down the same road, paying accounts will leave along with open source projects; they are managed by the same people, with the same concerns for quality and corporate attitude.
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.
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.
Being able to enforce additional semantics (such as priority/interest, reviewers, blocked by etc.) would be a big win
No one is saying that the issue does not exist. However,th author is suggesting that since it hardly impacts paying customers, it is going to get low priority.
It's stuff like this that gives me a bad taste in my mouth when I think about Chef.
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.
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.
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.
Bitbucket actually does many things better than GitHub. The pull requests, for example, are better in many small ways.
That said it's also buggy as hell, and Atlassian still haven't bothered to support git mv properly, so GitLab is something I plan to look into when I get time.
I've deployed a Gogs installation at home and am very happy with it. It's not Github, but it's great for my needs, and I can create accounts for friends to use privately, which is fantastic. I've tried GitLab and it is also very good.
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.
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?
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.
Edit: Julian doesn't work for GitHub. He works for Chef: https://github.com/juliandunn, 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.
Agreed. He works for Chef.io though, so those who are concerned about his response should consider what relies on Chef, not GitHub. There are many open source CI platforms available so it shouldn't be difficult.
Even if he did work for GH, they haven't published an initial response, so your actions would be spontaneous.
I noted this in the edit to my post that I posted just before your comment was written (you were probably writing this when I posted my change). Given the sort of 'distributed' nature, and low managerial overhead of GitHub, this could well be considered a "they" post were it from a GitHub employee.
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.
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 incredibly useful for when my team was using GitHub Issues.
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.
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.
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?
>>If the free tier isn't nice to use, why would you pay for it?
The free tier is good enough, and has been good enough, to use long enough for users to convince their orgs to move to the non-free tiers. Mission accomplished for GitHub.
Julian's point still stands: paying customers with complaints and suggested improvements have the best hope of influencing improvements.
Fortunately GitHub now has competition in the free offerings. It's no longer a question of being good enough. If GitLab is better, and OSS projects start moving to GitLab in large numbers, those OSS developers will start asking their employers to pay for GitLab instead of GitHub when they need the paid offerings.
GitHub not improving the free offerings while competitors do will affect their income.
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.
Please stop spreading the FUD that they adon't count
> You’re unlikely to see +1-DDoS-type behavior inside private repos, for example.
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.
(Bitbucket, I might add, has also become incredibly stagnant, as can be seen by this long standing issue to support Markdown[0])
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?
The real "thing" is, my git repos do not care where they are hosted. All I need to change is my origin.
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.
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.
Why? At the time of this comment (and -according to the timestamp-, the time of your comment), the title was 'Dear "Dear Github"', and the ___domain that hosted the article was listed as juliandunn.net.
I... can't imagine that any reasonable person would draw from these two facts that this was a GitHub employee writing in any official capacity.
> There is at least one thread where there's already been confusion around it.
It's impossible to prevent everyone from getting confused. What's more, it appears that purple_haze's confusion didn't materially alter what they had to say.
> At first, I thought this would be from someone who worked at GitHub, because I didn't understand why else it got upvoted.
I guess it got upvoted because people liked what it said and/or thought it contributed to the ongoing discussion here on HN. We're generally not too terribly authoritarian and/or credentialist around here.
I don't see much difference between a comment on Reddit/HN and a response article, except that the response article is platform-agnostic and (sometimes) more thoughtfully assembled.
because its practically a long comment on the original. If it has to be platform agnostic with formatting, then that is why comments are allowed to have links to other sites.
Otherwise we really should all start writing response articles and post those instead of comments, because there are only positives yeah? 70 comments for this post alone, all articles so people can use their own variant of formatting languages or whatever
Yes, a business focused on the things that make it money. Thats the purpose and the OP is not wrong on that. What he is missing is the immense power the open source community as whole has. They can boycott github and turn it into a ghost town in a manner of months. Github will then lose part of the appeal it sells to enterprise customers.
> They can boycott github and turn it into a ghost town in a manner of months.
The last paragraph in the OP rhetorically mocks that idea. Boycotting GitHub would negatively impact said projects since there is no competitior as robust, which is a worse outcome.
Indeed. Though it would not take that much convincing to have those people turn gitlab into what they want and host it themselves with a container based image. Plus they could simulate the social aspect of github by using a general index of projects.
Stars can also be ported over. You could even go one step further and create star similar to reddit's "gold". A "gold" star would contribute to the development of the project.
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.
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 and private source developers face today, and I really hope we all can start seeing that pain in our community eased soon.