Hacker News Reader

Comment by natfriedman | Hacker News Reader

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.

View on HN

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?

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.

Do you plan to make github enterprise available for free on their own premises for teams?

This has been possible since long, what am I missing?

I'm assuming he means on-prem GHE, for free, which I would doubt since that would eat away their revenue.

If you REALLY need to self-host, try Gitlab.

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.

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.

Big companies like Microsoft and Google like to burn products with little notice too.

...and small companies go under or radically morph their products.

There's this irrational demand vocal on social media that large corporations keep their products forever.

Sears is doing it!

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?

https://www.wired.com/2015/09/what-to-do-with-your-zune-rip-...

The company who STILL supports 16-bit apps?

https://www.groovypost.com/howto/enable-16-bit-application-s...

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".

Then again there is this list of 346 discontinued Microsoft products, some of which had very short lifespans: https://www.versionmuseum.com/history-of/discontinued-micros...

Yes, I would definitely hate to trust Microsoft with my enterprise software build pipeline because of how they refused to support Microsoft Bob.

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.

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?

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.

https://einvoice.microsoft.com/Default.aspx?MSIStateKey=f513...

Sharepoint is the backend for onedrive for business, and fully integrated in to Teams. What on earth would make you think it's going away?

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.

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.

What about Atom/VSCode? Atom development looks dead to me:

https://news.ycombinator.com/item?id=21142934

https://github.com/atom/atom/graphs/contributors

That is true for Google, but certainly not for Microsoft. Microsoft's support for legacy software is pretty amazing actually.

It's terrible. AppFabric, WCF, WWF, windows phone. I could go on for hours...

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)

See this: https://news.ycombinator.com/item?id=22872556

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.

> No company would invest a massive amount of money in a duplicate product.

Google's text messaging and video chat apps didn't get that memo.

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.

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"

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.

0: http://azpodcast.azurewebsites.net/post/Episode-321-GitHub

Very valuable comment / insight via the podcast – thanks!

The writing is on the wall... TFS is going the way of Silverlight.

Please deprecate Azure devops repos, which my company uses, to let me go back to GitHub. I absolutely hate the UI and miss GitHub greatly

As a former member of Azure DevOps, I've heard from my colleagues that the Work Items and Agile features are totally in maintenance mode

Can you explain what happened to Atom development?

I've seen numerous posts noting the sharp decline in contribution soon after the acquisition was announced.

https://news.ycombinator.com/item?id=22601451

https://news.ycombinator.com/item?id=21142934

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:

https://www.reddit.com/r/AMA/comments/8pc8mf/im_nat_friedman...

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.

I gave up on Atom this month because of the lack of development. Too bad really.

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.

VSCode is electron-based.

This is precisely what he is saying.

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.

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.

Sometimes my wife wants an explanation from me the human being who said he would take the trash out but then never did.

Then maybe you should own up to the consequences of the choice you made and explain your reasoning for not fulfilling the promise that you made.

I did. I was playing Factorio and all of a sudden it was 3am.

Why does he owe you an explanation for a product that was free? Its posts like this that convince him that open source isn't worth contributing to.

Nothing is free. Accountability matters.

Gosh, you have completely misunderstood the point of this comment.

The comment is not asking for an explanation about supporting an open source product.

They're asking for an explanation about promising continuing support for something and then apparently doing nothing to back that claim up.

You seem to be implying that integrity in public statements should only apply if you're referring to non-free commercial software.

> It offers very little solace to the few Atom users still hanging on

This is kind of hilarious. What are you hanging on for? It's damn editor. Pick a new one and move on.

You have the explanation laid out pretty well by chipotle_coyote in the comments of one of your linked posts.

https://news.ycombinator.com/item?id=22601557

Specifically:

> 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.

Um... I think you might have me confused with someone else?

I looked through my own post history and it looks like I did reply in a thread about this topic a while ago: https://news.ycombinator.com/item?id=22606843

(same thread that I linked above)

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.

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?

SS13 got banned? Damn, I loved reading that old DM codebase every once in a while. Where have you guys migrated to, GitLab?

I only follow it loosely but I believe most are planning to move to GitLab if their repos aren't unbanned.

Private repos are not subject to our Community Guidelines on public content, so no, we don't enforce the same rules there: https://help.github.com/en/github/site-policy/github-communi...

I wasn't aware of SS13, and will look into what happened there. Content moderation at GitHub scale is hard and sometimes mistakes are made.

> Content moderation at GitHub scale is hard and sometimes mistakes are made.

This is completely fair, but lack of transparency makes it significantly more frustrating.

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.

This is a well thought out response with factors that weren't obvious to me - thanks.

Transparency can give bad actors a way to game and workaround the system.

More likely, ammo in a potential legal battle between GitHub and the banned party.

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.

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.

> transparent juridical system and it works fine

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.

Online moderation is an issue of personal rights.

Not in the Constitutional sense, and not in anything administered by GitHub.

It should be!

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.

1) You can be thrown into jail without any explanation whatsoever.

2) You can be shot without any explanation whatsoever.

3) Your possessions can be taken away, and sold off without any explanation and without recourse.

Links about each of these claims:

https://abovethelaw.com/2018/07/innocent-people-who-plead-gu...

https://en.wikipedia.org/wiki/Shooting_of_Walter_Scott

https://www.forbes.com/sites/jacobsullum/2014/09/11/how-cops... (also applies to, say, cars)

So GitHub should aspire to do the same?

Are you willing to pay taxes for github usage!? You get what you pay for.

If it guaranteed that the repos stay up in perpetuity, that sounds amazing, actually.

How is "game and workaround the system" different from "comply with policies"? Is compliance not the objective?

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.

> It gives enforcement actors a little lee-way that they wouldn't otherwise have.

Which can be and often is subject to abuse.

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.

> Abuse can be exposed and punished, and very often is.

But nowhere near often enough.

Law in many countries comes down to "I know it when I see it" from the judges.

That sounds like it will lead to a lot more restrictions than there are today.

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.

Do you honestly not understand a difference between people who comply in good faith vs people who simply skirt the rules?

So just to be clear, are you arguing that rules shouldn't be clearly laid out, because then people would be able to follow them?

Not taking a side on this, but there do exist people who exactly follow the letter of the law to circumvent the spirit of the law.

For example, people who harass others just within the confines of the rules so that they can't be banned from a community solely using the rules.

This is why we need humans to judge the spirit of the rules.

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.

> 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.

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.

https://xkcd.com/1357/

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.

I think Munroe very much approves of it's abuse, when coming from the correct political side.

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.

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.

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.

Where did GP make that argument?

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.

"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."

In theory, yes. In practice, your github repo is more like a domain name. There should be due process.

Do public repos that get banned have access cut off, or are they just forcibly made private?

Access is cut off in our case (ss13), i don't know if that's different in user owned repos vs org owned repos.

I run /tg/station's servers.

A few questions:

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.

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).

Not that this seems like the real reason why SS13 got nuked anyway; if GitHub really has some kind of anti-profanity rule, they're doing a real bang-up job of consistently enforcing it: https://github.com/search?q=shit / https://github.com/search?q=piss / https://github.com/search?q=fuck / https://github.com/search?q=cunt / https://github.com/search?q=cocksucker / https://github.com/search?q=motherfucker / https://github.com/search?q=tits

We named our meatballs a old british name.

This was why we got nuked.

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

Blisteringly arrogant of a US company to police the language of another natively english speaking country.

This is not the Scunthorpe problem, this is a culture one.

Is the image, purportedly of a search of the codebase, in this post falsified? https://tgstation13.org/phpBB/viewtopic.php?f=2&t=26318#p554...

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.

First of all, thank you, this is great news.

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.)

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'm curious: since GitHub Pages intended to PUBLISH pages, why to make the repo PRIVATE?

Sometimes people want to keep the code, commits, etc. private but maintain a blog

Use a private repo, attach a code action to publish your output of your favourite blog to static html output to a public GitHub pages repo.

Nobody's saying it's not possible with a hack or workaround, just that it doesn't work out of the box.

I still get a Pro option when going to https://github.com/account/upgrade from a free account, and it seems to match Teams, here's the blurb:

> Required reviewers in private repos

> Protected branches in private repos

> Repository insights in private repos

> Wikis in private repos

> Pages in private repos

> Code owners in private repos

> 3,000 minutes for GitHub Actions

> 2GB of storage for packages

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.

It's on the FAQ at the bottom of the announcement blog: https://help.github.com/en/github/getting-started-with-githu...

Though it does require a bit of between the line reading

I think it's Okay. If you are going with the Pro account today you need a particular feature. So you likely know what you are looking for.

So basically Pro and Team are the same now?

Edit: The FAQ points to Github product page [1] which list GitHub Team having 10K Actions instead.

[1] https://help.github.com/en/github/getting-started-with-githu...

So... wouldn't this mean GitHub Team with a single user is better than GitHub pro?

Now that's just weird, pricing page says 3k for Team.

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.

C'mon, that's an unnecessarily cynical take. The offers in the student pack are here: https://education.github.com/pack

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.

> You can see that there's a lot of overlap and that these offers cover very broad sections of the industry.

True, but that applies as much to their $200k figure.

> This gives students the opportunity to explore and develop immediately employable skillsets without impacting their already limited budgets.

The stuff that's worth using has free or cheaper alternatives anyway.

As a student, I am hoping the company that I will work for later will pay for it.

At the same time, I am also aware of free and cheaper alternatives for some of the options there.

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.

Agreed. SAML even makes sense for solo dev.

So you care a lot about this, but not $4/month care?

SAML is an enterprise feature; it's $21/user/month.

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.

could you elaborate further with use-cases?

Not having to create separate usernames and passwords with yet another service (GitHub)

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).

sources:

* https://help.github.com/en/github/setting-up-and-managing-or...

* https://help.github.com/en/github/authenticating-to-github/a...

[edit: formatting]

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

I agree, but I think the GP was asking about use cases for a solo dev.

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.

If I was in a knife fight, and my buddy showed up and just hit the guy I was fighting with a SSME, I would be totally impressed and also grateful.

Stuff like SAML is kind of the only leverage freemium SaaS has for rationalizing charging enterprise customers.

Not true. There are other things (like audit logs, invoice/PO payments, better support) that enterprises will still want.

Yeah but considering SAML is one of the primary asks of enterprise, it kind of makes it a big selling point.

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.

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:

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.

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.

But saml is for integration (SSO). Github provides 2fa for free.

What enterprise is paying is the convenience, not security itself.

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.

Even the ability to just “login with gmail” for non-enterprise accounts would be huge

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.

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.

+1 Wish I had more upvotes to give. This should exist.

Nod to Keycloak / Red Hat SSO here, it’s my goto solution for dealing with identity these days.

> 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

You want Keycloak - https://www.keycloak.org/ - then.

+1 for keycloak

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.

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.

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.

What's the closed-source SAML library you're thinking of? Every SAML integration I've seen has been done with an open-source library.

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.)

What's are the other contenders for top 3?

MDM or endpoint tracking, and then it gets diverse.

> 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.

> so everyone treats this as an up-sell feature.

And that's the mistake.

What about OpenID Connect? That seems a lot simpler, and also has open source implementations that aren't too intimidating.

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.

I basically agree with the points.

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.

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.

I'd never heard of SAML before. Is it like a more complicated version of OAuth?

Basically, yes. Give me a choice between SAML and OIDC, and I'll choose OIDC every single time.

SAML has been around longer and handles AuthN and AuthZ

OAuth only does AuthZ. I've always found OAuth more complicated because you have to combine it with other technologies to get AuthN

For those like me who had never heard these abbreviations:

AuthN: Authentication (who you are) AuthZ: Authorization (what you are allowed to do)

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.

For sure. I never said SAML was any good -- I said I found it to be simpler. :)

For developers, they're both just libraries. As protocols to implement, SAML is drastically harder.

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.

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.

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:.

I was _just_ thinking of https://latacora.micro.blog/2020/03/12/the-soc-starting.html and https://sso.tax/ as I was writing my comment!

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.

Yes, we are working on an official CLI here: https://github.com/cli/cli

I think open sourcing GitHub is an interesting idea.

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!

Oh, I did not realize that was official & supported. Excellent. Looking forward to its maturity.

Unrelated: have you seen https://sourcehut.org/? Thoughts?

> 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.)

Utterly bizarre.

And now they have done it again, apparently because GitHub serves ICE: https://github.com/drop-ice/dear-github-2.0

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.

On behalf of our tiny team at WorkOS, thanks! :)

Hey Nat, thank you so much for this! We're a small team from India and we love Github but were always conflicted due to the pricing.

The new flat price of $4/user seems perfect for us. I've already moved one private repo to our org account.

Thanks again ^_^

Just curious what motivates you to pick the $4 plan over free? None of the features there are really deal-breaking for most orgs.

- Required reviewers

- 3,000 Actions minutes/month (Free for public repositories)

- 2GB of GitHub Packages storage (Free for public repositories)

- Code owners

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.

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:

* protected branches

* codeowners

* draft PRs

* pages and wikis

* multiple assignees (PRs and issues)

* required reviews & status checks

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

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.

[1] https://education.github.com/schools

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.

It was open source, but they have now closed it off, although the old source archive is still available.

See https://github.com/education/classroom/commit/a824a057b939c0...

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?

It looks like pro accounts have vanished? I can't find them anywhere; I assume we just won't be charged from here on out?

My account still says GitHub Pro but the billing amount has changed to $4

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...

A full FAQ on pricing is available here: https://help.github.com/en/github/getting-started-with-githu...

Hope that's helpful!

Seems kind of odd as Pro isn't listed on https://github.com/pricing as far as I can see.

We're working on clarifying this.

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.

Github pages are free for public repos, aren't they? Perhaps switching to a public repo is an option.

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.

Hi Nat, What's the plans for integrating Microsoft's VFS for Git into GitHub?

https://github.com/microsoft/VFSForGit

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.

Have you tried other CI/CD platforms? Different providers use different language but the workflow concept underpins all CI/CD pipelines.

My team stuck with Jenkins, Docker, and custom shell scripts to get the job done.

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.

[0] - https://github.com/actions/runner

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.

As an ios dev too, do you have any favorite actions you can recommend?

I don't think it was particularly difficult to use... the multi-os targets are probably about the most confusing.

I tend to stick with bare scripts and npm scripts as much as possible though, so the environment doesn't matter as much.

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.

A lot of things use YAML for configuration... what would you prefer for configuration? XML?

I want to write a Dockerfile. I don't particularly have an issue with YAML.

then why not write a dockerfile, and have your yaml, just do the docker build... command?

HCL, which is what GitHub Actions used when it first launched

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.

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?

When you're going through SOC-2, your auditor will ask for the SOC-2 report of each critical vendor.

If you're at that level of auditing I'd expect your company has enough cash to fork over for GHE.

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.

Thank you!

When you emailed this question to GitHub Support, how did they respond?

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.

thanks for the fast and reassuring answer, I appreciate it. I'll wait until that message goes away, I can't risk losing my private repos.

Is the system supposed to be charging for outside collaborators on the Team plan still? The language makes it sound like those should be free now.

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.

Thank you

Came here to ask the same thing. I literally set up Teams @ $25/month for 2 seats only and paid in full for annual...

How does this price change affect me?

Also, has the number of minutes for Actions gone down from 10k to 2k monthly?

Are you aware that GitHub users still can't sort their repositories into folders?

Because that's definitely one reason why some developers still don't use GitHub.

Take a look at this request which has been open for years and remains unfulfilled:

https://github.com/dear-github/dear-github/issues/74

Is there a reason that such incredibly basic functionality doesn't exist on GitHub but does on all your competitors' offerings?

Why do you still have a contract with ICE?

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?

Any plans for free on prem version, like Gitlab?

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.

This is completely unrelated to the announcement, but when will Enterprise Server ship support for GitHub Actions?

We'll have a beta next month, and should ship this summer.

Oh thank god. I was getting close to jumping ship to GitLab, which supposedly has toptier CICD stuff.

Now I can at least compare the two.

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.

Hey how about introducing a function to create a branches from issues

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.

Will there ever be an OSS version of GitHub, a la Gitlab?

Hi Nat, will GitHub ever support git diff algorithms other than the default?

Introducing pomodoro technique into the tasks would be great.

> every developer on earth

This now includes Iran, Syria, and Crimea. Bravo

Are you still providing services to people who put children in cages?

When will GitHub terminate its contract with ICE?

Reply on news.ycombinator.com