Live data from Hacker News

Why GitHub’s pricing model stinks (for us)

lostechies.com

41–50 of 90 posts

Re: Why GitHub’s pricing model stinks (for us)

#41
post #14

I agree and I wish I'd written this article myself. One of the great things about git compared to the version control systems of yesteryear is that it's lightweight enough and (with Github) discoverable enough to make many small repos a viable development pattern. I never liked the old giant-repo-for-all-the-code system, although I understand it's still popular at Google and many other large shops. I think what reall…

Lots of assumptions there. The largest cost of operating GitHub is certainly not storage, but the whole server infrastructure and employees. That's what you're paying for.

Otherwise, just put your repos in any online storage service, it's much cheaper, but then you don't get Github :)

edit: downvotes? care to explain?

Re: Why GitHub’s pricing model stinks (for us)

#42
post #37
post #14

I agree and I wish I'd written this article myself. One of the great things about git compared to the version control systems of yesteryear is that it's lightweight enough and (with Github) discoverable enough to make many small repos a viable development pattern. I never liked the old giant-repo-for-all-the-code system, although I understand it's still popular at Google and many other large shops. I think what reall…

This is precisely the reason why we switched from github to unfuddle. Why should my developers start rationing for repos and start putting everything in one large repository, just so that we don't hit the limit with github. For example, we use node.js heavily, and I would like create npm modules that can be shared across repos, and put them in a repo of their own (so npm can install them). Github's pricing forces me…

[deleted]

Re: Why GitHub’s pricing model stinks (for us)

#43
post #22
post #2

Github does have per seat pricing (for their enterprise product, which is meant to be hosted locally): https://enterprise.github.com/pricing - it costs $21/seat/month. With their per repo pricing I'd imagine they are more likely to earn more revenue per user, since so many developers will end up having many old pet projects in private repos sitting there.

The Github enterprise version is unrealistically expensive. We (a dutch 'embedded' software company of about 300 developers) currently use SVN for our version control. We use some tool, of which I forgot the name, to simplify managing repositories and permissions. This costs us a couple of hours per year in maintenance and support, and the tool cost somewhere around 1500 euro. Hours go for around 80 euro's here, so l…

When I learned about GitHub Enterprise I was very happy thinking that we can finally switch to Git (currently we use SVN) only to be saddened by their pricing. We have around 5000 employees, GitHub price for 500 seats is 125,000$, this is incredibly expensive. Judging by their pricing they don't want big companies to be their clients as simple as that. Atlassian for example had a lot of grief with us simply because their products didn't scale that well past 5000 users.

Re: Why GitHub’s pricing model stinks (for us)

#44

I really do not get the big deal. Just set up ssh on your own server and voilà... free unlimited repos. sure you miss out on some tools. But what's more important... repo storage/usage/access/privacy or a pretty graph of your commits? Perhaps catting a ssh key to the end of a text file is a bit too much complexity for a company who claim to be selling themselves as expert software solutions developers. And if you do…

Or use BitBucket. Just as easy as GitHub, but with unlimited private repos for free.

Re: Why GitHub’s pricing model stinks (for us)

#45
I think the GitHub pricing model is excellent - and super cheap. I have multiple accounts and I happily pay for all of them - the value of not having to use a bad interface like bitbucket is far larger than the price for GitHub.

With a cost of 200$ for 125 repos, it is less than 2$ per client - if thats a problem, I think you should rethink your business plan. Keep in mind, nothing prevents you from removing clients you didn't work on for e.g. 6 months and put them on a NAS (although I would not do that myself)

Re: Why GitHub’s pricing model stinks (for us)

#46
post #25

So from one consultant to another consultant, what do you say when a potential client starts to say "Actually, we don't think we can do this engagement, because $X is too much" where $X is some number in three digits?

Exactly. They can just create a new account for each new client for peanuts. No client is going to bark for an extra $20 for the github account.

Re: Why GitHub’s pricing model stinks (for us)

#47
post #37
post #14

I agree and I wish I'd written this article myself. One of the great things about git compared to the version control systems of yesteryear is that it's lightweight enough and (with Github) discoverable enough to make many small repos a viable development pattern. I never liked the old giant-repo-for-all-the-code system, although I understand it's still popular at Google and many other large shops. I think what reall…

This is precisely the reason why we switched from github to unfuddle. Why should my developers start rationing for repos and start putting everything in one large repository, just so that we don't hit the limit with github. For example, we use node.js heavily, and I would like create npm modules that can be shared across repos, and put them in a repo of their own (so npm can install them). Github's pricing forces me…

Is there a reason you wouldn't use public github repos for your npm modules?

Re: Why GitHub’s pricing model stinks (for us)

#48

Earlier quoted context omitted.

Because it's more work to do. Instead of setting that up, you could be working on your product. The company I work for does the same - code is all hosted locally, emails were (until recently) hosted locally, document sharing too. It was cheap but every so often there'd be a problem and it'd go down for 15-30 minutes, which would cost a few £1000 in lost productivity.

If you are of a significant size you will want to have a release or build engineer anyway who will normall be the person who takes ownership of these things. If not then it will be your office unix guy. I'm also not a fan of quantifying productivity lost in ££. When someone has a bowl movement do you chart that against company productivity?

> If you are of a significant size you will want to have a release or build engineer anyway who will normall be the person who takes ownership of these things. If not then it will be your office unix guy.

We have a sysadmin who looks after the servers. However, bad things can happen. If he was able to spend all his time working on these problems, they wouldn't occur, but he has other responsibilities too. Should we hire someone else? No! It's cheaper and more reliable to outsource these responsibilities to a team working 100% of the time on it.

> I'm also not a fan of quantifying productivity lost in ££. When someone has a bowl movement do you chart that against company productivity?

I don't understand your point. There's a big difference between going to get coffee, go to the toilet, etc - which is normal, expected and accounted for - and having large parts of the company unable to work because particular services are down.

Post reply on HN