Introducing unlimited private repositories(github.com) |
Introducing unlimited private repositories(github.com) |
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.
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.
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.
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.)
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.
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.
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.
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.
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!
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...
$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?
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.
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.
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 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.
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?
There is no free plan but the pricing is fair in my opinion: https://www.assembla.com/plans
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.
But don’t hate us too much GitHub. We still love you :)
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.
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
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.
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? :)
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.
Bravo, GitHub.
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.
[1] http://githubengineering.com/introducing-dgit/
[2] I'm a GitHubber. https://github.com/jssjr
Not saying the price is related to the cost, but I am not sure about the no marginal cost part.
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.
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.
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...
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.
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.
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.
Unfortunately, it doesn't appear that this follows that model. They're open to feedback: https://github.com/contact
Here's the link for anyone else who wants to read: https://get.slack.help/hc/en-us/articles/218915077-Understan...
That itself makes deploys seem like a chore. And it's enough to make me come back to github for a mere $7.
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 ).
Not to mention, they should have made you pay only for users with commit rights!
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://blogs.msdn.com/b/samer/archive/2010/01/27/quick-share...
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.
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.
Although I can very much see how it could go the other way.
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.
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.
(I say the same for all companies. Charge money for your product. If people see value, they will pay.)
I've actually been following that thread and it's been interesting to read and watch the progress.
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.
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'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).
In any case, for my org it would mean ~5x cost increase. So yes, nice spin.
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.
It's also nice for student, like myself, who get unlimited private repos for $0 a month.
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 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.
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.
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."
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.
> 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.
I get my private repos free, but I can only work with 5 people on them before I have to start paying.
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.
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.
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.
https://www.visualstudio.com/products/visual-studio-team-ser...
As an individual this model makes way more sense for me. I pay the same as before but get unlimited private repos? Awesome.
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?
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?
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.
it really depends on your perspective. i significantly prefer per-user over per-repo. i can see how per-repo might benefit others, however.
What to you is a fair price and why?
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.
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.
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)
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.
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.
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.
I'm glad there's at least a year that we can keep using the old plans.
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.
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!
(If you were an organization with few private repositories and large number of users, Github was earlier more affordable.)
And teams of up to 5 people.
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.
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!
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?
We switched from GH:Enterprise and saved $1000's a year. Worth it.
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.
GitLab and BitBucket are going to eat GitHub's lunch if they don't change this crazy pricing model.
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
⇒ 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.
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...
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)
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.
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.
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.
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.
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)
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.
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.
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?
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 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).
Companies using micro services? Companies that don't want to have one big repository for their software?
Team | Cost Before | Cost Now
1 repo, 100 users | $25 | $880
It appears that along with this announcement they are raising the prices of an account.
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.
This is a great news for me.
I personally also use Gitlab for private side project repos and only use Github now for open source projects.
With that being said, in those types of environments, cost is everything, and BitBucket is still the cheaper option.
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.
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.
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.
Any startup architected around microservices, for one
The real place where it hurts is users who aren't paid employees.
> These users do not fill a seat: Outside collaborators with access to only public repositories
https://github.com/blog/2164-introducing-unlimited-private-r...
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.
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.
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.
Gotcha.
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.
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.
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.
Do you seriously believe that programmers everywhere in the world are making the same money as ones at Bay Area?
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.
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.
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.
Then shouldn't they be using the organizational plan?
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!
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.)
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.
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.
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 :-)
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.
Billing screenshot: http://i.imgur.com/k1F0BxA.png
Just my 2c anyways, happy to hear feedback on why I'm wrong :)
This is shortsighted on their part, I hope they pay attention.
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.
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.
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.
Their strategy worked because when I moved my employer off of SVN, a paid Bitbucket is where we went.
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.
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.
The main issue with GitLab right now IMO is that it's so fucking slow at times -- ike seconds per page slow...
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.
> 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."
So you have an indefinite period of time + 12 months, not a hard 12 months starting now.
BTW on-premises GitLab installations should be fast already
I guess it can be a NFP that has closed-source repos. But why?
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 :)
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.
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)
> subsidized
Come on. Those things are not happening.
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.
Furthermore, Github's "Education" site doesn't actually say _what_ the acadmic pricing plans are like, just that you can "ask for a discount".
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...
[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.
Thank you for posting this!
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 :)
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.
Passwords emphatically do not belong in git.
Your private repos should be maintained such that accessing them would not compromise your security.
Please tell me you're kidding.
[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...
That's an extreme example, but we also have a single repo that a lot of collaborators get access to.
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.
Also, more users = more problems.
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.
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.
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!
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.
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 work in a small agency, and our GitHub bill will go down as a result of these changes.
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.
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.
Jira, HipChat and Confluence are really nice tools, but pricing seems to just snowball.
Let me brig another example for OSS projects that could need a private repository: 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.
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.
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.
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 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.
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...
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 ;)
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.
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."
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.
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. :)
"These users do not fill a seat:
Outside collaborators with access to only public repositories"
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).
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.
Wait, what?
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
"Being a nonprofit" doesn't mean "developing open source software".
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?
(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.)
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. :)
I'm more concerned about someone hacking the machine than someone hacking github to access the repo and retrieve the newrelic key from there.
- 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.
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.
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.
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.
[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/
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.
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.
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 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 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.
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 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.
http://doc.gitlab.com/ce/workflow/merge_when_build_succeeds....
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.
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.
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.)
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.
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.
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?
? 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?
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.
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.
Perhaps my biggest point of confusion with git comes from that nebulous intermediate structure which sits between the real working directory and the real repository, which sort of acts like a repository and sort of acts like a working directory. It has many names and no clear purpose, and it doesn't fit into my mental model of the work to be done when working with a VCS.
Your explanation of merges makes more sense from that context. I don't think of add/mv/rm as operations on the nebulous repository, because I don't have any idea why one operates on the nebulous repository; what I'm trying to do is tell git to track a file, or stop tracking a file, or notice that I've moved a file from one place to another. The fact that these operations also kind of half-commit changes to this semi-repository is just... confusing, because I don't know why one would care.
If the pseudo-semi-repository thingy actually made sense, perhaps it would seem more natural that add/mv/rm do things to it during merges. I suspect the behavior of checkout, reset, and commit might also make more sense; as is, they seem to be needlessly complex, because I am never manipulating the semi-repository on purpose: I'm either trying to move my changes from the working directory into the local repository, or I'm trying to update my working directory to match the local repository, but in no case am I ever trying to half-update the intermediate state I can't actually see.
Given this somewhat confused explanation and the fact that you've done a great job of explaining what git is doing so far, can you point me at something not written by the git authors that explains what the hell is going on here and why? I would like to understand the tools I'm using instead of just blindly typing arcane rituals cribbed from the internet, but as I said before trying to read the git documentation just leaves me more confused than before I started.
If so, I would describe the index as a sort of staging area for preparing your commit. You might not necessarily want to include every single change in your workspace in your next commit. The index allows you to pick which things you want to go into the commit then git-commit creates the commit from what's in the index. If you don't care for such behaviour, and you just want to commit all changes in tracked files in your workspace, git-commit -a does that.
This[0] is one of the best tools I've seen for understanding git commands and even a bit of how git works. It's interactive, divides things into the different 'places' that content can be in git and then shows you how each command moves content between those places. Click on the workspace and it will show each command which does things to content in your workspace, the bar the command is written on shows what the other area it interacts with is and the direction that the command moves content. I hope it helps. [0] http://ndpsoftware.com/git-cheatsheet.html
I might add that if you didn't have the index, then you could not make a commit that contained an add, a rename, and a deletion. If you think far too deeply about how Subversion handles these operations, it becomes clear that -conceptually- Subversion had an index/"staging area", too. Ferinstance, the output of 'svn help add' says
add: Put files and directories under version control, scheduling
them for addition to repository. They will be added in next commit.
usage: add PATH...
The big conceptual distinction between SVN and git is that with SVN you tie exactly one repository to a given working copy. In git you can tie multiple repos to a given working copy and (by default) one of those repos is stored in the same place as the working copy.
Does that make sense, or is the index still somewhat-to-rather unclear and/or mystifying? (I mean, other than its kinda crappy name.)
> ...can you point me at something not written by the git authors that explains what the hell is going on here and why?
If "here" is "with git in general", I read the Git Book [0] ages ago, and combined what I learned from it with a fair amount of fucking around with my repo, and also with the contents of the gittutorial(7), gittutorial-2(7) and (parts of) gitglossary(7) man pages. [1]
From looking at the ToC of the Git Book, it looks like chapters 1, 2, 3, and 7 would be relevant to your interest. Chapters 5 and 10 might be relevant. I can't offer any guarantees, as I last read the Git Book ages ago, and this look like it's a new version... the one I read didn't make any mention of Github.
Though, if you were asking about something more specific, I'm happy to take a stab at answering that question once I know what it is. :)
[0] https://git-scm.com/book/en/v2
[1] Even though you asked for things not written by the git guys, I got a fair bit of value from the official git tutorials. It's also possible that you've overlooked them, so I bring them up.
I'm often overly verbose, but am typically too lazy to write shorter comments. I considered re-working my comment to address your edited comment, but I think that it covers both comments.
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.
It's just one role, but multiple users.
Also, does this rule out hosting on clouds that don't offer vTPM support? (Are there any that do?)
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...