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!)
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.
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.
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.
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.
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).
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?
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.
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. :)
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.
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.
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.
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.)
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.
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.
Outside collaborators on public repositories of an organization are free. Only the ones invited to collaborate on private repositories are counted as paid users.
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.
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.
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.
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!
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.
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.
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?
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.
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.
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
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.
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.
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 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.
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 ;-)
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. mattc@xbox.com or a reply here would be much appreciated. Thanks!
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.
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.
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.
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
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.
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.
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.
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.
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. :)
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.)
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/
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
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.
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).
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.
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)
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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
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.
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.
> 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
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'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.
$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.
That amount may be change for $BigCorp, but I do care about 1380 USD. If you have them and want to get rid of them, care to send them to me? I'll use them for a good purpose.
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.
The post says this about personal accounts: you can even invite a few collaborators. I can't find the exact definition of "a few", but I imagine it's less than 90657.
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 support@github.com.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
661 comments
[ 3.0 ms ] story [ 314 ms ] threadIt'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.
I'm glad there's at least a year that we can keep using the old plans.
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
Anyone who's using CodeCommit - have you hit the limits? How much did you go over by?
http://aws.amazon.com/codecommit/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
And teams of up to 5 people.
It's all funded by enterprise licenses.
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.
(I say the same for all companies. Charge money for your product. If people see value, they will pay.)
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
Confirmation here: https://www.facebook.com/GitHubEducation/posts/5987704836162...
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!
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.
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.
How does everyone else create credentials that CI can use to checkout code?
https://developer.github.com/guides/managing-deploy-keys/
It's also what GitHub does internally.
This is shortsighted on their part, I hope they pay attention.
https://bitbucket.org/product/pricing
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.
It appears that along with this announcement they are raising the prices of an account.
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 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.
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).
Thank you for posting this!
[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.
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.
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...
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.
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.
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. :)
(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.)
https://bitbucket.org/site/master/issues/2874/ability-to-sea...
Integration with Jira is nice though.
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.
[1] https://about.gitlab.com/vulnerability-acknowledgements/
[2] https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B...
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/
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).
We try to achieve a good reputation by taking security seriously every day and being responsive to disclosures.
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.
Jira, HipChat and Confluence are really nice tools, but pricing seems to just snowball.
Companies using micro services? Companies that don't want to have one big repository for their software?
The real place where it hurts is users who aren't paid employees.
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.
With that being said, in those types of environments, cost is everything, and BitBucket is still the cheaper option.
This is a great news for me.
Team | Cost Before | Cost Now
1 repo, 100 users | $25 | $880
[0] http://danluu.com/monorepo/
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 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 personally also use Gitlab for private side project repos and only use Github now for open source projects.
Any startup architected around microservices, for one
http://blogs.msdn.com/b/samer/archive/2010/01/27/quick-share...
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.
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.
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.
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
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.
Not sure why the topic of fairness even comes to the discussion, this is a business not a charity.
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.
That is just how business-to-business deals work.
Gotcha.
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.
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.
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.
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.