Introducing unlimited private repositories(github.com)
github.com
Introducing unlimited private repositories
https://github.com/blog/2164-introducing-unlimited-private-repositories
656 comments
Per user pricing makes a lot more sense than per repo pricing. This way larger organizations pay more money than smaller ones regardless of how they structure their code.
This is a good deal for small organizations that like to have many small repositories (for internal libraries, utilities, micro services, modules, etc).
Sure, it screws up a few models that rely on external collaborators to get access to private repos, but those can stick with the old model for a while (at least 12 months). And in the meantime GitHub may adjust their model to accommodate those situations too.
Lastly, this is a huge freebie for individual accounts that now get unlimited repos for $7/month. That will benefit a lot of people.
So I don't see this as PR spinning, but rather as an overdue move on github's part to a model that makes a lot more sense and benefits small organizations and individuals.
This is a good deal for small organizations that like to have many small repositories (for internal libraries, utilities, micro services, modules, etc).
Sure, it screws up a few models that rely on external collaborators to get access to private repos, but those can stick with the old model for a while (at least 12 months). And in the meantime GitHub may adjust their model to accommodate those situations too.
Lastly, this is a huge freebie for individual accounts that now get unlimited repos for $7/month. That will benefit a lot of people.
So I don't see this as PR spinning, but rather as an overdue move on github's part to a model that makes a lot more sense and benefits small organizations and individuals.
I work for a non-profit open source organization that collaborates on github (https://github.com/edx/) We have lots of people who aren't employees, but have signed a contributor agreement with our organization and contribute changes to our software. Our bill will go up from $200/month to over $2000/month with this new pricing. We can afford it (it's still a small fraction of our AWS bill) but it will force us to look at other alternatives. Github's code review tools are already pretty mediocre compared to other tools like gerrit, and we've long since moved off of github issue tracking due to lack of features compared to JIRA.
I've used Bitbucket in the past. They charge per-user[1], and their pricing is significantly better free for 5 users and then once you eclipse 5 users it's $1/user up to 100 users and then $200 for unlimited users.
[1] - https://bitbucket.org/product/pricing
[1] - https://bitbucket.org/product/pricing
Absolutely.
I use Bitbucket for a variety of small, personal projects. And when I teach Git courses, I use Bitbucket to illustrate (and practice) pull, push, and pull requests (among other things). Sometimes people wonder why I'm not using GitHub, which has made itself synonymous with Git for many people, but after a short explanation, they understand.
However: GitHub has a huge network effect. Most developers with any sort of open-source connection have a GitHub account; many fewer have Bitbucket accounts. This isn't the end of the world, but it does mean that GitHub has a leg up on the competition as far as name recognition is concerned.
Plus, there are lots of tools that talk to the GitHub API.
So, while I personally endorse using BitBucket, I can understand why many would stick with GitHub. It'll be interesting to see what this price change does.
I use Bitbucket for a variety of small, personal projects. And when I teach Git courses, I use Bitbucket to illustrate (and practice) pull, push, and pull requests (among other things). Sometimes people wonder why I'm not using GitHub, which has made itself synonymous with Git for many people, but after a short explanation, they understand.
However: GitHub has a huge network effect. Most developers with any sort of open-source connection have a GitHub account; many fewer have Bitbucket accounts. This isn't the end of the world, but it does mean that GitHub has a leg up on the competition as far as name recognition is concerned.
Plus, there are lots of tools that talk to the GitHub API.
So, while I personally endorse using BitBucket, I can understand why many would stick with GitHub. It'll be interesting to see what this price change does.
This. I use bitbucket too and I can't understand why people are still paying github when bitbucket does exactly the same and is free.
Github does seem to be the gold standard for open source projects.
Having said that, I used to pay for Github's personal plan and found the cap on private repos (5 when I subscribed) to be a little too limiting. I ended up canceling the subscription and using a Bitbucket free account for private repos and Github for public repos.
After using Bitbucket for a while, I think if I had to upgrade to a paid service, I'd just stick to Bitbucket.
Having said that, I used to pay for Github's personal plan and found the cap on private repos (5 when I subscribed) to be a little too limiting. I ended up canceling the subscription and using a Bitbucket free account for private repos and Github for public repos.
After using Bitbucket for a while, I think if I had to upgrade to a paid service, I'd just stick to Bitbucket.
I will tell you one reason: Bitbucket is unbelievably slow where I live (Tokyo). Using it is mostly a matter of gnashing your teeth and waiting.
GitHub is actually painfully slow too; just not as slow.
That's the main reason I pay GitHub and use them for those projects where I need something more than just a git server for collaboration.
GitHub is actually painfully slow too; just not as slow.
That's the main reason I pay GitHub and use them for those projects where I need something more than just a git server for collaboration.
I also use Bitbucket and am very pleased with it. It seems like their model is that bitbucket is well integrated and complements their paid products like JIRA and Teamcity, so they are not depending on free users to upgrade like github needs to, so it seems more likely to be sustainable.
People use github over bitbucket if they like the features that github provides, the diffs, issues etc. Not sure which features are unique to github alone, but each provider (including gitlab) has their own flavor. Many are just used to github flavor.
I use bitbucket at work, and it has many of the same features as github. The UI is a bit clunkier, and it does lack some of the flashy features such as automatically squashing commits when merging a pull request. However it does work fine, and it is well integrated with atlassian's other offerings which we also use. Mainly JIRA and hipchat, though bitbucket also has a per-repository issue tracker.
An aside, but I hate that squash feature more and more each day at my job.
Could you elaborate? Is it used for every pull request? That would be annoying, but sometimes developer leaves a trail of "work in progress" commits, so I'll wind up squashing those anyway.
These services are not the same, not since I last checked. Someone forks your repo, makes a change and then submits a PR. I can't pull their changes down until they give me read access to their forked repo.
I found a lot of these little annoyances to be a big reason to switch to github. Not to mention their UI pales in comparison to github, which I think says a lot.
I found a lot of these little annoyances to be a big reason to switch to github. Not to mention their UI pales in comparison to github, which I think says a lot.
I've never understood why all the fork/change/commit/push/pull-request fol-de-rol is necessary. Why can't we just pull, hack, and submit a "push request"?
But I guess I've never understood why everyone else seems to be OK with a build/repo system where it is even possible to break the build at all; it's always seemed to me like it should be set up so you push to a testing stage, which merges to master if the build succeeds and the tests pass, but otherwise fails and sends you an error log. Never seen a build system set up that way, though, and the couple of times I've looked into the matter it seemed like I'd basically have to code it up myself, which was more effort than I was willing to put into it.
With such an architecture, the idea of a "push request" would just be a manual OK step in addition to the automated test validation step.
But I guess I've never understood why everyone else seems to be OK with a build/repo system where it is even possible to break the build at all; it's always seemed to me like it should be set up so you push to a testing stage, which merges to master if the build succeeds and the tests pass, but otherwise fails and sends you an error log. Never seen a build system set up that way, though, and the couple of times I've looked into the matter it seemed like I'd basically have to code it up myself, which was more effort than I was willing to put into it.
With such an architecture, the idea of a "push request" would just be a manual OK step in addition to the automated test validation step.
It's not necessary, it's a waste of development time and easily the biggest big-picture collective failure of our software engineering profession of the last decade. It easily beats out anything from the $foo.js world and the ongoing low-level security nightmare of web application development, because git, and more importantly, unnecessarily complex and error-prone git workflows have seen adoption across all kinds of software. There are probably a dozen projects in the world (the kernel admittedly being one of them) that are justifiably a good fit for the complex git-native workflows that have become standard practice across the industry today.
But if you're doing it the old-fashioned way, you might as well use Subversion. Or mercurial, if you want all the local history, with the added bonus that unlike git it sensibly keeps the least-surprise semantics of 'commit', 'revert', and other commands that merely have a 30-year history of expectations that held true prior to git. But Mercurial was not authored by Linus, nor does it have the impenetrable, otherworldly data model that a first-time version-control-system author would unavoidably end up concocting in scratching their itch without consulting the existing, completely satisfactory, solutions that served us well for decades, which greatly reduces the number of interesting topics you can blog about for Mercurial.
And so, git sees the adoption, github gets the $2bil valuation, and even bitbucket ends up switching to git as it's default. It won.
Software engineering, collectively, has a lot of maturing to do.
But if you're doing it the old-fashioned way, you might as well use Subversion. Or mercurial, if you want all the local history, with the added bonus that unlike git it sensibly keeps the least-surprise semantics of 'commit', 'revert', and other commands that merely have a 30-year history of expectations that held true prior to git. But Mercurial was not authored by Linus, nor does it have the impenetrable, otherworldly data model that a first-time version-control-system author would unavoidably end up concocting in scratching their itch without consulting the existing, completely satisfactory, solutions that served us well for decades, which greatly reduces the number of interesting topics you can blog about for Mercurial.
And so, git sees the adoption, github gets the $2bil valuation, and even bitbucket ends up switching to git as it's default. It won.
Software engineering, collectively, has a lot of maturing to do.
I have been using git for years and I still find its interface completely inscrutable. I have given up trying to learn it in a way that makes it make sense, and simply use a handful of everyday commands I've memorized by rote and look everything else up when I need it. I can't think of any other piece of software I actually use which has such a messy, non-predictable interface. Even 'make' eventually succumbed to rational analysis when I finally managed to suppress my nausea long enough to dig in and learn it as though it were a real language.
This. Even simple things like "undo last commit" has hard to remember syntax that I always have to google for it.
I wish darcs was more successful.
> I have given up trying to learn it in a way that makes it make sense, and simply use a handful of everyday commands I've memorized by rote and look everything else up when I need it.
? Here are the commands that I have used and make sense to me:
branch, tag, log, diff, push, pull, fetch, commit, rebase (with or without -i), reset, add, rm, mv, stash, status, remote, bisect, reflog, blame, and fsck.
Is this set of commands more or less the same as the set of commands that you've learned by rote memorization?
? Here are the commands that I have used and make sense to me:
branch, tag, log, diff, push, pull, fetch, commit, rebase (with or without -i), reset, add, rm, mv, stash, status, remote, bisect, reflog, blame, and fsck.
Is this set of commands more or less the same as the set of commands that you've learned by rote memorization?
Commonly: pull, push, commit -a, reset --hard HEAD, checkout $FILE, status, log, show $HASH.
Sometimes: commit --amend, rebase -i, add, rm, mv, stash [pop|apply].
Rarely: branch, revert.
Git's documentation uses such a wide and flagrantly inconsistent variety of terminology and maintains such a poor distinction between its interface and its implementation that trying to read it actually worsens my understanding and reduces my confidence. I get everything useful from stackoverflow and ignore the docs at this point, and have thus resigned myself to using git as a form of voodoo.
Subversion was so much clearer; I wish it had done a better job with merges and hadn't been so server-dependent. Mercurial seemed to actually care about its interface design, and the DVCS experience might suck less if it had won, but I've never had a chance to actually use it.
Sometimes: commit --amend, rebase -i, add, rm, mv, stash [pop|apply].
Rarely: branch, revert.
Git's documentation uses such a wide and flagrantly inconsistent variety of terminology and maintains such a poor distinction between its interface and its implementation that trying to read it actually worsens my understanding and reduces my confidence. I get everything useful from stackoverflow and ignore the docs at this point, and have thus resigned myself to using git as a form of voodoo.
Subversion was so much clearer; I wish it had done a better job with merges and hadn't been so server-dependent. Mercurial seemed to actually care about its interface design, and the DVCS experience might suck less if it had won, but I've never had a chance to actually use it.
Thanks for the reply!
I agree that some of the commands have a very large array of options. I see many these options as very specialized tools (and certainly don't claim to know all (or -in some cases- most) of them). I, too find the "git config" command to be largely useless. Its value is in scripts or in Git frontends. Also, the git-config manpage has a complete listing of all valid git config options. So, there's that. :)
> Commit, checkout, and reset seem rather more complicated than necessary and don't do anything useful in their default forms...
When called with no args, commit records changes staged with add/rm/mv in the local repo's history. Checkout changes the tracked contents of the working copy to that of another point in the repo's history (so it is meaningless to call it without an argument), and git reset is destructive (and has no --force option), so it makes sense to require an argument. [0]
In regards to commit and checkout:
I came to git by way of Subversion. These two confused me for quite a while. What helped me to understand the logic behind them was to realize that -unlike SVN- git has
* The working copy, which is manipulated with a bunch of commands
* The area where changes that will be included in the next commit live, which is cleared out after every successful commit, and is manipulated by add, rm, and others
* Your local repo, which is manipulated with commit and checkout
* One or more remote repos, which is manipulated with push, pull, and merge
But maybe you already had this solidly in mind, and this explanation was a waste of your time. :(
> As always, trying to read the documentation leaves me with less understanding than I had before I started.
Have you familiarized yourself with a significant fraction of git's vocabulary? The man pages became much clearer once I did so. [1]
> ...for reasons I cannot comprehend they also get involved in merge resolution, where they perform tasks with no visible relationship to their names or their normal jobs.
Oh. That's because a merge operation adds a series of commits from one or more branches into another branch and effectively makes a new commit with the result of the operation. If conflicts can be automatically resolved, then they are. If they cannot, then it's up to you to stage the changes you want to see in the merge commit (using add and friends) just like you would do when preparing any other commit. Does that make sense?
> I have no idea what reflog would do; is there a flog command too?
Nah. It's a command for examining and manipulating the reflog, which is -effectively- where git makes a record of every change that happened to your repo. You pretty much never need to use the command, but I have used to see just how git handled a set of complicated squash and commit reorder operations. From the man page:
> I am generally more inclined to use stash or a second working directory than to deal with branches, since it's less busy-work.
I'm curious. What busy-work do you have to do? I typically just have to do: "git branch whatever; git checkout another-branch; git branch -D some-other-branch".
[0] Though -conceptually- a substantial portion of reset's functionality overlaps with checkout's functionality. So, that's silly and nonsensical.
[1] Not that I'm implying that such a thing is be required to use git, mind.
I agree that some of the commands have a very large array of options. I see many these options as very specialized tools (and certainly don't claim to know all (or -in some cases- most) of them). I, too find the "git config" command to be largely useless. Its value is in scripts or in Git frontends. Also, the git-config manpage has a complete listing of all valid git config options. So, there's that. :)
> Commit, checkout, and reset seem rather more complicated than necessary and don't do anything useful in their default forms...
When called with no args, commit records changes staged with add/rm/mv in the local repo's history. Checkout changes the tracked contents of the working copy to that of another point in the repo's history (so it is meaningless to call it without an argument), and git reset is destructive (and has no --force option), so it makes sense to require an argument. [0]
In regards to commit and checkout:
I came to git by way of Subversion. These two confused me for quite a while. What helped me to understand the logic behind them was to realize that -unlike SVN- git has
* The working copy, which is manipulated with a bunch of commands
* The area where changes that will be included in the next commit live, which is cleared out after every successful commit, and is manipulated by add, rm, and others
* Your local repo, which is manipulated with commit and checkout
* One or more remote repos, which is manipulated with push, pull, and merge
But maybe you already had this solidly in mind, and this explanation was a waste of your time. :(
> As always, trying to read the documentation leaves me with less understanding than I had before I started.
Have you familiarized yourself with a significant fraction of git's vocabulary? The man pages became much clearer once I did so. [1]
> ...for reasons I cannot comprehend they also get involved in merge resolution, where they perform tasks with no visible relationship to their names or their normal jobs.
Oh. That's because a merge operation adds a series of commits from one or more branches into another branch and effectively makes a new commit with the result of the operation. If conflicts can be automatically resolved, then they are. If they cannot, then it's up to you to stage the changes you want to see in the merge commit (using add and friends) just like you would do when preparing any other commit. Does that make sense?
> I have no idea what reflog would do; is there a flog command too?
Nah. It's a command for examining and manipulating the reflog, which is -effectively- where git makes a record of every change that happened to your repo. You pretty much never need to use the command, but I have used to see just how git handled a set of complicated squash and commit reorder operations. From the man page:
Reference logs, or "reflogs", record when the tips of branches and
other references were updated in the local repository. Reflogs are
useful in various Git commands, to specify the old value of a
reference. For example, HEAD@{2} means "where HEAD used to be two moves
ago", master@{one.week.ago} means "where master used to point to one
week ago in this local repository", and so on. See gitrevisions(7) for
more details.
> I am generally more inclined to use stash or a second working directory than to deal with branches, since it's less busy-work.
I'm curious. What busy-work do you have to do? I typically just have to do: "git branch whatever; git checkout another-branch; git branch -D some-other-branch".
[0] Though -conceptually- a substantial portion of reset's functionality overlaps with checkout's functionality. So, that's silly and nonsensical.
[1] Not that I'm implying that such a thing is be required to use git, mind.
I agree, especially when all you really want to do is make a small change. (I'm less likely to contribute then - preferring to open an issue and nag someone on the team/who already has a fork to implement my one-liner!)
But I think it would be look pretty radically different architecturally - where would such a 'push request' live? You don't have push rights on the repo; nor do you have your own fork.
It needs to work in a Gitty-way - if not GH would anger far more people than one-line contributors. And Git needs access to a repo to which to push.
I suppose a fairly nice solution might be something like: - clone - edit - push --set-upstream origin gh-pr-<my-patch-name>
Github could then respond by mocking push-rights for the repo, but really creating a new 'hidden' repo; and mirroring commits on that branch to a PR opened on the original repo (to which you don't actually have anything beyond read-access).
When the PR merged they could delete the 'stealth repo'; of course if you wanted to maintain your own fork it could still work the way in which it does today.
But I think it would be look pretty radically different architecturally - where would such a 'push request' live? You don't have push rights on the repo; nor do you have your own fork.
It needs to work in a Gitty-way - if not GH would anger far more people than one-line contributors. And Git needs access to a repo to which to push.
I suppose a fairly nice solution might be something like: - clone - edit - push --set-upstream origin gh-pr-<my-patch-name>
Github could then respond by mocking push-rights for the repo, but really creating a new 'hidden' repo; and mirroring commits on that branch to a PR opened on the original repo (to which you don't actually have anything beyond read-access).
When the PR merged they could delete the 'stealth repo'; of course if you wanted to maintain your own fork it could still work the way in which it does today.
A "push request" would just be a git-format-patch on the contributor's side and a git-am on the project maintainer's side. Github wouldn't have to create a separate repository - they'd just have to keep an incoming "mail" spool for each repo and show some UI letting the project maintainer review these patches and approve them or deny them. Maybe there actually would be an email address representing "push requests" to the repo, but more likely I'd imagine github would just offer an upload box on the project page where you could post a patch file.
This would be so much easier than the pull-request dance that I bet it would lead to a lot of simple fixes or improvements being contributed by people who otherwise wouldn't get involved at all. Those have value in themselves - but it would also go a long way toward helping recruit new project members, if people could dip their toes in easily before having to go through all the mumbo-jumbo of a private fork and configuring the upstream and all that.
This would be so much easier than the pull-request dance that I bet it would lead to a lot of simple fixes or improvements being contributed by people who otherwise wouldn't get involved at all. Those have value in themselves - but it would also go a long way toward helping recruit new project members, if people could dip their toes in easily before having to go through all the mumbo-jumbo of a private fork and configuring the upstream and all that.
> I've never understood why all the fork/change/commit/push/pull-request fol-de-rol is necessary. Why can't we just pull, hack, and submit a "push request"?
I've always wondered why GitHub doesn't add automatically add an "upstream" remote when forking a repo. Once you fork a repo in the GitHub UI, there is no way to pull changes from upstream repo other than manually creating your own "upstream" remote.
I've always wondered why GitHub doesn't add automatically add an "upstream" remote when forking a repo. Once you fork a repo in the GitHub UI, there is no way to pull changes from upstream repo other than manually creating your own "upstream" remote.
Gitlab has the ability to do that.
http://doc.gitlab.com/ce/workflow/merge_when_build_succeeds....
http://doc.gitlab.com/ce/workflow/merge_when_build_succeeds....
Thanks - I am unfamiliar with gitlab but will have to check it out.
Network effects make github more valuable, to an open source organization, than self hosting or hosting on another provider. Almost everyone has a github account and asking users to sign up for another account is a significant barrier to contribute.
Neither service charges for public repositories. We're talking about private ones here.
[deleted]
I'd be more careful with any offering from Atlassian. They recently increased significantly Crucible/FishEye prices. IIRC unlimited plan used to start at 200 users, now they added more tiers but kept the prices of the original tiers.
If you are a non-profit, your bill can be $0. You just need to sign up here[0] and send in the data requested.
[0] https://github.com/nonprofit
[0] https://github.com/nonprofit
It doesn't seem this is valid for academic nonprofits (from the linked page) so I don't think EdX would qualify.
That's right. I didn't notice it was academic. GitHub has a similar deal for education[0]. The bottom of the page has a link to apply for a free educational org.
[0] https://education.github.com/
[0] https://education.github.com/
> We have lots of people who aren't employees, but have signed a contributor agreement with our organization and contribute changes to our software.
So you have volunteers, working on your proprietary, private software for free. The labor is free & now you're complaining that you'll have to pay a per-free-laborer fee for the infrastructure to manage all these free-laborers? I hope I'm missing something here...
So you have volunteers, working on your proprietary, private software for free. The labor is free & now you're complaining that you'll have to pay a per-free-laborer fee for the infrastructure to manage all these free-laborers? I hope I'm missing something here...
The problem being that a minor volunteer who donates 4 hours of coding over the course of a year would now incur a $108 github bill for having that access. It's totally out of proportion with how much they're using the service.
Or say you have 80 very-part-time contributors who together match the output of 1 full-time employee, github is going to charge you as much as they would for 80 full-time employees.
Any pricing structure is going to have some people who get a great deal and other people who get screwed, but it sucks when you've selected a platform, invested in getting set up on it, and then have the pricing rug pulled out from under you.
Or say you have 80 very-part-time contributors who together match the output of 1 full-time employee, github is going to charge you as much as they would for 80 full-time employees.
Any pricing structure is going to have some people who get a great deal and other people who get screwed, but it sucks when you've selected a platform, invested in getting set up on it, and then have the pricing rug pulled out from under you.
the software is AGPLv3'd, and run by hundreds of educational organizations around the world. Those organizations typically contribute changes back via Github. Non-employees don't contribute to our private repositories. We gain quite a bit from maintaining a large open source community, but it's not "free labor."
I apologize- I thought volunteers were contributing to your private repos. If I understand correctly, your issue is that you have (say) 10 employees accessing private repos and 100 contributors to public/Free ones, but you're to be charged for all users you add to your org? I can see how this would be frustrating.
I see two possible solutions that don't force you to switch vendors:
1. Have non-employees fork & submit pull requests. 2. Split your private stuff off to a different org & formally separate free stuff from proprietary, make the free stuff community managed.
If these are problems, I'd maintain that this is a "have your cake and eat it to" problem, on the one hand keeping ownership & control of the project and reaping the attendant benefit to the edx brand, and on the other hand getting people to hack on your stuff for free. But in any event this is a broader existential issue that exists across the OSS world right now (see express.js), so I'm probably reading too much into your case. :)
I see two possible solutions that don't force you to switch vendors:
1. Have non-employees fork & submit pull requests. 2. Split your private stuff off to a different org & formally separate free stuff from proprietary, make the free stuff community managed.
If these are problems, I'd maintain that this is a "have your cake and eat it to" problem, on the one hand keeping ownership & control of the project and reaping the attendant benefit to the edx brand, and on the other hand getting people to hack on your stuff for free. But in any event this is a broader existential issue that exists across the OSS world right now (see express.js), so I'm probably reading too much into your case. :)
From the announcement:
"These users do not fill a seat:
Outside collaborators with access to only public repositories"
"These users do not fill a seat:
Outside collaborators with access to only public repositories"
You are jumping to a whole lot of conclusions there.
Why are you assuming that the labor is free? And regardless if it is or isn't, how is that even relevant? GitHub has no idea how much or how little a contributor is paid for their contributions.
If you are non profit and open source do you really need private repos?
We have about 100 private repos at the moment, including internal tools, branding related components, infrastructure code and pre-release stuff that we're not developing in the open. We may just move those to AWS code commit, gitlab or gogs and switch back to a free org.
You're very welcome to switch to GitLab.com, we are free forever https://about.gitlab.com/gitlab-com/#why-gitlab-com-will-be-... and it can import directly from GitHub.
GitLab CE (Community Edition is Free) and is truly great we use it in our own internal software development process.
However for a bigger enterprise they require more functionality here is a comparison of the differences between the Community and Enterprise Editions.
https://about.gitlab.com/features/#compare
Several pricing options for EE but essentially the base cost is $39 /year per user.
https://about.gitlab.com/pricing/
However for a bigger enterprise they require more functionality here is a comparison of the differences between the Community and Enterprise Editions.
https://about.gitlab.com/features/#compare
Several pricing options for EE but essentially the base cost is $39 /year per user.
https://about.gitlab.com/pricing/
gitlab.com runs EE though doesn't it? You only need to pay if you want self hosted EE.
It does, yes :)
Great to know, thank you! However our requirements were offsite and must be why I never knew about the free EE hosted on GitLab!
I've only ever seen the trial but I could be wrong!
You are replying to the CEO of Gitlab... :P
Which is very OK :) BTW we published a blog on SaaS git pricing a minute ago https://about.gitlab.com/2016/05/11/git-repository-pricing/
Is gitlab still using MySQL or its variants behind the scenes?
The gitlab import is really SLOW and there is no clear indication of the progress. Try to import https://github.com/torvalds/linux.git, it takes forever.
FWIW, I work for an academic non-profit and we use public repositories with an appropriate LICENSE. We like it because we don't need to manage read permissions.
What kind of bad things will happen if people are able to see what you are doing?
Your first comment stated the problem was your large number of non-employee contributors. You said in another comment that non-employees don't contribute to your private repos.
I don't see the problem here. Your employees will have access to your private repos, and the volunteers will not (thus you won't be paying for their seats).
I don't see the problem here. Your employees will have access to your private repos, and the volunteers will not (thus you won't be paying for their seats).
"that we're not developing in the open"
Honest question... why?
I totally understand the mindset of "gotta go all secret squirrel to protect our profits" but if your org isn't in it for the profits there's not much to protect?
I have seen examples of people performing very naughty acts like private repos to hold plain text passwords, plain text cloud service keys, plain text corporate credit card numbers for expense payments, etc.
Honest question... why?
I totally understand the mindset of "gotta go all secret squirrel to protect our profits" but if your org isn't in it for the profits there's not much to protect?
I have seen examples of people performing very naughty acts like private repos to hold plain text passwords, plain text cloud service keys, plain text corporate credit card numbers for expense payments, etc.
There are a ton of reasons not to develop in the open, no matter what your structure.
- You're experimenting - You don't want comments from the peanut gallery while things are in progress - It is not for external use, specific to an institution or project, or otherwise nobody else will care - It deals with something sensitive - You've made an agreement with someone else that requires it - etc. etc. etc.
People seem to have weird notions about nonprofits. Your tax structure doesn't change the fact that you operate in a world of other human beings.
- You're experimenting - You don't want comments from the peanut gallery while things are in progress - It is not for external use, specific to an institution or project, or otherwise nobody else will care - It deals with something sensitive - You've made an agreement with someone else that requires it - etc. etc. etc.
People seem to have weird notions about nonprofits. Your tax structure doesn't change the fact that you operate in a world of other human beings.
mostly these reasons. We also want to make sure that code we open source is properly documented, has appropriate functional tests, and is useful outside of our organization. Our typical workflow is to build a POC, then an MVP, then build out documentation and unit tests.
Non-profit organizations still have a mission that they need to protect, and they almost always have revenue they care about, though not profit.
Private repos are a good way to review code for things like plaintext passwords and service keys before it's in production. If a developer commits something with a key, and code review goes "Oh, you shouldn't have put that there," and it was public, now you have to rekey. Private repos allow that code review step to take place.
(They're also pretty useful for legacy code where eliminating all the private keys is difficult and not an immediate priority, and for the rare but existent cases where including private keys in source is the right engineering tradeoff for new development.)
There's also no way to disable pull requests and other outside comments on your code, other than making a private repo. Having it private is a simple way to avoid inviting the public to have opinions all over your repo.
Private repos are a good way to review code for things like plaintext passwords and service keys before it's in production. If a developer commits something with a key, and code review goes "Oh, you shouldn't have put that there," and it was public, now you have to rekey. Private repos allow that code review step to take place.
(They're also pretty useful for legacy code where eliminating all the private keys is difficult and not an immediate priority, and for the rare but existent cases where including private keys in source is the right engineering tradeoff for new development.)
There's also no way to disable pull requests and other outside comments on your code, other than making a private repo. Having it private is a simple way to avoid inviting the public to have opinions all over your repo.
My first job out of university was at a not-for-profit, and it is a surprisingly cut-throat sector.
We had two main competitors in our space, and while the ultimate goal for everyone including our competitors was to do a common good, we were competing for a limited pool of donation dollars.
Because of that, sharing any intellectual property that made us better at what we did (i.e., raise more money, hire more staff, fund more initiatives) could result in a competitor using that same IP to put us out of business.
I get that in the big picture, it's not the way things should be done, but in the small picture, you're usually talking about individuals with their own agendas.
We had two main competitors in our space, and while the ultimate goal for everyone including our competitors was to do a common good, we were competing for a limited pool of donation dollars.
Because of that, sharing any intellectual property that made us better at what we did (i.e., raise more money, hire more staff, fund more initiatives) could result in a competitor using that same IP to put us out of business.
I get that in the big picture, it's not the way things should be done, but in the small picture, you're usually talking about individuals with their own agendas.
In a non-profit that I collaborate with [1] we use private repos to keep the server setup and some tickets that contain sensitive information (user data). All other code is open source. Obviously we don't want to keep api keys etc. in the public repos.
[1] https://github.com/sozialhelden/wheelmap
[1] https://github.com/sozialhelden/wheelmap
You shouldn't be keeping api keys or other sensitive information in git at all. And please note -- if you do remove it from git, it will be available in your git history so that needs to be taken care of as well (should the repo ever become public -- a common "exploit").
Git is just a format for storing data with a record of how that data changed. Saying you shouldn't store it in git seems rather like saying you shouldn't store it in btrfs. It's true that if your btrfs disk image becomes public, the data is recoverable, and it's hard to reliably scrub deleted files from btrfs, but that doesn't mean it's the wrong tool for a filesystem (or a repo) that stays entirely internal.
Saying that you shouldn't keep it on GitHub is different, and I might be more inclined to agree with that, but it still seems like it's not a 100% rule.
Saying that you shouldn't keep it on GitHub is different, and I might be more inclined to agree with that, but it still seems like it's not a 100% rule.
> Saying that you shouldn't keep it on GitHub is different
I'd be willing to argue about that, but for my newrelic api key, a private github repo is sufficiently safe - even if I'd prefer if nobody starts having his servers report to my account.
I'd be willing to argue about that, but for my newrelic api key, a private github repo is sufficiently safe - even if I'd prefer if nobody starts having his servers report to my account.
A git repo is usually shared over multiple machines/developers. So the chance of someone publicating it is larger. As well as the entire history is usually copied everywhere
All of these machines and developers have legitimate access to the secret in question, though. Hence my framing of git as just a file storage format—any other mechanism provides the technical means for any of these machines or developers to publicize it. (And a few other simple mechanisms, like "scp the secret from another machine" or "copy/paste it with your terminal", have an increased risk of doing so by accident. Accidentally making a git repo public is generally unlikely.)
Why would that be a general rule. I track my personal passwords in git (using pass). I'm the only person with access to that repo. I just like to have a history - and the convenient way of moving files around and merging changes.
> Saying you shouldn't store it in git seems rather like saying you shouldn't store it in btrfs.
Best practice is to avoid storing secrets in plaintext, or sharing secrets between users/roles. Yours isn't an argument in favour of git, it is an argument against btrfs.
(I don't have any problem with storing passwords in that way, I'm just pointing out why it's not the best practice.)
Best practice is to avoid storing secrets in plaintext, or sharing secrets between users/roles. Yours isn't an argument in favour of git, it is an argument against btrfs.
(I don't have any problem with storing passwords in that way, I'm just pointing out why it's not the best practice.)
> Best practice is to avoid storing secrets in plaintext
How do you store them, then? If they're encrypted with a password, how do you store that secret?
I'm pretty sure best practice is in fact to store things like SSL private keys, cookie HMAC secrets (e.g. Django's SECRET_KEY), and so forth on local disk unencrypted, protected by only filesystem permissions (and the host OS as a whole protected with standard means). In fact I'm not even sure it's possible to store OpenSSH private keys unencrypted.
> or sharing secrets between users/roles.
There's only one role here: the application that has an API key. There are multiple developers of that application, and possibly multiple instances of that application, but it's a single role.
How do you store them, then? If they're encrypted with a password, how do you store that secret?
I'm pretty sure best practice is in fact to store things like SSL private keys, cookie HMAC secrets (e.g. Django's SECRET_KEY), and so forth on local disk unencrypted, protected by only filesystem permissions (and the host OS as a whole protected with standard means). In fact I'm not even sure it's possible to store OpenSSH private keys unencrypted.
> or sharing secrets between users/roles.
There's only one role here: the application that has an API key. There are multiple developers of that application, and possibly multiple instances of that application, but it's a single role.
OpenSSH client private keys can be stored encrypted - that's what ssh-agent is for: it allows you to enter the key passphrase only once and then remember it for the rest of your desktop session.
OpenSSH server private keys, on the other hand - I don't think that makes a whole lot of sense. Unless you have a threat model that forces you to encrypt the entire server disk, but then adding private key encryption on top of that doesn't make much sense either.
OpenSSH server private keys, on the other hand - I don't think that makes a whole lot of sense. Unless you have a threat model that forces you to encrypt the entire server disk, but then adding private key encryption on top of that doesn't make much sense either.
Right, exactly. (I did mean to say "server", thanks.) It sounds like the secrets in question are essentially analogous to OpenSSH private keys: they allow a server / service to prove its own identity to others, and the servers should be able to launch automatically at boot so there's not a reasonable place to enter a passphrase.
TPM.
It's just one role, but multiple users.
It's just one role, but multiple users.
Do you have any tools you recommend for that? I love TPMs, but this seems wildly impractical for a small project with developers who aren't excited about becoming TPM experts.
Also, does this rule out hosting on clouds that don't offer vTPM support? (Are there any that do?)
Also, does this rule out hosting on clouds that don't offer vTPM support? (Are there any that do?)
There are dedicated discrete HSMs that can be installed. That's what I would do. Or, rather, wouldn't. I agree with you that it would be very impractical, unless the platform has a first-class API:
Chrome OS uses TPM heavily[1], and iOS has the Security Enclave. The standard TPM API is PKCS#11, so any hardware that speaks it can be used with any software that speaks it.
Problem with TPM is that the whole hardware and software stack needs to be secure, which in practice means it needs to be designed top-down with awareness of the TPM, and audited. The secrets must not be cached, written to file system, kept in memory, leaked over network. There are implementations such as Trousers[2], but it's more or less just a proof of concept; it may provide additional security, but most likely you're just using a very complex lock, and leaving the key under the mat.
[1] https://www.chromium.org/developers/design-documents/tpm-usa... [2] http://trousers.sourceforge.net/man/tpmtoken_setpasswd.1.htm...
Chrome OS uses TPM heavily[1], and iOS has the Security Enclave. The standard TPM API is PKCS#11, so any hardware that speaks it can be used with any software that speaks it.
Problem with TPM is that the whole hardware and software stack needs to be secure, which in practice means it needs to be designed top-down with awareness of the TPM, and audited. The secrets must not be cached, written to file system, kept in memory, leaked over network. There are implementations such as Trousers[2], but it's more or less just a proof of concept; it may provide additional security, but most likely you're just using a very complex lock, and leaving the key under the mat.
[1] https://www.chromium.org/developers/design-documents/tpm-usa... [2] http://trousers.sourceforge.net/man/tpmtoken_setpasswd.1.htm...
care to explain why? I need to keep my API keys somewhere so I can roll them out to the machine. Keeping them in git is as good as any storage - what would you propose instead? A shared dropbox account?
The newfangled approach is something like HashiCorp's Vault, which is a dream when you're looking at more than half a dozen systems with similar roles. A different approach that I like to use for single or smaller cluster systems is Ansible's Vault and rolling out config files based on templates per environment. All actual config files are gitignored so I don't have do deal with conflicts on the server if I use a git-pull style deployment, and ansible itself can backup/version whenever they change.
Additionally, git does keep that history (as it's supposed to), so if you just delete the key from a private repo as you're trying to make the repo public, it's trivial for someone to walk the commit history looking for historical API keys that might not have been rotated. In order to purge that information from git, you then have to go re-write the commit graph from the point of the key's insertion (with it removed) all the way to the present. It's not impossible to do, it's just a major pain.
Additionally, git does keep that history (as it's supposed to), so if you just delete the key from a private repo as you're trying to make the repo public, it's trivial for someone to walk the commit history looking for historical API keys that might not have been rotated. In order to purge that information from git, you then have to go re-write the commit graph from the point of the key's insertion (with it removed) all the way to the present. It's not impossible to do, it's just a major pain.
I'm aware of the implications concerning the history, but sorry, the machine park is two machines. Setting up vault would just be total overkill. The people that have access to that repo change like once every few years. The repo will never go public. Let's keep the solution at least somewhat tailored to the problem.
Hey, I'm not arguing one way or the other. I like using Ansible for configuration in the way I work. I can trust that I can show my best friend and my worst enemy my project and they won't have the capability of making my life hell. Rock on though. Use the simplest solution for the problem at hand. If you're just managing two boxes though, I'd have a hard time coming up with an argument for adding more complexity to the setup to essentially make it unchanged.
It's all chef-based so we could be using encrypted databags, but as anybody with access to the repo has root on the machines anyways, there's little to gain there as well, especially given the very limited security implications. I'd be more worried that somebody adds his account to the sudoers list that stealing the secret data. But hey, things were that way when I joined and there's better places to spend my time to improve security.
All keys are tracked in git's history, so it's a possible attack vector for hackers. You could use https://github.com/sobolevn/git-secret. But beware, anytime you revoke someone's access, you should regenerate all secrets stored in there.
In any case you should always regenerate the keys whenever someone's access is revoked
What the hell? Are you defending a decision to keep keys unencrypted in a git repo?
It's a perfectly defensible decision. The standard cryptographer's reply at this point would be, what is your threat model?
If "A developer could have their GitHub account broken into" or "Someone could break into GitHub deeply enough that they could access private repos" are in your threat model, you shouldn't be using GitHub at all for anything, including code, because it would be straightforward to use that access to subvert your site in other ways. Which is to say, especially for small sites, that's not a useful threat model.
If "You might do a git commit to remove them, then push the repo somewhere" is in your threat model, then the answer is just "Don't do that" (or more precisely, "Make sure everyone on the team understands that can't be done without precautions"). The easiest way to don't-do-that is to have them in a separate git repo from your code. But either way, as projects grow, there's going to be stuff in your git history you don't want to be public (like, oh, git commit -m "Implementing this stupid feature because this customer is stupid") because human error happens sometimes. So if you want to publish a previously-private codebase, the only robust approach is to copy all the files into a new non-git repo and make a new commit.
And the other part of the cryptographer's reply is, where else are you going to store the secrets and what are its security properties?
If "A developer could have their GitHub account broken into" or "Someone could break into GitHub deeply enough that they could access private repos" are in your threat model, you shouldn't be using GitHub at all for anything, including code, because it would be straightforward to use that access to subvert your site in other ways. Which is to say, especially for small sites, that's not a useful threat model.
If "You might do a git commit to remove them, then push the repo somewhere" is in your threat model, then the answer is just "Don't do that" (or more precisely, "Make sure everyone on the team understands that can't be done without precautions"). The easiest way to don't-do-that is to have them in a separate git repo from your code. But either way, as projects grow, there's going to be stuff in your git history you don't want to be public (like, oh, git commit -m "Implementing this stupid feature because this customer is stupid") because human error happens sometimes. So if you want to publish a previously-private codebase, the only robust approach is to copy all the files into a new non-git repo and make a new commit.
And the other part of the cryptographer's reply is, where else are you going to store the secrets and what are its security properties?
yes, indeed I am. I'm all in favor of keeping the tools used to a level where the effort makes sense to protect the value of the goods. I totally could lock up my newrelic api key in a bank safe, double encrypted with two persons 4096 bit GPG keys, but that would be a little overkill, wouldn't it? Do you do that? I'd be moderately annoyed if somebody started pushing false metrics to my NR account, but that's about all the damage they could do with the information in that repo. So what level of effort would you propose?
Agreed, we do this as well at some scale. The vast majority of application configuration falls into this category. The advantage of storing them in a git repo (we use a different git repo to the main codebase) is that you can re-use the same access control mechanisms (note that is not the same as giving the same people access to the different repos) and you get strong change history.
never store sensitive data like API keys in a repository. Or you can do that but encrypt it so that nobody which can view your repo (even if it's private) can use that data immediately. It's like storing passwords in plaintext in a DB. Every (DB) admin will tell you: Don't/Never do that.
I've recently also have to do with this problems while doing server setup with a private repo. I'm using Ansible and Ansible Vault to encrypt sensitive data and the encryption key itself is only accessible (a password safe) to certain members of our team http://docs.ansible.com/ansible/playbooks_vault.html
I've recently also have to do with this problems while doing server setup with a private repo. I'm using Ansible and Ansible Vault to encrypt sensitive data and the encryption key itself is only accessible (a password safe) to certain members of our team http://docs.ansible.com/ansible/playbooks_vault.html
see, the whole repo is accessible to the members of the team that are allowed to see the secret - basically the two folks that have root on the machine anyways. There's very limited use in encrypting the repo. There are no SSL keys or any secrets that would require tight security. It's basically our newrelic and some other api keys for reporting services. Even if that repo would be breached you could only start sending fake data to those services.
I'm more concerned about someone hacking the machine than someone hacking github to access the repo and retrieve the newrelic key from there.
I'm more concerned about someone hacking the machine than someone hacking github to access the repo and retrieve the newrelic key from there.
ok, agree. That is not that critical.
And you share the passwords with enough volunteers that per users pricing becomes a problem?
I don't handle the account in that case, so I can't even say if it's free or not. I was just replying to the implied question "why would a nonprofit org with an OS project need private repos?"
[deleted]
Nonprofits need CRUD apps just like any other organization.
"Being a nonprofit" doesn't mean "developing open source software".
"Being a nonprofit" doesn't mean "developing open source software".
At that scale of developers and cost, surely it makes sense to host your own instance of, say, GitLab?
Especially as you note AWS costs are much more - I'd have thought it would be much more economical to consolidate into AWS and run a VC server there.. but I'm not trying to tell you what's good for you, I'm just a guy with no experience of responsibility for things at that scale who's curious ;)
Especially as you note AWS costs are much more - I'd have thought it would be much more economical to consolidate into AWS and run a VC server there.. but I'm not trying to tell you what's good for you, I'm just a guy with no experience of responsibility for things at that scale who's curious ;)
It's a non-profit and open source? Why not just use public repos like Code.org and many other non-profit software teams. $0/mo is surely better for a non-profit.
For non-profits, you could reach out and see if they'd do something special for you. I used to work in for a higher ed institution and they were gracious enough to give me a free account.
[deleted]
just use gogs. https://gogs.io
[deleted]
I couldn't agree more. It has annoyed me when companies charge more for decisions about how you choose to do something - in this case how you split up your code. Paying per person makes much more sense.
This was exactly the reason we used Bitbucket in the beginning, even if it was worse in some aspects. Github would have been simply too expensive (or restricting) with our "it's always in source control" approach, even for smaller prototypes.
We're happy Gitlab users now by the way - and I'm curious how long Github will survive with their over-valuation as the alternatives get seriously better now - the lock-in and network effects are quite shallow IMHO.
We're happy Gitlab users now by the way - and I'm curious how long Github will survive with their over-valuation as the alternatives get seriously better now - the lock-in and network effects are quite shallow IMHO.
Just wanted to add that if you don't want to run GitLab yourself our GitLab.com is free with unlimited private repositories but it also has also unlimited private collaborators https://about.gitlab.com/gitlab-com/
I never realized gitlab.com offered free private repos. Thanks!
Any API on this service?
Sure, see http://doc.gitlab.com/ce/api/
The interface is horribly (painfully) slow. On the API side...any of the params I post when hitting the create project endpoint are not taken into consideration. With the following data posted to the API I still get public builds, issues not enabled, wiki not enabled and so on: {'issues_enabled': True, 'description': None, 'visibility_level': 0, 'public_builds': False, 'wiki_enabled': True, 'snippets_enabled': True, 'merge_requests_enabled': True, 'name': 'testfoo'}
> This is a good deal for small organizations that like to have many small repositories (for internal libraries, utilities, micro services, modules, etc).
I'm a small contracting shop: makes more sense to me. I might have 100 repos, but I can only develop so fast. Now all I'm costing GitHub is a little diskspace (which is insanely cheap, especially for text).
I'm a small contracting shop: makes more sense to me. I might have 100 repos, but I can only develop so fast. Now all I'm costing GitHub is a little diskspace (which is insanely cheap, especially for text).
If you want unlimited private repositories, just use bitbucket instead. It's free instead of $7 a month.
Price per idle/obsolete etc repo - $1.5-$2.5/month and goes down with number of repos. Price per idle/noncontributing user - $9/month and it stays constant.
In any case, for my org it would mean ~5x cost increase. So yes, nice spin.
In any case, for my org it would mean ~5x cost increase. So yes, nice spin.
My company, for one, was actually in the middle of shifting to BitBucket off of Github, because the costs were becoming unjustifiable.
We have a growing number of repos that are more-or-less "finished" projects, and few if any changes are made per year. Accounting was starting to groan... and BitBucket's model fit our small team almost perfectly, although Github's UI, flow, etc, was, in our opinion, still better. New talent almost always has an existing Github account we can integrate, instead of needing to make and manage a new BitBucket account.
Now, with this news, we'll just reverse course and stick it out with Github.
We have a growing number of repos that are more-or-less "finished" projects, and few if any changes are made per year. Accounting was starting to groan... and BitBucket's model fit our small team almost perfectly, although Github's UI, flow, etc, was, in our opinion, still better. New talent almost always has an existing Github account we can integrate, instead of needing to make and manage a new BitBucket account.
Now, with this news, we'll just reverse course and stick it out with Github.
The new pricing model is about 9x more expensive than Bitbucket, for a given number of users. If your cost-concerned, I can't understand why you should reverse your decision.
We have a fairly small team of developers, and a fairly large number of private repositories. So, for us, it's a pretty significant savings.
I've personally stuck to Bitbucket for all my private repositories exactly because Githubs pricing model made it untenable. For that price I might just sign up, even though I might keep syncing to Bitbucket anyway, just because I'm paranoid.
> Lastly, this is a huge freebie for individual accounts that now get unlimited repos for $7/month.
It's also nice for student, like myself, who get unlimited private repos for $0 a month.
It's also nice for student, like myself, who get unlimited private repos for $0 a month.
Best reply ITT
> But I'd appreciate if their PR department didn't expect us to swallow this as a positive change.
I don't have any numbers on how people structure their accounts on Github, but my feeling is that this is a positive change for the majority of Github users.
Git encourages having many smaller repos for modules over massive single repos. $1/repo/month is fine for active projects, but gets expensive really fast if you want to keep archives of small private experiments around. Because of the per-repo pricing on Github, I've seen many friends and startups I've worked with keeping their open-source public repos on Github (for free), while moving private repos to Bitbucket.
I would not be surprised if this pricing change would be a net revenue loss for Github, but still implemented to avoid losing market share to Bitbucket.
I don't have any numbers on how people structure their accounts on Github, but my feeling is that this is a positive change for the majority of Github users.
Git encourages having many smaller repos for modules over massive single repos. $1/repo/month is fine for active projects, but gets expensive really fast if you want to keep archives of small private experiments around. Because of the per-repo pricing on Github, I've seen many friends and startups I've worked with keeping their open-source public repos on Github (for free), while moving private repos to Bitbucket.
I would not be surprised if this pricing change would be a net revenue loss for Github, but still implemented to avoid losing market share to Bitbucket.
Majority user, here.
I already pay GitHub monthly because I have some repos that I want private. I'm a solo dev, only hacking on side projects that may or may not be something one day, but want to keep them private anyway. My bill is about to go down, and my benefits go up. All in all, I'm quite alright with this change, agree that it's positive.
I get that it gets worse if I ever take on N number of developers, but that's a hurdle I'll deal with if I ever get there. I do imagine I'm not alone in this position.
I already pay GitHub monthly because I have some repos that I want private. I'm a solo dev, only hacking on side projects that may or may not be something one day, but want to keep them private anyway. My bill is about to go down, and my benefits go up. All in all, I'm quite alright with this change, agree that it's positive.
I get that it gets worse if I ever take on N number of developers, but that's a hurdle I'll deal with if I ever get there. I do imagine I'm not alone in this position.
I'm curious, as a solo dev, had you considered bitbicket?
I've used BitBucket as a solo dev working on personal projects, a solo consultant, and an employee on a team. It's pretty mediocre, especially if you look beyond its integration with the rest of the Atlassian ecosystem.
The number of times I've wanted to search a repo for something only to have to clone it and search in my IDE is staggering.
The number of times I've wanted to search a repo for something only to have to clone it and search in my IDE is staggering.
Same for me - lack of searching kills me every time!
You might want to look into https://github.com/etsy/hound if you ever want to search. I found this superior to Github as well if I want to find all repos that reference something.
The repo migration functionality is also super flimsy.
Yeah, but GitHub got me early on before I cared about private repos, and honestly I was just too lazy to move stuff over. They also win me over with integrations, though I'm sure BitBucket has a similarly expansive set now. Had I ever gone full Atlassian, I'd have switched, but never wanted to add Jira to my life badly enough (though when I was seriously working on a project with a friend, I considered it).
Wow, you actually just made me think of something that could have been a great change for GitHub.
Rather than completely limiting private repos in their old pricing model, they could have limited "active" repos, and created an archive feature, where archived repos were not available via Git, but still existed as backups and in case you ever wanted to make them active again.
I do, however, believe that the new, per-user pricing is more sustainable. File storage is rather cheap; running Git pull / push is not necessarily.
Rather than completely limiting private repos in their old pricing model, they could have limited "active" repos, and created an archive feature, where archived repos were not available via Git, but still existed as backups and in case you ever wanted to make them active again.
I do, however, believe that the new, per-user pricing is more sustainable. File storage is rather cheap; running Git pull / push is not necessarily.
They already had this in their old model. If you downgrade your plan and have more repos than allowed, they don't force you to delete them. They archive them and if you ever need to access them and make them active again, you just upgrade, for at least the month. Seemed pretty fair.
You can still remove a repo and keep backups yourself. Allowing it through GH makes it very easy to exploit this by archiving/unarchiving repos constantly.
The problem for Github was that the best place to "keep backups yourself" was Bitbucket. I archived a number of inactive projects from Github to Bitbucket. But that gets tedious, so why not start them on Bitbucket in the first place?
This is a positive change for me as well.
From the perspective of a customer: repositories should be cheap, users shouldn't be. This is a positive change and one that will make me strongly consider moving from BitBucket to GitHub.
I've worked at places with two developers and 150 repositories. I've worked at places with 12 developers and 5 repositories. Who do you think gets more marginal utility out of another repository?
Every place I've worked that hasn't used GitHub either did so because of a regulatory reason (HIPAA and not wanting to do on-premise) or because the per-repository pricing model made it absolutely stupid expensive, or dumped you straight into Enterprise.
If you make a lot of money off a single private repo with many users, you'll move from "so cheap you don't even need to think about it" to "market rate." If you make a little money off of a lot of repos with a handful of users, you'll move from "don't even consider it due to cost" to "let's try it out for six months and see how it goes."
I've worked at places with two developers and 150 repositories. I've worked at places with 12 developers and 5 repositories. Who do you think gets more marginal utility out of another repository?
Every place I've worked that hasn't used GitHub either did so because of a regulatory reason (HIPAA and not wanting to do on-premise) or because the per-repository pricing model made it absolutely stupid expensive, or dumped you straight into Enterprise.
If you make a lot of money off a single private repo with many users, you'll move from "so cheap you don't even need to think about it" to "market rate." If you make a little money off of a lot of repos with a handful of users, you'll move from "don't even consider it due to cost" to "let's try it out for six months and see how it goes."
I work at a small company (7 engineers) and per-repo pricing is exactly why we chose not to use GitHub. Most of our projects are short-term, meaning we have hundreds of repos going back over ten years, the majority of which are inactive. GitHub's pricing didn't make sense for us at all. (We ended up using self-hosted GitLab which we're pretty happy with.)
I'm getting really tired of engineers complaining about pricing and being cheap (I'm a engineer + founder). User pricing is a much better model for organizations (scales as you do in terms of headcount).
And for individual accounts this is a win, win, no matter what. A flat $7 get's you unlimited repos.
GitHub is not out to get you. GitHub's "PR" department is not trying to trick you. GitHub builds and maintains a crazy powerful tool that you probably use hours a day. It should cost money, and honestly it should cost more if you ask me.
And for individual accounts this is a win, win, no matter what. A flat $7 get's you unlimited repos.
GitHub is not out to get you. GitHub's "PR" department is not trying to trick you. GitHub builds and maintains a crazy powerful tool that you probably use hours a day. It should cost money, and honestly it should cost more if you ask me.
Points 1-2 seem irrelevant to your argument.
> 4. Switch to a user-based pricing to generate more revenue for investors
You add "for investors" as a slur, like it's a bad thing. Every company, public or private, has investors -- even if it's just the founders.
> but spin it as a freebie "Hey! Look at the cool unlimited shit! No, no! Don't pay attention to the fact you're gonna be charged 3 times as much as before for the same service".
Except not everyone will be charged 3x as much. Many will be charged much less. It totally depends on the setup.
I have heard countless times over the years what a pain it is for orgs to be charged per repo. It incentives monolithic repos.
Equally important: from the perspective of a company trying to maintain budgets, it might actually make more sense to _them_. Factoring Github as a per-head charge, similar to everything from Slack/Gmail/Photoshop to laptops to food and other perks to healthcare benefits, might make things easier than worrying about whether your employees are structuring their repos in a way that minimizes costs.
> 4. Switch to a user-based pricing to generate more revenue for investors
You add "for investors" as a slur, like it's a bad thing. Every company, public or private, has investors -- even if it's just the founders.
> but spin it as a freebie "Hey! Look at the cool unlimited shit! No, no! Don't pay attention to the fact you're gonna be charged 3 times as much as before for the same service".
Except not everyone will be charged 3x as much. Many will be charged much less. It totally depends on the setup.
I have heard countless times over the years what a pain it is for orgs to be charged per repo. It incentives monolithic repos.
Equally important: from the perspective of a company trying to maintain budgets, it might actually make more sense to _them_. Factoring Github as a per-head charge, similar to everything from Slack/Gmail/Photoshop to laptops to food and other perks to healthcare benefits, might make things easier than worrying about whether your employees are structuring their repos in a way that minimizes costs.
When I was doing my PhD I ended up putting all my development into one repo and all my documents in a second because of GitHub's per repo rules. I didn't know about an academic pricing (they might have had it, but I think it was added after I finished) and I asked about the rules because I wanted a number of small repos, but all told would only be a few hundred meg at most. I was told no, so I decided on the two repo strategy. It worked, but it was awkward.
I personally like the bitbucket method.
I get my private repos free, but I can only work with 5 people on them before I have to start paying.
I get my private repos free, but I can only work with 5 people on them before I have to start paying.
Agreed. The goal should be accurate market segmentation. Students, open-source devs, and hobbyists pay little or nothing, small shops pay some, and large enterprises pay more. Collaborator count seems to do that better than most metrics.
It is worth noting that GitHub organizes the Student Developer Pack[1] which comes with a Micro plan ($7 - max 5 repos). It means GitHub will offer unlimited public and private repos for 2-3 years for students who were selected.
[1]: https://education.github.com/pack
[1]: https://education.github.com/pack
It says you will be able to add a few collaborators. So I think it will be very similar in the end.
Except that you have to pay for GitHub.
Which I already was. Now I'm paying less, and getting more.
But since they now are limiting the number of contributors to your private repos, you might as well use BitBucket for free.
I do, some? When I bumped up against the repo limit in GitHub, and didn't want to increase my account size. But it always felt like a cheap knock-off, so I don't spend much time there; generally I'd clear out an older repo, or just bump up my account.
Switch to a user-based pricing to generate more revenue for investors, but spin it as a freebie "Hey! Look at the cool unlimited shit! No, no! Don't pay attention to the fact you're gonna be charged 3 times as much as before for the same service".
Cynicism much? I don't know how your organization is structured, but for us, this will represent a price discount. Not by a huge margin now, but as the number of private repos we use will almost certainly grow faster than the number of users we have, this is definitely a better situation for us, now and in the future.
Cynicism much? I don't know how your organization is structured, but for us, this will represent a price discount. Not by a huge margin now, but as the number of private repos we use will almost certainly grow faster than the number of users we have, this is definitely a better situation for us, now and in the future.
Per repo pricing was why we didn't go with github.
Atlassian was our only option till we shopped around till we found Visual Studio Team Services.
For a team of 4. Simply great. No need to pay for Jira or anything at this point.
Now, I won't go back to github even if it was completely free. The value Atlassian gives makes it a much better and attractive offering if you don't like Microsoft.
Atlassian was our only option till we shopped around till we found Visual Studio Team Services.
For a team of 4. Simply great. No need to pay for Jira or anything at this point.
Now, I won't go back to github even if it was completely free. The value Atlassian gives makes it a much better and attractive offering if you don't like Microsoft.
All the production code here is on BitBucket.
Forcing users to pay for privacy has always stuck in my throat as a business model.
I think this change is due to GitHub feeling some heat from Atlassian and GitLab.
Forcing users to pay for privacy has always stuck in my throat as a business model.
I think this change is due to GitHub feeling some heat from Atlassian and GitLab.
I have a lot of half-finished projects kicking around that I would love to start on github, but I'm concerned about privacy and it certainly isn't worth it to me to pay $7/mo rather than keeping them on my Dropbox.
I haven't checked out BitBucket as I kind of thought GitHub was the only game in town, but will check it out. Would be nice to get these projects off my machine but not make them public.
edit: ohh and I'm just starting on BitBucket and it both imports from Git directly and defaults to private. Awesome.
I haven't checked out BitBucket as I kind of thought GitHub was the only game in town, but will check it out. Would be nice to get these projects off my machine but not make them public.
edit: ohh and I'm just starting on BitBucket and it both imports from Git directly and defaults to private. Awesome.
Yeah, I dropped github years ago for bitbucket for my personal private repos. Can't beat free.
Their strategy worked because when I moved my employer off of SVN, a paid Bitbucket is where we went.
Their strategy worked because when I moved my employer off of SVN, a paid Bitbucket is where we went.
Also, I think gh has this now, but for a long time bitbucket was the only one that gave you the ability to prevent history changes on certain branches (I always do develop and master). If this had been available in gh we would not have seen those couple big projects accidentally force push develop.
Once you start integrating with their other tools, you'll be giddy with joy.
But, they're not free so...
[deleted]
For us as a small team it's a very positive change. Our monthly bill just went from $100 to $25.
And for us it's negative, our monthly bill has just increased by hundreds of dollars. In theory, our respective organisations could be in competition, and GitHub has just increased our monthly bill to subsidise your organisation, instead of shouldering the financial burden themselves.
> GitHub has just increased our monthly bill to subsidise your organisation, instead of shouldering the financial burden themselves.
This is a really weird argument. They are a company supplying a service, why should they ever have to shoulder the bill?
I'd argue that if things stayed the same, this small company would subsidize you: if you have 100 accounts using 1 repo it's more likely you're using more resources than 1 account with even 1000 repos :)
This is a really weird argument. They are a company supplying a service, why should they ever have to shoulder the bill?
I'd argue that if things stayed the same, this small company would subsidize you: if you have 100 accounts using 1 repo it's more likely you're using more resources than 1 account with even 1000 repos :)
My point is that larger companies are now be punished for a failed initial pricing model by GitHub. I prefer the new pricing model from a personal point of view, but for larger organisations it's now too expensive and I think many will relocate their repositories to BitBucket, or GitLab, or Gogs, or etcetera.
Edit: My parent post is being down voted and that's fine, my point was not made in anger, it was an observation that smaller companies are having their monthly costs decreased, and the larger companies are seeing an increase, for organisations created after today that's a fair premise, but for those organisations that have been using GitHub for years and have now seen their monthly costs increase, it's a slap in the face.
Edit: My parent post is being down voted and that's fine, my point was not made in anger, it was an observation that smaller companies are having their monthly costs decreased, and the larger companies are seeing an increase, for organisations created after today that's a fair premise, but for those organisations that have been using GitHub for years and have now seen their monthly costs increase, it's a slap in the face.
> a failed initial pricing model by GitHub
It's been 8 years since they revealed their pricing model, which has remained mostly unchanged on the lower end and only adjusted on the high end to account for GitHub Enterprise and suggest people move to that instead of the gargantuan $3k/mo plans. I don't know many SaaS companies that don't tweak their pricing much more infrequently than that. Thoughtbot's Giant Robots Smashing into Other Giant Robots podcast for the past few episodes has been consistently talking about A/B testing pricing models, prices changes and signup, conversion and churn, as a weekly adjustment on some of their services (FormKeep, Upcase, etc)
https://github.com/blog/22-the-pricing-plans
It's been 8 years since they revealed their pricing model, which has remained mostly unchanged on the lower end and only adjusted on the high end to account for GitHub Enterprise and suggest people move to that instead of the gargantuan $3k/mo plans. I don't know many SaaS companies that don't tweak their pricing much more infrequently than that. Thoughtbot's Giant Robots Smashing into Other Giant Robots podcast for the past few episodes has been consistently talking about A/B testing pricing models, prices changes and signup, conversion and churn, as a weekly adjustment on some of their services (FormKeep, Upcase, etc)
https://github.com/blog/22-the-pricing-plans
Failed might have been a strong and stupid word, it's worked for GitHub. The new model just doesn't work for our organisation, and that's not the fault of GitHub but it does cause us some headaches.
Sorry to hear this change is frustrating for your team. If the new model doesn't work for you, can stay on the old structure. We're not automatically migrating anyone, so you can stay on the old plan. If we ever do decide to phase out the legacy structure completely, you'll still have 12 months from that point before you have to move over. (We've updated the blog post to reflect that clarification, too)
Thank you!
> punished
> subsidized
Come on. Those things are not happening.
> subsidized
Come on. Those things are not happening.
The sheer irony of this statement is staggering. Github is a business and their goal is to make money. If you have 5x the number of people doing dev work on your code, then by definition you are a "larger" organization from their vantage point. Why wouldn't you pay more?
"Why wouldn't you pay more?" comments are rather annoying.
Why would you pay more if you don't have to?
Bitbucket caps their price at $200/month for unlimited users.
That would pay for only ~25 users on github.
Basically they are 9 times as expensive per user as bitbucket.
Have you considered that if you self-hosted on a repurposed desktop machine running off solar panels, with unpaid interns doing maintenance, you could cap it at $0, and save on the heating bill during winter?
So then what is your solution? Per-repo pricing still?
If your bill increased by hundreds of dollars then you have many employees. You really can't afford $9 per user a month? This came up in the Jetbrains pricing arguments. What the hell are you paying software engineers if $9 or $20 a month matters. My employer has paid me more than $9 in the time I've been trolling this thread to respond to people.
This argument doesn't make sense. What matters is how much the total Github cost (or cost increase, if we're evaluating the impact of this change) affects your bottom line, or the costs of your department, or even your company profit. For instance, my company would get a $6k hit from this price change, and we spend ~30k on SaaS software in total or ~60k in IT costs (including wages). It's a very significant change, that will absolutely trigger a strong evaluation of alternatives.
Assuming you are using annual numbers there, you are saying you have 55 users on Github. The relevant number isn't your IT budget, it's the salaries of the people using GitHub. If it's $75k per person thats over $4.125 million a year.
Does 0.15% of your budget matter? Does GitHub not make your team 0.15% more productive? Would the switching cost to a new tool be less than 0.15% of your total cost?
If you are doing that math and coming up with the answer that switching makes sense, by all means do it, but I would argue that your problems are bigger than your GitHub bill. I personally can't fathom working for a company that strapped for cash, I'd be looking for a new job myself.
Does 0.15% of your budget matter? Does GitHub not make your team 0.15% more productive? Would the switching cost to a new tool be less than 0.15% of your total cost?
If you are doing that math and coming up with the answer that switching makes sense, by all means do it, but I would argue that your problems are bigger than your GitHub bill. I personally can't fathom working for a company that strapped for cash, I'd be looking for a new job myself.
They've not announced a timeline for forcing you to move plans. Maybe they never will.
You could move to bit bucket.
I use GitHub for my public repos, but use Visual Studio Online (poorly named, since it is not actually Visual Studio) for my private ones (also unlimited, but free.) I know a lot of others that use Bitbucket, etc because of GitHub's pricing. I feel like GitHub would make more sense to smaller devs, like myself, if it were bundled with other services. Like, if they partnered with Microsoft, Google & Amazon and offered some sort of bundling packages with their cloud services. I don't know, to me GitHub...from a small dev perspective only makes sense to share things publicly. I'm sure this new pricing model will help push some smaller devs onto the platform, but it's hard to compete in that space when you have others providing private repos for free.
I just looked it up again, they changed the name to Visual Studio Team Services which makes much more sense.
https://www.visualstudio.com/products/visual-studio-team-ser...
https://www.visualstudio.com/products/visual-studio-team-ser...
Eh? I was very happy with my micro account, this is pretty awesome! If I ever need to recommend a corporate account, GitHub is pretty much my first choice.
It's not basic math, it depends entirely on your code structure. In a world of 'microservices' repos proliferate very quickly. My last company has hundreds of repos, but only dozens of engineers. The pricing model was becoming a major pain point for us.
As an individual this model makes way more sense for me. I pay the same as before but get unlimited private repos? Awesome.
As an individual this model makes way more sense for me. I pay the same as before but get unlimited private repos? Awesome.
> But I'd appreciate if their PR department didn't expect us to swallow this as a positive change. Most coders understand basic maths.
If you don't like PR, then why can't you just see past it? Why wouldn't an organization try to make it sound like a positive change? Do you expect them to come out with negative changes?
What does valuation or organization changes have to do with this anyway? Are you somehow unhappy with their company? Sure they have issues but they have also created a great platform with lots of networks effects and value. It works, and it's very cheap for what it does. And if you don't like it, there are tons of competitors.
Seriously, what's the problem here?
If you don't like PR, then why can't you just see past it? Why wouldn't an organization try to make it sound like a positive change? Do you expect them to come out with negative changes?
What does valuation or organization changes have to do with this anyway? Are you somehow unhappy with their company? Sure they have issues but they have also created a great platform with lots of networks effects and value. It works, and it's very cheap for what it does. And if you don't like it, there are tons of competitors.
Seriously, what's the problem here?
From the article: "And while we're currently not enforcing a timeline to move..."
I too was sad to see many of the new developments at Github, but if they were money grubbing like you say, wouldn't they make everyone switch faster than this?
I too was sad to see many of the new developments at Github, but if they were money grubbing like you say, wouldn't they make everyone switch faster than this?
I actually love it and I'm thankful for Github's consistently great service - looking forward to all the bitbucket/gitlab customer project migrations over the coming months.
[deleted]
> 3. Notice that a significant segment of your growth (VC-funded startups) are running out of money.
No comment on the rest of your post, but I doubt this part is true. I'm sure a lot of VC funded startups use GitHub, but there just aren't enough of them to be a "significant" part of the GH customer base.
No comment on the rest of your post, but I doubt this part is true. I'm sure a lot of VC funded startups use GitHub, but there just aren't enough of them to be a "significant" part of the GH customer base.
Compared to products like Salesforce, GitHub seems cheap to me.
What to you is a fair price and why?
What to you is a fair price and why?
As stated at the end of my comment, a fair price is what they decide to charge. I simply don't like people to try and spin a price increase into a freebie.
You seem to be ignoring the comments to the contrary made on your original comment when stating this.
Sure it's going to cost some orgs more, and it makes sense that it does. I'd wager that data at rest (lots of repos) costs a hell of lot less to run than active requests (lots of users).
Personally my bill will be going down from $25 to $7, and I'm fine with that.
My companies bill will be going down from $650/month to $583/month.
Sure it's going to cost some orgs more, and it makes sense that it does. I'd wager that data at rest (lots of repos) costs a hell of lot less to run than active requests (lots of users).
Personally my bill will be going down from $25 to $7, and I'm fine with that.
My companies bill will be going down from $650/month to $583/month.
The point we are raising is there is an entire category of companies (agencies / software house) where the price is going up dramatically (5x, 10x or more). This happens because of the choice of billing outside collaborators (even read-only ones).
Lots of collaboraters does not translate to lots of requests. I'd be totally fine being charged by size of data, number of requests,... Number of people that I allow to view my code is a very bad metric for me, especially given that most of those people are already part of a paid account.
> active requests (lots of users).
Also, more users = more problems.
Also, more users = more problems.
Isn't that one of the points of marketing: Highlight issues as a positives to decrease their impact to sales?
ps. No pricing model will suit every org. The current model based on repo numbers has horrid steps which make no sense. eg. 125to300 private repos = $200to$450 cost. So if you need 126 repos you pay more than twice as much for that extra 1 repo. That makes little sense to me.
ps. No pricing model will suit every org. The current model based on repo numbers has horrid steps which make no sense. eg. 125to300 private repos = $200to$450 cost. So if you need 126 repos you pay more than twice as much for that extra 1 repo. That makes little sense to me.
yes, but you are comparing apples to oranges. If you had to jump from 125 to 300 users in ONE step as per the current pricing model instead of paying only for the marginal next user.
Recognizing the repository steps are a pain for customers and not moving towards a pricing per _single_ repository, say between 1$ or 2$ per private repository - is just plain misleading. They could have still thrown in the personal plan with a large number of private repositories and fewer collaborators.
Recognizing the repository steps are a pain for customers and not moving towards a pricing per _single_ repository, say between 1$ or 2$ per private repository - is just plain misleading. They could have still thrown in the personal plan with a large number of private repositories and fewer collaborators.
I'm not directly comparing, only highlighting the step issue.
To me, give a per user or private repo cost. Allow the customer to choose between user or repo model, each addition costs a single fixed unit. Simple!
To me, give a per user or private repo cost. Allow the customer to choose between user or repo model, each addition costs a single fixed unit. Simple!
I'd fire the PR department if they didn't give this a positive spin.
That doesn't mean that customers can't be annoyed being sold for stupid. The release announcement forgets to mention that collaborators are now costly - either a stupid oversight or part of the positive spin.
A good marketing department should display things in a positive fashion, but they should also strive to be honest, so they're not loosing credibility.
A good marketing department should display things in a positive fashion, but they should also strive to be honest, so they're not loosing credibility.
"loosing credibility" is subjective in this case. Some orgs/people will be better off, some won't.
I recall GitHub doing some extensive research on what their customer based wanted. This is most likely the outcome of that research.
If I were to migration our org. over we would be worse off. Even with that I don't think this move is disingenuous. Poorly thought through perhaps?
I recall GitHub doing some extensive research on what their customer based wanted. This is most likely the outcome of that research.
If I were to migration our org. over we would be worse off. Even with that I don't think this move is disingenuous. Poorly thought through perhaps?
> Even with that I don't think this move is disingenuous.
I never said that I consider the move disingenuous. Almost no change will unilaterally benefit everybody. I dislike the communication that reads as if the change is unilaterally beneficial - where it clearly is not.
I never said that I consider the move disingenuous. Almost no change will unilaterally benefit everybody. I dislike the communication that reads as if the change is unilaterally beneficial - where it clearly is not.
I didn't say you did. Well, I don't think I did. Either way, we agree it wasn't disingenuous. I'd also agree this change won't be beneficial to all.
And GitHub is also allowing everyone to make a choice. "...you'll have at least 12 months notice before any mandated change to your plan."
And GitHub is also allowing everyone to make a choice. "...you'll have at least 12 months notice before any mandated change to your plan."
I see it is honest and very positive and supportive
It's not like it's a unilateral "price increase". My bill, for example, will be going down as a result of this. Personally I'm pretty stoked about this change. YMMV.
> GitHub seems cheap to me
At $9/user/mo, github is 900% more expensive than the $1/user/mo direct competitor BitBucket. BitBucket uses brackets rather than pure scaling, but their most expensive option - 101 users require the $200 unlimited accounts plan - is still only $2/user.
At $9/user/mo, github is 900% more expensive than the $1/user/mo direct competitor BitBucket. BitBucket uses brackets rather than pure scaling, but their most expensive option - 101 users require the $200 unlimited accounts plan - is still only $2/user.
If $8 is a big deal per user, how little are you paying the poor bastards?
I guess he's not paying his employees 900% market rate, why would he pay 900% market rate for GitHub instead of BitBucket? Just trying to point that your logic doesn't check out.
I personally like the new pricing, but as a non-paying user of GitHub and BitBucket... I'll stick to BitBucket for my private repos :) I guess they don't give a damn as I'm still not paying either :)
I personally like the new pricing, but as a non-paying user of GitHub and BitBucket... I'll stick to BitBucket for my private repos :) I guess they don't give a damn as I'm still not paying either :)
You believe bitbucket represents the market?
Market (feature set requirements) is different for everybody.
If bitbucket's features are enough for me to migrate off github it's absolutely market. 9 times cheaper at that.
What's so broken in Bitbucket that's not worth at 1/9th the price of Github.com?
[deleted]
I don't know who gives them advice, but that's just horrible.
First, people ran to bitbucket visit if the per repo pricing. Now that that's been fixed, we're faced with high costs per user. That difference can be used to purchase other Atlassian products like Jira and Bamboo.
How can github beat that value? I think github is satisfied with bring #1 for hosting open source software.
First, people ran to bitbucket visit if the per repo pricing. Now that that's been fixed, we're faced with high costs per user. That difference can be used to purchase other Atlassian products like Jira and Bamboo.
How can github beat that value? I think github is satisfied with bring #1 for hosting open source software.
god beware if your open source project needs a single private repository to share passwords between admins for example or private config for your webserver. Suddenly you see yourself at 394$ compared to the 7$ you paid before.
> beware if your open source project needs a single private repository to share passwords
Passwords emphatically do not belong in git.
Your private repos should be maintained such that accessing them would not compromise your security.
Passwords emphatically do not belong in git.
Your private repos should be maintained such that accessing them would not compromise your security.
if you share Ansible inventory files that are encrypted with ansible-vault, then this is not happening. But i still wouldn't want to have a public repository with the files and the metadata of servers that is clearly not meant for public consumption.
Let me brig another example for OSS projects that could need a private repository: branches for security fixes that are not public yet.
Let me brig another example for OSS projects that could need a private repository: branches for security fixes that are not public yet.
> "branches for security fixes that are not public yet"
A private git server would probably be better for that, but also wouldn't cost $0.
A private git server would probably be better for that, but also wouldn't cost $0.
> a single private repository to share passwords between admins
Please tell me you're kidding.
Please tell me you're kidding.
I hope that any team using github to share passwords is driven to move away from that method because of this price change. That's a bad bad idea.
Why? If it is Encrypted in ansible vault or something it's not a terrible way to keep your creds.
I think that wasn't clear initially. But granted, valid point.
If they're encrypted, you can put them in a public repo.
Call it overkill, but I would see no reason not to go both private repo + encrypted creds.
Is ansible vault encryption brute force proof? I have no idea. I could spend an hour and figure out. But why not just follow decent engineering principles and double lock my door?
Is ansible vault encryption brute force proof? I have no idea. I could spend an hour and figure out. But why not just follow decent engineering principles and double lock my door?
What's wrong with using Dropbox or something like that?
Bitbucket seems to be at least in large part a subsidized loss-leader to the rest of the Atlassian infrastructure. And, legit question: how do you feel about Jira?
I don't mind Jira, with the exclusion of the abominably confusing user management[1]. I've never found a ticketing system that didn't suck in some major way; it's a difficult thing to get right.
[1] Somewhere I've got a screenshot I made that has arrows pointing to the four locations in Confluence where you can find different ways of adjusting user perms (jira uses the same user system). This doesn't include the location where you actually manage your Atlassian licenses...
[1] Somewhere I've got a screenshot I made that has arrows pointing to the four locations in Confluence where you can find different ways of adjusting user perms (jira uses the same user system). This doesn't include the location where you actually manage your Atlassian licenses...
It's actually 2500% more expensive for the first 5 users. Github will never learn.
I think for the first five users the price is capped at $25 total ($5/user).
I think you are correct. Boy that is a confusing way to word it on Github's end.
Maybe it's time to charge more for those closed source projects, just saying..
* 800% more expensive
I had no idea about any of the above, but for our team this is awesome. I love that they're doing this because limiting repo's based on price is a serious PITA - it really is the way GH described is which is that every time a user wants a new repo, they have to ask billing/accounting for permission. For us and any company that uses github heavily, which is pretty much everyone in tech, this is awesome!
Works well for me. I have like 10 or 12 private repos for personal projects I'm not ready to release publicly yet (or ever).
I think before it was $5, now it's $7? Three times? Anyway... both below $10, so no problem I see here, young padawan.
It's been $7 for a while. It was $7/month when I cancelled my service back in 2013. I was paying for private repos when I was doing my PhD thesis and once I finished I just kept my local copies and deleted the GitHub version. Now I just use my GitHub for public projects. All my private projects are on GitLab at the moment.
It is sensible pricing model.
[deleted]
40 times as much in our case. But sounds like they aren't forcing it on us right away.
Meanwhile many use BitBucket free private repos for years and are very happy about it.
A small comparison:
Team | Cost Before | Cost Now
1 repo, 5 users | $25 | $25
1 repo, 10 users | $25 | $70
11 repos, 5 users | $50 | $25
11 repos, 10 users | $50 | $70
5 repos, 50 users | $25 | $430
50 repos, 5 users | $100 | $25
50 repos, 50 users | $100 | $430
I'm not sure how common are organizations with few users and large number of repose - I guess software houses that keep old projects (for maintenance and future requests from clients) fall into this category, but who else?
The other case where it becomes cheaper is personal accounts.
In all the other cases - it just looks like a raise of prices.
Team | Cost Before | Cost Now
1 repo, 5 users | $25 | $25
1 repo, 10 users | $25 | $70
11 repos, 5 users | $50 | $25
11 repos, 10 users | $50 | $70
5 repos, 50 users | $25 | $430
50 repos, 5 users | $100 | $25
50 repos, 50 users | $100 | $430
I'm not sure how common are organizations with few users and large number of repose - I guess software houses that keep old projects (for maintenance and future requests from clients) fall into this category, but who else?
The other case where it becomes cheaper is personal accounts.
In all the other cases - it just looks like a raise of prices.
We have a tons of repositories, most are currently on BItbucket, because GitHub was to expensive. Only our largest projects are on GitHub. Our team is maybe 8 developers, depending on consultants, interns and other temporary employments, but we have 20 - 30 repos.
I think for small companies that do all development in-house, having large number of repos, and few developer is a pretty normal.
The way I look at it, GitHub is moving to a model where they assume that the number of employees is more indicative to the amount you can afford to pay, compared to previously where having a large number of repos meant you could pay more.
It will certainly help attract smaller businesses to GitHub.
I think for small companies that do all development in-house, having large number of repos, and few developer is a pretty normal.
The way I look at it, GitHub is moving to a model where they assume that the number of employees is more indicative to the amount you can afford to pay, compared to previously where having a large number of repos meant you could pay more.
It will certainly help attract smaller businesses to GitHub.
Except that now GitHub is 9x more expensive than BitBucket (and for a team under 5 developers, GitHub is $25 vs. BitBucket's $0).
Well, 7x, but yes, GitHub is more expensive. $70 for 10 developers is still really cheap. Personally I prefer the GitHub interface and $60 is still within the range of even smaller companies.
It's a bigger difference, especially as BB is $200 for unlimited users and unlimited repos. For that money, you can get 25 users on GH. 25 users on BB is $25. So on average it is ~8x difference, which then grows beyond 25 collaborators.
Bitbucket is terrible though, so what does it matter?
Respectfully disagree. I find the commit pages and issues pages to be much more clean and informative on bitbucket, in particular the commit pages with the "subway graphs". The closest thing I've found on github is the "Network graph", which is really hard to use (you have to mouse-over each commit dot to see the commit message, etc)
Bitbucket is awesome. Their bug tracker is much better... plus Hipchat for free! Do you seriously spend money on Slack ;)
Slack hasn't had the downtime issues HipChat has had this year.
*yet
Downtime for HC is nothing new. They had the same problems last year which caused me to switch to Slack.
Can you clarify? Why is Bitbucket "terrible"?
He probably means in terms of general usability. This is the reason why I don't use bitbucket at all, and I'm happy to give some money to github in exchange for their service.
Bitbucket's issue tracker is such a pain to work with. I remember being redirected to a new page whenever I had to create a new tag. Then I'd loose the content of the issue I had started to write, something like that.
Bitbucket's issue tracker is such a pain to work with. I remember being redirected to a new page whenever I had to create a new tag. Then I'd loose the content of the issue I had started to write, something like that.
you are doing it wrong. If you want issue management you will buy Jira from the same company which is superior to github. Bitbucket is one tool of many for Atlassian.
Isn't that the problem, though? GitHub has one Issue tracker that is "good enough" for most projects I've worked on, and gets better over time because GitHub dog foods it (even if they don't always see some of the large open projects issues with it). Bitbucket has two Issue trackers, a "sort of useful" minimalist one that is worse than GitHub's and an upsell to Jira which is maximalist overkill for any project I've worked on. Atlassian doesn't have much incentive to make Bitbucket's issue tracker any better than it's current "almost decent" because it wants to upsell Jira. You can pretty much assume that Atlassian only works in Jira themselves.
(Similarly, VS Team Services has only one issue tracker and I'd rather use that than both of Atlassian's offerings, even though it's almost equally maximalist with Jira, mostly because they clearly dog food it and don't try to upsell into it from a worse system that nobody wants to use.)
(Similarly, VS Team Services has only one issue tracker and I'd rather use that than both of Atlassian's offerings, even though it's almost equally maximalist with Jira, mostly because they clearly dog food it and don't try to upsell into it from a worse system that nobody wants to use.)
I've never said I'm a fan of Jira. I also think it is overkill for all the little projects I've been working on. As other mentioned before here: Maybe look into gitlab.com ... they dogfood their project and the bugtracker is pretty good. https://about.gitlab.com/2016/05/11/git-repository-pricing/
I've found github better for open source projects, and bitbucket better for businesses. Github only just recently introduced the idea that one 'deploy key' could be used on more than one repo(!), for example, not to mention that deploy keys had full write access.
User management - more important for a business - is much nicer on BitBucket, and was the specific reason why we shifted. And it will continue to be nicer, until they infect BitBucket with the same user management mess that blights Jira/Confluence. :)
User management - more important for a business - is much nicer on BitBucket, and was the specific reason why we shifted. And it will continue to be nicer, until they infect BitBucket with the same user management mess that blights Jira/Confluence. :)
A lack of search across a repo is pretty annoying.
https://bitbucket.org/site/master/issues/2874/ability-to-sea...
Integration with Jira is nice though.
https://bitbucket.org/site/master/issues/2874/ability-to-sea...
Integration with Jira is nice though.
Dunno, we've had downtime every month for months.
Its slow as heck.
The UI is clunky.
The 'projects' made it hard to find anything and broke bookmarks.
... but the downtime is the killer. Last week was the last one.
Its slow as heck.
The UI is clunky.
The 'projects' made it hard to find anything and broke bookmarks.
... but the downtime is the killer. Last week was the last one.
page load time is the big killer for me
Bitbucket is ok for private repos. I think private repos are relatively secure there because Atlassian has much of reputation to loose if there is a security breach. Another plus for Bitbucket is the integration with Jira and other Atlassians tools.
Beside that plus points I will rather go to GitLab.com (more features, better UI and integration with 3rd party) but my trust in private repos is lower there than on Bitbucket. I wished we could measure security somehow for private repos between Bitbucket, GitHub and Gitlab.com
How could we convince you that at GitLab we take security very seriously?
Make a dedicated site on gitlab.com about security (make it bold) and about private repos. Some buzzwords: Countermeasures, security tracking, rate limiting, DDoS attacks, Backups... what do you do to ensure security, privacy or that nothing is lost? It's a littlebit in the dark. I would love to see comparisons between gitlab, bitbucket and github if possible (but I'm guessing that's not easy) or I would love to see somehow you take that extremely seriously for gitlab.com. I only have this gut feeling (I cannot exactly say why) that bitbucket and github feel more secure for private repos than gitlab because their business is dependent on security of hosting private repos. On gitlab.com the hosted private repos are a bonus and not the business of gitlab (because the real business is selling gitlab enterprise software and their support).
Just ask yourself and imagine this: You have a new start up company based on very valuable closed source but you entirely do not want to host my own gitlab etc. server. Which service would you use? I'm guessing it is bitbucket or github because they are offering "premium" private repos and have a good reputation (at least I do not know that a private repo there was once disclosed).
Just ask yourself and imagine this: You have a new start up company based on very valuable closed source but you entirely do not want to host my own gitlab etc. server. Which service would you use? I'm guessing it is bitbucket or github because they are offering "premium" private repos and have a good reputation (at least I do not know that a private repo there was once disclosed).
Thanks for your input. I've added more security information on our website https://gitlab.com/gitlab-com/www-gitlab-com/commit/bb7deced...
We try to achieve a good reputation by taking security seriously every day and being responsive to disclosures.
We try to achieve a good reputation by taking security seriously every day and being responsive to disclosures.
Creating a Security page on the site to explain your infosec policies would go a long way. I like that we're able to view previous disclosures [1] and active security issues [2], but I had to dig a bit to find them. Surface those.
[1] https://about.gitlab.com/vulnerability-acknowledgements/
[2] https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B...
[1] https://about.gitlab.com/vulnerability-acknowledgements/
[2] https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B...
Sorry for the late reply, we've been busy releasing https://about.gitlab.com/2016/05/11/git-repository-pricing/
Anyway, I've added most information to https://about.gitlab.com/disclosure/ with https://gitlab.com/gitlab-com/www-gitlab-com/commit/eab7e345...
That page is linked from https://about.gitlab.com/contact/
Anyway, I've added most information to https://about.gitlab.com/disclosure/ with https://gitlab.com/gitlab-com/www-gitlab-com/commit/eab7e345...
That page is linked from https://about.gitlab.com/contact/
Awesome, thanks for the quick response.
All those sites are secure. Actually, between the three, GitHub has had the most vulnerabilities reported, like that one time someone got administration privileges over the entire website... yet people still trust them somehow.
If you're working on government contracted stuff or something like that, where you need perfect and utter secrecy, you could self-host a GitLab instance. Which is $0, compared to GitHub Enterprise.
If you're working on government contracted stuff or something like that, where you need perfect and utter secrecy, you could self-host a GitLab instance. Which is $0, compared to GitHub Enterprise.
Really? I guess entire Atlassian suite is awesome. Bitbucket for SCM, Jira, Wiki and all that make it a perfect combo.
But oh so expensive. If you're already paying for Jira and maybe Confluence, the new pricing model for GitHub shouldn't be much of a problem.
Jira, HipChat and Confluence are really nice tools, but pricing seems to just snowball.
Jira, HipChat and Confluence are really nice tools, but pricing seems to just snowball.
Even for software houses, it's VERY problematic as we add customers to projects as external collaborators and we're going to get billed for that forever, even if most customers have very light usage, and even for non active projects.
I was thrilled by this news but it's going to be completely unaffordable for us. We have 29 users and 51 external collaborators. We have recently upgraded to the Platinum plan ($2460/yr), but switching to the new user plan would raise the bill beyond affordable for us ($8k+ per year).
I think it is a big mistake to bill for external collaborators, it completely screws software houses that need this model to use GitHub.
I was thrilled by this news but it's going to be completely unaffordable for us. We have 29 users and 51 external collaborators. We have recently upgraded to the Platinum plan ($2460/yr), but switching to the new user plan would raise the bill beyond affordable for us ($8k+ per year).
I think it is a big mistake to bill for external collaborators, it completely screws software houses that need this model to use GitHub.
I keep my eye on Microsoft's Visual Studio Team Services. It has a bit of a clunky name and aimed more at enterprises but I think at some point they will position it as a competitor to GitHub. It's free for the first five developers, and no charge for "stakeholder" user accounts.
https://www.visualstudio.com/pricing/visual-studio-team-serv...
So 29 users would be $182/m (check my maths) and you'd pay nothing for the external collaborators (assuming they fit the "stakeholder" role ... no need access to the code).
https://www.visualstudio.com/pricing/visual-studio-team-serv...
So 29 users would be $182/m (check my maths) and you'd pay nothing for the external collaborators (assuming they fit the "stakeholder" role ... no need access to the code).
If you no longer want/need the social aspects of GitHub, you can just move to GitLab. Much more affordable and you can self host it yourself. We have an on premise GitLab installation. Besides the rare upgrade, it's pretty hands off. And it's costing us $0 in licensing fees for over 60 users ;-)
We self-host GitLab as well for ~20 users and are very happy with it.
We install every incremental update, which GitLab publishes very frequently -- weekly or several times a month. They are always seamless. The GitLab team is working so hard.
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELO...
We install every incremental update, which GitLab publishes very frequently -- weekly or several times a month. They are always seamless. The GitLab team is working so hard.
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELO...
Thanks tedmiston!
I started using gitlab.com for that reason, but I will not stay there because it is too slow, to the point it is very annoying.
I'm sorry GitLab.com is slow, we're working to improve the speed in https://gitlab.com/gitlab-com/operations/issues/42 and https://gitlab.com/gitlab-com/operations/issues/1
alternative, written in go and using way less moving components and resources is https://gogs.io It's lighter but also lighter in features than Gitlab.
I looked at GitLab, it seems to come off second best in terms of features [1].
[1] https://www.visualstudio.com/get-started/overview-of-get-sta...
Hard to argue with free though, if that's what you're looking for.
[1] https://www.visualstudio.com/get-started/overview-of-get-sta...
Hard to argue with free though, if that's what you're looking for.
I've always found VSTS to be at the same time expensive, bloated and missing essential functionality. I think the mentality of .NET / Microsoft developers is strange. By following Microsoft's lead, wherever that may take you, you're missing out and you don't even know what :-P
I'm a PM on VSTS. If you're willing to share what we're missing and what's bloated, I'd love to hear it. [email protected] or a reply here would be much appreciated. Thanks!
What features are you missing in GitLab?
> Besides the rare upgrade, it's pretty hands off
rare upgrade? They release every 4 weeks and often the update is absolutely mandatory due to various RCE vulnerabilities. Github would need to become much more expensive before it would be cheaper to use in-house gitlab.
rare upgrade? They release every 4 weeks and often the update is absolutely mandatory due to various RCE vulnerabilities. Github would need to become much more expensive before it would be cheaper to use in-house gitlab.
Any company that has a sysadmin should simply host their own GitLab.
Company I work at uses VSTS and we're happy with it. It's actually a much larger product than just code hosting, as it also includes loads of other things like Agile Planning tools, Build system (which is now much simpler than the crazy old TFS XAML based TeamBuild. Although you only get an allocation of build "minutes" every month) and Release Management (OctopusDeploy style system). You can do cool things around PRs, like enforcing that certain users, or groups of users must approve to be mergable, or that a certain build off that branch must succeed to be mergeable. All this stuff is possibe obviously in GitHub, it's just a bit more integrated. Worth checking out
Yes, your math is correct, verified with their pricing calculator https://azure.microsoft.com/en-us/pricing/calculator/?servic...
Thank you for posting this!
Thank you for posting this!
It feels to me like there needs to be a distinction between users and developers now they've changed their pricing model, with developers getting full git access, and users getting read-only source viewing through a browser, issues, and wikis. That way agencies can add customers for collaboration without having thousands of users to pay for.
great idea
we're in the same situation. I'm looking at at least a tenfold increase. All of a sudden self hosting a gitlab instance looks cost-efficient.
At those price points you don't have a sales rep and individual pricing?
Would billing your customers for Github access be a solution?
>I guess software houses that keep old projects (for maintenance and future requests from clients) fall into this category, but who else?
Companies using micro services? Companies that don't want to have one big repository for their software?
Companies using micro services? Companies that don't want to have one big repository for their software?
What made our small team choose BitBucket over GitHub was the consideration that having to pay for # repositories would force us (and about everyone) to organise code not based on development convenience, but on $ convenience, which means put everything in a few very big and messy repositories.
Good point. Also, before having 1 repository was a way to avoid higher bill. Now it'd require to have just 1 user which I doubt anyone will try to do.
Then again with git this isn't so much of a problem, if you aren't wanting to play the blame game this works quite well.
It's possible that people have started realizing the advantages of monolithic version control [0] which prompted Github.
Team | Cost Before | Cost Now
1 repo, 100 users | $25 | $880
[0] http://danluu.com/monorepo/
Team | Cost Before | Cost Now
1 repo, 100 users | $25 | $880
[0] http://danluu.com/monorepo/
I think this price increase is OK. You'd be hard pressed to find any enterprise product that would only charge you $25/mo for 100 users.
I'm not sure how common are organizations with few users and large number of repos
My feeling is that this is VERY common. Most of the software companies I've worked for had between 5-25 people, max, who would need github access. But if you break things up in a granular fashion repo-wise, you can easily have dozens or more repos.
In my own case, we only have about 5 people who need access, but we're already sitting on a bunch of repos and will be needing more soon'ish. I was just debating about if/when to upgrade to the next plan level w/ github, and now I don't have to.
Obviously different companies have different scenarios, but this is a win for us, and I expect it's a win for a lot of other organizations as well.
My feeling is that this is VERY common. Most of the software companies I've worked for had between 5-25 people, max, who would need github access. But if you break things up in a granular fashion repo-wise, you can easily have dozens or more repos.
In my own case, we only have about 5 people who need access, but we're already sitting on a bunch of repos and will be needing more soon'ish. I was just debating about if/when to upgrade to the next plan level w/ github, and now I don't have to.
Obviously different companies have different scenarios, but this is a win for us, and I expect it's a win for a lot of other organizations as well.
I'm a nodejs developer. I use its package manager `npm` on a daily basis. `nodejs` packaging philosophy enforces you to break every lib into smaller modules in order to have small, consistent, easy to reason about, modules. While being a great philosophy, it requires developers to maintain many projects, thus owning many github repositories (often private when working for clients).
This is a great news for me.
This is a great news for me.
We have about 300+ users and 100+ repos. We moved to Bitbucket because it would be too expensive to keep using Github. Looks like the pricing change would make it even more expensive for us.
I personally also use Gitlab for private side project repos and only use Github now for open source projects.
I personally also use Gitlab for private side project repos and only use Github now for open source projects.
That kind of thing is quite common in small agency environments, where you might have a bunch of different clients on support contracts paying for x hours a month of time.
With that being said, in those types of environments, cost is everything, and BitBucket is still the cheaper option.
With that being said, in those types of environments, cost is everything, and BitBucket is still the cheaper option.
We're at 394 repos and 13 active users (with 32 disabled users) on our self-hosted GitLab install. All repos are private as well. We're a software agency that usually has 15-20 different projects being actively developed. It adds up quick
For a 50 person group, $430 is peanuts, it's just peanuts.
I'm sorry, I just don't feel for these people, this is getting upset about the $0.10 charge for butter when you paid $10.00 for the popcorn.
I'm sorry, I just don't feel for these people, this is getting upset about the $0.10 charge for butter when you paid $10.00 for the popcorn.
Any company with 5-10 users, has at least 5-10 repos if they're structuring things properly. That said, I prefer self-hosted GitLab (free) when there are a large number of repos.
The last few places that I worked at only had one big repository hosting all of the projects. They weren't using Git though, SVN and Perforce.
In some ways I can see the ability to have fewer users and more repositories suited towards consultancies (specifically web development). Where there are a lot of projects and customers.
In some ways I can see the ability to have fewer users and more repositories suited towards consultancies (specifically web development). Where there are a lot of projects and customers.
Yeah, I worked at a company that used one big repository for all their software. It wasn't to save money (they were spending quite a lot of money on other tools), but it was just more comfortable for them - in terms of code management, deployment etc. But still, with the old Github pricing, they were paying just a few bucks for a team of 10 people, so in this case getting paid per user makes much more sense.
At my workplace we have 1/5 ratio of users to repositories on our git server. We tend to create separate repositories for modules, applications and even prototypes. In any case if we were to use Github their new pay-per-user model would make more sense for us than the pay-per-repository model.
At work we have a bitbucket server with 6 users and 25 repositories. We recently switched to bitbucket server a few months ago. I'm sure we will get more repositories in the future. Some of the repositories are just a small collection of scripts while others are fairly big software projects.
Are you working on projects for clients or on your own product?
Also, maybe I'm mistaken and this change actually makes sense. Until now I had a one repo called `utils` and we kept random scripts there. Now there won't be any cost for adding new repository, so it might happen we'll start splitting that one.
Also, maybe I'm mistaken and this change actually makes sense. Until now I had a one repo called `utils` and we kept random scripts there. Now there won't be any cost for adding new repository, so it might happen we'll start splitting that one.
> I'm not sure how common are organizations with few users and large number of repose - I guess software houses that keep old projects (for maintenance and future requests from clients) fall into this category, but who else?
Any startup architected around microservices, for one
Any startup architected around microservices, for one
But to me this makes sense - one naturally will have more repos than developers, and as it is costly to add a developer to your team, but adding a repo is a command line, then making cost a function of developers seems to align most software teams with githubs incentives.
Right - and the total cost of a developer is far more than $9/month.
The real place where it hurts is users who aren't paid employees.
The real place where it hurts is users who aren't paid employees.
Put me on that list: small business doing lots of very small projects. I just upgraded my gh account to the next tier a few months ago and now it looks like my bill will be going back down.
At Gilt we had a ratio of ~10 repos per engineer. #microservices.
At least in our case the new pricing would be couple % below what we used to pay under the per-repo pricing scheme. And about 30% less if we merge our two organizations.
We have a few users and a large number of repos - small team of developers supporting research projects in a university department.
BitBucket is free if you have an academic email address
https://bitbucket.org/product/pricing
wow... our bill will be 8x.... $xxx to $6xxx
The incentive changes for this are so massive, nice "experiment" from an economics perspective.
1. penalizes OpenSource organizations that need a few private repos for password, server configuration or other things. Was 25$ before, now for example Doctrine with 48 collaborators it would be 394$. Even if just the admins have access to that repository.
2. penalizes collaboration, inviting every non-technical person in the company? 2-5 employees of the customer? not really. Will lead organizations to create a single "non-technical" user that everyone can use to comment on stuff. not to mention bots, especially since you need users for servers in more complex deployment scenarios.
3. rewards having many repos, small throw away stuff and generally will lead to "messy" repositories lying around everywhere that are committed on once or twice and never touched again. "Not having to think about another private repository", imho will produce technical debt for organizations.
4. users in many private orgs will need to pay or get paid for every organization each. I myself will be worth 45$ now for Github, being in private repositories of five different companies.
All in all, this just shows that Github does not care as much about open source anymore as it cares about Enterprise.
Btw: Mentioning the price jumps in repository usage of the old pricing is not really helpful. Consider a pricing that would be per repository (1$ for personal, 2$ for organizations) and doesnt have jumps and compare that to the new per using pricing. The new pricing only feels better for some, because you pay marginal costs for every single user instead of the old pricing where every 50 repositories you have to suddenly pay 100$ extra.
Edit: Forgot about bots, and deployment machine users (which even Github recommends for many scenarios)
1. penalizes OpenSource organizations that need a few private repos for password, server configuration or other things. Was 25$ before, now for example Doctrine with 48 collaborators it would be 394$. Even if just the admins have access to that repository.
2. penalizes collaboration, inviting every non-technical person in the company? 2-5 employees of the customer? not really. Will lead organizations to create a single "non-technical" user that everyone can use to comment on stuff. not to mention bots, especially since you need users for servers in more complex deployment scenarios.
3. rewards having many repos, small throw away stuff and generally will lead to "messy" repositories lying around everywhere that are committed on once or twice and never touched again. "Not having to think about another private repository", imho will produce technical debt for organizations.
4. users in many private orgs will need to pay or get paid for every organization each. I myself will be worth 45$ now for Github, being in private repositories of five different companies.
All in all, this just shows that Github does not care as much about open source anymore as it cares about Enterprise.
Btw: Mentioning the price jumps in repository usage of the old pricing is not really helpful. Consider a pricing that would be per repository (1$ for personal, 2$ for organizations) and doesnt have jumps and compare that to the new per using pricing. The new pricing only feels better for some, because you pay marginal costs for every single user instead of the old pricing where every 50 repositories you have to suddenly pay 100$ extra.
Edit: Forgot about bots, and deployment machine users (which even Github recommends for many scenarios)
Yup, #2 would hits us very hard. We have just over 40 people split between two organizations; everyone has access to Github and all have been trained to use it. Only about half are developers; are a lot of rules in a simple DSL that business analysts maintain and designer need to be able to update art and that's not even counting the bots. We have about as many Github users as repos -- we archive anything that's out of date to long term storage. If we are forced to switch to the new pricing model Github will likely lose us as a customer. The new model is just insanely expensive. The main reason we choose Github was the ability to have everyone use it. Feels like an outright cash grab honestly, especially with #4.
Your #1 isn't correct. Collaborators don't count as a seat if they don't have access to a private repo.
> These users do not fill a seat: Outside collaborators with access to only public repositories
https://github.com/blog/2164-introducing-unlimited-private-r...
> These users do not fill a seat: Outside collaborators with access to only public repositories
https://github.com/blog/2164-introducing-unlimited-private-r...
What about companies like Epic Games that have few repos but many users?
With their 2 private UnrealEngine and UnrealTournament repos they would have been paying $25 a month and under the new pricing structure will have to pay $815,913 per month...
edit: That's based on what I can see as a UE4 subscriber, 2 private repos and 90657 users.
With their 2 private UnrealEngine and UnrealTournament repos they would have been paying $25 a month and under the new pricing structure will have to pay $815,913 per month...
edit: That's based on what I can see as a UE4 subscriber, 2 private repos and 90657 users.
We are a small shop that has 4 repositories and 36 users (over half the company). About 10 of those users actually contribute code, the others are monitoring issues, pulling code just to run tests or create distributions, or bots.
If we accidentally hit the upgrade button (we won't), our cost would go from 300/year to 3,648/year. Since only a small number of projects are on github - we use TFS for our main project and github for tools - its just a non-starter.
Heck, 5 "bot accounts" is $540/year to support CI builds and slack notifications. Yikes! More than we pay now.
It seems like the only shop that would save money would be the little in-house development departments with 5 people and tons of projects. However, even there they would probably forego using issues tracking in github because of the extra user cost.
I would be very interested to see real stats on how many orgs actually "upgrade" to this new more expensive pricing model vs how many stay with the more sane model. The real losers are orgs that can't sign up under the old model. The real winners will be the github alternatives (gitlab, bitbucket, etc) that can use this as an opportunity to grow user base.
If we accidentally hit the upgrade button (we won't), our cost would go from 300/year to 3,648/year. Since only a small number of projects are on github - we use TFS for our main project and github for tools - its just a non-starter.
Heck, 5 "bot accounts" is $540/year to support CI builds and slack notifications. Yikes! More than we pay now.
It seems like the only shop that would save money would be the little in-house development departments with 5 people and tons of projects. However, even there they would probably forego using issues tracking in github because of the extra user cost.
I would be very interested to see real stats on how many orgs actually "upgrade" to this new more expensive pricing model vs how many stay with the more sane model. The real losers are orgs that can't sign up under the old model. The real winners will be the github alternatives (gitlab, bitbucket, etc) that can use this as an opportunity to grow user base.
Hopefully, GitHub can adopt a similar "non-human user" account concept as Slack has. They are free to add and don't log into the normal applications.
Of course, do you really need full accounts for those purposes? Their APIs are really extensive and should give you access to set up things like CI and notifications.
Of course, do you really need full accounts for those purposes? Their APIs are really extensive and should give you access to set up things like CI and notifications.
We are reaching out to customers that are in unique situations such as the one you're mentioning here. If you have questions about how the pricing changes affect you, please don’t hesitate to contact [email protected].
If you need to give Epic Games special treatment just because they have a huge amount of outside collaborators, then your pricing model is broken.
It would be more fair to charge $9/mo per organization member + $1/mo per active outside collaborator (somewhat similar to AWS CodeCommit) than to charge for every single active and inactive member and collaborator equally. Maybe throw in a 50% bulk discount for active outside collaborators over 1000.
This is not a "unique situation", it's how many organizations use GitHub (just on a smaller scale than Epic Games). As giovannibajo1 puts it[1], this change is very unfair to software houses. Giving Epic Games special treatment is only avoiding the issue.
If 5% of Epic Game's 90664 collaborators are active for a given month, then with my proposed pricing model it would now cost them ($9/organization member + ~$2766)/mo, instead of >$800k/mo. No special deals needed, and everyone (presumably) is happy.
This proposed pricing model also scales well for software houses that have have many active outside collaborators. For example, a company with 20 employees and 50% of 100 outside collaborators active in any given month would be charged $230/mo. With 50 employees and 50% of 500 outside collaborators active, it would be $700/mo.
This should also work well for large companies. 200 employees + 30% of 4000 outside contributors active = $2900/mo.
[1]: https://news.ycombinator.com/item?id=11673352
It would be more fair to charge $9/mo per organization member + $1/mo per active outside collaborator (somewhat similar to AWS CodeCommit) than to charge for every single active and inactive member and collaborator equally. Maybe throw in a 50% bulk discount for active outside collaborators over 1000.
This is not a "unique situation", it's how many organizations use GitHub (just on a smaller scale than Epic Games). As giovannibajo1 puts it[1], this change is very unfair to software houses. Giving Epic Games special treatment is only avoiding the issue.
If 5% of Epic Game's 90664 collaborators are active for a given month, then with my proposed pricing model it would now cost them ($9/organization member + ~$2766)/mo, instead of >$800k/mo. No special deals needed, and everyone (presumably) is happy.
This proposed pricing model also scales well for software houses that have have many active outside collaborators. For example, a company with 20 employees and 50% of 100 outside collaborators active in any given month would be charged $230/mo. With 50 employees and 50% of 500 outside collaborators active, it would be $700/mo.
This should also work well for large companies. 200 employees + 30% of 4000 outside contributors active = $2900/mo.
[1]: https://news.ycombinator.com/item?id=11673352
Business are free to close deals with clients in their own terms whenever is lucrative for them. Almost every single company will have "unfair" treatment for big corporations... That way they can get big paying clients. clients that could possibly host their own solutions... It might be that Epic Games in the old business model, with so many users, was not profitable for github, but they are open to negotiate a middle term. It's just business. It is fair.
I think github is on their own right and if you have a case where you think you would be able to negotiate with them, you can send them an email as well... If not, go search another company that have a better cost/benefit for your use case.
I think github is on their own right and if you have a case where you think you would be able to negotiate with them, you can send them an email as well... If not, go search another company that have a better cost/benefit for your use case.
Special deals can be made for special cases, it happens all the time. We have a service related business with official pricing, but always bend over backwards when we want to retain long term customers or big paying customers by giving them price cuts and other concessions that we wouldn't normally do to any of our other regular clients.
Not sure why the topic of fairness even comes to the discussion, this is a business not a charity.
Not sure why the topic of fairness even comes to the discussion, this is a business not a charity.
> If you need to give Epic Games special treatment just because they have a huge amount of outside collaborators, then your pricing model is broken.
This is an unfair thing to say. Exceptions to otherwise simple rules does not at all mean that the simple rules are "broken".
It is also an unfair thing to say since he clearly says that not only is Epic Games getting this treatment, so is everyone in a similar situation. Furthermore, it has always been possible to negotiate special pricing for special cases. Just send them a message. That is how sales works at almost every company.
This is an unfair thing to say. Exceptions to otherwise simple rules does not at all mean that the simple rules are "broken".
It is also an unfair thing to say since he clearly says that not only is Epic Games getting this treatment, so is everyone in a similar situation. Furthermore, it has always been possible to negotiate special pricing for special cases. Just send them a message. That is how sales works at almost every company.
Do you understand how businesses work? Almost every company I work for has different terms for lots of customers. They negotiate a deal with a customer, and sign a contract. Every customer might pay different amounts.
That is just how business-to-business deals work.
That is just how business-to-business deals work.
Ho but they can give to consultancies too
The new plan doesn't fit wide organizations at all. With 300+ users we are looking at $30000 pr year for 70 repositories..
We get the freedom to create more repositories for the price of having to actively kick any inactive user out to save cost.
PS: Please make it like Slack. Don't pay for inactive users that doesn't commit anything that month.
We get the freedom to create more repositories for the price of having to actively kick any inactive user out to save cost.
PS: Please make it like Slack. Don't pay for inactive users that doesn't commit anything that month.
So what you're saying is - you know your new pricing is even more ridiculous than your old pricing, but you're willing to burn a little profit to keep big-name clients for the sake of PR.
Gotcha.
Gotcha.
If I understand this model correctly you fail to admit that there are at least 3 distinct types of users: developers (full access), users (read-only), issue trackers (wiki/issues only). And this model is geared toward a very specific type of organization with a relatively low number of users/trackers compared to developers.
Epic's example is just silly, but nevertheless the world is not black and white. I guess there should be a large number of organizations with multiple CI/CD agents each using distinct credentials for each target. Or examples of software houses requiring client access to issue tracker/wiki.
I guess GitHub analysed their data and made the best decision, but this really does not seem geared toward Enterprise in traditional sense of the word.
Some $vendors (just using familiar terms here) somewhat cover the gray areas pricing $x per unit, where unit is e.g. 2 users or 5 repos, whichever is higher.
Epic's example is just silly, but nevertheless the world is not black and white. I guess there should be a large number of organizations with multiple CI/CD agents each using distinct credentials for each target. Or examples of software houses requiring client access to issue tracker/wiki.
I guess GitHub analysed their data and made the best decision, but this really does not seem geared toward Enterprise in traditional sense of the word.
Some $vendors (just using familiar terms here) somewhat cover the gray areas pricing $x per unit, where unit is e.g. 2 users or 5 repos, whichever is higher.
It is interesting that - this change will force organizations to pay for "bot" users - that exist for deployment/notifications etc. Our payment bill just doubled from $50 to $106 now (including the bot accounts).
What about organizations that have many members, but few that actually contribute code? We have accounts for most of the people at our company so they can view issues and pull requests, but only about a dozen ever push code.
Epic Games could just move to BitBucket, where you get Unlimited Users for $200/mo.
I find it interesting that so many people here are unhappy with the change. Sure, prices will go up for a lot of organizations, but is $9/worker/month really a lot to pay for all the stuff GitHub offers? At Bay Area prices isn't that about 5 minutes of developer pay per month?
For independent use it seems like a very positive change, in fact I'm guessing it's a direct challenge to GitLab. I was considering moving my stuff to GitLab simply because I'm tired of bundling experiments/prototypes into umbrella repos just to stay under the 10 repo limit at GitHub. For people like me this will be awesome, and I take it as a good sign that they're responding to the competition.
One thing I don't get however: how do they count shared access to private repos?
If I have a private repo and you have a private repo, and we each grant access to the other's repo so we can collaborate, do we now have two or four billing units?
They say "you can even invite a few collaborators" -- but how are you billed if it's more than a "few?"
I don't mind if they try to close the loophole of making up an "organization" out of a lot of "individual developers" but it seems a little vague.
For independent use it seems like a very positive change, in fact I'm guessing it's a direct challenge to GitLab. I was considering moving my stuff to GitLab simply because I'm tired of bundling experiments/prototypes into umbrella repos just to stay under the 10 repo limit at GitHub. For people like me this will be awesome, and I take it as a good sign that they're responding to the competition.
One thing I don't get however: how do they count shared access to private repos?
If I have a private repo and you have a private repo, and we each grant access to the other's repo so we can collaborate, do we now have two or four billing units?
They say "you can even invite a few collaborators" -- but how are you billed if it's more than a "few?"
I don't mind if they try to close the loophole of making up an "organization" out of a lot of "individual developers" but it seems a little vague.
> At Bay Area prices isn't that about 5 minutes of developer pay per month?
I work for an academic nonprofit. Asking to spend any money is like pulling teeth, and any purchase I make has to go through many layers of bureaucracy who don't understand or care what I do and have no incentive to make my life easier. I don't want to leave Github, but now I have to, because I just won't get the approval to spend hundreds a year. But I know that's nothing to Bay Area companies, so the rest of us will just go kick rocks or something.
I work for an academic nonprofit. Asking to spend any money is like pulling teeth, and any purchase I make has to go through many layers of bureaucracy who don't understand or care what I do and have no incentive to make my life easier. I don't want to leave Github, but now I have to, because I just won't get the approval to spend hundreds a year. But I know that's nothing to Bay Area companies, so the rest of us will just go kick rocks or something.
> I don't want to leave Github, but now I have to, because I just won't get the approval to spend ~100's a month.
No you don't have to leave GitHub now. GitHub isn't forcing existing customers onto the new pricing, and it says in the post that if that changes at least 12 months notice will be given.
No you don't have to leave GitHub now. GitHub isn't forcing existing customers onto the new pricing, and it says in the post that if that changes at least 12 months notice will be given.
What announcement are you reading? It states very clearly that this is the new pricing model, period.
Yes, existing customers have a 12-month grace period before they're impacted by a price change... but that clock just started ticking. There isn't an indefinite opt-out for this model change.
Yes, existing customers have a 12-month grace period before they're impacted by a price change... but that clock just started ticking. There isn't an indefinite opt-out for this model change.
I'm looking at this one [0]. Specifically this item in the FAQ:
> Will GitHub force me to move to per-user pricing after 12 months?
> No. At this time we are not enforcing a timeline to move and if in the future we do decide to set a timeline we are committing to giving you at least 12 months.
[0] https://github.com/blog/2164-introducing-unlimited-private-r...
> Will GitHub force me to move to per-user pricing after 12 months?
> No. At this time we are not enforcing a timeline to move and if in the future we do decide to set a timeline we are committing to giving you at least 12 months.
[0] https://github.com/blog/2164-introducing-unlimited-private-r...
> Yes, existing customers have a 12-month grace period before they're impacted by a price change... but that clock just started ticking
"Will GitHub force me to move to per-user pricing after 12 months?
No. At this time we are not enforcing a timeline to move and if in the future we do decide to set a timeline we are committing to giving you at least 12 months."
So you have an indefinite period of time + 12 months, not a hard 12 months starting now.
"Will GitHub force me to move to per-user pricing after 12 months?
No. At this time we are not enforcing a timeline to move and if in the future we do decide to set a timeline we are committing to giving you at least 12 months."
So you have an indefinite period of time + 12 months, not a hard 12 months starting now.
Are you guys going through the nonprofit or the academics pricing?
Their nonprofit accounts are designed for "nonacademic" orgs. If there's an account type that's applicable to university research (not just students) then I'd be thrilled.
Check the bottom of this page [0] and prepare to be thrilled.
[0] https://education.github.com/
[0] https://education.github.com/
This is only for the teaching/student aspect of academia. There's the whole business side of academia which is still a non-profit, still doesn't have any money, but for which the academic stuff doesn't apply.
Very well-put.
Furthermore, Github's "Education" site doesn't actually say _what_ the acadmic pricing plans are like, just that you can "ask for a discount".
Furthermore, Github's "Education" site doesn't actually say _what_ the acadmic pricing plans are like, just that you can "ask for a discount".
They gave us free private repos for our organization when we were an academic research team building robots. It doesn't hurt to try.
>At Bay Area prices isn't that about 5 minutes of developer pay per month?
Do you seriously believe that programmers everywhere in the world are making the same money as ones at Bay Area?
Do you seriously believe that programmers everywhere in the world are making the same money as ones at Bay Area?
No. I myself do not. But it seemed like a relevant metric on this forum.
> but is $9/worker/month really a lot to pay for all the stuff GitHub offers?
You make it sound like they're curing cancer. What does GitHub really offer above and beyond the other providers?
As an example, their PR reviewing systems sucks balls. It chokes on larger PRs (250 files!? Really?). Also, with files which have been essentially replaced, the diff can become so large that GitHub won't even show it, and since you can only add comments on PRs, you're sunk. I have to resort to sending around emails with code lines and comments on them.
GitHub is amateur hour. Their half-assed implementations of almost every piece of their functionality reminds me of the same BS Apple does on iOS.
You make it sound like they're curing cancer. What does GitHub really offer above and beyond the other providers?
As an example, their PR reviewing systems sucks balls. It chokes on larger PRs (250 files!? Really?). Also, with files which have been essentially replaced, the diff can become so large that GitHub won't even show it, and since you can only add comments on PRs, you're sunk. I have to resort to sending around emails with code lines and comments on them.
GitHub is amateur hour. Their half-assed implementations of almost every piece of their functionality reminds me of the same BS Apple does on iOS.
I'd definitely pay more than $9 for a cure to cancer.
But since I also make my living writing software, I don't think it's wrong to charge a fair price for it.
If you think they're doing such a bad job, you can always use the competition. As with iOS.
But since I also make my living writing software, I don't think it's wrong to charge a fair price for it.
If you think they're doing such a bad job, you can always use the competition. As with iOS.
Curious what you think of GitLab and Bitbucket?
> If I have a private repo and you have a private repo, and we each grant access to the other's repo so we can collaborate, do we now have two or four billing units?
4. Each of you has 2. One for yourself and one for the collaborator. Which answers the question of why some people are unhappy with the change: it punishes organizations that collaborate a lot.
4. Each of you has 2. One for yourself and one for the collaborator. Which answers the question of why some people are unhappy with the change: it punishes organizations that collaborate a lot.
[deleted]
Out of morbid curiosity I switched ones of my orgs over to the new billing scheme. I have 4 users in the org team, and 1 external contributor (a client who has access). I am being billed for 5 seats.
So yes, if you invite external contributors to a single repo (Say a consultant with clients). You will pay for each and every account you invite. Gitlab it is!
So yes, if you invite external contributors to a single repo (Say a consultant with clients). You will pay for each and every account you invite. Gitlab it is!
From what I read, as long as you don't mind giving your collaborators full access, you can have as many as you want on your private repo. If you want to grant limited access (say, read but not write), then you have to use an org.
But you do know that it's not bay area only right? Millions of people outside US use it and the price difference is a lot to bear for some of them.
Yes, of course. I'm in Europe myself. However if you're a company trying to make money I see $9/mo as a fair price for what GitHub offers, pretty much anywhere.
And if it's really a lot of money then there is plenty of free software that can solve the same set of problems, you just have to install/configure/maintain/modify it yourself. Which should be a reasonable option if $9/person/month is a lot of money where you are.
(I get that for some people obtaining the $9 is difficult because they work for highly dysfunctional organizations, but that still doesn't make it an unreasonable fee.)
And if it's really a lot of money then there is plenty of free software that can solve the same set of problems, you just have to install/configure/maintain/modify it yourself. Which should be a reasonable option if $9/person/month is a lot of money where you are.
(I get that for some people obtaining the $9 is difficult because they work for highly dysfunctional organizations, but that still doesn't make it an unreasonable fee.)
That's cool but seeing as Bitbucket has unlimited private repos for everyone, I'll be sticking with Bitbucket for private trash and Github for public trash.
What's with all the negativity? This is really good pricing - all individuals now pay much less (a flat rate of $7), all small shops pay almost the same thing ($30 to $90 for 3 to 10 people). Both groups no longer need to think twice about creating repos, which has always been a huge pain that I've seen. I've even thought twice about microservices because the repo cost would be a pain.
This will affect enterprises - but then they're either already on Github Enterprise or are used to per user pricing anyway. Google Apps, Slack etc all have (quantitavely similar) per user pricing. Google doesn't charge you based on the number of emails you send, nor does Slack charge based on the number of private rooms there are - that would be dumb.
The band of companies between small shops and enterprises are likely to be affected, but then this is really employee lunch money.
This will affect enterprises - but then they're either already on Github Enterprise or are used to per user pricing anyway. Google Apps, Slack etc all have (quantitavely similar) per user pricing. Google doesn't charge you based on the number of emails you send, nor does Slack charge based on the number of private rooms there are - that would be dumb.
The band of companies between small shops and enterprises are likely to be affected, but then this is really employee lunch money.
> This will affect enterprises - but then they're either already on Github Enterprise or are used to per user pricing anyway
my organization currently contains 15 github users. 2 of which are used by error reporting tools to open bugs (Sentry, Crashlytics), one of which is used by Jenkins, 3 of which are outside contractor for which github now will get the money multiple times as companies move to the same billing method.
We had 9 repos on github (and about 20 smaller ones with less collaboration on a self-hoste gitolite installation), so we paid $300 per year.
Now I have unlimited repos of which I still only use 9, but now I pay $1300 per year, whereby 3 of these accounts I'm paying for aren't actually real people and another 3 of these accounts I'm paying for even though multiple other companies are also paying for them.
Aside of the nearly 5x increase in price, I think it's also unfair having to pay for practically unused bug-reporting-only accounts and having to pay for accounts that are already paid for by a multitude of other companies.
I don't think this is good pricing for me.
Also as this isn't just a moderate increase, but a whopping 5x increase, I also strongly consider moving back away to a self-hosted solution because increasing the price by 5x is breaking the trust put into github as a third-party provider.
Increasing the price a bit is fine. But 5x is excessive.
my organization currently contains 15 github users. 2 of which are used by error reporting tools to open bugs (Sentry, Crashlytics), one of which is used by Jenkins, 3 of which are outside contractor for which github now will get the money multiple times as companies move to the same billing method.
We had 9 repos on github (and about 20 smaller ones with less collaboration on a self-hoste gitolite installation), so we paid $300 per year.
Now I have unlimited repos of which I still only use 9, but now I pay $1300 per year, whereby 3 of these accounts I'm paying for aren't actually real people and another 3 of these accounts I'm paying for even though multiple other companies are also paying for them.
Aside of the nearly 5x increase in price, I think it's also unfair having to pay for practically unused bug-reporting-only accounts and having to pay for accounts that are already paid for by a multitude of other companies.
I don't think this is good pricing for me.
Also as this isn't just a moderate increase, but a whopping 5x increase, I also strongly consider moving back away to a self-hosted solution because increasing the price by 5x is breaking the trust put into github as a third-party provider.
Increasing the price a bit is fine. But 5x is excessive.
It sounds like it would be a big help if github offered unlimited read-only/bot accounts. Not sure how technically feasible is that but it doesn't sound impossible.
Or as someone mentioned above, if they went the Slack route of not charging for users who don't push/pull code in a 30/60 day period. That way you could still have collaborator users (issues, PRs, etc) and only pay for the users who actually code.
There is the threshold effect to consider also.
Maintaining a gitlab instance is kind of ridiculous vs $300/yr.
On the other hand, its not exactly rocket surgery and $1300/yr would probably cover it.
So its not a theoretical issue in an isolated abstract sense but market position issue. The competition isn't the employee lunch fund but is actual competitors.
Aside from maintaining your own instance, I have no experience or contact with them but githost.io offers quite a bit for less than $100/month.
Maintaining a gitlab instance is kind of ridiculous vs $300/yr.
On the other hand, its not exactly rocket surgery and $1300/yr would probably cover it.
So its not a theoretical issue in an isolated abstract sense but market position issue. The competition isn't the employee lunch fund but is actual competitors.
Aside from maintaining your own instance, I have no experience or contact with them but githost.io offers quite a bit for less than $100/month.
Are the bug-only accounts reporting against your private repos? Public contributors are still free.
As pointed out by numerous other comments, this pricing model makes no sense for a lot of use-cases: external collabs, inactive collabs, wide org structure etc.
Many companies would expect to now pay a magnitude or multiple more than before, this is hardly "lunch money".
This has almost quadrupled our monthly cost ($850 vs $2914). We have ~300 users which will have to be reduced massively to save costs - perhaps with non-engineers sharing accounts or having no access at all. I'm not sure if charging per user is really in the spirit of open collaboration that GitHub champions.
I slo wonder if charging per user rather than per repo will also discourage the creation of open-source repos from orgs? There's no longer a (reduced) cost benefit after all, even if that was a minor influence compared with the other benefits of open-sourcing your code.
I slo wonder if charging per user rather than per repo will also discourage the creation of open-source repos from orgs? There's no longer a (reduced) cost benefit after all, even if that was a minor influence compared with the other benefits of open-sourcing your code.
You have 300 employees and an extra $6/mo/em is going to break you? How much do you spend on toilet paper? :)
Haha we probably spend a lot on toilet paper as we have ~5k employees (FTSE 100 company) but that isn't the point I was trying to make :-) it doesn't matter how big or rich you are - if costs for a thing increase by x3.5 it's probably going to have an impact. I'm no enterprise-lover and we spend tons of money on crap with annoys me but I'm not in a position to change that.
We are not a "technology company" (and unfortunately I'm not the CTO!) so we will have to report upwards that costs will be increasing x3.5. Their reaction will probably be to ask us to investigate alternatives.
It looks like smaller companies/startups will benefit much more from this change which is fair enough to charge the big boys more really.
I'm not asking anyone to get their violins out but it makes me a little sad that we may have to move away from GitHub. On the flip side, GitLab has been looking great lately!
We are not a "technology company" (and unfortunately I'm not the CTO!) so we will have to report upwards that costs will be increasing x3.5. Their reaction will probably be to ask us to investigate alternatives.
It looks like smaller companies/startups will benefit much more from this change which is fair enough to charge the big boys more really.
I'm not asking anyone to get their violins out but it makes me a little sad that we may have to move away from GitHub. On the flip side, GitLab has been looking great lately!
Doesn't say they are employees.
So it's an open source project?
I guess it can be a NFP that has closed-source repos. But why?
I guess it can be a NFP that has closed-source repos. But why?
Doesn't have to be OS. It could be a commercial product that grants access to the source.
It's possible, but that's a weird requirement (weird you'd want all your clients on the same repo, anyway) and you'd be able to circumvent this and come out pretty swell on the other side if that money is really worth it to you.
Why would they not use the same repo? It can easily be a standard product - look at the example further downthread of the unreal engine: All clients get access to the code. 2 private repos and 90657 users.
That's an extreme example, but we also have a single repo that a lot of collaborators get access to.
That's an extreme example, but we also have a single repo that a lot of collaborators get access to.
That's a good point. It still seems like an odd use-case!
If you already invest into this monthly, why don't you just have GitLab on premise?
We like to use hosted services rather than host them on-prem where possible (AWS, Artifactory, Slack, GitHub).
For the size of our company we have relatively few engineers. Not hosting things ourselves increases our productivity and we can concentrate on our own products :-)
For the size of our company we have relatively few engineers. Not hosting things ourselves increases our productivity and we can concentrate on our own products :-)
GitLab has a hosted solution, take a look at that. We love them, and they making moving over from GitHub easy.
> This has almost quadrupled our monthly cost ($850 vs $2914)
Has it really? Existing orgs aren't being forced to change, and on top of that they say they will give at least 12 months notice if they decide to force existing orgs into new pricing.
Has it really? Existing orgs aren't being forced to change, and on top of that they say they will give at least 12 months notice if they decide to force existing orgs into new pricing.
Sorry, yes, will change in 12 months time. I'm sure they will force the new pricing structure then (and that's cool).
Billing screenshot: http://i.imgur.com/k1F0BxA.png
Billing screenshot: http://i.imgur.com/k1F0BxA.png
With this change, BitBucket pricing [0] gets to appear pretty attractive.
(If you were an organization with few private repositories and large number of users, Github was earlier more affordable.)
[0] https://bitbucket.org/product/pricing?tab=cloud-pricing
(If you were an organization with few private repositories and large number of users, Github was earlier more affordable.)
[0] https://bitbucket.org/product/pricing?tab=cloud-pricing
It was already pretty attractive: Personal accounts get free unlimited repos (so inf% cheaper than github), and for organizations with few numbers of users but a huge number of repositories, github's largest plan was too small. :)
> Personal accounts get free unlimited repos
And teams of up to 5 people.
And teams of up to 5 people.
Nothing beats https://bitbucket.org/ when it comes to free, unlimited, private repositories. It has seen the first hosted repositories of far more startups than github ever will. Which is special achievement in itself.
You should check out gitlab.com
I have, I'll continue to use bitbucket.
Any reason why? Just wondering.
GitLab's UI is pretty terrible, even compared to the not-so-great-either BitBucket UI.
GitLab's UI/UX is regressive to the point that when you visit a repo, you have to click another link just to see the damn sourcecode. It's as though they ignored every advance in source-code UX post-Sourceforge.
The stacked global and per-repo sidebars are confusing in a way that baffled me for several minutes, as well. They need a serious rethink of their UI/UX.
GitLab's UI/UX is regressive to the point that when you visit a repo, you have to click another link just to see the damn sourcecode. It's as though they ignored every advance in source-code UX post-Sourceforge.
The stacked global and per-repo sidebars are confusing in a way that baffled me for several minutes, as well. They need a serious rethink of their UI/UX.
IDK, you have the option of whether to show files vs readme on landing but I actually actually prefer landing on readme first as it gives me an idea of what it is I'm looking at before deciding to dig into the code or not.
The main issue with GitLab right now IMO is that it's so fucking slow at times -- ike seconds per page slow...
The main issue with GitLab right now IMO is that it's so fucking slow at times -- ike seconds per page slow...
Sorry that GitLab.com is slow. We're working on it in the appropriately numbered issue https://gitlab.com/gitlab-com/operations/issues/42
BTW on-premises GitLab installations should be fast already
BTW on-premises GitLab installations should be fast already
Do you have numbers behind the first hosted repositories statement?
Have been using Github for a community radio station, have been encouraging all staffers to use github accounts to file issues against our private repos, etc. The friendly policies for many collaborators have made this attractive, even though most users have rarely interacted with the repos, if at all.
Now each user for the private repo has a significant cost (pretty significant for a non-profit community radio station); looks like we'll have to rethink this whole Github thing.
Now each user for the private repo has a significant cost (pretty significant for a non-profit community radio station); looks like we'll have to rethink this whole Github thing.
Similar situation here, have a whole segment of our organization that is non-developer but they file issues. I'm not paying for all of them just to submit issues. We also have bot users that I'm not willing to spend good money on maintaining. They need to think about a lite user of some kind for this use case.
Certainly appreciate your question around pricing for non-profits here - have you applied for non-profit status through GitHub?
We do have discounts to support eligible non-profit organizations, and you can request the discount at https://github.com/nonprofit. Feel free to reach out to Support (https://github.com/c) if you have any further questions around this!
We do have discounts to support eligible non-profit organizations, and you can request the discount at https://github.com/nonprofit. Feel free to reach out to Support (https://github.com/c) if you have any further questions around this!
Out of interest, why do you require charities to have no religious affiliation at all? Perhaps there's some US tax or legal aspect to it?
At at first glance from overseas, it seems oddly churlish and monoculturalist (dare I say "fearful of the prayerful") to disallow community groups and charities where actually yes their beliefs did prompt them to step out in service, and they are not ashamed of that.
I can't imagine it's a big part of your revenue base, and I wonder if there's more people like me who casually read it and quietly think "ooh, that's a bit inward-looking and snarky -- and goodness they put it on the page twice to make sure" than groups who are actually affected by it.
Suddenly those cheery octocats under "We love people who are changing the world" seem just that bit more limited and exclusionary. If I was in a satirical and provocative mood, I might ask, are they holding hands in togetherness, or to keep the undesirables out?
At at first glance from overseas, it seems oddly churlish and monoculturalist (dare I say "fearful of the prayerful") to disallow community groups and charities where actually yes their beliefs did prompt them to step out in service, and they are not ashamed of that.
I can't imagine it's a big part of your revenue base, and I wonder if there's more people like me who casually read it and quietly think "ooh, that's a bit inward-looking and snarky -- and goodness they put it on the page twice to make sure" than groups who are actually affected by it.
Suddenly those cheery octocats under "We love people who are changing the world" seem just that bit more limited and exclusionary. If I was in a satirical and provocative mood, I might ask, are they holding hands in togetherness, or to keep the undesirables out?
Excluding religious groups from special nonprofit deals is pretty normal in the US. For example, my employer does donation matching for non-religious nonprofits. You're reading a lot more into it than you probably should.
[deleted]
I never noticed that before.. I like the "nonpolitical" one as well, pretty vague in my opinion.
I don't think there is a question in that post. Also there's "non-profit" (business) and "non-profit" (hobby).
Did you evaluate Discourse for your use case? You can self host it cheaply on a small vps, and it's great for non dev issues discussion.
I see absolutely no reason why one would pay GitHub for private repositories when there is Bitbucket, or much better alternative to GitHub altogether - GitLab.
$25 a month is such a minor cost for our company that cost doesn't come into it.
Yeah, this makes internally hosted GitLab VERY attractive for us now. Even the Enterprise edition is going to be significantly cheaper than GitHub.
Glad to hear you're considering GitLab, our on-premises pricing can be found on https://about.gitlab.com/pricing/
BitBucket Server (hosted) is better.
We switched from GH:Enterprise and saved $1000's a year. Worth it.
We switched from GH:Enterprise and saved $1000's a year. Worth it.
Because businesses need money to survive and most have no problem spending it when it increases productivity or provides perceived value over another product.
When people mention GitLab I always wonder if you mean the public hosted GitLab, or running your own GitLab.
Usually, they are referring to the public GitLab as it is a free installation of GitLab Enterprise Edition with free private repositories.
Public GitLab is amazing, especially built-in CI integration, however it is not as fast as Github (page loadspeeds)
It seems most users here don't have gitlab.com in their radar and only mentioning Bitbucket as competitor. I've recently switched all my private personal repos to gitlab.com which also allows unlimited private repositories because gitlab.com seems to have better UI and more features than Bitbucket (when not buying any additional Atlassian Jira etc. products).
Same here I love gitlab and especially their UI. I've seen some gitlab devs on here before too and they were really friendly. Only draw back is that the sites kind of slow for me, but so was github.
Good to note that self hosting Gitlab (CE in my case) is a breeze. I'm pretty bad at infra and sysadmin stuff and I've been maintaining an instance for a group of friends for about a year now with no issue.
Installation is easy, upgrading (even between major versions) is completely painless, you get integration with Gitlab Continuous Integration, the Community Edition doesn't feel artificially gimped to get you to switch to a paid plan, Gitlab is great at fixing security issues. I also love the UX and it's not missing any feature in my experience compared to GitHub/Bitbucket.
I'm not affiliated with Gitlab in any way but it's honestly one of the rare pieces of software I only have praise for.
Installation is easy, upgrading (even between major versions) is completely painless, you get integration with Gitlab Continuous Integration, the Community Edition doesn't feel artificially gimped to get you to switch to a paid plan, Gitlab is great at fixing security issues. I also love the UX and it's not missing any feature in my experience compared to GitHub/Bitbucket.
I'm not affiliated with Gitlab in any way but it's honestly one of the rare pieces of software I only have praise for.
For all of my personal projects I use GitLab. It has about the same amount of features as GitHub (more in many areas, in fact) and it's free for most usage, even private.
GitLab and BitBucket are going to eat GitHub's lunch if they don't change this crazy pricing model.
GitLab and BitBucket are going to eat GitHub's lunch if they don't change this crazy pricing model.
Glad to hear you like GitLab!
This is absolutely fucking atrocious news for any company who wants to run an agile operation.
I always framed the "Github vs Bitbucket" as an "agile vs enterprise" mentality -- BitBucket made you think hard about adding new people, and air on the side of limiting access -- ie. conceal by default. That's perfect for enterprise, but the worst fucking incentive ever for an org that wants to make as many projects as possible accessible to all company members. GitHub (in times past), removed this cognitive burden of thinking "does this person /really/ need access....?" -- ie. transparent by default.
But now they've fucked up.
I was always in favour of avoiding self-hosting when there was a great hosted service like GitHub available. But I would now never advise any company that I cared about to use GitHub. It will contort and twist the openness you wish to imbue in your growing company
I always framed the "Github vs Bitbucket" as an "agile vs enterprise" mentality -- BitBucket made you think hard about adding new people, and air on the side of limiting access -- ie. conceal by default. That's perfect for enterprise, but the worst fucking incentive ever for an org that wants to make as many projects as possible accessible to all company members. GitHub (in times past), removed this cognitive burden of thinking "does this person /really/ need access....?" -- ie. transparent by default.
But now they've fucked up.
I was always in favour of avoiding self-hosting when there was a great hosted service like GitHub available. But I would now never advise any company that I cared about to use GitHub. It will contort and twist the openness you wish to imbue in your growing company
This is an awful pricing model.
⇒ One-size-fits-all never fits all. Getting rid of tiers is naïve and misguided. Even if just for anchoring and the illusion of choice in face of terrible choices, tiers are a necessity. Sales will suffer, customer satisfaction will suffer.
⇒ I don't care if existing private customers pay the same or less. The price points should have been retained, and customers let to switch to a lower tier if they wished. Capturing consumer surplus leads to increased revenue. Github needs that money; the more money they throw away foolishly, the closer they are to bankruptcy.
⇒ "Starting today"?! At least current developer plans have been grandfathered in, with a 12-month notice period. Still, if an org has been in the process of planning a move to Github, they will have to re-evaluate.
Github has been such a great platform. A major stumble like this, I'm worried they may not be with us for much longer.
⇒ One-size-fits-all never fits all. Getting rid of tiers is naïve and misguided. Even if just for anchoring and the illusion of choice in face of terrible choices, tiers are a necessity. Sales will suffer, customer satisfaction will suffer.
⇒ I don't care if existing private customers pay the same or less. The price points should have been retained, and customers let to switch to a lower tier if they wished. Capturing consumer surplus leads to increased revenue. Github needs that money; the more money they throw away foolishly, the closer they are to bankruptcy.
⇒ "Starting today"?! At least current developer plans have been grandfathered in, with a 12-month notice period. Still, if an org has been in the process of planning a move to Github, they will have to re-evaluate.
Github has been such a great platform. A major stumble like this, I'm worried they may not be with us for much longer.
Does anyone know if this will effect student plans as well? So far it included a free micro plan with the usual 5 private repos. Would be pretty awesome, I just had to host a repo somewhere else a few days ago because I ran out of private repos.
Other than that it sounds like a great improvement, it'll make it a lot more likely that I'll pay for GitHub when I'm not a student anymore.
/edit: https://github.com/pricing makes it sound like this is for free student plans as well
Other than that it sounds like a great improvement, it'll make it a lot more likely that I'll pay for GitHub when I'm not a student anymore.
/edit: https://github.com/pricing makes it sound like this is for free student plans as well
Good question! Students get free private repositories for 2 years. You can request the student discount at https://education.github.com/
Awesome, thanks for the confirmation :)
Yes, students will also get unlimited private repos.
Confirmation here: https://www.facebook.com/GitHubEducation/posts/5987704836162...
Confirmation here: https://www.facebook.com/GitHubEducation/posts/5987704836162...
Under the billing tab in my account it says: "Sit tight! We’re in the process of upgrading your account to unlimited private repositories."
It would be interesting to know how many users and repositories a typical organization has on Github.
To me, it looks like they're just "optimizing" their pricing, as I would guess that most large organizations using Github have significantly more users than repositories, especially with the recent trend towards "mono-repositories".
That said, SaaS pricing is really hard to get right from the beginning. I run a code analysis company (https://www.quantifiedcode.com) and we thought a lot about which kind of pricing would be the best for us and our users (we decided to use per-repo pricing). In the end, your pricing needs to support your business model, so it's normal to change it especially if you have a lot of data on how your users use your product.
I wonder though if this will drive organizations to other solutions like Gitlab or Bitbucket, as those are significantly cheaper and pretty easy to set up these days (and you get the extra benefit of a self-hosted solution that can be hosted in your own, secure infrastructure)
To me, it looks like they're just "optimizing" their pricing, as I would guess that most large organizations using Github have significantly more users than repositories, especially with the recent trend towards "mono-repositories".
That said, SaaS pricing is really hard to get right from the beginning. I run a code analysis company (https://www.quantifiedcode.com) and we thought a lot about which kind of pricing would be the best for us and our users (we decided to use per-repo pricing). In the end, your pricing needs to support your business model, so it's normal to change it especially if you have a lot of data on how your users use your product.
I wonder though if this will drive organizations to other solutions like Gitlab or Bitbucket, as those are significantly cheaper and pretty easy to set up these days (and you get the extra benefit of a self-hosted solution that can be hosted in your own, secure infrastructure)
I find it quite hard to comprehend why people use Github for private repositories. There are many free alternatives. BitBucket seems to be the famous one, but Gitlab has grown into an amazing product with 3 different offerings; On premise community edition, on premise enterprise and hosted (like Github).
We have used the on premise community edition for about 3 years now. I first installed it when you had to run about a billion commands manually and it was great even then. Now you can install it with an apt-get and a few lines.
Lets not forget about the obvious negatives of Github (ignoring pricing).
1) Its hosted which means it can go down 2) It is closed source 3) Feature based is quite small (compared to Gitlab)
Gitlab is a regular release cycle, once a month which always comes with new features.
I personally think it is a no brainer.
We have used the on premise community edition for about 3 years now. I first installed it when you had to run about a billion commands manually and it was great even then. Now you can install it with an apt-get and a few lines.
Lets not forget about the obvious negatives of Github (ignoring pricing).
1) Its hosted which means it can go down 2) It is closed source 3) Feature based is quite small (compared to Gitlab)
Gitlab is a regular release cycle, once a month which always comes with new features.
I personally think it is a no brainer.
If every organization went to free alternatives, not only would those free alternatives need a source of revenue to support the new business, I think you'd find they too will change their pricing structure to better fit the people that use their product.
One thing I also have to mention is a majority of for profit organizations have no problem paying for services they use. HN is a special snowflake on the internet, it's not a reliable source of market research by any means.
I can guarantee you none of the competitors are in it to provide a charity. They all want and NEED to make money somehow, I think you'll be surprised how long free solutions tend to last.
One thing I also have to mention is a majority of for profit organizations have no problem paying for services they use. HN is a special snowflake on the internet, it's not a reliable source of market research by any means.
I can guarantee you none of the competitors are in it to provide a charity. They all want and NEED to make money somehow, I think you'll be surprised how long free solutions tend to last.
On Gitlab.com's homepage[0] there is a giant product listing showing you exactly what you are saying they need to have: A source of revenue (GitLab Enterprise Edition).
[0]: https://about.gitlab.com/
[0]: https://about.gitlab.com/
I understand their Enterprise offering offsets the costs of hosting the open source version for you. But should another product be the dependency of determining if the open source version is free? What if the Enterprise offering stops making money? Wouldn't you rather pay for the service you use so it supports future development? It's like Apple depending on product A to give away B for free, that doesn't seem like it'd scale a whole lot. Product B will just reach into the resources needed to build and manage product A.
Just my 2c anyways, happy to hear feedback on why I'm wrong :)
Just my 2c anyways, happy to hear feedback on why I'm wrong :)
I get that, but and most of these companies do offer paid alternatives. My point is that if you are able, why not self host? There will always be companies that cannot self host which pay for the hosted solutions.
Thanks for mentioning GitLab!
Now I have to pay for external collaborators? Are you kidding me? We are a small team of 5, but making softwares for other, I'll have to move away from github with the new pricing, we have nearly ten people per repository that might just be exec who never accessed the repo but must have access to it.
git is distributed. You can give access to a mirror of your git repo for execs that don't access the repo or contribute to it. They don't need to be github users, they just need git access to an url. If github is still convenient for you, there is a solution to avoid paying for this users. It only really makes sense to have developers added as github users (of course, it used to be convenient to just ask them to be github users, but it never really made sense)
I know git is distributed, that's not the point. Github as a platform is convenient and understood even by non technical people. They can browse files, even edit on the web.
I hope they create a stakeholder account for that. But it is wrong to put all your eggs in one basket. Github is nice to show to non technical people but it is definitely an over kill.
The linked page is telling us that eventually, only the new plans will be available. For my case (15 users in the organization, using the bronze plan with a lot of not-so-important repos on our own server), this will be a price increase from $300/y to $1380/y - nearly 5x more expensive.
I really hope the old plans stay around as long as possible.
Also, consider external collaborators that are part of multiple organizations: Github will now receive the $9/month per external collaborator and organization they are in. That's one hell of a deal for github.
I really hope the old plans stay around as long as possible.
Also, consider external collaborators that are part of multiple organizations: Github will now receive the $9/month per external collaborator and organization they are in. That's one hell of a deal for github.
I'll assume that none of your 15 users are software developers and that none of your users live in a first world country. I'll assume you pay a user $15,000 USD per year in salary. $225,000 for all 15 total. Cost of Github: $1,380. New operating costs: $226,380. I see that they have gone up by %0.6. Crushing.
Some of these users are used for various error-reporting tools to report issues as. I'm not paying these any salary, nor are they actual, you know, people.
Some of these users also aren't developers but just need access to the bug tracker. Some of them are outside contractors for whom multiple companies are now paying the github tax.
But sure. $1.3K isn't much, but it's 5x more than what we had to pay previously and it's being sold as an improvement.
It also means that I have to be much more mindful what other bot-accounts I'm going to add to the organisation. Plus now that github has increased the prices by 5x, who's to say they don't do it again at a late time?
I don't have a problem with moderate price increases. But 5x is too much.
Some of these users also aren't developers but just need access to the bug tracker. Some of them are outside contractors for whom multiple companies are now paying the github tax.
But sure. $1.3K isn't much, but it's 5x more than what we had to pay previously and it's being sold as an improvement.
It also means that I have to be much more mindful what other bot-accounts I'm going to add to the organisation. Plus now that github has increased the prices by 5x, who's to say they don't do it again at a late time?
I don't have a problem with moderate price increases. But 5x is too much.
$1,380 is so small an amount that when I worked at BigCorp I could expense that and more each month without approval. No one cares about a thousand bucks.
Pretty angry that Github have made this change with no mechanism for adding machine users without paying a per month charge. It seems like a key feature, which is currently horribly painful to manage and now expensive.
How does everyone else create credentials that CI can use to checkout code?
How does everyone else create credentials that CI can use to checkout code?
Both Travis and Circle automatically install a deploy key into the project. It doesn't require additional machine users.
That's fine if you have a single repo, but CI normally needs to access lots of different repos. GitHub's documentation describes why you need machine users for anything but the most trivial deployment.
https://developer.github.com/guides/managing-deploy-keys/
It's also what GitHub does internally.
https://developer.github.com/guides/managing-deploy-keys/
It's also what GitHub does internally.
If I understand that page correctly, the only real difference is that Github arbitrarily prevents you from using the same deploy key for multiple repositories. If they lifted that restriction, this problem would go away.
Yep, same here. Our build system uses multiple repos (and now you can have as many as you want!)
This is shortsighted on their part, I hope they pay attention.
This is shortsighted on their part, I hope they pay attention.
Semaphore works the same way.
CI machines cause most of their traffic, why should they be free?
Why don't you just add the SSH public keys of your CI machine to your own GitHub account?
I wouldn't want a CI to store a key that has R/W access to all my repos in all my organizations. I'm in at least 5 active organizations that I would be putting at risk
Use shadow repos just for CI and nothing else.
[deleted]
[deleted]
If you happen to be a group that will be affected negatively by this move because you have a need for read-only users...
Gogs has mirror functionality where you could self-host access for those users in a fairly painless way. Screenshot of import screen: http://i.imgur.com/J4vWCIB.png
More on gogs here: https://github.com/gogits/gogs
(no association with gogs, just thought it might be helpful)
Gogs has mirror functionality where you could self-host access for those users in a fairly painless way. Screenshot of import screen: http://i.imgur.com/J4vWCIB.png
More on gogs here: https://github.com/gogits/gogs
(no association with gogs, just thought it might be helpful)
The number of very small teams or individuals this encourages to start using github probably allows every organization who can't afford this to leave and github to still increase the money they're making. It seems like a good move based on my imagined profile of their user base. 1 million teens and young 20-somethings just decided they'll give 7$ a month to github.
For bigger organizations, this is practically no money compared to other software they're using. So they'll just take the hit.
Sounds like the only customers being lost were those using github for no-commit users. Is that really a huge segment? If so they just need a special account status to fix this.
I think the question is why this took so long.
For bigger organizations, this is practically no money compared to other software they're using. So they'll just take the hit.
Sounds like the only customers being lost were those using github for no-commit users. Is that really a huge segment? If so they just need a special account status to fix this.
I think the question is why this took so long.
> Sounds like the only customers being lost were those using github for no-commit users. Is that really a huge segment? If so they just need a special account status to fix this.
I would think this is a large segment, or at least Github would like it to be. Any software company that sells its software directly, and so has a sales team, a support team, marketing and so on will need to make all of those people users in Github if they're going to raise GH issues, see the code, prototype something for a client, help with branding, or anything else. If you're using Github the way they want you to (issue tracking, wiki, all of the things Github adds over vanilla Git that are "sticky"/hard to transfer to a competing service) you don't want to restrict access to just your developers. You want your whole company to be using it.
In any software company I've worked for, those non-developer users number 3-4x the actual number of developers. And I've never worked for a company that would consider restricting which users could raise issues with the product.
I agree that having a non-commit account status that didn't count toward the per-user pricing would fix this, for that particular (I think common?) case.
I would think this is a large segment, or at least Github would like it to be. Any software company that sells its software directly, and so has a sales team, a support team, marketing and so on will need to make all of those people users in Github if they're going to raise GH issues, see the code, prototype something for a client, help with branding, or anything else. If you're using Github the way they want you to (issue tracking, wiki, all of the things Github adds over vanilla Git that are "sticky"/hard to transfer to a competing service) you don't want to restrict access to just your developers. You want your whole company to be using it.
In any software company I've worked for, those non-developer users number 3-4x the actual number of developers. And I've never worked for a company that would consider restricting which users could raise issues with the product.
I agree that having a non-commit account status that didn't count toward the per-user pricing would fix this, for that particular (I think common?) case.
TL;DR - GitHub is switching to Bitbucket's pricing model, but with a monthly charge of $9/user rather than $1/user.
Seems bizarre to me. The "enterprise" market they're chasing are largely Atlassian customers already, and Bitbucket has a competitive edge there with its JIRA integration. GitHub's distinguishing characteristic was a different pricing model, that for some organizations makes more sense than Atlassian's does.
If they start competing apples-to-apples, but at 9x the cost, why would any enterprise use GitHub unless they have a hipster CIO/CTO who just thinks it's a "cooler" brand?
Seems bizarre to me. The "enterprise" market they're chasing are largely Atlassian customers already, and Bitbucket has a competitive edge there with its JIRA integration. GitHub's distinguishing characteristic was a different pricing model, that for some organizations makes more sense than Atlassian's does.
If they start competing apples-to-apples, but at 9x the cost, why would any enterprise use GitHub unless they have a hipster CIO/CTO who just thinks it's a "cooler" brand?
Github is betting on stickiness aka lock-in.
That might prove to be bad bet.
Short term everybody who saves (small teams) will switch to new price model. No sane org will opt to multitude of price increase voluntarily. So github looses revenue short term.
If github forces the switch on everybody many big orgs will jump the ship one way or another. So github looses again.
Hopefully this opens the eyes of at least some people into realising that GitHib !== git, and GitHub !== dvcs (similarly, git !== dvcs). There are several alternatives out there, almost all of which provide more options at lower cost than GitHub.
I know, I know "everyone is familiar with github". If your developers can't function without GitHub specifically, you have a bigger problem than the new GitHub pricing.
I know, I know "everyone is familiar with github". If your developers can't function without GitHub specifically, you have a bigger problem than the new GitHub pricing.
Hmm, I still will use Gitlab instead of Github. Unlimited public and private repos for free is nice.
Does anyone know how Gitlab plan to sustain that?
We think repository hosting will be like email hosting, for most people it will be free. See https://about.gitlab.com/gitlab-com/#why-gitlab-com-will-be-...
I believe that their profit comes from selling the Enterprise Edition of GitLab and support. gitlab.com and the Community Edition are all free, and I believe they intend to keep it this way.
They basically use the hosted environment to get a better understanding of how their software runs at scale, so they can improve it.
It's all funded by enterprise licenses.
It's all funded by enterprise licenses.
For the vast majority of users the repos use almost zero ressources except for some tiny amount of space - limiting the amount you can have is artificial. Many repositories is no different than facebooks mega repository pattern, but that is allowed, so why not give the customers what they want? If they want a "sustainable model" they'd have to set an upper limit on space and reqs/day.
a) They are vc funded
b) They give things free to drive up adoption. For example, I don't think it will be free anymore if it was as popular as GitHub. Since that would not be sustainable.
IMO, it's a poor decision by gitlab to give things out for free. Instead of innovating on features, they try to keep it cheap.
b) They give things free to drive up adoption. For example, I don't think it will be free anymore if it was as popular as GitHub. Since that would not be sustainable.
IMO, it's a poor decision by gitlab to give things out for free. Instead of innovating on features, they try to keep it cheap.
Having a free GitLab.com doesn't mean we don't innovate on features. See https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELO... and https://about.gitlab.com/2016/03/29/gitlab-runner-1-1-releas... for features we recently added.
Sorry, I didn't imply GitLab was not innovating. (Apologies for wording my comment poorly). In fact, quite the opposite. I want to see GitLab build a product that people willingly pay for.
(I say the same for all companies. Charge money for your product. If people see value, they will pay.)
(I say the same for all companies. Charge money for your product. If people see value, they will pay.)
As others said, Gitlabs business comes mostly from clients who want or have to have their own on premise solution.
I'm glad. Occasionally I would delete abandoned projects to make space and now they can live forever to remind me of my failure!
[deleted]
Its unfortunate that this doesn't promote trying to get business users to look at the code. In our organization 3 or 4 users are read only and really just go in at times to check specific errors, or logic for certain SQL queries, they don't really contribute. We will now have to pay $9 per month for these type of "read only" users.
Couldn't you use some other kind of display for these users? Seems like you'd only need 2 or 3 of these to justify a small project to get them the information they need without needing to be a paying GitHub user.
This change worked out well for us. Gone from paying $200/month to just $25/month for our 5 person organisation.
You could've had it for free this whole time. (And still can!)
https://bitbucket.org/product/pricing
https://bitbucket.org/product/pricing
Free != better
Github is... adopting the old Visual Studio logo?
http://static.flickr.com/2768/4307936121_5b5e51a790.jpg
http://static.flickr.com/2768/4307936121_5b5e51a790.jpg
As a solo developer who had currently paid up for monthly access annually, I feel obligated to feed back that this is pretty good news for me. Go github.
The 5 private repositories was a bit grating and making me considering a move elsewhere. I was going to have to consider changing how I stored/structured my projects in order to stay under what seemed to me to a relatively arbitrary limit, which interfered with some of my automated tools and how I'd set them up to assume a separate repository for each project.
I realise there are a number of bigger organisations for whom this realistically means a hike in prices, and I'm winning relative to their losing, but as someone who wants to keep advantages to the little guys (that's the genuinely little guys, not a bunch of 50-100 guys bankrolled by several SV millionaires/billionaires)...well, I feel its my duty to weigh in with positive feedback against what is probably going to be some negativity from the bigger guys...
The 5 private repositories was a bit grating and making me considering a move elsewhere. I was going to have to consider changing how I stored/structured my projects in order to stay under what seemed to me to a relatively arbitrary limit, which interfered with some of my automated tools and how I'd set them up to assume a separate repository for each project.
I realise there are a number of bigger organisations for whom this realistically means a hike in prices, and I'm winning relative to their losing, but as someone who wants to keep advantages to the little guys (that's the genuinely little guys, not a bunch of 50-100 guys bankrolled by several SV millionaires/billionaires)...well, I feel its my duty to weigh in with positive feedback against what is probably going to be some negativity from the bigger guys...
Five private repos were more then enough for me.
When I ran out of them, I noticed that there's at least one that either does not need to be private anymore or just does not have to be on GitHub since I ditched that idea. It was a nice way for me to keep my GitHub profile nice and tidy.
When I ran out of them, I noticed that there's at least one that either does not need to be private anymore or just does not have to be on GitHub since I ditched that idea. It was a nice way for me to keep my GitHub profile nice and tidy.
I'm sure a lot of people will be moving from Bitbucket to this, Bitbucket's plans were great for hundreds of repos, but Github's ecosystem is definitely preferable.
I'm not sure, Bitbucket's price effectively is $1/user and Github's $9/user. I wouldn't expect organisations to move to Bitbucket either, as change is generally costly in terms of man-hour, but current price structure makes Bitbucket eight-fold cheaper.
[deleted]
Not really, I personnaly see no point of moving our (dozens of) repos to github at the moment. It would cost us a lot more than $0, for no advantage that justifies paying a premium. I am not sure what you mean by ecosystem, but we don't really miss anything from github. Yes the UI is more polished but who cares when 99% of the interactions with the repos are done with git clients (in various flavors).
Why? BitBucket is superior in every respect, plus importantly they give free private repos for every user. No price gouging like we're seeing with GitHub.
Oh, come on. It's OK to dislike this change, but "BitBucket is superior in every respect" and "price gouging" are far from objectively obvious.
BitBucket has branch level permission, but in Github its cryptic.
BitBucket is okay, but not superior in any way.
It's cheaper and has private repos for free and that's it.
The UI is clunky and the community is much smaller than Githubs.
I also don't understand why they try to sell it with the Jira integration as if it was a good thing. The only people I heard saying good things about Jira and this marketplace where working on companies that sold stuff there.
It's cheaper and has private repos for free and that's it.
The UI is clunky and the community is much smaller than Githubs.
I also don't understand why they try to sell it with the Jira integration as if it was a good thing. The only people I heard saying good things about Jira and this marketplace where working on companies that sold stuff there.
It's not really price gouging. GitHub's product is GitHub. Atlassian's product is Jira, which nets them a tidy penny, and BitBucket is their loss-leader value-add that they can use to undercut GitHub.
Very cleverly worded to sound like a price reduction when it's actually a price increase.
So what makes them think that they can get away with it? There's already decent competitors - GitLab, BitBucket, Azure or you can just host your own git repos - gitlab will even give you a nice Web UI for it.
Why do they think that people with stick with github, if we're talking $thousands/year then surely migrating to another git repo provider is worth it?
Vendor lockin. Because there is a lot more involved that accessing files in a .git directory. All those CI systems and workflow plugins and whatnots such as travis-ci work with github, not git. And all the inflight issues and pull requests etc. Migrating or giving up the features you use has a cost (not just in dollars), and if github has done their sums right most customers will realize they are better off staying where they are.
Travis CI is pretty minor player (google search 10M > hits), and I would say 3rd party service integration is exactly vendor lockin.
Imho this makes sense, because users who cared about pricing already moved on to cheaper alternatives and/or not used github to begin with. I agree, mass migration or phasing out github is unlikely because of the associated costs, however with all the other great services around new users might think twice where to sign up.
Imho this makes sense, because users who cared about pricing already moved on to cheaper alternatives and/or not used github to begin with. I agree, mass migration or phasing out github is unlikely because of the associated costs, however with all the other great services around new users might think twice where to sign up.
Just wanted to mention that on GitLab.com we offer unlimited GitLab CI to run your tests https://about.gitlab.com/gitlab-ci/ https://about.gitlab.com/2016/04/19/gitlab-partners-with-dig...
For small private projects, gitlab.com has had unlimited private repos for $0/month for a while now.
And on top of that we don't charge for collaborators.
As has Bitbucket. Unlimited users too if you have a .edu or equivalent email.
All I ask is that Github implement Slack's Fair Billing Policy. Managing who at the organization can access a service is a silly task.
Unfortunately, it doesn't appear that this follows that model. They're open to feedback: https://github.com/contact
Unfortunately, it doesn't appear that this follows that model. They're open to feedback: https://github.com/contact
I wasn't aware Slack had that model. It's really interesting.
Here's the link for anyone else who wants to read: https://get.slack.help/hc/en-us/articles/218915077-Understan...
Here's the link for anyone else who wants to read: https://get.slack.help/hc/en-us/articles/218915077-Understan...
I am strongly considering moving to gitlab.
I have some private repos on gitlab and it is sloooooooow to push and pull. It routinely takes 10 seconds to push or pull.
That itself makes deploys seem like a chore. And it's enough to make me come back to github for a mere $7.
That itself makes deploys seem like a chore. And it's enough to make me come back to github for a mere $7.
I'm sorry GitLab.com is slow, we're working to make it faster in https://gitlab.com/gitlab-com/operations/issues/42
I have all my private projects in gitlab for quite some time, and only my public projects in github..
Well, I bet you won't move. Just do it and let us know.
Wow. Companies definitely suffer. For me ( freelancing dev, working primarily with startups ) it's a huge win.
GitHub vs BitBucket was always about :
1) 3rd party integrations ( CircleCI - e.g. ) - sadly bitbucket is behind that.
2) Issue management. Bitbucket's default behavior doesn't support labels or any other way of managing the issues structure.
Now, honestly CircleCI + GitHub for 7$ is just extremely cheap. ( talking solo devs / small teams ).
GitHub vs BitBucket was always about :
1) 3rd party integrations ( CircleCI - e.g. ) - sadly bitbucket is behind that.
2) Issue management. Bitbucket's default behavior doesn't support labels or any other way of managing the issues structure.
Now, honestly CircleCI + GitHub for 7$ is just extremely cheap. ( talking solo devs / small teams ).
This is way too expensive! Self-hosted GitLab is cheaper and has better uptime!
Not to mention, they should have made you pay only for users with commit rights!
Not to mention, they should have made you pay only for users with commit rights!
Only if you assign no value to your own time, and assume you can do a better job with availability and durability than a dedicated Operations team and a multi-million dollar budget.
Like Salesforce has?
http://www.theregister.co.uk/2016/05/11/marc_benioff_publica...
Only if you think GitHub is the only SaaS option... which it is not.
For comparison, quoting from the AWS CodeCommit pricing page...
AWS CodeCommit costs:
$1 per active user per month For every active user, your account receives for that month:
10 GB-month of storage
2,000 Git requests
And the 1 year free tier is:
5 active users 50 GB-month of storage 10,000 Git requests
AWS CodeCommit costs:
$1 per active user per month For every active user, your account receives for that month:
10 GB-month of storage
2,000 Git requests
And the 1 year free tier is:
5 active users 50 GB-month of storage 10,000 Git requests
It took a bit of searching to find out what a "Git Request" entailed: "A Git request includes any push or pull that transmits repository objects. The request does not count towards your Git request allowance if there is no object transfer due to local and remote branches being up-to-date."
Anyone who's using CodeCommit - have you hit the limits? How much did you go over by?
Anyone who's using CodeCommit - have you hit the limits? How much did you go over by?
Even if you hit the limit it's $1 per 1000 requests after that... still potentially cheaper than GitHub.
http://aws.amazon.com/codecommit/pricing/
http://aws.amazon.com/codecommit/pricing/
I don't use CodeCommit, but I doubt that an average developer would be hitting the 2000-request boundary (that's 100 requests per day assuming a 5-day work week). Technical users like a CI might be more problematic.
I think it's 2000 requests overall, and if you add in a few buildplans for each of a few repos, you'll easily hit it. Still, it's not pricey if you do.
The main image on that page looks remarkably similar to the 2010 Visual Studio logo:
http://blogs.msdn.com/b/samer/archive/2010/01/27/quick-share...
http://blogs.msdn.com/b/samer/archive/2010/01/27/quick-share...
Link to plans: https://github.com/pricing
How many startups have a non-core-dev-advisor who they will now pay $9/month to get occasional comments from? Or not?
One downside of this change is if you have a private Github org, you are now incentivized not to add advisors/randoms to your org/repos. I wonder how much scurrying Github sees to remove errant users from orgs.
One downside of this change is if you have a private Github org, you are now incentivized not to add advisors/randoms to your org/repos. I wonder how much scurrying Github sees to remove errant users from orgs.
Do outside collaborators count as paid users?
Hi alanfranzoni,
Outside collaborators on public repositories of an organization are free. Only the ones invited to collaborate on private repositories are counted as paid users.
Hope this helps!
Outside collaborators on public repositories of an organization are free. Only the ones invited to collaborate on private repositories are counted as paid users.
Hope this helps!
So to clarify: if I'm an organisation with 100 private repositories, and I add an outside collaborator with access to just one of them, I have to pay $9 a month for them?
I was quite excited about this change (we're an agency with a large number of repos and a relatively small number of users) until I read your comment.
I was quite excited about this change (we're an agency with a large number of repos and a relatively small number of users) until I read your comment.
Yes, they're actively screwing agencies and software houses.
When they introduced the new organization features, I smelled they were heading here, but I honestly thought that the "outside collaborator" concept was meant exactly for not billing this kind of rare users. Guess what, greediness has no limit.
When they introduced the new organization features, I smelled they were heading here, but I honestly thought that the "outside collaborator" concept was meant exactly for not billing this kind of rare users. Guess what, greediness has no limit.
Is there no distinction for "read-only collaborators"? We build software for many clients, they often request some (say 2 to 10) of their own users be added to the repository but only for viewing our work, not committing new code. If they are charged at the same rate as our own users the effective cost per repo for this model becomes $10-$50 per month!
That means that the same user that is member of multiple organisations gets paid for multiple times? We're doing a lot of consulting and thus we do have a lot of people from other companies that get to have a read-only peek at some of our repos - the price would increase at least tenfold for us.
That is really unfair to software houses that need to add customers to projects. We have 29 users and 51 outside collaborators, and 60 repos. You can see that this plan change is going to be unaffordable for us.
This helps as a clarification. But doesn't help for usage. I was happy about the unlimited repos feature, and willing to pay the surplus. But if an outside collaborator with access to one repo out of 100s of ours must count towards headcount, that's a pretty useless model for us.
[deleted]
Outside collaborators count towards a seat on private repositories and are free on public repositories.
I'm curious as well.
GitLab gets 1 point without doing anything, oddly.
This change actually saved me a lot of money per month. We use micro-service architecture and furthermore do consulting work so we had a Platinum level plan with only 7 people with access. This greatly improved our billing situation.
Although I can very much see how it could go the other way.
Although I can very much see how it could go the other way.
Thank you - this is very exciting. Bitbucket uses a per-user pricing and it has been extremely useful for us. People forget how useful it has been to not worry about the number of scratch repositories we can create as we experiment.
Our main repo is a single monolithic repo. But do you not ask your consultants/outside resources to work on a company repo ? how do you price that I wonder.
I am not sure why people would like stuff to be priced per repo. It is a fairly unintuitive model for me and is a huge problem when you need to go an explain to the finance team that you need to spend more because you "created more repos"... say wut? Spending per user is a very clean way of pricing.
I am not sure why people would like stuff to be priced per repo. It is a fairly unintuitive model for me and is a huge problem when you need to go an explain to the finance team that you need to spend more because you "created more repos"... say wut? Spending per user is a very clean way of pricing.
While unlimited private repositories sounds good, this change means that our GitHub costs are now 2.3x higher.
If this is going to be enforced, we'll need to decide between cutting away users from the org or moving to a different platform.
If this is going to be enforced, we'll need to decide between cutting away users from the org or moving to a different platform.
There is an element of "double dipping" here that I see as a problem.
I already pay $7 a month for my own personal Github account, and for me personally it's nice to have no limit.
But if we switch to the new model at work then not only am I paying my $7, but my company will have to pay an additional $9p/m for me to have access to the repos I use daily for work.
Even if they removed me from the organisation and added me as a collaborator this will be an additional cost.
They can spin it how they like but I suspect for a large number of organisations they are going to see quite an increase in cost from using Github.
I already pay $7 a month for my own personal Github account, and for me personally it's nice to have no limit.
But if we switch to the new model at work then not only am I paying my $7, but my company will have to pay an additional $9p/m for me to have access to the repos I use daily for work.
Even if they removed me from the organisation and added me as a collaborator this will be an additional cost.
They can spin it how they like but I suspect for a large number of organisations they are going to see quite an increase in cost from using Github.
Does your ISP double dip if they charge your employer for business internet access and you for home internet access?
But why should I use Github over Gitlab? I don't care about popularity, Gitlab already offers the minimal set of features I care about, and has demonstrated a neutral business model.
Github had leaks coming out about how 'white men' aren't suitable to solve GH's business problems, why should I want to associate with an organization that discriminates people based on the color of their skin rather than by the contents of their code?
I'm glad that they are offering this, I think their customers will put this offering to good use, but it doesn't convince me.
Github had leaks coming out about how 'white men' aren't suitable to solve GH's business problems, why should I want to associate with an organization that discriminates people based on the color of their skin rather than by the contents of their code?
I'm glad that they are offering this, I think their customers will put this offering to good use, but it doesn't convince me.
Finally! While as others point out this can work out more expensive the improvement is is that it scales as my company scales and doesn't act as a disincentive to developers spinning up new repos.
The pricing is clearly designed to make more revenue from businesses with a lot of users, which makes sense for Github but not for big teams in /mid sized shops who will be paying a lot more.
It will attract more small companies and freelance single developers as well.
Misleading headline alert; should say "for paid accounts" I got way too excited there :-(
Links not up yet, but you can already switch your plan https://github.com/organizations/your_org/settings/billing/p... for unlimited private repositories at $25/month for your first 5 users. $9/month for each additional user. (Edit: Up now! Personal plans get upgraded to unlimited too!)
This change was beneficial to me.
Before upgrading, a grand total of 4 users had access to our private repositories, of which we were only using 7 out of 10. I was nervous about running out of repositories moreso than the cost of adding people.
(If we grow our team, it's because we have a lot of client work that's outside my immediate strong suits and we had to hire. If we do that twice, I'll gladly pay the extra $9/month.)
Before upgrading, a grand total of 4 users had access to our private repositories, of which we were only using 7 out of 10. I was nervous about running out of repositories moreso than the cost of adding people.
(If we grow our team, it's because we have a lot of client work that's outside my immediate strong suits and we had to hire. If we do that twice, I'll gladly pay the extra $9/month.)
Well, I will say that this is a good thing, because when we had paid for ~20 repos at a last company, and eng made a new repo - number 21, that was then made public by default as we were out of private repos. FUCK THAT.
He made a mistake and checked in (yes this is on him) an AWS access and secret.
Within hours we have 1,500 machines launched in every region doing bitcoin mining....
Making a repo "public by default" is pure BS.
He made a mistake and checked in (yes this is on him) an AWS access and secret.
Within hours we have 1,500 machines launched in every region doing bitcoin mining....
Making a repo "public by default" is pure BS.
Still, not even a couple of free private repositories?
This will help organizations that keep huge monolithic repos on GH - one of my customers does that. They have one repo that should be dozens of smaller repos.
I use GH for my open source projects and code examples for my books and I use Bitbucket (which is also a great service) for my private repos. I have always felt somewhat guilty with this setup, working both companies for free services.
I use GH for my open source projects and code examples for my books and I use Bitbucket (which is also a great service) for my private repos. I have always felt somewhat guilty with this setup, working both companies for free services.
I think the new pricing structure makes a lot of sense, however is awkwardly limiting in some respects that GitHub might not have considered.
We have essentially 2 classes of GitHub user on our organisation - developers, and non-developers. While our devs use GitHub all the time (and therefore are worth the $25 a month for the development team), our other users might edit a specific few config files, or jobs pages (for example) once a month - paying $9/month each seems quite overpriced.
We want to be an open company, one that doesn't keep secrets from employees, one that doesn't create unnecessary barriers to productivity, or have unnecessary process, so giving GitHub access to everyone in the company who wants it is important to us - this stops us from reasonably doing this. As a result, we likely won't be switching to the new pricing structure for as long as possible, which is a shame, because it would be nice to not have to think about private repos.
We have essentially 2 classes of GitHub user on our organisation - developers, and non-developers. While our devs use GitHub all the time (and therefore are worth the $25 a month for the development team), our other users might edit a specific few config files, or jobs pages (for example) once a month - paying $9/month each seems quite overpriced.
We want to be an open company, one that doesn't keep secrets from employees, one that doesn't create unnecessary barriers to productivity, or have unnecessary process, so giving GitHub access to everyone in the company who wants it is important to us - this stops us from reasonably doing this. As a result, we likely won't be switching to the new pricing structure for as long as possible, which is a shame, because it would be nice to not have to think about private repos.
If someone is unsure about this math, our (we're https://github.com/artsy) bill goes up from 450$ to 1051$ per month.
But it's not about just the money, it's about incentives.
- We have large amounts of open-source code, so we were encouraged to open-source more to avoid jumping to the next tier.
- We're going to probably close access to a bunch of code to a big chunk of our organization. We have hundreds of humans. Whereas before we would give them permissions to view as a default and hope they look at our code one day or at least know that they can, or sometimes would get a link to look at a change from a discussion, we'll now have to have to see whether it's worth 9x100s of people every month.
I am not complaining, Github provides excellent service. Seems worth it at 5K$ a year and probably 10K$ a year, too. I wish it didn't just double though and was more gradual.
But it's not about just the money, it's about incentives.
- We have large amounts of open-source code, so we were encouraged to open-source more to avoid jumping to the next tier.
- We're going to probably close access to a bunch of code to a big chunk of our organization. We have hundreds of humans. Whereas before we would give them permissions to view as a default and hope they look at our code one day or at least know that they can, or sometimes would get a link to look at a change from a discussion, we'll now have to have to see whether it's worth 9x100s of people every month.
I am not complaining, Github provides excellent service. Seems worth it at 5K$ a year and probably 10K$ a year, too. I wish it didn't just double though and was more gradual.
This is awesome! I'm currently paying 50 USD per month for more repos on my private account. Definitely the right way to go.
I just had a discussion with my buddy about repositories yesterday. He wanted access to some code I had for uploading CSV files to iCloud and it's hosted on a private repo on GitHub. He was saying "I still use BitBucket's private repos"; My response was that the GitHub community is a lot stronger. Outside of community, it was hard for me to convince him that GitHub is worth it.
I've been using GitHub for a few years now to host private and public repos and paid private repos was always a point of contention. Now that they are unlimited, I can say that GitHub is definitely going to be the home to all of my future projects. I really feel like GitHub has been kicking it up a notch in 2016. Awesome work team and thanks!
I've been using GitHub for a few years now to host private and public repos and paid private repos was always a point of contention. Now that they are unlimited, I can say that GitHub is definitely going to be the home to all of my future projects. I really feel like GitHub has been kicking it up a notch in 2016. Awesome work team and thanks!
All those private repos and no way to organize them :( Where are the namespaces/projects github?
I think this is a clear win for individual users that have been paying for GitHub. For organizations, I'm curious how many organizations they have just bumped above the $300-500/month mark. A lot of companies allow managers discretionary spending limits that they can spend without requesting approval, and if makes me wonder if they just made a bunch of managers need to start asking for approval for their GitHub bill. Another comment mentioned that having it filter up that the cost of a service just increase several times, will likely result in people being told to investigate alternatives. If that's the case, there are a fair number of alternatives to go to, depending on your specific situation.
This is nice. Now I won't have to keep deleting private repos to make room for new ones
Is there a definition of "a few collaborators" anywhere? How many people, and is it per repo or per paid account? Really need more information before I decide if GitHub continues to get my $7/month or not.
The main drawback of a lot of Cloud based business model I have seen is that nobody think its fine to pay for leechers.
The per user pricing is pretty reasonable but only when you think of seeders (publishers/editors/pushers call them as you like).
For instance I would love to subscribe to a BI cloud suite that really fit my need, but I'm basically the sole query editor and I have potentially 200 private readers + some public OpenData. I simply just can't come to my boss and ask that we subscribe to this service on a 200 users basis while only one users will really have the use of the license...
The per user pricing is pretty reasonable but only when you think of seeders (publishers/editors/pushers call them as you like).
For instance I would love to subscribe to a BI cloud suite that really fit my need, but I'm basically the sole query editor and I have potentially 200 private readers + some public OpenData. I simply just can't come to my boss and ask that we subscribe to this service on a 200 users basis while only one users will really have the use of the license...
There is one case we have where the newer per seat pricing doesn't facilitate how we're using github. One of our repositories is "docs" with a bunch of markdown files, pdfs, images, and other documents related to our tech. It's mostly used in a read only way by a bunch of non-developers while engineers contribute heavily to the documentation. Paying $9/month per biz person to be able to view the documentation is too much and will force that use case off to Confluence or some other wiki/documenting tool.
We have a large number of people in our organization who have GitHub access who do not code and instead file or manage tickets. $9 a month just to be able to file a ticket is rather steep.
It's amazing how cheap people/companies are if they're complaining about these prices.
$9/user/month for one of the best and easy-to-use platforms to store and manage your repos and help your software development, which for most companies is extremely important to their product.
Slack is $8/user/month and yet people have no problem with that pricing. Git is also extremely portable and easy to move and takes minutes to self-host so what's the problem here?
$9/user/month for one of the best and easy-to-use platforms to store and manage your repos and help your software development, which for most companies is extremely important to their product.
Slack is $8/user/month and yet people have no problem with that pricing. Git is also extremely portable and easy to move and takes minutes to self-host so what's the problem here?
This is awesome! I have wanted a different pricing structure for personal accounts for a long time.
And for those who have issues with the organizational changes, did you see?
> I am an existing organization customer and prefer the per-repository plans. Can I remain on my current plan?
> Yes, you can choose to continue paying based on the number of repositories you use. You can also upgrade or downgrade in the legacy repository structure based on the number of repositories you need.
And for those who have issues with the organizational changes, did you see?
> I am an existing organization customer and prefer the per-repository plans. Can I remain on my current plan?
> Yes, you can choose to continue paying based on the number of repositories you use. You can also upgrade or downgrade in the legacy repository structure based on the number of repositories you need.
Why don't more people use Assembla? We've used it for years and it has so many more features than Github. Tickets, milestones, time tracking, standup, wiki, unlimited repos with protected-branch merge rights, file sharing, discussions...
There is no free plan but the pricing is fair in my opinion: https://www.assembla.com/plans
There is no free plan but the pricing is fair in my opinion: https://www.assembla.com/plans
That makes a lot more sense in term of pricing and if that had existed earlier, I'd probably not have bothered hosting my own gitlab repository. I like to have a lot of little repos even keeping some of my private experiments and so the limit of repositories never really made sense to me.
It might make sense however to not count collaborators with read-only access.
Of course, now that I have gitlab, there's very little reason for me to come back.
It might make sense however to not count collaborators with read-only access.
Of course, now that I have gitlab, there's very little reason for me to come back.
self hosted gitlab, for about 10$/month you get unlimited repos, unlimited users.
In the spirit of offering alternatives, we created a quick price calculator to show you whether you’d be better off moving from GitHub to Planio: https://plan.io/github-alternative/
But don’t hate us too much GitHub. We still love you :)
But don’t hate us too much GitHub. We still love you :)
I like gitthub, I have my open source stuff with github, but when it comes to private repos, bitbucket just seems better pricing and in someways just a nicer and cleaner interface https://bitbucket.org/product/pricing
I like github, I have my open source stuff with github, but when it comes to private repos, bitbucket just seems better pricing and in someways just a nicer and cleaner interface https://bitbucket.org/product/pricing
As much as I would love to switch to GitHub for our private repos, it still is way more expensive than BitBucket.
I hope this doesn't lead to less open sourced software. Since it will be easier to keep your code private.
Looks like with our company the price goes from $25 a month to $133 if we move (or are forced to move) over to the cost-per-user model.
GitLab was already looking good, if we're forced to change well likely move to GitLab. Github's pricing was already overly expensive for what you get, in my opinion.
GitLab was already looking good, if we're forced to change well likely move to GitLab. Github's pricing was already overly expensive for what you get, in my opinion.
Seems like a good move, it's unclear to me what the difference is between Personal & Organization.
Comments here are mostly from a single org view, due to the many X increase for that orgs price (large teams only)... but if I work on n_orgs repos, I'm now worth 9-25*n_orgs to github. That is a big shift from a model where I had no direct value to them as a unit.
Worth noting that for some (many) companies with large teams, this amounts to a new laptop or two in price change... and while a cost change, it really is noise (to some extent) for the value provided.
I know a lot of companies that are too cheap to pay for hosting (or even host in-house), and therefore use bitbucket with its unlimited private repos. It's their gateway drug, and once they get used to that, good luck having them move over to github.
> too cheap to pay for hosting
That's your view of companies that don't throw money at an over priced service with a history of ignoring customer requests? "too cheap".
I hear that's why Linus first wrote the Linux kernel back in the day - he was too cheap to buy a license for a commercial unix. /s
That's your view of companies that don't throw money at an over priced service with a history of ignoring customer requests? "too cheap".
I hear that's why Linus first wrote the Linux kernel back in the day - he was too cheap to buy a license for a commercial unix. /s
Why use the derogaroty 'too cheap'? Maybe they are just not 'too stupid' to pay more than they have to.
I guess my critic is that you should always know why you use a service, and not just use it because it's the cheapest solution out there. In particular, is bitbucket(/github/gitlab…) adapted to your needs ? Will it support your growth ? Is it ok to have your source code on someone else's (or another country's) server ? Lots of question to be answered, and a conscious choice to make, without looking at only pricing. I was talking about companies doing the latter, not all bitbucket free users (of which I am one myself).
"Too cheap" sounds a fair comment to me if the price is free. Anything free is almost certainly a loss-leader, as providing the service itself is almost certainly not free (whether it's a tiny-but-non-zero bandwidth cost, or the costs of providing support).
So long as the loss-leader is paying its way via the upsell, it's fine. And if those businesses have contingency plans for moving if BitBucket shuts down the free plan, then it's fine for them too. But the fear is that "too cheap" companies also tend to be cheap when it comes to managing contingencies.
So long as the loss-leader is paying its way via the upsell, it's fine. And if those businesses have contingency plans for moving if BitBucket shuts down the free plan, then it's fine for them too. But the fear is that "too cheap" companies also tend to be cheap when it comes to managing contingencies.
So I have a normal user account at $7/month. Great, I now have unlimited private repos.
I also had an organization a/c (only 1 user) at $9/month. I switched to the $25/month, so yes, its now costing me more.
I understand math. Why not just give me $5/user? :)
I also had an organization a/c (only 1 user) at $9/month. I switched to the $25/month, so yes, its now costing me more.
I understand math. Why not just give me $5/user? :)
Yay, no more using single repo with orphan branches to save on number of repositories :-)
I think this is great. I'm part of a small 2-person consultancy (my wife and I) and we've been abusing a user account for our business for sometime on the 'medium' plan since it would give us 20 private repos, although over the last 6 years, we're had to cycle stuff to backups, rotate it around in order to keep older client work in there.
It's been hard to justify upgrading to an organization for awhile, since our work is hit or miss and we both have other jobs form time to time. We aren't much in terms of load on Github, but we'd like to be able to store 40-50 private repos or add more without worrying about our limit. The new organization pricing makes tons of sense for us since it's very close to the old 'medium' plan we were using, instead of being 2.5 times as much, which we never felt we could justify.
It's been hard to justify upgrading to an organization for awhile, since our work is hit or miss and we both have other jobs form time to time. We aren't much in terms of load on Github, but we'd like to be able to store 40-50 private repos or add more without worrying about our limit. The new organization pricing makes tons of sense for us since it's very close to the old 'medium' plan we were using, instead of being 2.5 times as much, which we never felt we could justify.
> Over the next few days, we will automatically move all paid accounts, from Micro to Large, to the new plan. If you’re currently paying for one of those larger plans, look out for a prorated credit on your account.
Bravo, GitHub.
Bravo, GitHub.
Christmas is early this year.
So basically they're going to start using the same model as BitBucket?
bitbucket still sounds like a better deal as far as money goes, though github somehow catches all the eyeballs. bitbucket has been providing similar service for less since long time ago.
I'm really looking forward to no longer having to figure out which project I have to axe to keep my "small" plan under the 10 repo maximum. That was always annoying.
Pretty sure this wont end well for Github. They seem to be making a lot of moves like this recently. It's only a matter of time until a mass migration begins IMO.
This is just another reason to move to something like Gitlab or just self-host your Git repos. It takes literally seconds to set up your own Git server, so why not?
What's the difference between a GIT server and say a HTTP server? To my understanding, Github are unable to scale GIT, so they have to price accordingly.
This is not how pricing works.
You would need a lot of margin to not base the price on the production costs.
If 200 users cost double as much as 100 users, it's hard to not base the price on number of users.
Pricing is a function of what people will pay for it, not what it costs to make. Consider Slack as a fine example.
I read an article not long ago that Github had to spin up three physical machines, just to handle one customer. Although it was an extreme example. Compared to slack, who could probably have a million users one a single machine, making it almost zero marginal cost per new user. While a user for Github means buying more hardware and a notable marginal cost.
If you for example are a reseller of commodity goods, you can't have a lower price then the price you buy it for. So you can't have a model of say unlimited goods for a monthly fee. And the price will most likely be based on per good.
If you for example are a reseller of commodity goods, you can't have a lower price then the price you buy it for. So you can't have a model of say unlimited goods for a monthly fee. And the price will most likely be based on per good.
I think you're referring to the GitHub Engineering blog post [1] about our git storage tier. We [2] store your code on at least 3 servers, which is an improvement in many ways from our previous storage architecture. There are a lot of servers [3] powering things but not the millions it would require to give every customer three dedicated machines. Developing efficient solutions to problems is a requirement (and a fun challenge!) for anything at GitHub's scale.
[1] http://githubengineering.com/introducing-dgit/
[2] I'm a GitHubber. https://github.com/jssjr
[3] https://twitter.com/GitHubEng/status/730429227896463360
[1] http://githubengineering.com/introducing-dgit/
[2] I'm a GitHubber. https://github.com/jssjr
[3] https://twitter.com/GitHubEng/status/730429227896463360
It was another post about someone using Github to host "packages".
I'm not sure what your point is. Your initial comment seemed to indicate that you thought Github was increasing their pricing because they were struggling to pay for the underlying infrastructure, or that the per-customer cost was too high for the current margins. This is almost certainly not the case, they have simply realized that compared to similar services they are leaving a staggering amount of money on the table, and that people will pay a lot more. I imagine this pricing change will substantially improve their business in all regards.
You are correct. But if that is not the case, I think they are using the wrong strategy. Having such large margins will flood the market with competitors, lowering both market share and margins in the long run.
You realize Slack does full searching on your chat + your attached google drive? I would not be surprised for some big Enterprise customers to have 100GB of total data indexed.
Not saying the price is related to the cost, but I am not sure about the no marginal cost part.
Not saying the price is related to the cost, but I am not sure about the no marginal cost part.
Definitely cool, but I honestly think that if your organisation needs more than a handful of repositories then it's very likely doing something wrong.
I really don't understand why Github sets their prices higher while GitLab ( mostly) is gaining more and more traction...
So...GitLab looks better and better every day.
This is great for private accounts; it encourages better practice of smaller repos.
To me this is a good change, I have lots of private repositories and a small team.
Sounds like a lot of companies are going to end up with multiple GitHub orgs.
For less than these price plans, you can have your own domain and server.
Sorry it's too late, I already migrated to bitbucket 6 months ago.
I think I'll stick with my own private Gogs instance anyway.
bitbucket: still unlimited free private repositories
What's the delta from the old model?
github, soon to be the next sourceforge
This is fantastic news in my opinion.
I love the clickbait. It's missing 3 words - "for paid users". Everyone has clicked it to be disappointed. GitLab++.
Yay! No more bitbucket for all my private repos. I wonder if this change is because of competition?
If you are interpreting this post as suggesting that github private repos are free, you are mistaken. It just means that if you pay for private repos, you don't have to worry about how many of them you have.
I will stick with GitLab.
too expensive
I'm a member of a Github organisation with 63 members and 20 private repositories. As far as I can see, this changes our yearly cost from $600 to $6564.
[deleted]
Its awesm
and bitbucket's sole reason for existing has gone away
Everyone who is crying right now would be crying more if Github were to make the price free for private repos because with that, the amount of open source libraries they use would be cut in half.
-points but no reasons?
Agreed this will impact some organizations in negative ways such as the non-for-profit orgs. To that Github offers support in this sense here: https://github.com/nonprofit
Like others, without specific data, I would assume this will impact the majority of users on Github for the better and that organizations with many contributors needing access to private repos are the minority. In any pricing structure change, there is always going to be a minority that is impacted negatively. I don't think Github would have made this decision without analytics to back it up.
Another fair point is I think this structure is more appealing to companies who prefer to look at cost-per-employee for something that is an everyday tool rather than cost-of-architecture.
Agreed this will impact some organizations in negative ways such as the non-for-profit orgs. To that Github offers support in this sense here: https://github.com/nonprofit
Like others, without specific data, I would assume this will impact the majority of users on Github for the better and that organizations with many contributors needing access to private repos are the minority. In any pricing structure change, there is always going to be a minority that is impacted negatively. I don't think Github would have made this decision without analytics to back it up.
Another fair point is I think this structure is more appealing to companies who prefer to look at cost-per-employee for something that is an everyday tool rather than cost-of-architecture.
[deleted]
Honestly when I read the title I thought GH switched their business model and offered free users the ability to start a private repo, but this is not the case.
If it is the case that I have to pay to have privacy on Github, then it imposes a privacy-rich versus privacy-poor dichotomy which I am uncomfortable with. Now I know as far as these things go (GH can be subject to National Security Letters), that GH is not really absolutely private. (Backdoors into people's 'secret' GISTS anyone?).
GH had an opportunity here to change their business model so that free users can avail of private repos, and GH could still manage to bring in revenue. GH primarily makes the bulk of their income from what I call 'stakeholder accounts'. That is; those companies who simply couldn't function correctly if GH didn't exist. It is in these stakeholders that there is a symbiotic relationship of revenue for GH, and value for the stakeholder(s).
There are very little lone private individuals who have that kind of symbiotic relationship, and so at least give these low income users the same equal rights of privacy as behemoth tech organizations. It makes sense.
In terms of how GH gets revenue from these users, there are countless other ways to do this instead of relying on the monolithic device of a premium subscription model. Offer paid licenses for their proprietary GH clients. (A one off payment of $20.00 for the GH Windows client is something I would actually pay money for)...
If it is the case that I have to pay to have privacy on Github, then it imposes a privacy-rich versus privacy-poor dichotomy which I am uncomfortable with. Now I know as far as these things go (GH can be subject to National Security Letters), that GH is not really absolutely private. (Backdoors into people's 'secret' GISTS anyone?).
GH had an opportunity here to change their business model so that free users can avail of private repos, and GH could still manage to bring in revenue. GH primarily makes the bulk of their income from what I call 'stakeholder accounts'. That is; those companies who simply couldn't function correctly if GH didn't exist. It is in these stakeholders that there is a symbiotic relationship of revenue for GH, and value for the stakeholder(s).
There are very little lone private individuals who have that kind of symbiotic relationship, and so at least give these low income users the same equal rights of privacy as behemoth tech organizations. It makes sense.
In terms of how GH gets revenue from these users, there are countless other ways to do this instead of relying on the monolithic device of a premium subscription model. Offer paid licenses for their proprietary GH clients. (A one off payment of $20.00 for the GH Windows client is something I would actually pay money for)...
It's 7$/month. You sure can be made uncomfortable easily.
If someone wants a private repo but doesn't value his/her private code to the amount of 7$/month for ALL their private repos, then I guess it shouldn't have been made private in the first place.
FWIW, a Big Mac combo is around the same price. One is junk, the other is where you showcase/store all your professionnal knowledge and experience.
If someone wants a private repo but doesn't value his/her private code to the amount of 7$/month for ALL their private repos, then I guess it shouldn't have been made private in the first place.
FWIW, a Big Mac combo is around the same price. One is junk, the other is where you showcase/store all your professionnal knowledge and experience.
What are you going on about? You're bringing in National Security Letters into a discussion about public vs. private repos on Github? Do you know what a threat model is?
I wager they've kept people using public by default for several reasons, among them these:
* It gives them something to upsell on. If you're not completely poor, giving $7/mo for a code repo is not unreasonable. Or, to price it in a more relatable manner, 1.5 mochas.
* It encourages the "social coding" ecosystem. I believe the network effect of Github is the strongest thing keeping people using it instead of dispersing across Bitbucket/Gitlab/etc. a lot more.
And as a simple point of disagreement, I think fewer people would pay for a Github client than a private Github repo. And why is charging for a client so much more ethical to you than charging for a service, with ongoing maintenance costs?
I wager they've kept people using public by default for several reasons, among them these:
* It gives them something to upsell on. If you're not completely poor, giving $7/mo for a code repo is not unreasonable. Or, to price it in a more relatable manner, 1.5 mochas.
* It encourages the "social coding" ecosystem. I believe the network effect of Github is the strongest thing keeping people using it instead of dispersing across Bitbucket/Gitlab/etc. a lot more.
And as a simple point of disagreement, I think fewer people would pay for a Github client than a private Github repo. And why is charging for a client so much more ethical to you than charging for a service, with ongoing maintenance costs?
2. Go through significant organizational changes that end up with the departure of a co-founder (and more suits in the building).
3. Notice that a significant segment of your growth (VC-funded startups) are running out of money.
4. Switch to a user-based pricing to generate more revenue for investors, but spin it as a freebie "Hey! Look at the cool unlimited shit! No, no! Don't pay attention to the fact you're gonna be charged 3 times as much as before for the same service".
The bottom line is that GitHub is free to do whatever the heck they want; if they believe that charging per user is going to make more (financial) sense to them, then they can go ahead and do it.
But I'd appreciate if their PR department didn't expect us to swallow this as a positive change. Most coders understand basic maths.