Hacker News Reader

Comment by maccard | Hacker News Reader

Where are we seeing the extend or extinguish with GitHub? It's been 3.5 years and GitHub is just as compatible with git as it has ever been.

View on HN

Microsoft plays a very long game. 3-4 years is not enough time to boil a frog; it takes much longer or the frog will realize what's happening. Be patient. Give them 10-15 years after their "We love Linux" shift and you'll see. They love it so much, they will own it.

Just think of Microsoft like the Borg.

Microsoft is a trillion dollar company in large part because they embraced open source. Azure is extraordinarily profitable.

Why would they fuck with their number one audience, developers?

According to this site, Microsoft's profit is divided into thirds:

https://www.investopedia.com/how-microsoft-makes-money-47988...

A third is for Office, a third for cloud, and a third is Windows.

IMO Microsoft is a trillion-dollar company because of their long monopoly with Windows. It's so entrenched that their "punishment" for abusing their monopoly position (according to the DOJ) was to give all schools free copies of Microsoft Office, thereby forcing every parent to own a copy of Microsoft office to be able to read reports from their kids' schools. Ingenious!

You know why they would fuck with developers? Because developers have choices now, and Microsoft doesn't like it when anyone has a choice besides Microsoft. They are remedying that.

You know how they added Github CLI[0], right? There may be a time where you must use Github CLI instead of a "standard" git client to interact with Github projects. That would be the "extinguish" phase. Right now they have embraced and are extending (such as with Github CLI).

[0] https://cli.github.com/

If you wish to leverage the advanced features of github, the CLI gives you direct access rather than rolling your own api client. git will always be a first class citizen at GIThub.. but how do you open, close, or comment on PRs with a standard git client?

Edit: The last part came across a bit snarky, but I’m trying to stimulate the thought process. Such as leveraging GitHub Actions to automate all aspects of PRs via gitops instead of using the GitHub client. Many ways to avoid dependence of the CLI!

As another commenter pointed out, we're at extend part of embrace, extend, extinguish. This part is just making Github tools work easier than non Github.

In extinguish phase - Git won't prevent GitHub from rejecting a commit if it doesn't contain <TrackingMethodSignature>.

That sounds very much like the "extend" part of the process.

It feels like an open source standard on top of git that defines how to do this stuff would be helpful to reduce lockin. I wonder if Fossil or Gitlab have something.

I made this comment elsewhere [0], but by this logic anyone who builds an ecosystem for an open source tool should be accused of the EEE strategy.

> There may be a time where you must use Github CLI instead of a "standard" git client to interact with Github projects

So we're accusing MS of a slippery slope based on a phrase from 25 years ago, which there is absolutely zero proof or indication of them pursuing in the last decade (at least).

When GitHub show the _slightest_ inclination to do anything of the sort, I will be standing there with you, screaming blue murder. As of right now, they're progressing the development of git, "embracing" the open standards that have been developed (lfs being exemplary) and have shown absolutely zero signs of extending git in incompatible ways. See elasticsearch [1] for what "extend" _actually_ looks like.

> Right now they have embraced and are extending (such as with Github CLI).

If they _hadn't_ embraced, people would be complaining that GH are forcing non-open standards to be used. I firmly disagree that the GH issue tracker and pull request management are an "extension" of git. They have nothing to do with git whatsoever.

[0] https://news.ycombinator.com/item?id=28149098 [1] https://news.ycombinator.com/item?id=28110610

> I made this comment elsewhere [0], but by this logic anyone who builds an ecosystem for an open source tool should be accused of the EEE strategy.

Yes, of course.

Why, did you somehow think otherwise?

In practice, it doesn't matter what an "actual" extension looks like, but how your product is viewed by customers, because those are the ones you want to lock in. And judging by HN comments, to very many people, Git means Github, making it an extension, if not outright a synonym.

And their extending has nothing to do with open standards, which is worrying due to the potential to create lock-in.

By that logic, anyone who builds a product around an open standard is guilty of EEE. A web browser that implements a sync feature, an XML editor that implements syntax highlighting , an RSS reader that implements link previews all "embrace" open source standards and "extend" their core open standards with non-standard features, which is _exactly_ what github have done. They have been excellent players in the git ecosystem.

I think this conundrum can be broken up by noticing how pervasive one extension is. A feature that has become identical with the core product in the eyes of a layman is problematic in the same way as thinking "IE6" is the same as "the web". If there's no awreness of choice, then the only outcome is further lock-in.

Implementing "sync" on its own doesn't matter that much, because few people think "sync" is a defining feature of the web standards, or that preview is an inherent part of web feeds. The awareness of alternatives still exists (I hope).

That's the trick, the git is open, but the metadata is what matters. Issues, PRs, integrations into various code auditing services. That's the whole "extend" bit.

By that logic any proprietary product that provides an interface with an open source tool is guilty. I think accusing MS of EEE in this case is a huge stretch; GitHub is a commercial product that uses a popular open source tool with 100% compatibility (that I'm aware of) and actively participates in the development and features of that tool. When Ms start implementing extensions to git that only work with GitHub, we can point fingers but accusing them of extending git to extinguish based on pull requests is baseless

> By that logic any proprietary product that provides an interface with an open source tool is guilty.

In my view, the entire PaaS ecosystem modus operandi is building on top of open hardware & software, allowing and enticing people to move in easily (familiar tech/open source), and making locked-in products out of them. If that's not EEE I don't know what is.

I can’t think of a single person I’ve worked with in the last 10 years who understands the difference between vanilla git and GitHub. Nobody really understands why pull requests are named that way, or that it’s possible to have very different workflows to what GitHub offers.

I don’t know that this is the result of a deliberate strategy by GitHub, but by any metric the extend step is a resounding success.

> I can’t think of a single person I’ve worked with in the last 10 years who understands the difference between vanilla git and GitHub.

If not one developer in a decade can tell the difference between a source control hosting service and a tool they use, that's not really GitHub's problem. This is the same as my parents not konwing that "facebook" isn't the internet.

> Nobody really understands why pull requests are named that way,

Sure they do, the answer is one google search away on the largest Q&A forum for programmers [0]. it was the first google hit for "why are pull requests called pull requests"

> or that it’s possible to have very different workflows to what GitHub offers.

Maybe inside your circle, but plenty of people are aware of different workflows. Some of the largest open source projects in the world exist on github and don't use the pull request workflow (linux kernel, firefox, chromium off the top of my head).

[0] https://stackoverflow.com/questions/14817051/why-does-github...

> If not one developer in a decade can tell the difference between a source control hosting service and a tool they use, that's not really GitHub's problem. This is the same as my parents not konwing that "facebook" isn't the internet.

Nobody said it was GitHub's problem just like nobody said it's Facebook's problem in your example. They're both laughing their heads off all the way to the bank. It's everybody else's problem.

GitHub isn't the only one using pull requests, Stash and Gitlab does too. Pull requests have just become standard workflow without it ever being part of git.

FWIW, Gitlab calls them merge requests instead of pull requests, which IMO is a more descriptive name.

there's never a stretch with Microsoft. It is always, and has always been the same play. You can make excuses all you like, but in the end they will attemtp to embrace, extend and extinguish all competition.

Wheh they show any signs of extending git, or extinguishing any other open source competitors, I will be standing there with you calling them out. Until then, they're developing an excellent product that people want to use, built with open tooling

Those who don't study history are doomed to repeat it.

I'm arguing against soundbytes here, which is really unfortunate and something I hoped would be above HN. It's very easy to shut down an argument with a soundbyte or a famous quote when you don't have any actual proof that history is repeating itself. The situation and landscape is _very_ different from the mid 90s, Microsoft are showing _no_ indication of being bad actors whatsoever, (in fact they're showing the exact opposite) and haven't done for at least a decade.

We're down to soundbites because all of the arguments already happened and we're down to agree to disagree. You are basically asking for proof of a future event already occuring when the best we can do is look at the historic behavior of not just MS but similar companies. Your entire stance is to ignore any historical trends or behavior and only agree once the damage is already done. There's no constructive argument to be had there.

Effectively you're saying that all decision making should be based on current observable reality only and any projections about the future should be ignored because they are not 100% provable. I guess that's a way to function, and based on how bad people often get the future wrong it might even be a productive one, but it does explain why we're down to soundbites, because we've reached a fundamental disagreement not on opensource or Github, but a disagreement on how to plan for the future.

If you're going to tell me to look at the history, then I should tell you to do the same. The history says the did it, 25 years ago, and haven't been doing it for almost 20. The history says they are being good citizens in all their open source contributions in the last decade. It says they're actively working to further the open standards they're building on. At a certain point, a specific incident becomes an outlier, which is a point I believe we have passed.

That is somewhat fair - there aren't great alternatives to migrate issues and the like to today. But all of those bits of metadata are easy to pull out of the service via API hooks. If someone wanted to start a serious competitor to github that shares the same basic data model it'd be pretty trivial to write up migration aides.

I don't disbelieve that it's possible for microsoft to severely restrict these - but entirely removing them is off the table unless they cut out a lot of value. Inter-service communication to third party review tools and CI/CD tools all depend strongly on those API hooks.

> If someone wanted to start a serious competitor to github that shares the same basic data model it'd be pretty trivial to write up migration aides.

Like Gitlab? I assumed Gitlab would dominate after the MS purchase of Github, but I was incorrect that people wouldn't want to trust their data and personal projects to the epic abusers of privacy that is Microsoft.

Well I don't think the personal projects are really a significant factor in terms of where MS's paychecks are coming from - they care more about the commercial subscribers. And, speaking as someone employed at a commercial subscriber, objecting to continuing to use github due to the microsoft acquisition when we use office for pretty much all document production is going to be a pretty hard argument.

There are really simple ways to play dirty with APIs like making sure that they are incomplete in subtle and inconvenient ways like leaving out some of the metadata. Hypothetical example: make it impossible to query tags on issues. You'd still be able to do most things through the API, but if you have a workflow that's heavily dependent on tags, the data is effectively siloed.

So to be clear, the proof the GitHub is extending is a hypothetical example of an incomplete api that is not based on an open standard?

I didn't want to prove anything. I just pointed out what is possible.

Sorry, I misread the username and assumed you were the commentor I replied to. Yes, these things are _possible_ but there is no evidence or indication that they are happening with Github.

I agree that there are no signs at the moment. Companies change over time, so a certain risk - however small - is present, as with all 3rd party services.

Are there any foss initiatives to making these metadata bits portable?

https://fossil-scm.org/

What is going to be extinguished?

Reply on news.ycombinator.com