zlacker

>>ig0r0+(OP)
Well, this is amazing! I never would have thought the Microsoft acquisition would have these kinds of results! Congrats to Nat and the GitHub team (and by extension Microsoft) for making this possible!

I wonder whether this is a result of market conditions, or whether GitHub sees this is a first-to-market play of some sort, or whether it's something else. I hate to be a cynic given how much good Microsoft + GitHub have been doing lately, but what prevents this change from being rolled back?

Congrats again! I love using GitHub and look forward to many happy years shipping code on the platform.

>>yingw7+R1
I feel like anyone who lived through the 90s could have expected "these kinds of results".

Git is open source and widely supported, which doesn't benefit Microsoft. By causing GitHub-specific features to be an essential part of a "modern" or "industry standard" git workflow, they can capture more marketshare/attention, and cause alternatives to be sidelined. This requires removing all friction to entering the proprietary ecosystem, including purchasing. This, along with the acquisition of NPM, is the "embrace" part.

The next will be an expansion of GitHub and NPM's featuresets in ways that are only accessible via branded, first party tools (i.e. not git/ssh/yarn). GitHub has already made some inroads there prior to the Microsoft acquisition with of course the ubiquitous PRs as well as GitHub Issues and Actions. I imagine the ability to check out GitHub wikis as git repos will probably eventually go away to further this.

The last part ("extinguish") is turning off support for non-firstparty tools like git-via-ssh, .patch URL support, issue collaboration via email, yarn, et c. By the time they do this, few people will notice, having acclimated to the entirely-proprietary ecosystem they've been incrementally subjected to.

The goal, as always: a Microsoft editor (VS Code or Atom), editing code in a Microsoft language (TypeScript/.NET/whatever), signed off via Microsoft review software (GitHub mobile), publishing to a Microsoft website (GitHub/npm), running CI on a Microsoft VM (GitHub Actions), pushing code to a Microsoft datacenter (Azure).

It's simply a moat to prevent open, unfettered competition in any intersection of the vertical. Any weak spots (such as GitHub signup friction) are to be subsidized as they will yield benefits when later used as a cohesive whole in an anticompetitive fashion.

>>sneak+68
I think it's worth pointing out that GH was always on this path, to the point where it's actually kind of hard to explain the difference between git and GitHub to fairly technical people.

It's also worth pointing out that it doesn't have to come from malicious intentions.

>>anders+fC
It's tough to say that the urge to replace free software and open collaboration protocols with proprietary, closed source pay-to-play tools that the user isn't in control of (the whole GitHub SaaS model) isn't "malicious intentions".

It's replacing an open, free (in both senses), decentralized system with a closed, for-profit, centralized one that expressly benefits a single organization at the expense of everyone else in the ecosystem.

This is not to say that GitHub isn't a benefit over emailing patches around; just that it's probably also worth mentioning that Linus et al have not migrated to this shiny new (centralized) system for the largest collaborative development effort in the history of the world, and, indeed, git itself was developed specifically to avoid a hard dependency on a single, centralized point.