Live data from Hacker News

GitHub is now free for teams

github.blog

371–380 of 664 posts

Re: GitHub is now free for teams

#371
post #317
post #311

Earlier quoted context omitted.

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.

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

Re: GitHub is now free for teams

#372

Earlier quoted context omitted.

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),…

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 t…

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.

Re: GitHub is now free for teams

#373
post #282

Earlier quoted context omitted.

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…

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

Re: GitHub is now free for teams

#374
post #297

Earlier quoted context omitted.

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…

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

Re: GitHub is now free for teams

#375
post #297

Earlier quoted context omitted.

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…

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.

Re: GitHub is now free for teams

#376
post #81

Earlier quoted context omitted.

I feel like anyone who lived through the 90s could have expected "these kinds of results". Git is open source and widely supported, which doesn't benefit Microsoft. By causing GitHub-specific features to be an essential part of a "modern" or "industry standard" git workflow, they can capture more marketshare/attention, and cause alternatives to be sidelined. This requires removing all friction to entering the proprie…

Luckily history has shown that competitors still exist in a world where Microsoft tried hard to “extinguish”. macOS and Linux still exist, Chrome is the most popular browser (not IE), and most people who use Windows are fairly happy with it. You can try to point to Microsoft’s past behavior as proof that the future of GitHub is dystopic, but I don’t think their past behavior was particularly effective at snuffing out…

> I don’t think their past behavior was particularly effective at snuffing out all competition and forcing people into their ecosystem

I still buy a Windows license to play video games. I don't want to use Windows or buy a Windows license.

Of course, I could always choose to not play video games, so technically you're correct that I wasn't "forced" into their ecosystem. But I'm still there and I don't want to be. This is a direct result and present day residual benefit of their anticompetitive practices over twenty years ago. These are very long games that they play; you don't make hundreds of billions of dollars by accident.

Re: GitHub is now free for teams

#377
post #361

Probably not very smart to use this feature, since your so-called "private" repository is an exploit or a leaking employee away from becoming public. Instead, use a self-hosted Gitlab instance or similar, preferably with an external firewall preventing outbound and non-team inbound connections if feasible.

Your proposed solution handles neither the rogue employee nor the exploit scenario. It does incur a lot of additional cost in maintenance.

Re: GitHub is now free for teams

#378

Earlier quoted context omitted.

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 li…

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.

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"

Re: GitHub is now free for teams

#379

Earlier quoted context omitted.

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 t…

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.

Re: GitHub is now free for teams

#380
post #297

Earlier quoted context omitted.

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…

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 direc…

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.

Post reply on HN