zlacker

[return to "GitHub is now free for teams"]
1. yingw7+R1[view] [source] 2020-04-14 16:14:29
>>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.

◧◩
2. sneak+68[view] [source] 2020-04-14 16:42:00
>>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.

◧◩◪
3. ghshep+ji[view] [source] 2020-04-14 17:27:24
>>sneak+68
Speaking as someone who worked at Netscape during the 90s, your comparison is missing on a lot of fronts.

First, Microsoft was evil back then because they didn't just rely on excellent pricing and features (both of which they had) - but also because they leveraged their monopoly in one market (desktop operating systems) to prevent competition in adjacent markets (browsers).

I think it's difficult for people to believe that Microsoft has evolved, and grown more responsible (Hell, I can run linux directly with windows - with kernels available on the Microsoft store) - but you need to follow the evidence.

Also, leadership: Satya Nadella != Steve Ballmer.

◧◩◪◨
4. chubot+ho[view] [source] 2020-04-14 17:53:42
>>ghshep+ji
> First, Microsoft was evil back then because they didn't just rely on excellent pricing and features (both of which they had) - but also because they leveraged their monopoly in one market (desktop operating systems) to prevent competition in adjacent markets (browsers).

Isn't that exactly what's happening here?

Gitlab competes with Github, but doesn't have the equivalent of Azure to subsidize it with.

Azure competes with AWS and GCP, but Amazon or Google don't really have a Github competitor. (Maybe Google has a small one (?), but I've never heard of anyone using outside their cloud product.)

Bringing Github and Azure closer together is an obvious move.

Github might not be a monopoly in the legal sense, but it's a solid #1 in the space, with strong network effects. On the other hand, Azure is far behind the near-monopoly AWS.

◧◩◪◨⬒
5. ghshep+1e1[view] [source] 2020-04-14 22:36:54
>>chubot+ho
The question of whether you are a monopoly is really important. Once effectively everybody is using your platform, there are restrictions on your behavior. Being the category leader is very different than being a monopoly.

And, note, that there is, and obviously wouldn't be, a law against a monopolist giving it's monopoly product away for free - That's kind of like anti-leveraging.

Look at this from a different perspective - free git hosting for teams is awesome. This is unquestionably a positive thing that Microsoft has done. It's good to be a bit cynical, but not to be so cynical that we put blinders on to the wonderful resources that are now being made gratis.

And, as long as they don't try and put some crappy "Microsoft only" extension onto their platform so that the vanilla git doesn't support all of it's capabilities - it hasn't taken that dark step into "extend." Once they do that, then it's worth a post to HN about Microsoft's Embrace-Extend-Extinguish dark past.

◧◩◪◨⬒⬓
6. quadra+Iq1[view] [source] 2020-04-15 00:33:33
>>ghshep+1e1
EEE strategy doesn't require starting out as a monopoly, it's just that it's easier if you're already a monopoly.

One could argue that EEE is a strategy to gain monopoly status. Microsoft does NOT have a monopoly in this space currently, but perhaps they want to get one (but only in practice, not quite legally recognized as one).

I see nothing wrong with bringing up EEE before it happens. Which scenario is more likely to discourage the tactic (A) nobody cares until the second E or (B) people are worried about any hint of it.

What is Microsoft doing right now to remove EEE from their options? For example, they could release the whole GitHub codebase under AGPL, and that would be quite a reassurance but not a guarantee.

"It is easier to avoid temptation than to resist it" — Dan Ariely

◧◩◪◨⬒⬓⬔
7. sneak+on2[view] [source] 2020-04-15 12:08:54
>>quadra+Iq1
GitHub’s danger is that it is centralized, not that it is closed source. For example, npm is already open source and Microsoft owning it is still a threat to the ecosystem via their ability to control the software and decide what goes in and what does not.

Microsoft could open source GitHub and it wouldn’t make one bit of difference to their strategy, as it would not pose any danger to GitHub’s defaultness.

Gitea implementing a federated mentions model, plus easy cross-instance linking and federated notifications, plus one-click $5/mo hosted instances on a bring-your-own-domain model would, however.

I am beginning to think we need something along the lines of go modules for the javascript world. Cryptographically assured via merkle hash root, fetchable from any url with a standard protocol, and a public caching proxy. Go got it right, rubygems/pypi/npm most assuredly did not. (To be fair, go modules were designed latest of all of the members of that list, giving them the benefit of hindsight.)

Maybe yarn can go this route ifwhen npm breaks fetch for non-first party tools.

I wonder what would be involved in forking npm (the hosted package repository, not the cli tool).

[go to top]