Hi HN, I'm the CEO of GitHub. Everyone at GitHub is really excited about this announcement, and I'm happy to answer any questions.
We've wanted to make this change for the last 18 months, but needed our Enterprise business to be big enough to enable the free use of GitHub by the rest of the world. I'm happy to say that it's grown dramatically in the last year, and so we're able to make GitHub free for teams that don't need Enterprise features.
We also retained our Team pricing plan for people who need email support (and a couple of other features like code owners).
In general we think that every developer on earth should be able to use GitHub for their work, and so it is great to remove price as a barrier.
Hi Nat, with Microsoft now owning Github, I'm really curious to know what the future holds for both Azure DevOps and Github?
I'm a user of both - Github for OSS, and Azure DevOps for private work. IMO, these areas are where they are best suited - pipelines in particular are really powerful in Azure DevOps, and user/permission management, AAD integration and integration with build agents are all excellent.
I really like Azure DevOps, but all this has me worried about it's future - do you know if it's going to continue to exist and be developed in tandem with Github?
Both products have a bright future and millions of users, and so we're continuing to invest in both for the foreseeable future. We're also finding ways to improve integration between them, so people can use them together if they want to. GitHub Actions reuses a bunch of code from Pipelines under the hood, for example.
After listening to episode 321 of The Azure Podcast[0] my understanding was that Azure DevOps would eventually be phased out; question begins at ~10:30 and at about ~12:00 a rough timeline of 5 years was given with guidance to select GitHub if just starting out.
As somebody who uses Pipeline (well, VSTS Releases, we're not on Azure Devops yet) professionally, I've got to pick up GH actions now. Hadn't gotten around to it.
That said, like 90% of my Pipeline actions are "screw it, I'll do it all in PowersHell"
I get that you guys want to say that publicly, but let's be real. No company would invest a massive amount of money in a duplicate product. One product will eventually starve.
I guess it is up to us to guess. Anyone?
I see GitHub being the unmovable giant here. Microsoft is publicly developing on it, as opposed to Azure Dev Ops. It has a very large mind-share. More developers are willing to use it without having the Microsoft stigma that some nix people feel.
> No company would invest a massive amount of money in a duplicate product.
I don't mean to be rude, but have you worked at a very large company like Microsoft or Amazon or Google? Redundant products are par for the course because of the byzantine internal politics and funding structures of big companies.
Google sure, but Microsoft? The company that kept the Zune service alive for 4 years after the product was EOL and with a userbase likely measured in the hundreds of thousands?
Ya... I would hardly say MS is known for killing stuff early - more like they've spent years being ridiculed for carrying baggage forward for decades longer than anyone else.
MS might be bad at a lot of things, but I'd hardly say they're known for "burning products with little notice".
Have you done any development work on .Net in the last 10 years or so. I've been buggered at least 5 times by massive discontinued chunks of stuff and the several reorganisations that got rid of my entire selection of enterprise customer and MS connect cases conveniently.
Well, probably not because of Bob, but their cloud based offerings have make me wonder about trust.
- Business Contact Manager for Outlook, Outlook Customer Manager
- Microsoft Invoicing, Listings etc.
And these are critical applications for a company.
Have a look at Sharepoint which is widely used and has an uncertain future. Or the strategy behind Lync, Skype and now teams.
But we'll see. Microsoft has shifted in a good way in the last couple of years but their track record in keeping legacy operating system APIs for decades is not necessarily a good indicator of the stability of their other product lines.
Business Contact manager is still fully supported - it's just not supported on the latest version of outlook. On Outlook 2010 you've got support through the end of 2020. For Outlook 2013 they haven't announced an end-of-support date yet.
Microsoft Invoice has transitioned to a cloud-based product, so again, they didn't end support. You might not like the new purchasing model, but that's very much different than them burning the product to the ground.
Sharepoint has an uncertain future? I had never heard of it a year ago, but as I got to know the "enterprise" space, it seems every large company is heavily invested in it. What might replace the need to share documents across a company in the MS world?
well a lot of things in the business section had a different production which could directly import the data from the old one or different migrate the data. like business server essetnial or dynamics marketing most often the new stuff was more expensive.
Even skype for business online is upgradable.
some stuff has less features, like hotmail which could use all custom domain names and not only godaddy ones like outlook.
WCF is still supported and a lot of stuff works on .net core 3.x and more is coming in 5.x. webforms on the other hand... (which should die a more faster death)
ADO is widely used inside Microsoft, with a variety of internal extensions to integrate with our internal build & deployment solutions.
AFAIK, there aren't any plans in Azure to give up ADO in favor of GitHub. If anything, with the push to standardize builds internally, it wouldn't make sense to move to GitHub for at least another 2-5 years.
Obviously, I don't speak for my employer and leadership may have other directions in mind.
Even then... I don't expect Github actions to go away any time soon. I would expect a lot of the underlying systems, build agents and workers to be the same over time though.
Azure DevOps and Github largely cover different, though overlapping market segments.
I would be slightly more concerned about Github Enterprise and Devops co-mingling over time, as I think that may be inevitable, which makes me concerned over the public/free resources that Github offers in the long run... even then, migrating to Gitlab is an option should that time come. My only hope would be better discoverability and social coding with Gitlab to better match Github over the interim time.
Even then, it's just a possibility and somewhat unlikely that MS would burn this much karma.
They clearly capture different markets and are both doing well. Why is is it inevitable that one will starve? I feel like that's only likely to happen if a new CEO comes or something and decides to shake things up.
Same question here. We use the hosted version of Azure DevOps for work, but I use github for open source contributions. They both have their place, and DevOps feels more suited to enterprise use than GitHub right now.
Without an official explanation, given the timing, it'd be reasonable to assume you pulled development resources away from it, the exact thing you actually went on Reddit to claim you wouldn't do:
P.S. I've observed that these kinds of posts tend to turn into a place where people shit on Atom in favor of _insert preferred other editor here_. Feel free to do that here too, but just note that I'm not going to be obliged to engage since it's completely orthogonal to the topic at hand. I think any remaining Atom users at this point are likely already painfully aware that Atom has long since lost the war in developer mindshare, but don't let that stop you from pouring salt on the wound.
Microsoft owns Github. Microsoft owns VS Code. VS Code is superior to Atom. Do you need an official comment? It seems abundantly obvious to me.
Nat is the CEO of GitHub, not Microsoft, and despite any promises made on a Reddit AMA a year ago, why would they devote resources to two competing editors?
All I really want is to hear an explanation from Nat Friedman, CEO of GitHub, the human being, who said he wouldn't pull resources away from Atom development and then evidently did so soon after, to end all this needless speculation once and for all (and what you've suggested in your comment is still speculation, however plausible it might seem to you).
It offers very little solace to the few Atom users still hanging on, but I think the least he could do is end the speculation, and provide some certainty on Atom's future as a GitHub/Microsoft funded project so we could decide to either move on or stick around for longer.
Please realize that there still hasn't been an official statement that Atom's development at GitHub/Microsoft has been halted/dramatically reduced, or that they hope to transition it into a community led project, or anything to that effect.
I hope an official nail in the proverbial coffin is not too much to ask for.
EDIT: This comment was a lot snarkier in an earlier iteration. In hindsight, I realize that was in bad taste, so I've reworded it and adjusted the tone. I don't think being needlessly confrontational adds any substance to the discussion here (or anywhere else for that matter), so I would like to apologize for that and hopefully de-escalate so we can resume civil discourse.
> But the words of the linked Reddit comment from Nat Friedman were "we will continue to develop and support both Atom and VS Code going forward"; that's a true statement today. Atom is currently being developed and supported. That's a case of adhering to the letter of the statement rather than the spirit, I know. But that circles around to the problem of VSCode's rapid ascent in mindshare -- if your company ends up owning two very similar editors and they both have roughly equal downloads and community interest, you might try to support both equally. But if one of them has orders of magnitude more downloads and community interest than the other, you're going to focus your efforts on the popular one.
This is the second time I've seen a comment from you complaining about Atom development when an unrelated Github article is posted. What's the purpose of these posts? Do you expect Github to start funding active development of Atom again?
If not, what's the goal of the complaints? I.e. why do you keep bringing this up if you know this is water under the bridge?
I'm a github user, though I wouldn't call myself a fan exactly, and I don't really know how "teams" works or why it's valuable. I came to this thread to learn more, and I find your comments grousing about Atom again. Hence my question.
I can only speak for myself as to why I posted here. And I really just want an answer for the question I posted (I'm not naive enough to believe a post like this has any chance of changing project priorities at a megacorp). I wrote about this in a bit more detail here: https://news.ycombinator.com/item?id=22875388
And judging from the upvotes, a decent number of people want the same question answered. If you don't care about the answer, my recommendation would be to simply collapse the thread, downvote if you must, and move on.
I'm honestly puzzled as to why so many people seem to be actually offended by the very fact that I'm asking the question, and even seem to be taking it somewhat personally, even though it's not directed at anyone other than the OP.
> I'm honestly puzzled as to why so many people seem to be actually offended by the very fact that I'm asking the question
Comment quality and civility has dropped in the last few months.
I don't use or even like Atom but if this natfriedman says it will be continue to be supported post-merger, then it isn't, then he needs to clear the air.
I did confuse you with someone else. lewisl9029 opened this question last time, you were further down thread, apologies.
Mostly I'm curious, just like you. You're curious "what happened to Atom development", I'm curious why people bring this question up over and over on unrelated GH threads when they already seem to know the answer–to wit: active feature development on Atom by Github/MSFT has stopped and will not resume.
I don't see the point of derailing threads/starting editor flame wars over this question, but I am frequently missing some crucial point. So I ask: What am I missing? What's the point of these "what about atom!!" questions when you know the answer already?
I think you're taking that specific opening question a bit too literally (though to be fair, I'm also at fault for not being as direct as I could have been with my point). It's fairly clear from the rest of my post and from the linked posts that I'm fully aware that Github/MSFT-funded Atom development has mostly grounded to a halt.
These are the actual questions I'm trying to get at:
What made Github/MSFT stop funding Atom development when their CEO went on record to say they won't?
And why haven't they announced that was the case officially?
If the very same CEO then goes on an AMA on Hacker News, surely it's fair game hold him accountable to previous public statements and ask him to clear the air. If this was just some random scrub posting their thoughts on the acquisition I definitely wouldn't have wasted my time to bring this up.
Makes sense that you'd like some sort of apology or mea culpa from the CEO, who has not been completely forthright. I know you don't want answers from me specifically, but here's my thoughts:
> What made Github/MSFT stop funding Atom development when their CEO went on record to say they won't?
Because circumstances changed and it made no sense to continue to do this. Atom shrank as VSCode grew by leaps and bounds, there's no clear business case for continuing to develop a withering product.
> And why haven't they announced that was the case officially?
Why would they? Why go out of their way to print upsetting news (to some) in a 40pt headline, when the writing is already on the wall for anyone who cares to read it? i.e. what's the benefit to the company of doing this?
I think the better question for the Github CEO was "why did you ever promise to continue supporting Atom? You either knew this was not possible, or were making a promise you could not keep, either one is bad." And the answer to that is probably "to avoid creating a furor around cutting Atom off at the same time as the acquisition was announced." But yeah hearing him say that would be useful.
I gave up on Atom when it was released because it was the most slow editor I have ever seen.
It single handy bias me against Electron app until I discover VSCode.
Slow or no slow, I couldn't understand how it works. Windows kept opening wherever one least expected it, i got multiple copies of tabs with some introductory help text when i just wanted to get back to my project etc.
For once, I'm not going to complain that something is made in Electron :) It was unusable to me in other ways too.
Hey Nat glad to see you here. A few days ago one of the biggest team collaborative games (Space Station 13) got banned on GitHub without a public explanation from GitHub staff, but some suspect it was because the code contained bad words and slurs. Do you know if this is why the project was banned, and will these new private team repos be subject to the same terms/rules?
Do you think the scale could be handled better if you informed repo owners 1: that their repo was disabled, and 2: why their repo was disabled?
Currently the owner has to contact support to know why it was disabled, our repo was disabled thursday at 5am pdt, we sent a ticket by 6am. We still don't know why it was disabled. Its tuesday. (edit: we did get a reply, vague comment about slurs, nobody's sure if its the nword word filter (so thats getting removed, ironically enough), or the comment from 2014 with a soft-a, (but it can go), or the fact that the meatball food item has a, umm, british name)).
Also, do you think the scale of content moderation would be easier if you tiered repo disables between can be resolved and can not be resolved, and in the former case provide the same 24 hours deadline that you provide line item dmcas, as well as provide access to the owner during any suspension if the 24 hours deadline is not met (That you also provide to line item dmcas)?
All of these unneeded trips to support has to be eating into the efficiency of things.
No, it’s not fair. Banning a repo should be taken as seriously as banning a book. Living in a country that is US where github HQ is hosted, freedom of speech should be prized and cared for dearly. For a commercial company, there should be only one reason to ban a repo and that is to abide with a law. For even that company should do everything in its power to prevent that or provide a viable lawful alternative. This should be taken so seriously that each ban should have been reviewed at CEO level. GitHub CEO saying he has no clue, it’s a scale issue and “mistakes are made” is not really acceptable.
I appreciate the idealism here, but the reality is that trying to run a business under the pretense of free speech absolutism can alienate an otherwise profitable market segment. With the loss of that market segment likely comes the grumbling of investors, to whom ultimately the executive management is beholden.
Grumbly investors beget grumbly board members, who then vote to oust executives to correct the profitability problem.
I think this is the most sensible answer here. My sibling comments are attempting to draw analogies to other types of censorship of minority groups which don't strike me as apt.
IMO you correctly summarized the forces they are dealing with. These people are just trying to make money. Idealism is problematic for the people invested in the company that aren't there for idealism, but money.
> can alienate an otherwise profitable market segment
How are you going to alienate/lose customers by not getting rid of customers? If anything, I'd argue the opposite; a platform that refuses to ban legal content is one that I find easier to trust (for a counterexample, see Google). It's not even like github-like companies are social networks where you can claim that one user's experience of the platform is made worse by another user's posts.
We all know that the most vocal on the left, who want to silence anyone who doesn't pander to their political ideals, pressure public companies, advertisers, etc. to 'cancel' those who refuse to go along - drop their advertising, cut off their servers, purge their DNS, ban their accounts, shame them relentlessly until they disappear.
Most US companies these days have no morals, and are easily influenced by these tactics due to greed and fear of being targeted themselves. Silicon Valley and the majority of the big tech companies seem to be especially vulnerable to this, probably due to their own employee demographics.
What many of these companies don't understand, possibly because they live in a relative 'bubble' surrounded by those who think similarly, is that there are a lot of us out there who not only disagree with this type of behavior, but will actively NOT use the services of any company who supports these types of tactics.
You aren't the customers in this situation. For every 10,000 of you who don't pay even pay GitHub the $7/mo for a subscription, there's a 3000-seat behemoth who pays $70k/mo for a GitHub Enterprise license.
You're principled minnows to that one profitable shark.
These companies understand profit, and that's where they derive their morality. I'd say it's probably more accurate that most US companies simply don't share your morals, not that they don't have morals at all.
Follow the money. This is a much more useful lens to analyze the situation than to consider the left/right political spectrum.
Sure, but that "lot of us" out there is a much smaller and usually much rowdier group of users that time and time again companies have been happy to wash their hands of. You're not profitable enough (and I'm not even getting started on the morality or ethics side of this).
I have assumed that many tech companies, especially in California and other liberal strongholds, hold this opinion. Like I said, they live in their insular bubbles, and imagine that the rest of the country is either deplorable and poor or they share their views.
Meanwhile, I work in a relatively conservative industry that also happens to have one of the largest budgets of any 'company' in the world. I have seen first hand when vendors were being evaluated for multi-million (or even billion) dollar projects, both Google and Github being crossed off the list without a second thought due to some of the publicly made political statements and actions of their executives and employees.
Why do people always feel the need to bring "the left" into this? Wanting to silence people who disagree with you has nothing to do with either the original definition of "left" or the parties considered "left" these days.
The same kinds of "censorship" that you talk about coming from "the left" can be found in extreme parts of every ideology. Conservatives (probably of the rich and christian variety) have pushed many platforms to completely remove all even slightly adult content (the latest example being Tumblr), all sides of the political spectrum have been pressuring sites like YouTube to the point where no political discussion from any side can be monetized...
This is not an issue of political sides - it's an issue of politics (and society) in general.
As for the part about companies not knowing about the people who don't approve of this behaviour: they do. They know exactly how many of us there are: not enough. Losing even a single big investor will make a company lose more money than if everyone who disagreed with them completely stopped using their services.
This comic is abused so much that I wonder if Randall would ever consider a follow-up poking fun at how it's wielded. It's meaningless in a normative, rather than legal, conversation such as this one.
You making the argument that to make some religious customers/investors happy, it's ok to mistreat LGBTs. After all, they are such minority segment and, you know, we are all here just for shareholder wealth maximization.
"Banning a book" colloquially means that nobody is allowed to read that book, it conjures images of book burnings and the gestapo searching your house for contraband. "Banning" a repo here means, "Github is not offering you free resources to develop your code. Fortunately, you're using a distributed source control management scheme so everyone has a backup. Please take it elsewhere."
Agree strongly with this. If a repo is public and gets banned, I think it's reasonable to expect that the community can know why, regardless of the rights or wrongs of the decision.
It seems reasonable to expect this, but it can fall down in practice for several reasons:
* Sometimes legal counsel provide advice that there should be no further response to the individual or organization. Often technical people don't understand this situation, but it doesn't change the merits of the legal advice. In smaller organizations a leader might take a chance in further engagement, if they think it's helpful, but it's unlikely a large organization would expose themselves to this risk.
* Breakdown in internal response processes. You'll find that many people are really uncomfortable in these situations (e.g. compliance team shut down service, but don't "own" the response.) Unless the legal team has written a response and instructions on how to deliver it, you will often see people in organizations avoid giving the response. Things get passed down as low as they can go which doesn't help because there is less experience with handling tough situations. Very often some poor person with support ends up having to give the response and they basically ignore it because they can avoid the situation. This isn't very professional of the organization, but it's a reality.
We're living with transparent juridical system and it works fine. Imagine that you could be thrown to jail without explaining a reason. That would be outrageous.
Yeah, criminals are always arrested and convicted. /s
It's a balance. With something as essential as human rights and personal freedom, people (tend to) err on the safe side. Online moderation can err on the other side, since consequences are relatively modest. If you get banned on GH, move to Gitlab or host your own, that's hardly a tragedy.
That is exactly what I do. I use self hosted solutions for my source code repositories. I just can't digest my code being handled by some other entity. Too important.
Amazing that you got downvoted for this. I pay for code hosting precisely because I want to see an ecosystem of code hosts, and monocultures are dangerous.
Well I've never downvoted a single post no matter how much I disliked it. Personally I consider this a kind of weakness and the whole system as promoting herd mentality. But whatever floats their boat.
Exactly. Screw around and try to game/skirt the law IRL and the risk is way too high that you'll goto jail anyway. There are usually no consequences for doing this online.
Compliance with the spirit is the objective. Sometimes the spirit and the letter differ for any number of reasons (many of which are completely reasonable).
People tend to get pretty upset when someone is very clearly complying with the letter while flying in complete opposition to the spirit, and it's not always an easy fix.
In that case, it sounds like the letter needs to be fixed. It's not fair to expect people to follow an ephemeral ideal of what the rules are rather than what they're told the rules actually are.
Like I said, it's not always that simple. When it's not, something less than 100% transparency allows one to look at the given particulars of a case and determine whether or not someone is simply trying to evade the spirit of a rule or not. It gives enforcement actors a little lee-way that they wouldn't otherwise have.
One of the worst things about engineers in general and HN specifically is we all pretend that law is executed like code, in a vacuum, idempotently based on the inputs. That's was, is, and will never be the case.
Abuse can be exposed and punished, and very often is.
That's why the letter of the law needs to be updated to better reflect the spirit. Imagine if police could arrest you, and keep you, without telling you why. That's something that society figured out a long time ago isn't healthy.
> Imagine if police could arrest you, and keep you, without telling you why. That's something that society figured out a long time ago isn't healthy.
The judicial system that backs it is a massive beast. If someone wants that level of assurances, they should be paying thousands of dollars for a github account. You get the level of perfection you pay for.
So far it's been mostly small / independent developers or organizations that were banned, and Github has Microsoft behind it, a $125bn / year revenue company with a legal team 1,500 strong (https://www.bizjournals.com/seattle/news/2019/12/02/how-brad...). I don't think fear of litigation is the issue.
The very first thing a corporate lawyer does is proactively prevent litigation through protective policies that specifically do NOT emphasize transparency.
Whoa, wanted to jump in here! SS13 is, in my opinion, one of the best games of all time when it runs well. Not very many people know about it.
I worry about the community dying and losing my favorite game, but have taken solace in the fact that the source will always be publicly available. If it was banned from GitHub, that's a major problem.
Is it? There are several GitHub alternatives, many completely free as well, and none of the source was lost unless all the maintainers and contributors also delete their local copies.
The alternatives don't have the mindshare that GitHub has when it comes to open source software. If the community around the game is already weak, moving to another provider will likely weaken it even more. The source won't be gone, but that's only half of what matters.
If it was the bad words/slurs, could that have been resolved by hiding them behind some basic string manipulation (ex. a caesar cipher)? I can see how GitHub wouldn't want a public repo to have objectionable words, but can't imagine the harm from obfuscating stored copy.
> I can see how GitHub wouldn't want a public repo to have objectionable words
I can't. Does GitHub really have nothing better to do than to play nanny cop because I used a naughty word in my code? Are brainfuck interpreters now off-limits? How about drivers for teledildonics hardware? Or libraries specifically for detecting and filtering swear words? Or maybe I just want to vent a bit in a comment every once in awhile because of some annoyance with the language or target platform or problem to be solved?
Fuck that and the horse it rode in on. We're all adults here (well, or possibly teenagers, but let's face it: they've probably already heard much worse at school).
If only we knew that 4 days ago when we first got banned, and not, well, 4 days later.
The issue is github works by report only.
You can do what ever you want in a github repo, but if you make a video game on github, and ban the wrong person, they can just go through your repo and look for ToS violations to troll you.
We are literally removing the in game chat word filter for the n word out of fear it could be used to git us banned again by somebody else mad their buggy pr got rejected or their character got banned in game for breaking the server rules
If that's official GitHub policy it's both unworkable and exceedingly ignorant of how people use the English language outside of the US. GitHub should have no business telling people how to write their source files.
That said, the news made me wonder what exactly I’m still paying for with my personal Pro account. I went to the pricing page https://github.com/pricing and it seems Pro isn’t even listed anymore? And the Billings page https://github.com/settings/billing says “Pages, Wikis, protected branches and more for Pro developers” without any further explanation or link to docs explaining the differences. I can only assume that Pro has the same set of features as the $4/user/mo Team plan, but the messaging is certainly pretty confusing, don’t you think?
(I sure hope this isn’t a sign of neglect for individual developers, who are still the backbone of open source activities.)
Thanks for the confirmation, that’s what I figured. It would be nice to see this laid out somewhere public, preferably the pricing page, not gated behind a free account.
I went to go downgrade to the free plan and noticed that GitHub Pages static sites served from Private repos still require payment. That will keep me on $4/month for now.
I'd like to thank you for this change but also in general all the amazing things Github is doing. I haven't finished high school yet but your Github Education pack is SO useful for me and I know I will never have time to use half of the stuff on it.
Thanks to everyone at Github making stuff like this possible and creating such a great epicenter for open source in general. Keep on being awesome!
Also I was wondering, Github is offering so many features for free, but does the company sustain itself through entreprise payments or some other stream? I was just curious. :)
Glad you like the Student Developer Pack. All credit goes to the 100+ partners who provide something like $200k in tools and services to each student who qualifies for the pack. It's kind of mind-boggling, actually.
As for how we sustain ourselves -- lots of big enterprise customers!
Good point. For anyone using the Student Developer Pack (or any other similar student offer), ask yourself this: Do you really want to become reliant on software and services that will cost you ~$70k/year as soon as you graduate?
Well, unless they decide to switch market or shut down, in which case you're hosed no matter how much you're willing to pay.
You can see that there's a lot of overlap and that these offers cover very broad sections of the industry. This gives students the opportunity to explore and develop immediately employable skillsets without impacting their already limited budgets.
And you only use a subset. And your employer is typically very happy to pay money for productivity.
For sure this is to the benefit of the involved companies. But paying for good tooling is normal not strange. When you go to your local handyman he will tell you a lot about good and expensive tools.
> And your employer is typically very happy to pay money for productivity.
And that's money that's not going to better equipment. Or your salary. Or whatever else that it could be spent on that would have a far bigger effect.
> But paying for good tooling is normal not strange.
Paying for bad tooling is normal. Good tooling tends to come as a consequence of trying to solve something else.
Bad tooling also tends to be much more expensive to produce, because it's so prone to scope creep. Visual Studio had to build their own Docker wrapper, because telling people to just use it directly would give their users a glimpse of the outside world, and we can't have that!
> When you go to your local handyman he will tell you a lot about good and expensive tools.
The vital difference is that physical tools are expensive to duplicate and maintain. You can't distribute a hammer via BitTorrent.
> Visual Studio had to build their own Docker wrapper, because telling people to just use it directly would give their users a glimpse of the outside world, and we can't have that!
Do you actually believe this was the reason behind developing Docker wrapper for VS? I mean you can always try stretching out the worst intention and motives, but do you actually believe this?
Suppose you do, how do you think about the gazillion 3rd party open source extensions to VS code? Did Red Hat develop OpenShift extension because they are part of the conspiracy too? Do you think that this is part of course change due to the IBM acquisition?
>The vital difference is that physical tools are expensive to duplicate and maintain. You can't distribute a hammer via BitTorrent.
The fact that you can distribute software for nearly free doesn't make the cost of producing it to be cheaper than hammer.
> Do you actually believe this was the reason behind developing Docker wrapper for VS? I mean you can always try stretching out the worst intention and motives, but do you actually believe this?
I don't think there is an explicit conspiracy. I do think there is a negative spiral where IDE addicts (for the lack of a better term) produce tools that "help" others avoid leaving their comfort zone.
I'm not immune to it either. When trying to learn Kubernetes I spent weeks fighting the graphical dashboard before just hunkering down and learning the core concepts and building my own intuition.
And I still like having an integrated environment. But with Emacs I'm at least generally just a `describe-function` or `describe-key` away from peeking behind the curtains.
> The fact that you can distribute software for nearly free doesn't make the cost of producing it to be cheaper than hammer.
Bad analogy. Producing it would be closer to developing the blueprint. Which is:
1. Done once
2. Tends to happen without economic incentives because, as it turns out, you probably want a hammer too
> I do think there is a negative spiral where IDE addicts (for the lack of a better term) produce tools that "help" others avoid leaving their comfort zone.
Alternatively, many people see value in focusing on what they develop and not have to bother studying the fine details of the underlying platforms they use. As someone who live deep down in detail and assist others using tools in the whole range from IDEs to cli, I have no disrespect for engineers who won't bother spending their time on knowing the subtitlities of the systems where their code will run.
>Bad analogy. Producing it would be closer to developing the blueprint.
Software tools are far from blueprints that are done once, they require constant maintenance to be compatible with changes in other tools and environments, bug and security fixing as well as implementing new features that users request.
Software development is extremely expensive, libre software is free only because someone is paying the cost of production and prefer to distribute it for free. Probably most of the open source software today is paid for by big companies, and their aim is usually to gain something from the investment. Docker wasn't developed as a manifestation of free speech, nor was Kubernetes born under GNU's roof. If not for the piles of money Google and Red Hat spent on it, Kubernetes couldn't be anything resembling the amazing beast that it is.
> Docker wasn't developed as a manifestation of free speech
Docker was developed because a cloud provider (Dotcloud) wanted a better way to package their own and their customers' software. As it turned out, Docker was succesful while Dotcloud failed spectacularly. So Docker became the main product.. and now that failed too, as of a few months ago.
In short, Docker's development was payed for by a company for commercial purposes. Moreover, it was build as an abstraction over kernel features so that developers won't need learn anything about them. It's success is product of the fact that tools can create extremely useful abstractions and when they do people benefit from using them and depends on them.
This is a great change! One request: I wish that SAML was not an enterprise feature. SAML ought be a basic security feature like 2FA—it's especially valuable for open source teams who might use a mixture of services, and an easily accessible and cheap SSO solution would go a long way in raising the security bar for all teams, not just open source teams.
SAML (and 2FA to a lesser extent) comes with some serious support burdens on the companies offering it. There's a long tail of more or less broken SAML implementations on both the service and identity provider sides, provisioning issues, configuration issues, "Sally can't login on Tuesdays" issues, duplicated slightly-inconsistent data in IdP and Service side records issues...
If you as a SaaS provider outsource your SAML integration to a third party provider like Okta or Auth0, the auth provider pricing is immediately on a "call us" tier, with a per-federation pricing in the low four figures for each company connecting via SAML. Let me just state that again, to have company X connect to my SaaS via SAML, I as the SaaS provider have to pay my auth provider $X,000 per year for the privilege, not counting the base enterprise tier pricing for the auth.
It's a paid service, but AWS Cognito supports SAML in a similar way to Okta/Auth0 but with a much lower initial cost (you just pay a reasonable rate for what you use, not multiple thousands of dollars to get it up and running). I used it to build a SAML integration at the end of last year and have been pretty happy with it so far.
I've looked at Cognito in depth, and it seems like an abandoned service. Hundreds of open issues that got rolled into the Amplify issue tracker, with little to no response. It lacks some pretty basic SAML capabilities, like IdP-initiated logins. If your customers want to put you as an icon in their Okta dashboard or whatever, can't do it. They reported that as being "on their roadmap" in 2017.
It does work for the basic use cases, so I would still consider that an better option than rolling your own for the average service provider.
Sounds like SAML needs the same "everyone gets together to make a FOSS implementation that knows about the weird quirks of all the implementations it interacts with" approach that e.g. the Samba project was founded upon.
I agree. There's a million SAML for Java/Python/Node.js/Foo libraries out there, all with a long list of issues and known cases that don't work correctly, security issues etc. but it's the wrong model in my opinion.
Instead of directly bolting SAML into your app, I think a FOSS implementation of an independently running service is the way to go. You run the battle tested open source service (locally / in your cloud), it accepts the SAML assertions and mints something sane like JWTs which can easily be consumed by the service providers, isolating the entire thing from your core app and allowing it be used with any stack. E.g. essentially an open source locally deployed Okta. Doesn't even need to do any user management, just focus on rock solid interoperability and forward all decision making to the actual app server.
If you want JWT tokens, you should be using OpenID Connect instead of SAML. There is very little reasons to use SAML in 2020, it's over complicated and has little support. OpenID Connect does 95% of the same, much better.
If you want self hosted IAM solutions. The most common one is Microsoft active directory. It provides both SAML and OpenID Connect integrations out of the box as of ADFS 2016.
Still, SAML requires to onboard applications individually, create keys, and stuff. It's not plug and play, it really needs humans on both sides to add a new service.
Unfortunately the demand for SAML is 100% customer driven. As service providers, we don't control the other end (the customer's IdP/AD).
Even in cases where the IdP supports both SAML & OIDC, I see almost no one choosing to use OIDC (a case of the devil you know?). The only real users of OIDC in an enterprise setting I see as a service provider, is G Suite businesses.
I think this is mostly driven by history. OIDC came in few years after SAML, so people are still thinking of SAML first and asking for it for enterprise integrations.
I'm pretty sure OIDC can be supported everywhere now. Okta, Oauth, PingIdentity, ForgeRock, Microsoft all support both. The last offender was Microsoft but it's included with active directory since 2016 both on premise or through Azure.
I'm working on auth for a big bank and it's definitely there, although not necessarily advertised and not everybody understand what is supported or preferred.
If a company were to only support OIDC nowadays, and maintain that OIDC is the preferred protocol when customers ask "can you do SAML?", I am willing to bet that most customers would integrate just fine either way.
> it accepts the SAML assertions and mints something sane like JWTs which can easily be consumed by the service providers, isolating the entire thing from your core app and allowing it be used with any stack. E.g. essentially an open source locally deployed Okta
This sounds like Shibboleth. The SP bolts onto httpd and delivers things like user attributes as server variables that apps can simply read. It even works if httpd is a reverse proxy in front of nodejs or whatever else, since you protect the app using location directives which play nice with proxypass directives.
The opposite certainly exists though, for example simplesamlphp which gets commingled into a php app codebase as you described.
This doesn't make sense. Login of any kind can be a tricky problem, you need to handle passwords, rate limits, email verification, password resets, etc. In most popular web frameworks there are libraries you can drop-in that handle all of this for you (like Devise in rails). There are drop-in libraries like OmniAuth (again for ruby/rails) to make handling multiple types of Oauth login simple.
The same could clearly be done for SAML (and I've even implemented SAML and SCIM auth and user management for Okta before in an app, it's not difficult).
The problem is that the only organizations that would make this single issue of SSO support a deal-breaker are bigger companies who can afford to be upsold, so everyone treats this as an up-sell feature. This comes at the expense of the smaller companies, who can't afford to care as much about security. The industry should be making things secure by default as much as possible, and there's a big gap here in what basically every SAAS company is doing.
> The problem is that the only organizations that would make this single issue of SSO support a deal-breaker are bigger companies who can afford to be upsold
That's not true. We are a tiny company (~10 ppl), but SAML, OIDC (or GSSAPI or Radius, if really necessary) support are a deal-breaker for anything we use.
We used to have separate accounts for everything we had. It became a drag, we had to solve it. Nowadays, either it can be integrated with SSO, or we will do without.
Passwords, rate limits, resets, etc. are the same for everyone, and so are the problems and the solutions to those.
SAML on the other hand is different for each organization. Providers pay Auth0 and the like to have developers on staff who know the pitfalls and quirks of ADFS 3.0 on Windows Server 2012 R2, so they don't have to. Dealing with a single Okta as IdP integration is like the absolute best-case scenario there is. There is also zero consistency in what actual data IdPs returns out of the box to the SPs, so now you're walking the customer's admin through setting up the proper attribute mappings, etc.
I also very much disagree that SAML is a net security benefit, at least directly. It's for convenience, top-down visibility and control into what people are using, de-provisioning services, onboarding and offboarding users at scale etc. e.g. problems that only big companies have. Many SAML implementations are just as likely to add truck-sized security holes to the service provider when done poorly, and a lot of them are done poorly.
It's a little odd to say something is not a "net security benefit" and, in the next sentence, make a powerful case for it as a net security benefit. SSO is probably the most important organization security tool there is, and a survey of tech company CSOs will average it in the top 3, if not the top 2 technology acquisitions most would make at a new firm (this is a question I've actually surveyed).
SSO is a great benefit to the customers, with real tangible security and management benefits.
I'm however speaking from the point of view of the service provider (the SaaS app) and about SAML in particular. I feel that the addition of SAML into a given service is a net-negative from that service's security point of view. It's a large additional complex attack surface, many open source SAML libraries that I've reviewed have a history (and in some cases open issues right now) of "pants on head" type of security errors. A popular library in use right now, has a known race condition where it gets confused if there are concurrent SAML requests happening.
And that's just the libraries. Then you have to use them correctly. The libraries do the absolute minimum checking since they don't have the context, you have to add a laundry list of your own checks to them. Just recently there was a HN article about taking SAML assertions posted to provider A and re-using them on provider B, where clearly the most basic of checks aren't in place at all. There's all kinds of confused-deputy type of problems I believe most service providers don't think about at all. And that was an easily offline checked attribute, I believe if you'd start to check how many services correctly implement even the basic "inResponseTo" check on SP-initiated flows (which requires a distributed cache on the service provider side), you'd find they don't.
I'm a security researcher with a minor focus in SSO libraries, working on OIDC and SAML right now. I've discovered and reported some of the kinds of issues you're referring to. Both OIDC and SAML are fraught in implementation, but so are all login features.
Meanwhile: we're discussing Github, not a random cat-sharing startup. Github has one of the larger security teams in the industry. The parties implicated in Github SAML are Github, Okta, and Github customers, who do not actually have to implement SAML. Github SAML is not in fact a net-negative for security.
100% agreed, GitHub SAML is unequivocally good. I'm in the "cat sharing startup", so my view and comments are colored by that perspective. Our options are to pay $$$ for a competent auth provider, or take on a much larger and complex security responsibility than it would seem at first, that might end up compromising our entire service.
I have a theory that one reason we don't see many your-SAML-implementation-is-completely-broken reports is precisely because it's a gated enterprise feature, so few independent security researchers have the access or ability to poke and prod at them outside of private penetration tests.
The riskiest components in SSO deployments are SP-side libraries, and those are all open source. If you want to use Okta to drive those libraries, the trial account you need is free.
The worst bugs here are indeed mostly private, but that's because they're feature bugs inside of people's random products; they're like every other bug in that regard. But people do find and report bugs in the SP libraries.
I agree that SAML is risky to implement; since we agree that Github SAML is an unalloyed good thing, we'd be searching for reasons to disagree at this point.
I'm surprised you'd say SP-side libraries are open source. In my experience, it's always been mostly custom and close source in every company I've seen and done.
You take some open source pieces you can (saml, xml, oidc, ssl, jwt) but permissions, groups, user attributes, keys are always per company then the whole thing together has to be supported into end-user applications running on language and frameworks of the day with their own restrictions, so custom.
I mean the company is writing it's own code for a significant part. Let's say one has to integrate SAML/OIDC into a Java app of some sort.
One can find an open source library to handle part of the SAML or XML in Java, but it doesn't take the right settings or import user attributes as needed or handle URL redirections properly. So the company has to write a ton of authentication code to make it work. It may start from an open-source library but the result is either separate code on top or an outright fork.
One will find a library to do the SAML. That library will almost certainly do the XML (most likely with xmlsec1). The library will have a call for the ACS endpoint, for the SSO login endpoint, and maybe for the SLO endpoint; it won't implement the endpoints itself, but it'll implement all the logic of the endpoint.
The company will end up writing a ton of authentication and authorization code --- it'll do that no matter what, because the application will have its own security logic, like all applications do.
(OIDC doesn't use XML. But the story is the same, with different endpoints.)
It's not a technology problem. Integration with "foreign" SSOs is complicated no matter what protocol you use, with lots of corner cases and support costs, but these features are expensive for the same reason that single-day-turnaround short-notice flights between Chicago and NYC tend to be expensive: the people who want them have money to spend on them, and it isn't their money. That money pays for the cheap seats everyone else sits in.
SAML is a technology problem, on top of all other problems.
The messages are under specified and overcomplicated, doing incredibly obscure stuff (XML signing and canonization for one) that nobody can understand and implement. That's mainly why it's so hard to use and there is so little support from libraries.
As security researcher, we could nitpick all days on security being hard, no matter the solution. It is factually true but it doesn't help developers, fact is, developers would be better off ignoring SAML and going with OIDC instead.
1. I don't think this particular thread is a good venue to litigate SAML vs. OIDC.
2. I think the product complexity issues are, like, 95% the same whether you use OIDC or SAML.
3. I think no matter how much simplification you got from using OIDC instead of SAML, none of it is going to offset the actual reason why SSO integration is a paid feature.
4. I agree that SAML is much worse than OIDC from a protocol implementor's perspective even if I'm not so sure that it's much better from a developer's perspective, so wouldn't want to find new reasons to disagree.
Ironically, the first point makes me realize that half the work to bring in a product in an entreprise is to deploy and set it up -properly with authentication- while the other half is to get the budget and approvals to buy it. Thus it's rather relevant to the thread in an unfortunate way.
And people keep saying that it's a security feature but that's not why large orgs pay for it. It's a "I'll pay you to not have to manually manage account access to all these different services.
If it's possible for GH to run a profitable business while offering SAML integration for free, I am 100% supportive of the suggestion. It's hard to say exactly how many enterprises pay specifically or exclusively for this reason, as opposed to other enterprise features, like audit trails.
Yes, I'm pretty happy with the new pricing but my employer will probably have to go with the Enterprise plan to get access to the "Audit Log" and HIPAA compliance. :frown:
Since they just said they were waiting for Enterprise revenue to reach a level where they could free the core product, and since SAML is an important driver of Enterprise upgrades (I've seen it happen), I wouldn't hold your breath.
Now that the core Pro features are free, I wonder if Rob will update sso.tax to set Github to :inf:.
Agree. I sell simple sass product myself and offer SAML to everyone. I view security as a basic right, not something to be used to extract more money for. Charging for additional features is ok, charging for keeping your account more secure is just plain wrong.
SSO is a security feature, not a convenience. It happens to be a security feature that comes bundled with some extra convenience, but it's not the only one like that; so are password managers.
SAML is the de facto standard single sign-on protocol for enterprise-grade applications. If a SAAS app integrates directly with Okta or OneLogin, it probably does so with SAML.
There's a lot of functional overlap between SAML and OIDC/OAuth, but SAML is a very different (and idiosyncratic) protocol; the "what" is the same, but the "how" is very different.
OpenID Connect is the standardized AuthN process built on top of OAuth. It’s “on top of” but in practice it’s a simplification if OAuth for the specific purpose of AuttN
I know, I just personally find it to be a fragmented and confusing set of standards. And a lot of people say OAuth when they mean OpenID Connect, which doesn't help with the confusion... or they abbreviate OpenID Connect as "OpenID" which also means something else.
I've never had to clarify what someone is actually trying to accomplish when they want "SAML 2.0"
You said "OAuth only does authz and must be combined with other technologies to get authn"; obviously, that's not true, in the sense that you can simply use OIDC --- a dialect of OAuth --- to get both.
Since OIDC is better than SAML, which is probably the scariest security standard on the Internet, I think it's worth being clear to people that OIDC/OAuth is viable.
The SAML authz story, for what it's worth, is pretty shady.
SAML is pretty simple, it just uses XML which I think turns people off to it by default. I've implemented it once and I feel like I have a decent handle on what it is (though maybe I've just avoided the worst edge cases).
OAuth is way more complex, I've used it countless times and still get confused by it. It has more complex patterns like having a separate resource server and authentication server, it's used for more purposes, e.g. sometimes for API access and sometimes for login and sometimes a confusing mix of both, and there are big differences between v1 and v2 and some services are still using v1.
> SAML is pretty simple, it just uses XML which I think turns people off to it by default. I've implemented it once and I feel like I have a decent handle on what it is (though maybe I've just avoided the worst edge cases).
I once tried to implement it, and found that the specification was spread across ~500 pages of dense PDFs. I find it to be complex.
Well, relatively simple. If you added up the number of pages in the specs for http, html, css, ecmascript, and all the various apis that web developers use every day it would likely be hundreds of thousands, maybe millions of pages. That doesn't seem like a particularly useful metric, because you don't have to read and understand the entire spec to use a technology.
Right but $5/month/service is where it starts to add up. Unless you're managing hundreds of users across a bunch of disparate services the value/cost doesn't work out in your favor.
As a business customer of a SaaS product, being able to revoke any employee's access to the SaaS tool if they are terminated. (Imagine how hard this would be for e.g. the SaaS tool your company uses to view financial reporting if it required every user at your company to create their own username/password. If you wanted to prevent someone from "going rogue" during termination, you would need to have an admin remove their account access prior to termination -- and do it on every SaaS product that person used. With SSO you revoke their access and everything gets locked out.
Source: Watching an alcoholic CTO get fired by the board and taking the startup's hosted Mongo database hostage
Good clarification! If you're a solo dev who wants to sell your side project to any company >500 people, SAML integration is tablestakes. If you're a solo dev who needs to secure your hobby project on the public internet, it's like bringing a Space Shuttle engine to a knife fight.
With GitHub (cloud version) specifically it doesn't (currently) work that way, you still need a "normal" GitHub username and password, and you do the organisational SAML login in regular intervals when trying to access that org's resources. I'm not aware of this being a widespread way of doing SAML, but I guess it supports certain use-cases (like keeping a GitHub identity despite switching jobs/OSS projects).
Hi Nat. Big fan. I've been on GitHub for a long time now. There's a fair bit of friction in issue/PR management for people who have primarily CLI-centered workflows. I know that `hub` and friends exist, but will there be official, supported clients in the future?
Also: are there plans to open source more of GitHub? Post Microsoft acquisition, I have been increasingly concerned about vendor lock-in, EEE, and so forth.
I love github, but the fact that it is not open source has always been a big problem to me, especially given that github has become the de-facto home for so many open source projects, yet is not itself open source. I would love to see that change to a model like Gitlab uses!
> Existing customers will have their bills automatically reduced going forward.
That is a class act right there.
Now, if you would open source github...
I kid. I have zero hope that that will ever happen.
It has always been bizarre (IMO) that arguably the most popular open source dev forge, er, hub, is closed and proprietary. But what can you do?
Remember when all those FOSS devs sent an open letter to github whining about that and begging for attention? https://github.com/dear-github/dear-github
(Ironically, they "signed" it by filling out a Google docs spreadsheet! As opposed to, say, patching a file.)
They "call upon GitHub to: Immediately cancel your contract with ICE ; Commit yourself to a higher ethical standard with all of your business dealings ..." [in writing]. But they stop short of threatening to leave if GitHub doesn't comply with their demands.
Leaving aside the politics of ICE, and the strangeness of talking to "GitHub" like it's a single person, it seems to me that without taking some action (like moving to e.g. Srht or self-hosting a DVCS hub) that this is just posturing.
Anyway, congratulations on sucking more air out of the room of FOSS development. In the words of the aforementioned, undersigned, concerned peasants, excuse me! users, of GitHub:
> We still believe in GitHub as a platform, as a place to help the open source community make the world a genuinely better place. Please, step up and join us.
Just want to say that I am _so_ happy and continue to be impressed but what you've done since joining GitHub. Feels like a big shift from even a couple years ago.
If you check the extended breakdown down the https://github.com/pricing page below the marketing bits, lots of features are not available on private repos unless you're paying for a Teams plan. Depending how you use github it could be an issue:
Hey, captain nemo! The major feature which we're looking for is Github Pages for private repos, coupled with Github actions.
We have multiple client sites (completely static) we're hosting on $5 Droplets (+GST+Backups).
We plan to deploy more such sites and keeping them on Gh-pages (auto build using GH-Actions) would reduce a lot of headaches for us.
Right now we've had all private repos scattered over everyones individual accounts and managing this has been a pain. So it would be nice if there is a single place to keep it all (thanks to free private repos for teams, we'll be migrating all of it to one place soon enough).
With 3 team members, $12/month for all the extra goodies seems reasonable.
We initially used BitBucket but switched to GitHub as we prefer it's UI/UX/Familiarity + a single place to manage both work/open source issues/prs etc is definitely easier.
Oh and gotta need that repo/contributor insight to compete with team mates :P
Kind of off-topic but for $4/user/month only 2gb of private GH packages storage is laughably low, and the pay-as-you-go pricing model is pretty expensive if you want to use it for docker images.
Slightly off topic, but I would like to request that you open Github for Education [1] for pandemic-related home-schoolers. Currently it requires verification as an accredited school & credentials. Any help is appreciated.
When I signed up for the Student Dev Pack originally in HS, the school district's evil IT department blocked mail from outside domains for whatever reason, so I sent GitHub a picture of my schedule (which had the name of the school and my name on it), and they accepted it. If you have evidence of being a home schooler (I believe there's some paperwork you have to file with the government?), they'll probably take it too.
And for the classroom system, it's open-source (https://classroom.github.com/) and you can run it on a box at home. That'd work given you probably only have a couple users at any one time.
Hi Nat. Just to clarify, do these pricing changes imply that users without a paid plan will no longer receive any e-mail support from GitHub?
Speaking as a long-time user, over the last 10(?) years I've only ever needed to reach out to support@ twice or so, both times with fairly obscure issues that were promptly dealt with -- thank you.
It'd be a shame if the implied change to "community support only" for free accounts means that free users no longer have any direct way to contact support.
Hi, any reason to still have a restriction on number of free bot accounts one may have (currently one)? There are limitations in products built on GitHub that require you to create multiple accounts if you don't want to share tokens between repositories (bad idea security wise): https://github.com/rust-lang/crates.io/issues/849#issuecomme...
Hey Nat -- quick Q, with this change, is there any need for individual developers to pay for "Pro" accounts? Or did the benefits of a "Pro" account just get covered by the "Free" plan?
Hi, I'm Erica, GitHub's COO. Pricing for Pro Accounts has been changed to $4/mo.It includes 2GB of Packages storage, 10 GB of data transfer and email support. You can downgrade your account to the Free tier if you'd like by following these steps: https://help.github.com/en/github/setting-up-and-managing-bi...
I just tried downgrading from my Pro Account and got:
"Your account can not be downgraded yet because one or more of your private repositories is over the collaborator limit for the free plan. Please make sure that each of the private repositories owned by your account below has 3 or fewer collaborators before downgrading your account. Questions? Please contact support@github.com."
Am I missing something or is this not implemented yet?
I would request similar to the sibling post, that at least OpenID Connect or some such SSO could be a feature for us smaller companies that still want to practice good security by doing SSO.
Hmm, looks like GitHub pages are a paid feature? One of our private repos hosts our (public) website. Even with the price cut, the Team plan is still almost $100/month more expensive than the grandfathered in legacy plan we currently have that includes GitHub pages.
Yes, I considered it, but that's how unfinished draft blog posts end up on HN ;). We'll probably just stop using Pages and deploy to S3 instead - it's a fairly minimal change.
Or you can use Netlify connected to a private GitHub repo. I use it for my personal website (hugo blog) and it works flawlessly. CI/CD integrated, so it's just push to deploy.
Forgive the skeptic in me: from the outside, it looks like MS is pushing GH to copy features that people use GitLab for right now - how much of this is "we're going to move into GL's space" vs. "this is our own thing"?
(because I'm sure MS wouldn't mind if GL's IPO went less than swimmingly because GH duplicated a number of their selling points "for free" ("for now"))
I'd like to share feedback on GitHub Actions. Tried it out, and the learning curve was too much. I want to use stuff I already know -- e.g., write a Dockerfile, and then GH could run it on PR builds. The "workflow" concept didn't land for me, and I hope you consider a more generalized, open-source approach to running arbitrary scripts in response to PRs being opened, merges to master, etc.
They opened sourced the runner[0] if you're interested in learning how it works. Understanding the internals of it may or may not help the syntax and concepts of Actions land though.
My guess is that it is unlikely to see your request for a more generalized script or Dockerfile runner realized because that (Dockerfiles) was the original implementation of Actions during the beta; they pivoted away from that to the current form.
Counterpoint: I've never used Docker at all (I'm a Mac/iOS dev), and was able to get GitHub actions set up and doing what I needed it to in ~30 minutes. Its general similarity to other CI/CD solutions, TravisCI being the one I'm most familiar with, helped a lot.
Coming from Travis CI and GitLab CI, GitHub Actions was very intuitive and I had it running in the very first take.
The concept of actions is new, but it is brilliant compared to traditional approach of doing everything inside the CI jobs, or bring your own docker images.
The YAML configuration is something I have to learn that provides no value-add outside of GitHub. If it was at least based on Docker, you could re-use existing technical knowledge or teach people something that's valuable in other contexts.
Hi! Any perspective of extending SOC2 Report access to the Teams level? Small companies in regulated environments aren't able to jump to enterprise ($$$) so need to look elsewhere to get a SOC2 compliant version control system at a decent price. Love the Github product so it was tough when we had to make the decision to move off of it.
I don't work at GitHub, but I believe if you reach out to GitHub Support and sign an NDA they can provide you the SOC-2 report. (Most vendors will do this.)
We reached out and were told we would need to upgrade to the enterprise version. (This was probably 5 months ago before they announced a few startup friendly offerings)
I'm curious why you need the SOC2 report itself instead of some sort of signed statement of compliance. The details of the SOC2 don't seem like they should be important?
While we have your here, any plans for more fine-grained IAM for GitHub Apps? It's already a lot better than legacy apps, but it's still pretty broad. Ideally every API call/resource could be specified individually in an IAM policy, so we can only request the minimum permissions possible in our GitHub Apps.
Hi Nat,
first of all thanks from every developer in the world. I think this is going to be a great step forward for people who don't need enterprise features (yet).
One question: is this service going to be available in countries that are currently hit by US sanctions?
(eg. Iran)
Thanks again
This is amazing for us folks towing the line between open-source and proprietary, enabling an open core while allowing access to our closed-source products without having to leave GitHub. Right now, we mirror our GitHub repos to a private Bitbucket server so that our clients can make PRs and such, but now we can just add their GitHub accounts to our team!
We do have a paid plan, right now. Is there any way to continue having that paid plan on the team (paying per user for the extra features) while also adding users who don't share the extra features? We'd like to open up our org to all of our clients who use our private repos, but we don't want them to e.g. have access to all the private k8s cluster configs.
I currently pay for a Github Silver plan annually ($600). When I try to downgrade to Free I get a message (in red) "You will no longer be able to access your private repositories or create new private repositories."
How do I downgrade without losing all my private repos.
Martin from GitHub here. Sorry about that message - team are rolling out an update to change the text and should be fixed soon. In the meantime if you ignore that message and downgrade from a legacy plan to Free then you will retain access to your private repositories.
Biz question for you: do you think given enough of a run way i.e time you could have gotten to that enterprise run rate without Microsoft or have customers come to you now that you have Microsoft's backing -- i.e has that made sales easier?
Hi nat,
I came here prepared to ask about how this would play out for annual billing customers since I only just set it up in March. On searching, I can't actually find where you charged me, so I suspect you might have pre-empted this.
So instead of a question, this is more thank you. I'm a tiny bootstrapped startup and was only using 3 of the 5 previously minimum seats. I'm a prime beneficiary of this change, and look forward (fingers crossed) to being one of the enterprise customers that pays for everyone else :D
For others, can you elaborate on how this will work for current annual billing customers, I found some vague references but no detail.
Thanks for doing this. Is this effective immediately now? I tried to downgrade to free just now but it's giving me a giant list of features I'd lose if I continue. Also any change to Data pack pricing for LFS Data?
Due to the on-going Pandemic, I've been trying to cut business costs left and right. Github Team was one of those I wanted to cut but it's also so important that I couldn't decide easily. So thanks again for the change. Much appreciated!
It is effective immediately. There is a full FAQ here: https://help.github.com/en/github/getting-started-with-githu... Essentially, "Pro" = Team - the only difference is whether it is an individual account or an organizational account. We'll work to clarify this on the site.
No, there has not been any change to the data pack pricing for LFS data.
Glad this will help you continue building on GitHub!
Hi Nat - this is a really bold move, and shows how competitive the market for developer tooling is.
Does GitHub anticipate that this pricing change will affect the proportion of code that's provided under free / open source licensing on your platform, and if so can you share any information regarding the direction GitHub would like to lead the community in?
Considering Github Enterprise (which offers on-prem) is their main feature, and main source of revenue (paying for the free stuff) it's really unlikely.
Why not just use Gitlab if you really need on-prem for cheap/free?
Heh, well, there you go - it's exactly why we are using Gitlab. It's going to be a pressure point for them just lke the free private repos has been previously.
Let us know how your comparison goes - we're doing a challenge asking community members to compare both tools and share their responses for some swag. I'm a community advocate at GitLab. This blog post outlines more of the challenge if you'd like to participate: https://about.gitlab.com/blog/2020/04/14/github-free-for-tea...
Can making Github Actions share code between them be a super high priority? Copy/pasting all the setup for a project on each action is repetitive and any time you need to make a change, you need to make it in 6-7 places in our case.
This great news, I appreciate the free stuff, but on the other hand free stuff can be tricky as the company must make money. So I hope that your enterprise model will work.
Read his comment again. They are supporting the free plans with Github Enterprise.
> We've wanted to make this change for the last 18 months, but needed our Enterprise business to be big enough to enable the free use of GitHub by the rest of the world. I'm happy to say that it's grown dramatically in the last year, and so we're able to make GitHub free for teams that don't need Enterprise features.
Being an SRE who’s worked for a lot of different companies, I can tell you building and hosting something like GitHub is expensive, it seems unreal to me they’re selling enough self hosted solutions to pay for everything and keep GitHub profitable.
Not sure how that's your takeaway from the announcement? Sounds more like they can cover the costs of hosting free plans from the revenue through enterprise customers, and so can attrack more customers without having to charge them
Great news for everyone bar startups competing with them as it looks like Microsoft is turning their multi-billion acquisition of GitHub into a loss leader to get as many devs using their platform as possible, no doubt to flex seamless integrations into Azure which looks like they're executing exceptionally well with their acquisitions & new feature giveaways.
From the side-lines it looks like they're slowly becoming an unstoppable dominant force, what's surprising to me is AWS's / GCP's inaction, they're either asleep at the wheel or they don't see Microsoft's dev mindshare grab as a threat.
The new Team plan will be a downgrade in specs from the old teams plan. For example it only includes 3000 Github Action minutes. The old plan included 10000. The next plan up would be > 2 * old price.
You can buy extra build minutes. The missing 7k minutes would cost $56, which means teams with 12 or more devs who are using the full 10k minutes will be better off. Smaller teams using more than 10k will be worse off.
It’s probably great news for the vast majority of teams.
This is only true if you're using exclusively Linux runners. If those same 7,000 minutes are on macOS, you're paying $560. On Windows, $112. At my company, we definitely use a mixture of all three for various things, so this will sting, with varying degrees, depending on how often we build new iOS, Mac, and Windows releases.
I'm not sure it's great news for those of us who are smaller users of Github. You would expect Github to concentrate even harder on enterprise users now that we're not paying anymore.
I'm not complaining; MS should point GH at where the money is and there is competition you can switch to. I'm just not excited to save a few bucks a month given what will likely change.
Unlikely, freemium users would make up the overwhelming majority which has been getting more value & less reasons to need a paid subscription with each release since their acquisition of which I've yet to see any signs of neglecting their existing user base.
IMO Microsoft views GitHub's user base as potential Azure leads and Cloud computing as the current & future lucrative computing utilization business model who has been pulling out all stops to grow Azure as fast as possible.
They're fortunately rich & big enough that they don't need every one of their business to maximize their profits and are more than happy to leverage the synergies in their different assets to funnel more business into Azure.
Agreed. I cannot believe that GCP and AWS are so asleep at the wheel either. If I were them I would literally be throwing money at some of the GitHub folks to have them fix AWS or GCP.
And it was should have been rather obvious when GitHub released the beta of Actions a few years ago. Actions remains the most important thing GitHub has done, ever, in my opinion. It might take a few more years for people to fully realize what this could be. Hope GitHub doesn't screw it up!
There are dozens of CI/CD offerings and many are better designed than Github actions, including Gitlab's CI runners.
I don't see what paying Github would do for AWS or GCP. They both have their own code repos, build pipelines, container registries, and more. Even Azure has its own DevOps product.
I use Gitlab's CI runners and I agree. However, I am pretty excited about the direction that Github is going with their actions. Having a directory of user created actions and integrations seems like gold to me and I hope Gitlab starts leaning that way soon.
I agree, but GitHub must fix the security nightmare that is waiting to happen with GitHub actions marketplace. Seems like this would be such an easy fix, too.
It's all about the ease of use. Manually setting up CI/CD is _hard_ and requires a team to maintain and support it. Whether through a home-rolled Jenkins deployment or Buildkite.
It was super obvious the value prop when it was HCL based. YAML based it kind of looks more like 'another CI'. It's still insanely powerful, just not as developer friendly anymore.
Continuous integration (CI) and continuous deployment (CD) services. Essentially when you merge a changeset you can configure a specific branch to automatically test, package, deploy, and integration test that branch with no additional human intervention.
That doesn't preclude AWS (or anyone else) from trying to buy them. :)
I don't know how much control their external board members have, but if an offer came in, the board may be able to force acceptance instead of going public.
While Amazon tried to go into the private hosting and ci/cd market, they are not a dev tool company. Microsoft was born as one. When Amazon or Google would buy GitLab they would meaningless integrate it, reduce staff by half and then ruin it over time.
Maybe when Microsoft would have opened up some years earlier, Codeplex would not share the fate of Google Cloud.
It breaks the site guidelines to post accusations of astroturfing like this. The overwhelming majority of the time, there isn't the slightest evidence for these. Somebody liking something that you dislike does not count as evidence.
I've studied the question closely on HN and looked at data for years. There have been occasional cases where we've banned accounts for the kind of thing you're complaining about, but we have to go by evidence. Well over 99.9% of the time, users are just making shit up. Please don't trash talk like that here.
Please review https://news.ycombinator.com/newsguidelines.html and stick to the rules from now on. If you're genuinely worried about astroturfing, you're welcome to email links to hn@ycombinator.com and we'll look into it.
Hi Dan, my apologies for that. I wasn't trying to specifically single out that account. I've seen a strong push for MS products since VS Code, and it is impossible to be an accident. My post was made out of curiosity as opposed to malice. It was not intended as a passive-aggressive accusation, but I understand the rule there. I appreciate the guidance.
Internet users are overwhelmingly, like a million times too likely to generate sinister explanations for phenomena like this, which are typically just artifacts of a large population size plus randomness. There's something in how human nature meets the internet which makes us vulnerable to this bias. Probably it's just that we're not wired to interact with very large populations of people. Cognitive bias plus randomness equals narrative.
I think there might be a mixup about how it might appear that I'm talking about astroturfing. I'm referencing a situation where one or more marketing teams have leveraged their large employee and contractor network to engage positively with Microsoft's listed products and services on HN. More of a mobilize from within as opposed to a secret or stealthy program to create false accounts.
Quick edit: I definitely appreciate the "red car effect" you are referencing.
FYI, I am not a member of Microsoft. Just a fanboy. Do not know what is worse ;)
But I agree with the statement. The presence of Product Managers, Senior Devs and high ranking managers here on HN is pretty well orchestrated. I mean makes sense.
You mean Microsoft's latest attempt at Web Forms/Silverlight, a product that yet again tries to muddy the separation between client and server execution contexts using magic.
Seems like every generation re-invents this idea, and every time it fails for the same fatal flaw: Illusions are just that, and you'll wind up hacking around the illusion if you want to do something not envisioned (or run into a bug in the secret sauce).
And before someone replies "it is nothing like Web Forms!!!" here's a direct quote from Blazor's homepage:
> Blazor can run your client logic on the server. Client UI events are sent back to the server using SignalR - a real-time messaging framework. Once execution completes, the required UI changes are sent to the client and merged into the DOM.
I'm also not sure why you are conflating Silverlight with Web Forms - it was never competing with Web Forms, it was client-side only, a replacement to Flash - a better UI and API (at the time) than HTML/CSS/JS.
Blazor is OSS, and doesn't work like Web Forms.
As in your own quote, Blazor uses SignalR - which uses push-based comms, such as Web Sockets; Web Forms was standard HTTP.
I was a Web Forms developers, I've earned at least that. Blazor absolutely does work like Web Forms, in terms of client<->server integration, just because it uses WebAssembly & SignalR instead of JavaScript & Ajax doesn't really change that but rather obfuscates it. Essentially it is just another set of abstractions attempting to paper over a real boundary.
> As in your own quote, Blazor uses SignalR - which uses push-based comms, such as Web Sockets; Web Forms was standard HTTP.
Which makes it even worse, if the client/server boundary wasn't muddied enough with with the unidirectional magic Web Forms used, now we have omnidirectional instead. As if that will make it less complicated and buggy.
Definitely put me in the "nay" category with Blazor. I've danced this exact tango with Microsoft twice before, and their obsession with making browsers desktop-like applications. WebAssembly is cool tech for one day, they're just abusing it for something that is an inherently bad idea.
Uh, have you used SignalR over web sockets? From a performance point of view its going to be much better than Http based polling. Which should make a different when we are talking about updating the UI.
Blazor may not work like Web Forms, but the philosophy is similar. Abstract away the fundamentals of HTML/JS, making back-end devs feel like front-end devs.
I started my dev career a long time ago in Web Forms. I went so long without understanding HTTP POST/GET/etc that it harmed me.
Anyone remember UpdatePanel? AjaxControlToolkit? Blazor gives me the same feelings.
There's nothing magic about it. Web Forms was a great innovation and brought the WinForms model to the web. It was more productive than anything else at the time and directly influenced MVC patterns (which asp.net itself went towards) and component-based UI.
Blazor is the next evolution in client-side and offers an alternative to building component UI with C# running through WebAssembly instead of Javascript. Again it's much more productive and lets backend teams reuse much of the same code, similar to JS/node projects today.
Blazor's server-side runtime is a optional model where all the component logic can run on the server and be delivered over a SignalR connection to further increase productivity and efficiency where it makes sense (highly constrained devices, local intranet apps, etc. There's even experimental projects to bring Blazor for mobile apps.
As a .NET fanboy: no it will not be a game changer. It is too fat and does not fit the rest of the web development model. Similar to Xamarin it will be a platform to run C# and .NET on. It will not be the native or best experience. It will be productive and enable cross form factor reuse of code. Not more, not less.
This is an awesome change! In case anyone else was wondering, here's what you lose by cancelling:
You are downgrading to GitHub Free
After April 15, 2020, ... features and limits will change:
Protected branches in private repos
Draft PRs in private repos
GitHub Pages in private repos (using 1)
Wikis in private repos
Code owners in private repos
Multiple issue assignees in private repos
Multiple PR assignees in private repos
Code review automatic assignment in private repos
Scheduled reminders in private repos
Standard support
2,000 minutes for GitHub Actions (currently 3,000)
500MB of storage for packages (currently 2GB)
It's not clear to me whether this is possible under any configuration, but: can you enforce a two-person rule? I'd like all users to be able to merge accepted PRs, but no one should be able to push directly to master (unless an admin specifically elevates permissions to do that).
The only way I can think of is to have a bot be the only one with commit access, and to interact with the bot to do merging. But that seems pretty roundabout.
OK.. maybe it is terminology then because Free public repos have Branch Protection rules. Do you not have those with Free private repos? Or is "Protected Branches" some bigger feature?
Well, this is amazing! I never would have thought the Microsoft acquisition would have these kinds of results! Congrats to Nat and the GitHub team (and by extension Microsoft) for making this possible!
I wonder whether this is a result of market conditions, or whether GitHub sees this is a first-to-market play of some sort, or whether it's something else. I hate to be a cynic given how much good Microsoft + GitHub have been doing lately, but what prevents this change from being rolled back?
Congrats again! I love using GitHub and look forward to many happy years shipping code on the platform.
I feel like anyone who lived through the 90s could have expected "these kinds of results".
Git is open source and widely supported, which doesn't benefit Microsoft. By causing GitHub-specific features to be an essential part of a "modern" or "industry standard" git workflow, they can capture more marketshare/attention, and cause alternatives to be sidelined. This requires removing all friction to entering the proprietary ecosystem, including purchasing.
This, along with the acquisition of NPM, is the "embrace" part.
The next will be an expansion of GitHub and NPM's featuresets in ways that are only accessible via branded, first party tools (i.e. not git/ssh/yarn). GitHub has already made some inroads there prior to the Microsoft acquisition with of course the ubiquitous PRs as well as GitHub Issues and Actions. I imagine the ability to check out GitHub wikis as git repos will probably eventually go away to further this.
The last part ("extinguish") is turning off support for non-firstparty tools like git-via-ssh, .patch URL support, issue collaboration via email, yarn, et c. By the time they do this, few people will notice, having acclimated to the entirely-proprietary ecosystem they've been incrementally subjected to.
The goal, as always: a Microsoft editor (VS Code or Atom), editing code in a Microsoft language (TypeScript/.NET/whatever), signed off via Microsoft review software (GitHub mobile), publishing to a Microsoft website (GitHub/npm), running CI on a Microsoft VM (GitHub Actions), pushing code to a Microsoft datacenter (Azure).
It's simply a moat to prevent open, unfettered competition in any intersection of the vertical. Any weak spots (such as GitHub signup friction) are to be subsidized as they will yield benefits when later used as a cohesive whole in an anticompetitive fashion.
Luckily history has shown that competitors still exist in a world where Microsoft tried hard to “extinguish”. macOS and Linux still exist, Chrome is the most popular browser (not IE), and most people who use Windows are fairly happy with it. You can try to point to Microsoft’s past behavior as proof that the future of GitHub is dystopic, but I don’t think their past behavior was particularly effective at snuffing out all competition and forcing people into their ecosystem. I suppose this is a matter of opinion, but I think being scared of GitHub sliding into terribleness does seem to be in the realm of paranoid conspiracy theories. Even if it does happen, git will always exist and there will always be alternatives.
> I don’t think their past behavior was particularly effective at snuffing out all competition and forcing people into their ecosystem
I still buy a Windows license to play video games. I don't want to use Windows or buy a Windows license.
Of course, I could always choose to not play video games, so technically you're correct that I wasn't "forced" into their ecosystem. But I'm still there and I don't want to be. This is a direct result and present day residual benefit of their anticompetitive practices over twenty years ago. These are very long games that they play; you don't make hundreds of billions of dollars by accident.
Maybe that's true, but I'd like to think Windows is the current market leader because their desktop OS was the only one on the market at the time that was user-friendly and ran on any hardware (unlike OS X).
It seems that video game APIs require lots of investment, and Valve has worked on their version of Wine and other stuff which is quite successful at running Windows games on Linux, so you've got that option - giving your money to Valve through Steam. Or you can also get a console.
Speaking as someone who worked at Netscape during the 90s, your comparison is missing on a lot of fronts.
First, Microsoft was evil back then because they didn't just rely on excellent pricing and features (both of which they had) - but also because they leveraged their monopoly in one market (desktop operating systems) to prevent competition in adjacent markets (browsers).
I think it's difficult for people to believe that Microsoft has evolved, and grown more responsible (Hell, I can run linux directly with windows - with kernels available on the Microsoft store) - but you need to follow the evidence.
> First, Microsoft was evil back then because they didn't just rely on excellent pricing and features (both of which they had) - but also because they leveraged their monopoly in one market (desktop operating systems) to prevent competition in adjacent markets (browsers).
Isn't that exactly what's happening here?
Gitlab competes with Github, but doesn't have the equivalent of Azure to subsidize it with.
Azure competes with AWS and GCP, but Amazon or Google don't really have a Github competitor. (Maybe Google has a small one (?), but I've never heard of anyone using outside their cloud product.)
Bringing Github and Azure closer together is an obvious move.
Github might not be a monopoly in the legal sense, but it's a solid #1 in the space, with strong network effects. On the other hand, Azure is far behind the near-monopoly AWS.
The question of whether you are a monopoly is really important. Once effectively everybody is using your platform, there are restrictions on your behavior. Being the category leader is very different than being a monopoly.
And, note, that there is, and obviously wouldn't be, a law against a monopolist giving it's monopoly product away for free - That's kind of like anti-leveraging.
Look at this from a different perspective - free git hosting for teams is awesome. This is unquestionably a positive thing that Microsoft has done. It's good to be a bit cynical, but not to be so cynical that we put blinders on to the wonderful resources that are now being made gratis.
And, as long as they don't try and put some crappy "Microsoft only" extension onto their platform so that the vanilla git doesn't support all of it's capabilities - it hasn't taken that dark step into "extend." Once they do that, then it's worth a post to HN about Microsoft's Embrace-Extend-Extinguish dark past.
EEE strategy doesn't require starting out as a monopoly, it's just that it's easier if you're already a monopoly.
One could argue that EEE is a strategy to gain monopoly status. Microsoft does NOT have a monopoly in this space currently, but perhaps they want to get one (but only in practice, not quite legally recognized as one).
I see nothing wrong with bringing up EEE before it happens. Which scenario is more likely to discourage the tactic (A) nobody cares until the second E or (B) people are worried about any hint of it.
What is Microsoft doing right now to remove EEE from their options? For example, they could release the whole GitHub codebase under AGPL, and that would be quite a reassurance but not a guarantee.
"It is easier to avoid temptation than to resist it" — Dan Ariely
GitHub’s danger is that it is centralized, not that it is closed source. For example, npm is already open source and Microsoft owning it is still a threat to the ecosystem via their ability to control the software and decide what goes in and what does not.
Microsoft could open source GitHub and it wouldn’t make one bit of difference to their strategy, as it would not pose any danger to GitHub’s defaultness.
Gitea implementing a federated mentions model, plus easy cross-instance linking and federated notifications, plus one-click $5/mo hosted instances on a bring-your-own-domain model would, however.
I am beginning to think we need something along the lines of go modules for the javascript world. Cryptographically assured via merkle hash root, fetchable from any url with a standard protocol, and a public caching proxy. Go got it right, rubygems/pypi/npm most assuredly did not. (To be fair, go modules were designed latest of all of the members of that list, giving them the benefit of hindsight.)
Maybe yarn can go this route ifwhen npm breaks fetch for non-first party tools.
I wonder what would be involved in forking npm (the hosted package repository, not the cli tool).
Centralization is indeed a danger, but so is being proprietary. It would show some good will or otherwise willingness to avoid temptation if Microsoft freed the GitHub codebase even while staying centralized.
Freeing the code is a check-and-balance issue. It doesn't remove their core power, but it provides more of an escape hatch if they abuse the power. Sure, people could go to GitLab, but (A) if GitHub gets strong enough, they could hurt GitLab's business and progress and (B) it's a much more trivial move for a project to switch from Microsoft GitHub to an alternate GitHub host.
In other words, the easier it is for people to leave, the more incentive Microsoft has not to abuse people too much.
If we were going to go for the most ethical and trustworthy directions, it would probably be stuff like Fossil or SourceHut.
I think it's worth pointing out that GH was always on this path, to the point where it's actually kind of hard to explain the difference between git and GitHub to fairly technical people.
It's also worth pointing out that it doesn't have to come from malicious intentions.
It's tough to say that the urge to replace free software and open collaboration protocols with proprietary, closed source pay-to-play tools that the user isn't in control of (the whole GitHub SaaS model) isn't "malicious intentions".
It's replacing an open, free (in both senses), decentralized system with a closed, for-profit, centralized one that expressly benefits a single organization at the expense of everyone else in the ecosystem.
This is not to say that GitHub isn't a benefit over emailing patches around; just that it's probably also worth mentioning that Linus et al have not migrated to this shiny new (centralized) system for the largest collaborative development effort in the history of the world, and, indeed, git itself was developed specifically to avoid a hard dependency on a single, centralized point.
That's kind of my point: doing something to protect the best interests of your company isn't inherently malicious. Sure, altruism has benefits, but they're much harder to measure than the bottom line.
Also, FWIW I think we need to move away from GitHub.
I might buy the conspiracy theory except for the fact that Azure DevOps exists and provides all the features of GitHub already with none of the restrictions you've mentioned except that you pay for the service.
Can it really be called a conspiracy theory when there is proof that MS has done this same sort of thing in the past? Past behavior is a good predictor of future behavior. Saying that someone has been shown to do something in the past, therefore it is likely that they will do the same thing in the future doesn't seem to qualify as a conspiracy theory.
I've read that more than half of government/regime changes that happened in the 20th century were the result of some kind of coup. In other words, conspiracy is the norm.
The real question is whether corporations behave like "someone", like a natural (biological, real flesh-and-blood) person.
Whereas there is a need for legal corporate personhood (so they can enter contracts, be sued and sue others, etc), the extent to which a corporation has a "personality" is very much debatable— sign contracts, sure; but fund political candidates? Have a political opinion even? That's crossing a big phat red line most countries have outlawed (with good reason)— only citizens in their own name (that of a natural person) may participate in the civic life, whether board member/CEO or the lowest paid employee: same rights and duties, in a truly democratic political theory.
Factually, when psychologists attempt to describe the behavior of corporations, they are faced with "sociopathy"— but let's not pretend it's a trait, because it results more likely from the absence of consistency between people, departments, historical periods... it's not and cannot be as stable in space and time as a real natural person.
Corporations are neither good nor bad "people", they are simply not "people", but a different category of objects. We could also demonstrate conversely that natural persons and households belong to very broken categories of businesses... because they're not businesses!
So when we anthropomorphize corporations and businesses like they're people... we really create meaning out of thin air that never was there. If it's a one-man show, sure, obviously. Above that begins a very slippery slope that leads to super PACs and other churches like Evil MS versus Heavenly Apple and what-have-you.
Whatever greatness or horrors we observe from corporations should be attributed directly to the natural people who make those decisions— it's not Boeing that's bad, it's whoever's in charge and whoever condoned it. People. Boeing is just a 6-letter words, you can't put "Boeing" in jail, nor make it "Sir" by a Queen...
So I'd rather praise Nat himself than "GitHub" here, and I'd rather judge him and Satya Nadella in name than "GitHub" or "Microsoft"; recognizing that he (they) can't possibly be alone in this so the praise extends to all employees who strive to make great on a vision... and also the blame lies with them, when they're being disingenuous. People, real people, with real names and a past and loved ones and maybe kids and political opinions. Not an abstract 6-letter name who's already changed in the timeframe I wrote this post, as two new people got hired and another one left.
Indeed, a corporation is a permanent ship of Theseus: who's left, at Microsoft, from the 1990s? How much power do they command? Here is the real link between that era and now, behaviorally. The name matters little, people manning Microsoft 40 years from now will all be new people. Transmission of culture is limited between kids and parents, and even more so between one's predecessor and one's successor at a job.
Microsoft has changed, as a group of people, because well... most of these people have left and new ones came in.
Sorry for a long piece; but this truth needs saying, especially in these times if we are to reform our societies to better solve the pursue of a "greater, common good". Mistakes were made (in the legal structure of things), ethical compasses need realignment (let's just admit people from the past couple centuries couldn't get everything right nor possibly predict our present, and let's just move on with our times, our challenges, shall we?)
I'm very interested to hear what Hackers have to say about this, although I suspect it's become a fairly non-controversial, almost benign realization nowadays (used to be ridiculous, then dangerous thinking, now it seems obvious retrospectively like any real paradigm shift).
Doing that can get you banned from a lot of projects on GitHub. Citing specific humans by name as having undertaken specific actions on specific dates is sometimes seen as aggression or harassment, even if you stick to pure factual statements. The actions of people at work, socially, are often seen as “actions of the company”. Mentioning people by personal name is frowned upon.
I’ve actually had comments deleted for discussing things in this mode: Human X did thing Y.
I think our society doesn’t like it when we highlight personal responsibility for things people are only choosing to do to get a paycheck to pay their bills.
It’s easier for everyone involved to say “Google developed AI software that allowed military drones to decide who to kill” than to say “John Smith developed AI software that allowed military drones to decide who to kill”.
Not that I think we should not use both forms. Individual choices matter, and facts are facts.
> Whatever greatness or horrors we observe from corporations should be attributed directly to the natural people who make those decisions— it's not Boeing that's bad, it's whoever's in charge and whoever condoned it. People. Boeing is just a 6-letter words, you can't put "Boeing" in jail, nor make it "Sir" by a Queen...
I think it's interesting how British English pluralises companies and groups in general, in recognition of this fact. For example, "Boeing have made a big mistake with the 737 MAX", where American English would use has. Or, "the family next door are lovely".
But dismissing presence of companies culture is as extreme point of view as dismissing possibility of change. To name a few - Oracle, Google, Facebook, Apple, Toyota, Tesla - they are different and quite predictable.
> If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.
I am not in "Evil MS" camp but
> Fool me once, shame on you; fool me twice, shame on me
Same as with people - sometimes they change but sometimes they don't
And corporations are inherently dangerous - they maximize profit. Unbound by law, unchecked by people, even amazing people with nicest slogans would make dystopia.
Azure DevOps has a really generous free tier too, with unlimited public and private repos.
Just pointing that out - to be clear, I don't buy into all the Microsoft bashing that there is on HN (and I say that as someone who was around when Microsoft gave plenty reason to be hated).
Thank you, it summarises it pretty well.
MS is back pretty strong.
It's also to note they attacking on two fronts, the open source and startup folks (VS code, github, typescrip, azure) , and the enterprise with communication, productivity tools and cloud infra (Teams, Office 365, Azure)
I don't think it's an attack to try and make good products. Unless they're playing dirty / being anticompetitive, you're just describing a company making dev and cloud products.
Other things I assume will fall in the future: accessing GitHub Issues via API (for anyone other than paying enterprise customers), support for third-party GitHub API clients (use our first-party app with built-in spyware only, please), et c.
One need only look at what they've done with Windows and Office and Xbox to see how Microsoft approaches client software.
Maybe, but this move looks to flatten GitHub pricing down to two tiers: enterprise and free, while GitLab has four pricing tiers and the enterprise feature offering doesn't seem to be there (Gold doesn't look too enterprise-y at first glance).
IMO the biggest difference between the two is self-hosting which makes sense for the price difference.
Even setting that aside, SSO is a feature which is very meaningful to businesses and relatively meaningless to individuals. Because of that its often used to differentiate between the customers. This differentiation results in individuals getting a discount at the expense of the businesses; which to me makes sense.
Ha! sso.tax, what a great site. As an IT person I always thought this same thing with SSO - even if you have an identity provider, it's often under utilized because nearly everything else needs to go to enterprise pricing for SAML auth. I wouldn't mind paying $1-2 more per user/platform, but as sso.tax tallies, the price jump is often much more.
On sso.tax, it states that "Single sign-on (SSO) is a mechanism for outsourcing the authentication for your website (or other product) to a third party identity provider, such as Google, Facebook, Okta, PingFederate, etc."
Isn't this the definition of Federation, rather than SSO?
As I understand it, federation enables two separate instances of some particular service to interact. They can still use single sign-on independently for their own authentication needs.
Seems like Github is feeling heat from GitLab/BitBucket.
I guess the calculation here is that the enterprise contracts are where all the money is, and keeping smaller customers on GitHub is worth the price cut?
I have been favoring Gitlab over Github because their CI is the best CI I've ever used. It just works, whereas every other CI found a way to make things hard for me.
You can even spin up postgres and redis instances for tests by just specifying that you want them. It's amazing.
Couldn't agree more. Gitlab's CI is what made me finally fall in love with CI as a concept. Obviously it was needed before, but it always felt like an ugly chore. With Gitlab, it's one of the first things I do when setting up a new project.
Throwing in a second opinion here for those curious. I've worked with a number of CI systems and had trouble with many.
Gitlab CI has been the opposite of other experiences I've had with well over 10k jobs completed across different projects with diverse needs. Even for small hobby projects it's been great for me, it's nice to easily be able to push updates without having to worry about it. Makes it much easier to iterate and test things out!
I guarantee that this move had absolutely nothing to do with competitors and everything to do with Microsofts new rise to dominance. Coding is going to be the next blue-collar job, they are positioning themselves to do well when we reach that inflection point.
Google haven't built up too much of a user base for GCP's Cloud Source Repositories service yet (my speculation), so I wonder if they're viewing Gitlab as an acquisition target.
TBQH, I don't see Gitlab lasting too much longer without an acquisition event of some sort, when facing up against this sort of Microsoft-backed feature funding. And I say this as a bigger user of Gitlab than Github (primarily because of the free private repositories and organisations).
I think an acquisition of Gitlab would be the only way for me to migrate back to GH from GL. I've been a happy user of Gitlab for years now and have no yearning desire to return to Github.
Gitlab need only wait before GH starts adding Azure-first and Azure-only features, as they are wont to do. At that point they can just offer "the same but for any other cloud provider". Amazon, Google, or IBM, might even throw them a bone.
It seems like in the medium term, staying independent could be a huge boon to Gitlab- like you said, it'd allow them to make high quality integrations with all cloud provider utilities.
In the long term we'd probably see the cloud providers create their own social revision control projects, and then fuck around with private APIs so the quality of the integration between their cloud service and their source control leads you to stay locked in.
Even in that scenario it could make sense for there to be a 'neutral' party like gitlab, though.
I acknowledge this is my own imagination and I've no claim to know the future! :)
because if you're referring to requiring review approvals before a PR can be merged, that's available in the free plan (under branch protection rules).
A feature that's available for free on public repos isn't necessarily free for private repos, it seems. The wording on the pricing page isn't very clear about this, though.
If they mean that they're now removing required reviewers for public repos in the free plan, that's definitely a big step backward I think.
Very few companies can make me feel like part of their journey like Github (Cloudflare also)
They understand their target audience more than most of the companies out there. When they are making moves such as this, they explain what was behind it. I find it authentic.
Me too! Microsoft has done a really great job of managing the acquisition without ruining GitHub. GitHub already had a great understanding of their audience and a pulse on the community prior to being bought, so I'm really glad that they haven't lost that now that they're a Microsoft subsidiary.
I mean, if they hadn't done a thing it would have been a great job, too. Pumping in cash to fund previously paid features for free sure goes a long way, too, but the changes they've made so far I'd hardly call managing and more not touching it aside from making paid things free.
Speaking of, I just had a momentary panic because Backblaze’s hard disk report timeline is missing a link to the last update (from February) and I thought maybe they’d stopped doing them...
Who else is good at this? I’m somewhat fond of Digital Ocean’s docs.
Not for the technical aspects, but I'm fond of TransferWise an Signal. Even within Microsoft, their WSL, and new terminal are well-received in open source communities.
I think GitHub are doing well, but one cannot deny that GitLab has carved out a fantastic niche (on-prem, private instances, OSS, etc) that GitHub doesn't compete in. So while I agree GitHub are "the" company to beat, I think GitLab is doing a good job of contrasting.
For developers everywhere competition is great. We recently made 18 new features free and open source https://about.gitlab.com/blog/2020/03/30/new-features-to-cor... and today Github with an improved free plan and their team plan came down to the exact same price as our most affordable plan. BTW Maybe an idea to rename their lowest tier from team, may we suggest bronze? :)
Since you mentioned contrasting here is a quick take on the features that you lose if you go from a GitHub Pro account to a Free account, I got the list from https://news.ycombinator.com/item?id=22867974 :
Protected branches in private repos => Free on GItLab
Draft PRs in private repos => Free on GItLab
GitHub Pages in private repos (using 1) => => Free on GItLab
Wikis in private repos => Free on GItLab
Code owners in private repos => Bronze on GItLab
Multiple issue assignees in private repos => Bronze on GItLab
Multiple PR assignees in private repos => Bronze on GItLab
Code review automatic assignment in private repos => ?
Scheduled reminders in private repos => TODOs are free on GitLab
Standard support => Bronze on GitLab
Thanks for your inputs! Offering the flexibility of monthly pricing to our customers is definitely one of our priorities. We are currently working on optimizing the online portal to ensure our customers have a seamless experience when monthly pricing is available.
GitLab community advocate here, wanted to see if you're interested in participating in our #GitChallenge - If you send us your review of GitLab vs GitHub (whether positive/negative/neutral), we'll send you some swag. Here's some more info if you're interested! https://about.gitlab.com/blog/2020/04/14/github-free-for-tea...
I hope developers still default to making their personal repos public after this change. One of the fringe benefits of GitHub is the ability to search across the entire site for uses of obscure, poorly-documented APIs. Defaulting to most repos becoming private would greatly hinder this.
I agree that’s a potential concern, but you’re worrying about it a year too late. Individual developers have been able to make repos private on the free plan since January 2019: https://github.blog/2019-01-07-new-year-new-github/. This announcement only affects the cost of private repos for teams of collaborators.
I've not been a big fan of GitHub historically, but the pace of innovation since the MS acquisition is really impressive. I wonder how much of that is MS influence vs just MS funding.
That's odd, it's the opposite for me. I did like GitHub, but then setup a Gitea and made sure to figure out how to move things over (even if I haven't done it since they haven't really given me a reason) after Microsoft acquired it. Now I watch every move with a weary eye, though truth be told so far it's going fine (mostly by being hands-off, of course).
I do assume a lot of this is their own money, but with the financial security that Microsoft offers you just can't do much wrong. Even without actual money actually moving, it might still be MS funding that makes the difference.
Bit disappointed that this isn't an "Everyone Wins" pricing change.
The new plan is a downgrade from the old one. For example, it will only include 3000 Github Action minutes. The old plan included 10000. The next plan up would be > 2 * old price.
It depends how many users you had. https://github.com/features/actions#pricing-details shows that if you have 12 members you can buy the difference in Linux Github Actions and still get ahead. The price on Mac is prohibitive though and yeah you definitely lose out there as I don't think many people on that plan have 120 people.
> We’re happy to announce we’re making private repositories with unlimited collaborators available to all GitHub accounts.
Huh, I thought github made private repos available to free github accounts a while ago?
Looking for historical announcement, aha, it was not with "unlimited collaborators" before.
From Jan 2019:
> GitHub Free now includes unlimited private repositories. For the first time, developers can use GitHub for their private projects with up to three collaborators per repository for free.
So what's new is dropping the 3-collaborators-per-repo restriction.
I hadn't actually realized this restriction was there, apparently I've never used a private github repo in a free account! And the messaging from a year ago stuck in my head as "private repos are free on github now", I thought they had already done what they did today, oops.
Above natfriedman writes:
> We've wanted to make this change for the last 18 months,
So apparently they had wanted to do this even in Jan 2019 when they did something less than this...
The same safeguards that are in place on Azure (which is used by 99% of Fortune 500s for either Office 365 or cloud stuff), which is to say, ethics, and the fact that if they tried it once most of those companies would reduce their spend with Microsoft immediately. Not to mention the government contracts.
We got a sales call (seminar) from elastic.co. Despite all the positives, it was a hard value proposition. Why would we switch from Amazon's offering? For us noobs, elastic.co wasn't enough better to entice us to switch.
AWS is clearly scooping up the vast majority of users with their "good enough" offering. (I assume Azure, GCP, do the same.) I'm not saying it's right or wrong. I'm just saying it happens. And now Microsoft has much better forward looking intel.
I've been chewing on this ever since. Feels just like the 90s. I used to write AutoCAD add-ons. We third party developers knew in our bones that eventually Autodesk would steal our lunch money.
FWIW, I closed my personal repos on GitHub, in case any of my wares some day become popular.
--
[0] Amazon Has Gone From Neutral Platform to Cutthroat Competitor, Say Open Source Developers
Community leaders say AWS increasingly poses an existential threat
I suspect Microsoft wants to capture as much developer mindshare as possible and then cross-sell Azure. Reducing/eliminating entry costs for commercial grade features helps to do that.
I'll bite: They are shifting profits to CI and service landscape. I paid for 8 seats (previous: $64, now: $32) which gave me 10 000 included CI minutes (now: 3 000). I was just at that limit. Its surprisingly hard to find what the cost per minute is after that, but I guess I can check back in a month and see what my spending ends up at.
I'm sure they have enough info about onboarding and unit economics to see how it will pay off mid to long term.
I'll happily pay for use though, it makes sense and it makes the value addition of github core vs extra more clear.
Ok, so that'd cost me USD$56, leading to a higher monthly than previous pricing. So, steering users toward the Action landscape is obviously a better monetization model.
> For more than 99% of customers, these changes have lowered their GitHub bills, in many cases quite dramatically. For a very small number of customers who use a large percentage of the free Actions minutes allotment each month, these changes have the potential to cause your bill to increase by $20-50/month, depending on how much you use Actions in the future. To offset that possibility, we’re adding a free credit of $500 to your organization’s GitHub account for you to use in any way you want.
The fact that they're mirroring Gitlab's offering probably suggests that Gitlab is capturing market share from them. It's probably happening more now, as companies are taking very serious looks at their expenses.
I'm sure GitHub lands a lot more Enterprise customers compared to Gitlab, but for individual users who use organizations to have a separation in repos, and smaller teams, this price change is very convincing to move to GitHub even for teams, now that private repos are free.
GitHub has significant vendor lock-in, so it makes sense to make it free to capture the market before a competitor gets traction.
[Speculation:]
Perhaps they've run the numbers and can figure out that they make enough money from enterprise clients and will make enough more money from the 'marketplace' being a channel for selling github integrations and addons to cover this cost of not trying to monetize through supporting teams.
It also moves a large base from 'customer' with needed support to free users which don't need the same level of support.
E.g. I have git repos where I use multiple remotes (1 Github, 2 Gitlab..). So git is the same as everwhere.. I never felt locked in. It's not too hard to transfer your repos to another provider.
GitHub has pull requests, actions (mini CI integrations), other fuller integrations running off github hooks.
It's the issues, and pull requests that are the most immediate lock in. Transfer away and you lose your issues and PR history.
But more deeply it's the integrations. Even if it's all theoretically possible through other providers, if you have a working CI system set up to "just work" through GitHub then there's little chance you'll want to migrate to a different provider and have to re-do all that configuration.
Even with a dedicated dev-ops team it's weeks of disruption, not to mention the possibility to get half way through and discover something doesn't work the same way in [Competitor].
If you're up and running with github PRs driving JIRA issues and JIRA issues feeding into GitHub issues. And you have paid github marketplace integrations delivering value, then you're not going to look at a competitor unless that competitor is offering something that GitHub doesn't do.
Up to now the competitors have only differentiated on price as far as I can tell. There's certainly no killer feature of GitLab that people talk about.
Do they? Unless you're on GitHub Enterprise, migrating is just moving your repos over the weekend, setting up new webhooks, emailing everyone a command to switch their upstream URL, and hoping the new workflow works for you. For teams of <100, this it one of the easier transitions to make.
Thanks for sharing this, I'm a GitLab community advocate, and wanted to see if you'd like to join our #GitChallenge - You share a review of GitLab vs GitHub (whether positive/negative/neutral), and we send you some swag. More info if you're interested: https://about.gitlab.com/blog/2020/04/14/github-free-for-tea...
Probably to lure in early startups away from GitLab, which has this pricing model (free private repos, pay for required reviews and SSO) for a while now.
For one they have a good budget from Microsoft, secondly GitLab is good competition and thirdly I would assume they see their revenues in project.amangment and CI/CD features (tie in build workers with Azure etc.) and there is more money to make than restricting users (which can be bypassed realticely easily, while more contributors means more build hosts, means larger azure bills)
Can you please prioritize stability of your SaaS offering for paying customers? Our dev team and infra gets impacted seemingly every week with github outages, and it especially seems to correlate with delivery of new features. Thanks!
One thing to note is I had 3 members, it did not automatically downgrade my seats from 5. So in order to get it down to $12 a month I had to go downgrade my seats from 5 to 3.
This is great and I will most likely take advantage of this new offering, but I cant help but wonder why.
"everyone deserves GitHub" is marketing, not a corporate strategy.
How does GitHub stand to benefit from this change? How does more non-paying users help the company?
I am not trying to be a tinfoil hat jerk here. Life in the age of information has taught us all that (again) "nothing is free". So what am I paying here?
They lost that battle a decade ago. I would previously have suggested some kind of enterprise devops offering pairing with their other services but Microsoft will probably get there faster and better.
The pricing change appears to fall right in line with Gitlab's pricing (Free, $4/user/month, ~$20/user/month, and super expensive). I haven't managed to compare their feature matrices to see if the tiers are closely aligned, but from a glance they look similar.
The way I read the title and heading, it sounded like teams was now free.
This messaging is very confusing. Teams is not being made free, you need to pay $4 per user. A better message would be: "we're reducing your price to $4pp, and giving you access to more features."
Ugh.. did you notice that they also changed what the Free plan includes? Many of the premium features, including unlimited private repos for an org, are now included in the free plan.
I am actually going through the list and thinking my company might be able to do with the free plan from now on.
Hmm, literally the only paid feature left on the Teams plan we're using is Draft PRs. I am worried that as it looks like I won't need to pay for this service, that I, my team and my code will become the product to monetize at some point in the future.
Elsewhere in the thread they say that their big customers earn them enough to keep the lights on.
I’m much happier with a sliding scale model than ad or spyware based models. The problem there is that my experiences have been that a lot of expensive scaling work that you might otherwise have deferred gets done for your biggest customers, and we don’t often get the revenue right to absorb that hit. More than once our biggest customers have ended up having the lowest margins, if you de-fuzz the math.
Are there any plans to make GitHub itself available for self-hosting? I am not sure but the go-to place for open source software cannot be closed source.
Bitbucket was certainly more generous than GitHub at the time. I used them too. Their problem was the pricing structure. The break between "free" and "all your money, please" felt pretty harsh. They always appeared to be pushing very industrial companion tooling (eg Jira) which might have suited enterprise customers but wasn't very helpful to a freelancer. That's pretty common in SaaS. Enterprise is easier than volume.
By contrast GitLab's tiers are... Cheap. And it's perfectly feasible to do professional, modern CI flows on their free tier.
Microsoft could run all of Github free and still make money by integrating with Github and Azure so tightly that it is so easy to run code in Azure if you use Github
My legacy silver org plan (20 private repos) only shows a migration plan to teams at $4/user, is there something I'm missing? The new free tier seems effectively the same or better.
This isn’t really surprising. Microsoft has had a free equivalent for years with Azure Devops (formerly known as Visual Studio Team Service). Azure Devops has hosted build and deployment orchestration with either hosted build servers or local build servers using local agents. It also has private Nuget repositories, project planning, bug tracking etc.
Azure Devops deployment tools are (were? It’s been a couple of years) just as good for deploying to AWS as AWS’s own tools.
That's awesome, I feel like many companies increase prices over time trying to squeeze more revenue, but that usually requires monopoly power.
I remember from economics that in an idealized, efficient, large market, the price of a product should tend towards the marginal cost of production. In the case of SaaS, that's almost $0 (server costs being fairly low), so SaaS products ideally should all get cheaper over time. Good to see theory matching real-world here.
If you're like us and your entire Github usecase now fits within this free tier, it seems like you'll have to manually downgrade for it to take effect.
> We’re also reducing the price of our paid Team plan from $9 per user/month to $4 per user/month, effective immediately. Existing customers will have their bills automatically reduced going forward.
I don't mind this - we'll likely stay on the paid plan anyways at that price point. But there you are.
Would it be fair to explain this move as a "user retention" tactic. Perhaps it becomes a more difficult decision for teams to close out their paid accounts, even amidst an economic downturn, when the fees are removed.
One could argue some MSFT acquisitions have been focused on acquiring large swaths of exisiting users moreso than acquiring revenue streams or work product. Github could have been one such acquisition.
I'm confused about the "Collaborators for private repositories" feature. The Free plan shows an "unlimited" number of collaborators but each of the paid plans show "Up to org size". What does "Up to org size" mean? Which organization are you talking about? Does this mean that the free plans have more functionality?
Sounds like Microsoft is creating a new branch attempting to replicate the Atlassian business model. First get developers hooked on GitHub, then build GitHub integrations into enterprise software, then let developers make the sale to their own employers (primarily because developers like the little green activity boxes).
Linkedin was always a predatory organization, and now they are empowered to do what they actually wanted to do without the risk of going bankrupt if they miscalculate. Github is also empowered to do what they actually wanted to do without the risk of going bankrupt if they miscalculate. This is what you end up. You can't fundamentally change an organization by acquisition without destroying it. For example, Skype was destroyed like that. Github and Linkedin were not, and you are seeing them acting with fewer constraints. Linkedin is using their newfound power for evil, Github much less so.
I'd much rather they threw in more LFS storage on my $7 plan. But I suppose they know that already if they're moving towards a more "freemium" model. First hit is free, and then pay through the nose for LFS.
This is great news! I've always had my repositories spread across GitHub, gitlab, and bitbucket depending on what size group or features I needed but this helps centralize everything to GitHub. That is probably their goal!
Oh dear. That doesn't really sound like a good idea in the long term.
So once you place all your projects/repositories on a third party git service like Github and it goes down, what can you do to push that critical change? Might be no big deal for personal projects but unacceptable for big business and open source orgs.
You might as well call the CEO of GitHub for support. A better way is to self-host...
Even ignoring the higher cost to set up, are you sure your self-hosted solution will have better uptime? Are you sure you'll be able to get things up and running faster when it does go down than GitHub will when GitHub goes down?
Short answer: Absolutely yes. If you can setup a website using Docker, you can do the same with a Git server on-premise. Many companies have done this without Github for years.
Why you ask? You have total control over the stack, CI, etc and some orgs have in-house sys-admins or IT department to do all the work independent of a third party like GitHub. Maybe you should ask the Linux Kernel Project, WebKit, OpenBSD, Mozilla Firefox and even RedoxOS maintainers about why they self-host their projects which some even have mirrors on GitHub.
On another note I keep seeing this over on some repositories and now because it is 'private' I don't even think it remotely makes sense or is a good idea to even use GitHub to backup private keys even if the repository is 'private'. As long as it is on someone else's server, you're not in control.
However, looks like the Actions minutes included in the Team plan have dropped from 10K to 3K, so if you're currently paying for a team plan and using Actions your costs might not decrease, or might increase a bit
Thanks for sharing this feedback, we're doing a #GitChallenge right now (I'm a community advocate at GitLab) asking community members to send us reviews of GitLab vs GitHub (whether positive/negative/neutral) https://about.gitlab.com/blog/2020/04/14/github-free-for-tea...
> Note: Currently, you can add a self-hosted runner to a single repository. The ability to add and manage self-hosted runners for an entire organization will come in a future release.
Same. I liked that GitHub really nudged you to be open unless you were willing to pay to keep it closed (well, sure, you can go ahead and setup your own server or find a competitor you like, but in the base form, if you want to be part of the ecosystem, be open) and am wondering just how many student projects are now staying behind locked doors because GitHub wants to catch bigger fish.
Not saying they're a philanthropic organisation that should promote open source to the kids or anything, just agreeing about an almost certain side effect.
Ask for a refund of all the charges, people don't realize that a lot of companies do that these days. You should be upset if they refuse (assuming you genuinely weren't using their premium features).
Thanks. I'm not surprised by this. I know this isn't a "mainstream" opinion, but I was fairly happy when MS brought GitHub. I think that the Nadella MS is much more streamlined than the old "Enemy of the State" version that got our undies in a bunch, back in the last century.
All the places Microsoft has shipped awesome products and won the market didn't have as strong monopoly (or duopoly) effects as in the mobile space. I don't think we'll see a MS phone any time soon unfortunately.
Does anyone remember the arbitrary actions GitHub has taken in the past few months and all the "maybe it's time to start leaving GitHub if you want to avoid getting your repositories permanently deleted?"
Or is HN just as susceptible to the narrow news horizon?
Fair enough... Hence also why Google have plenty of Apps users etc even though they have a long track record of dropping even popular products at their whim.
Thanks for reminding me that it really is to each their own, and good luck to you on your path.
Microsoft/GitHub is doing something clever this time. They know where the developers are and know that the new consumers are developers, hence 'devsumers'.
So how does Microsoft make them happy? Give 'em free stuff: Free repositories, student pack, ebooks, courses, cloud credits, etc and they come running back to GitHub. There's Sign in with GitHub which makes it easy to claim all the freebies, unlike the rest of the alternatives.
This is why the majority of developers will stay and some would realise that it will all go down and will leave Github and self-host their own git server instead.
Many comments are saying that Microsoft is doing this move to help cross-selling Azure.
I don't see many users of free tier willing to spend money on Azure.
If anyone from GitHub's around in this thread, would you mind putting "ui-monospace" at the front of that list? SFMono-Regular no longer works in Safari because of fingerprinting concerns.
Not from US and dont know the topic in depth, but I like this idea that instead of not engaging with your government, you earn their money and actively help / fund action to reverse its course. After all that is or should be how is works in a democratic country.
This should be the overriding concern of everyone in this forum. It's no longer astonishing[0], but it is quite disgusting how HN participants are able to compartmentalize their enthusiasm for technology away from moral or ethical qualms. I suppose the most generous interpretation is to assume that they are simply unaware.[1] Upstream of that ignorance, however, is a fearful unwillingness to interrogate the foundations of one's own life.
0. "It is difficult to get a man to understand something, when his salary depends on his not understanding it." ― Upton Sinclair
That's basically the "yet you participate in society" of ethics discourse. It's entirely possible to encounter qualms in everything you see - that's hardly a sign that the world is okay as it is and we shouldn't try to make it better.
If you think I hold you all to a higher standard than I hold myself, you're mistaken. I have never been able to leave the house without encountering qualms. The world around me is an interconnected weave. Denying that fact only makes it easer to live a very particularly worthless kind of life.
Not compartmentalising is trickier than you imply, as the whole corporate-capitalist system of power (which supplies nearly all of your and my goods) depends at its root on current exploitation and drawing down on its investment in future destruction (of the entire biosphere). We can point fingers at many hideous individual corporate citizens in tech (Dropbox & Amazon spring immediately to mind, current Microsoft doesn't), but the whole system depends intrinsically on maintaining the ignorance you write of.
How to extricate ourselves from all that? Personally, I'm for revolution to take it all down. But we know that isn't going to happen.
I'm not entirely sure. If I had a recipe I'd probably be a leader somewhere rather than an anonymous sometime programmer in deepest Northern NSW!
One of the few things I'm pretty certain of though is that the capitalist-corporate system is a road to worldwide destruction. And that there are no diversions within the system, no reforms that can do anything other than alter the speed of the decline. It all has to go, by whatever means necessary. Though I'm open to the possibility that the course is a biological given, and capitalist-corporatism is merely a consequence of that biology. In which case, we're done.
github is not doing anything special to make ICE worse. the reasoning of divestment from disagreeable organizations is an individual right, but does not make sense to be adopted as a company policy to not work with LEO's.
being politically minded at a company is fine, but trying to shame companies into adopting your ideals is unrealistic and counterproductive for neutral tools like Github
> “You can’t be neutral on a moving train,” I would tell them. Some were baffled by the metaphor, especially if they took it literally and tried to dissect its meaning. Others immediately saw what I meant: that events are already moving in certain deadly directions, and to be neutral means to accept that.
― Howard Zinn
They've stated that it's not actually that much money. Which makes the decision even more baffling. They could easily afford to drop the contract, but choose not to anyway.
Can you explain this position? If GitHub were funding their free teams product with revenue from, say, organized crime which is kidnapping children, would it be appropriate and on-topic to ask about that? But it's no longer appropriate when it's a government agency?
Is it just US government agencies, or would it be appropriate again to ask if the funding were coming from ISIS?
Also, is it generally the case that complaints about the NSA and their spying programs are off-topic for HN because they too are a US government agency? Or is that different?
No, your comment just doesn't make sense. Lightbulb manufacturers are not responsible for wars because tanks have lightbulbs in them, and GitHub is not responsible for all the harm in the world either because some bad actors use GitHub.
Sorry, I can't even discuss this with you. I rather disagree - this is what the whole "military-industrial complex" is about - but it's off-topic and forbidden.
This is totally not what the "military-industrial complex" is about. Wow.
The MIC concept is a specific application of the general idea of regulatory capture of policymakers to the vertical of defence contracting. This is nothing like that: the corporation here isn't a defence contractor and they're not bribing the government. It fits 0%.
organized crime doesn't exist. governments are indeed allowed to commit organized crime as you said.
if you want to overthrow or change that government you are free to do so. revenue obtained from that government is as bloodstained as any capitalist money, and most sources of profit can be dismissed as exploitive. its quite literally the point of profits.
if github teams were funded by isis I literally would not change my opinion on github.
It's not really fair to compare selling tooling to a large agency that does a lot of different things with directly writing software that does something evil.
whats stopping torture workstations from being managed with Kubernetes and Chef?
you could use any modern orchestration tools to replace humans running torture machinery. code only serves to automate human behavior not create new behavior that isn't just amplifications of humanities worst desires.
Arguable but irrelevant. I'm arguing against your absurd universal and inhuman suggestion (nay, command!) to keep politics out of the discussion. On the particular topic at hand I think I'm somewhat in agreement with your conclusion (though I'd need to reflect more to be sure).
You know what the Greeks would have thought about someone that doesn't care about politics? They'd think their best station in life would to be a slave.
but anyone including drug cartels are free to use github and google docs.
sure it might be against Googles policy on a technically but are you seriously suggesting crime orgs care about the TOS included with their burner android phones?
Probably not very smart to use this feature, since your so-called "private" repository is an exploit or a leaking employee away from becoming public.
Instead, use a self-hosted Gitlab instance or similar, preferably with an external firewall preventing outbound and non-team inbound connections if feasible.
We've wanted to make this change for the last 18 months, but needed our Enterprise business to be big enough to enable the free use of GitHub by the rest of the world. I'm happy to say that it's grown dramatically in the last year, and so we're able to make GitHub free for teams that don't need Enterprise features.
We also retained our Team pricing plan for people who need email support (and a couple of other features like code owners).
In general we think that every developer on earth should be able to use GitHub for their work, and so it is great to remove price as a barrier.