I think that is the thesis of the linked story. I did not write the linked story nor am I in complete agreement with the author. But I think that the thesis is that there is the github way and then there is the git cli way. To use the author's analogy to gmail, what actions do you drop to the shell to complete instead of using gmail's interface.
> But I think the thesis is there is the github way and then there is the goit cli way.
Which is, again, a false dichotomy. Github is a remote repo. In git you always also have your own local repo, and things like 'git am' and 'git send-email' (and 'git rebase --interactive', and 'git bisect', and any other non-trivial use of git) are operations that you would always want to be performing locally before pushing it out to a remote repository.
That there's no interface to perform these things on Github doesn't mean that Github is trying to engage in vendor lock-in, it's just a reflection of the reality of the fact that you should be doing that stuff to your local private repo, with your local client.
If that is the thesis, then his example of gmail is strange. After all, he uses fetchmail, alpine, mutt and Thunderbird to use the service. I strongly doubt that gmail has every single feature of mutt in their web UI!
I think the difference is that gmail wasn't the first simplification (web-based or otherwise) of email.
Remember when people used to sign (and/or encrypt) their emails with PGP/GPG? I'm not aware of a way to do that in gmail in any realistic sense.
I do remember, however, many early webmail clients barely supporting even small attachments. Some didn't support multipart.
Eventually, as webmail providers improved, the userbase decided the trade-off of losing the low-level access for the usability advances was worthwhile. I think email is an apt analogy.
GitHub is the first highly-successful incarnation of its kind. There are already credible competitors (albeit with much smaller user counts), and there will be more. GH has made a business decision on what features they spend time on. Other competitors will arrive at different decisions.
Developers, along with popular open source projects, will go to the providers that support their needs.