3 ms·
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 lightwe
by sgentle 14y ago
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 really rankles is that it fires up my developer edge-case sense. Wait, so you mean I can have one repository of 100MB, but if I have two of 50MB that costs more? Bits are bits, so why are you punishing one particular factoring of my data vs another? That's like charging for S3 per top-level directory, or for iTunes by album. I feel like charging per repository makes you feel bad about making more repositories, which can often lead to feeling bad about good decisions.
Also, realistically, a cost per developer is so miniscule compared to the overall cost of that developer. The proportional cost per project is much higher, particularly if it's some skunkworks side-project and you're the one trying to explain why you should double how much you're paying github so that you can have a live coffee consumption dashboard for the break room.
It might be irrational, but it's the truth - we associate costs together in buckets, and Github is associating itself with the wrong bucket.
- StavrosK 14y agoBits 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.
- derefr 14y agoI 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.
- mqzaidi 14y agoThis 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 not to do this, and discourages code reuse.
- deleted 14y ago[deleted]
- analog 14y agoIs there a reason you wouldn't use public github repos for your npm modules?
- tomfakes 14y agoI used to be a big fan of Unfuddle, and I still have an account there, but the reality is that all of the integrations I use (CI is the most recent one) work great with Github and not at all, or are much harder to configure, with Unfuddle. Github is creating value with their ecosystem, which is great for them, and, since the code is all in Git, not a complete lock-in if you choose to move.
- ricardobeat 14y agoLots 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?
- gm 14y agoYour comment's good, it's the children of HN not liking what you said. Nothing to do but move on.
- jimrandomh 14y agoAgreed, but even worse than that, it makes GitHub's pricing O(n^2) with time. If a project involves creating a repository and then leaving it up when the project's finished or in maintenance, that costs money forever; and if a person creates such projects at a fixed rate, then that gets unreasonably expensive.
- jimrandomh 14y agoAgreed, but even worse than that, it makes GitHub's pricing O(n^2) with time. If a project involves creating a repository and then leaving it up when the project's finished or in maintenance, that costs money forever; and if a person creates such projects at a fixed rate, then that gets unreasonably expensive.