Published

Dear “Dear GitHub”, From Your Local Friendly Product Person

Dear “Dear GitHub”,

Thanks for your recent open letter about GitHub’s shortcomings. As an occasional contributor to Chef, a large open source project itself , I completely empathize with your position. It totally sucks, for example, when an issue is DoSsed with a wall of unhelpful +1’s, especially by people who think open source creates a contractual obligation of free support and instantaneous bug fixes. I also agree that it sucks that GitHub hasn’t provided you with timely responses about your feedback, even if it’s to tell you “no”.

However, as a product person working for Chef Software, Inc., the company backing the aforementioned open source project, I feel obligated to inform you that, if I were the product manager for GitHub, the answer to your requests would probably be “no”. That’s not because I think your feature requests aren’t legitimate. It’s because they don’t impact paying customers very highly. And as a company whose developers have to eat, GitHub is probably going to prioritize those customers first. Sorry!

I could delve into a detailed analysis of why each feature you’ve asked for doesn’t matter much to GitHub’s paying customer base, but I think it’s pretty obvious. Paying customers use private repositories and/or GitHub Enterprise, and the wild[er]-west aspects of an open-source ecosystem simply don’t exist inside a company. You’re unlikely to see +1-DDoS-type behavior inside private repos, for example.

Don’t get me wrong. GitHub’s success has been built upon its popularity as a platform for open-source collaboration, and part of creating a commercial business upon an open-source foundation involves maintaining a fine balance between paying customers and open-source users. We have the same challenges at Chef. We’re a bit luckier, actually: we’re not trying to directly monetize our product, so we can afford to make the source code available to both our client and server so that anyone can contribute to it. But GitHub’s trying to sell the code behind the site as GitHub Enterprise, so that’s not a viable option for them.

In summary, I think you’re right to highlight GitHub’s lack of response to your feature requests. That’s just not nice. However, I don’t think they’re going to prioritize your actual requests highly. After all, what options do you have? Move Selenium, ember.js, and every other project the open letter signatories work on to BitBucket? Just the fact that you posted your missive to GitHub itself shows how attached you are to the platform. The only reason GitHub will work on your requests is if the media attention over your open letter gets too hot.

Well, I guess maybe your open letter isn’t such a bad idea after all. Carry on?

Hrm. I’m a product guy too, and I think your angle on this misses something important about freemium businesses. In any freemium business, the users who evangelize your product are actually more valuable (or at least equally valuable) than the people who pay. The reason is simple: growth is everything. Freemium businesses convert a % of their users to paid, and it isn’t hard to get people to pay if you have a great product. So the biggest question is really, how many total users do you have and what’s your growth rate. Popular open source libraries adopting GitHub has been the primary driver of its ubiquitousness for private repos, I believe, and thus their popular open source maintainers are one of their most important audiences.

I’m not going to comment on the issues raised by Dear Github, nor Julian’s reply. But I will say that looking at that signer list from the perspective of someone who runs tech events, I am very impressed by thenameslist gathered and would love to see a conference with all those maintainers speaking or on a panel!! Damn!! Who’s with me?

You seem to be conflating prioritizing paying customers *first* with prioritizing them *exclusively*.

Github has time for aesthetic / usability tweaks that have at best a marginal impact for any of their customers — it’s not unreasonable to expect that at least *some* effort be devoted to cultivating the very thing that makes their commercial effort viable.

Frankly, if that’s the attitude you approach such a division of concerns with, it makes me considerably more nervous about betting on Chef in the future.

Also, like I said, Chef doesn’t have the same challenges GitHub does. The code for the base offering is completely open-source, and it’s governed by a board at arms-length from the company. We also fund a small team of developers to work solely on open-source issues that aren’t related to making money.

Hi, Julian, I understand your point, but a voting system even in a company should be very useful. Example, a number of different customers opening tickets about the same bug/feature, these tickets are automatically integrate with the voting system.

Anyways, the most people who signed the letter one way or another are in fact paying customers.

I wonder, am I the only one bugged by the page layout change where both navigation areas are one above the other? I can sometimes click on project navigation instead of pull request navigation and that’s annoying (and takes cycles to avoid).

In the past having project navigation on the right was much better IMO. But given I’m on the paying side and the issue is ignored, I assume most people don’t care or even prefer the change.