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.
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?
That said, like 90% of my Pipeline actions are "screw it, I'll do it all in PowersHell"
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.
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.
The company who STILL supports 16-bit apps?
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".
- 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.
Microsoft Invoice has transitioned to a cloud-based product, so again, they didn't end support. You might not like the new purchasing model, but that's very much different than them burning the product to the ground.
Sharepoint is the backend for onedrive for business, and fully integrated in to Teams. What on earth would make you think it's going away?
There's this irrational demand vocal on social media that large corporations keep their products forever.
Google's text messaging and video chat apps didn't get that memo.
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.
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.
I've seen numerous posts noting the sharp decline in contribution soon after the acquisition was announced.
Without an official explanation, given the timing, it'd be reasonable to assume you pulled development resources away from it, the exact thing you actually went on Reddit to claim you wouldn't do:
P.S. I've observed that these kinds of posts tend to turn into a place where people shit on Atom in favor of _insert preferred other editor here_. Feel free to do that here too, but just note that I'm not going to be obliged to engage since it's completely orthogonal to the topic at hand. I think any remaining Atom users at this point are likely already painfully aware that Atom has long since lost the war in developer mindshare, but don't let that stop you from pouring salt on the wound.
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?
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.
This is kind of hilarious. What are you hanging on for? It's damn editor. Pick a new one and move on.
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.
> 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.
If not, what's the goal of the complaints? I.e. why do you keep bringing this up if you know this is water under the bridge?
I'm a github user, though I wouldn't call myself a fan exactly, and I don't really know how "teams" works or why it's valuable. I came to this thread to learn more, and I find your comments grousing about Atom again. Hence my question.
I 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.
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.
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?
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.
> 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.
For once, I'm not going to complain that something is made in Electron :) It was unusable to me in other ways too.
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.
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.
This is completely fair, but lack of transparency makes it significantly more frustrating.
Grumbly investors beget grumbly board members, who then vote to oust executives to correct the profitability problem.
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.
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.
Most US companies these days have no morals, and are easily influenced by these tactics due to greed and fear of being targeted themselves. Silicon Valley and the majority of the big tech companies seem to be especially vulnerable to this, probably due to their own employee demographics.
What many of these companies don't understand, possibly because they live in a relative 'bubble' surrounded by those who think similarly, is that there are a lot of us out there who not only disagree with this type of behavior, but will actively NOT use the services of any company who supports these types of tactics.
You'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.
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.
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.
* 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.
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://www.forbes.com/sites/jacobsullum/2014/09/11/how-cops... (also applies to, say, cars)
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.
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.
Which can be and often is subject to abuse.
Abuse can be exposed and punished, and very often is.
But nowhere near often enough.
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.
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.
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.
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
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
This is not the Scunthorpe problem, this is a culture one.
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.)
> 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
Edit: The FAQ points to Github product page  which list GitHub Team having 10K Actions instead.
Though it does require a bit of between the line reading
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. :)
As for how we sustain ourselves -- lots of big enterprise customers!
Well, unless they decide to switch market or shut down, in which case you're hosed no matter how much you're willing to pay.
You can see that there's a lot of overlap and that these offers cover very broad sections of the industry. This gives students the opportunity to explore and develop immediately employable skillsets without impacting their already limited budgets.
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.
At the same time, I am also aware of free and cheaper alternatives for some of the options there.
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 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.
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.
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
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 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.
If you as a SaaS provider outsource your SAML integration to a third party provider like Okta or Auth0, the auth provider pricing is immediately on a "call us" tier, with a per-federation pricing in the low four figures for each company connecting via SAML. Let me just state that again, to have company X connect to my SaaS via SAML, I as the SaaS provider have to pay my auth provider $X,000 per year for the privilege, not counting the base enterprise tier pricing for the auth.
It 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.
Instead of directly bolting SAML into your app, I think a FOSS implementation of an independently running service is the way to go. You run the battle tested open source service (locally / in your cloud), it accepts the SAML assertions and mints something sane like JWTs which can easily be consumed by the service providers, isolating the entire thing from your core app and allowing it be used with any stack. E.g. essentially an open source locally deployed Okta. Doesn't even need to do any user management, just focus on rock solid interoperability and forward all decision making to the actual app server.
If you want 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.
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'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.
You want Keycloak - https://www.keycloak.org/ - then.
The opposite certainly exists though, for example simplesamlphp which gets commingled into a php app codebase as you described.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.)
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.
2. I think the product complexity issues are, like, 95% the same whether you use OIDC or SAML.
3. I think no matter how much simplification you got from using OIDC instead of SAML, none of it is going to offset the actual reason why SSO integration is a paid feature.
4. I agree that SAML is much worse than OIDC from a protocol implementor's perspective even if I'm not so sure that it's much better from a developer's perspective, so wouldn't want to find new reasons to disagree.
Ironically, the first point makes me realize that half the work to bring in a product in an entreprise is to deploy and set it up -properly with authentication- while the other half is to get the budget and approvals to buy it. Thus it's rather relevant to the thread in an unfortunate way.
Now that the core Pro features are free, I wonder if Rob will update sso.tax to set Github to :inf:.
What enterprise is paying is the convenience, not security itself.
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.
OAuth only does AuthZ. I've always found OAuth more complicated because you have to combine it with other technologies to get AuthN
AuthN: Authentication (who you are)
AuthZ: Authorization (what you are allowed to do)
I've never had to clarify what someone is actually trying to accomplish when they want "SAML 2.0"
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.
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.
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.
Source: Watching an alcoholic CTO get fired by the board and taking the startup's hosted Mongo database hostage
Even the ability to just “login with gmail” for non-enterprise accounts would be huge
Also: are there plans to open source more of GitHub? Post Microsoft acquisition, I have been increasingly concerned about vendor lock-in, EEE, and so forth.
I think open sourcing GitHub is an interesting idea.
Unrelated: have you seen https://sourcehut.org/? Thoughts?
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.)
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.
On behalf of our tiny team at WorkOS, thanks! :)
The new flat price of $4/user seems perfect for us. I've already moved one private repo to our org account.
Thanks again ^_^
- Required reviewers
- 3,000 Actions minutes/month (Free for public repositories)
- 2GB of GitHub Packages storage (Free for public repositories)
- Code owners
* protected branches
* draft PRs
* pages and wikis
* multiple assignees (PRs and issues)
* required reviews & status checks
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
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.
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.
A full FAQ on pricing is available here: https://help.github.com/en/github/getting-started-with-githu...
Hope that's helpful!
"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 firstname.lastname@example.org."
Am I missing something or is this not implemented yet?
(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"))
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.
 - https://github.com/actions/runner
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.
I tend to stick with bare scripts and npm scripts as much as possible though, so the environment doesn't matter as much.
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.
How do I downgrade without losing all my private repos.
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.
How does this price change affect me?
Also, has the number of minutes for Actions gone down from 10k to 2k monthly?
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:
Is there a reason that such incredibly basic functionality doesn't exist on GitHub but does on all your competitors' offerings?
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!
No, there has not been any change to the data pack pricing for LFS data.
Glad this will help you continue building on GitHub!
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?
Why not just use Gitlab if you really need on-prem for cheap/free?
Now I can at least compare the two.
This now includes Iran, Syria, and Crimea. Bravo
> 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.