Using the number of repositories for pricing is a ridiculous metric in many ways and for many reasons. What is the rationale behind it? Transparency?
Why GitHub’s pricing model stinks (for us)
21–30 of 90 posts
Re: Why GitHub’s pricing model stinks (for us)
#22Github 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 lets say 3.000 euro TCO per year.
For us having code in the cloud (read within reach of the US government) is not an option, our customers will not allow it. I believe our insurance will not even allow that. Also we need to have Ldap/Active Directory integration; Ldap is the only way we can effectively manage authorisation between a large amount of services.
Looking at all the alternatives, Atlassian Stash, Gitstack, etc. Github is by far the most expensive(75.000 per year). Right now, we have decided that setting up a Gitblit server ourselves, will be the most cost effective.
There is no way I can convince my boss that using Github will save us 60.000 euro per year.
Re: Why GitHub’s pricing model stinks (for us)
#23I 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…
Bits might be bits, but you aren't paying for storage. If you are, just get a 1TB hard disk for $50 and have more space than you'll ever need for repos.
You're paying for Github, and it's not priced by bits stored.
Re: Why GitHub’s pricing model stinks (for us)
#24I use both: I stick my private repos up on Bitbucket (where I don't need to show them to anyone, and thus pay nothing), and my public repos on Github (where I don't need to hide them from anyone, and thus pay nothing.)
And I don't miss Github's collaborative features in my private repos because I'm not collaborating in those :) Bitbucket is literally just "a place to push my repo where it'll be safe" for me[1]; Github is "a place where I can collaborate with others."
And you know what? You can even use both for a single project. Push your public branches to Github, accept patches, then base a private product on the result [just some extra non-pushed-to-public branches] and work on that in Bitbucket. For example, you could have, say, the Chromium codebase on Github, and then Chrome on Bitbucket.
[1] Well, okay, Bitbucket is also pretty good for doing deploys from: you can CNAME git.yourcompany.com to them, set up some Deploy Keys and Deploy Hooks, and it'll feel just like you had your own internal repo server for your deploy server to talk to.
Re: Why GitHub’s pricing model stinks (for us)
#25So 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?
Re: Why GitHub’s pricing model stinks (for us)
#26We've also been discussing this recently where I work. Our problem is that the small wordpress projects quickly eat up the repo quota.
The price isn't a problem, but their largest plan only gives 125 repos, which we'll reach relatively quick at this rate. Enterprise is not an option, as we're not really interested in hosting and maintaining it ourselves.
They do however say "If you need a plan larger than Platinum, contact us for details about our larger business plans." Does anyone have any details about what their larger business plans consist of?
Most likely we'll eventually migrate to Bitbucket.
Re: Why GitHub’s pricing model stinks (for us)
#27Using the number of repositories for pricing is a ridiculous metric in many ways and for many reasons. What is the rationale behind it? Transparency?
How so? What would you use instead?
Re: Why GitHub’s pricing model stinks (for us)
#28Earlier quoted context omitted.
Out of interest, how would you say you compare to BitBucket? Your given plan structures seem to suggest that their pricing structure per user is superior. "A startup with 30 repos and a team of two is completely free." Same with them. "A professional plan with 60 repos and 5 collaborators is $9 per month." 5 collaborators is free with them. "A business plan 150 repos and 10 collaborators is $72 per month." BitBucket…
Thank you for the question. We want to make sure that the pricing only increases in small steps. If you add one more user you should never go from $25 to $50. We also have a free issue tracker, you don't have to pay for it. Jira prices are 4 times more expensive than BitBucket prices. And of course there is the option to go self hosted easily in the future. What do you think we can improve in the pricing of GitLab.co…
Not to put you off, but more to provide an interesting case study.. patio11 wrote about the difference between configurable/scalable pricing and fixed plans recently: http://www.kalzumeus.com/2012/08/13/doubling-saas-revenue/
Re: Why GitHub’s pricing model stinks (for us)
#29I'm in a similar position. I'm a freelancer, and I have quite a few clients for various Ruby/iOS/Node projects. I need more private repositories, but the jump to Gold is too much for my business.
The issue is largely down to older clients that I only occasionally do maintenance work for. I've got about 15 of these, and they cut into my private repo count. Of course, it's easy to dump repositories on a server, which I have done in some cases, but I find my clients often like GitHub's interface. I've also put a few onto Bitbucket to give myself a bit of breathing room, this works well when projects are effectively 'archived' and have little client involvement but are still running.
I'm thinking about using GitLab, but I'm wondering about the amount of effort it'd take to maintain it. Cost for GitHub/Bitbucket vs. time to maintain another web application? Hmm...
Re: Why GitHub’s pricing model stinks (for us)
#30I 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…
Bits might be bits, but you aren't paying for storage. If you are, just get a 1TB hard disk for $50 and have more space than you'll ever need for repos. You're paying for Github, and it's not priced by bits stored.
I think the idea is that all the stuff Github gives you scales pretty much linearly with the number of bits you're storing. Bigger repo = longer commit history; more commits = more issues tracked, more features, bigger wiki, more forks, etc.
When you split a project into two subprojects that are fairly equal in scope, each one will likely get just about half of the number of tickets/wiki articles/forks made that the original would have. So making a new repo isn't adding overhead for Github in any marginal way; the overhead would be there either way, as long as that original repo was being used to do the work of two sub-projects.