Hacker News Reader

Comment by holman | Hacker News Reader

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.

View on HN

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).

Yeah. We use GitHub private repos here at work, and honestly a lot of the requests in "Dear Github" apply for us, too.

I work for Chef (where Julian works) and all of the requests in "Dear GitHub" certainly apply for getting my job done as well.

> and that I couldn't address these problems while I was there really, deeply depresses me.

I think you should let it go, and be proud that your beta quality is another mans release quality.

I agree -- numerous people working on .NET at Microsoft have mentioned that they wish issues could support more things.

Why did you decide to leave github (if you don't mind sharing)?

awkward

http://zachholman.com/posts/fired/

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.

What a PR disaster.

You know the author of the article wasn't a product person from Github right? They work at Chef.

Correction made, thanks.

Julian Dunn does not work for Github.

Reply on news.ycombinator.com