zlacker

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.

>>ghshep+(OP)
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

>>quadra+Hc
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).

>>sneak+n91
Centralization is indeed a danger, but so is being proprietary. It would show some good will or otherwise willingness to avoid temptation if Microsoft freed the GitHub codebase even while staying centralized.

Freeing the code is a check-and-balance issue. It doesn't remove their core power, but it provides more of an escape hatch if they abuse the power. Sure, people could go to GitLab, but (A) if GitHub gets strong enough, they could hurt GitLab's business and progress and (B) it's a much more trivial move for a project to switch from Microsoft GitHub to an alternate GitHub host.

In other words, the easier it is for people to leave, the more incentive Microsoft has not to abuse people too much.

If we were going to go for the most ethical and trustworthy directions, it would probably be stuff like Fossil or SourceHut.