Open source needs to pull its head out of its collective ass and not hand over its entire workflow to private companies.
Github may be the single greatest execution of embrace/extend/extinguish in computing history.
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.
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.
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.
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.
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...
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.
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.
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!
In extinguish phase - Git won't prevent GitHub from rejecting a commit if it doesn't contain <TrackingMethodSignature>.
> 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
And their extending has nothing to do with open standards, which is worrying due to the potential to create 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).
Yes, of course.
Why, did you somehow think otherwise?
Just think of Microsoft like the Borg.
Why would they fuck with their number one audience, developers?
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.
Well, for starters, there is GitLab which attempts to do a lot of what GitHub does, while allowing you to self host it: https://gitlab.com/gitlab-org/gitlab
In some respects, i'd say that it does things better, for example, GitLab CI seems way easier to use in comparison to GitHub Actions: https://docs.gitlab.com/ee/ci/
As far as alternative source code management platforms go, with some code review and issue management functionality added on top, there is also Gogs, which is a far more lightweight solution and better fits smaller deployments: https://github.com/gogs/gogs
It was also forked by the Gitea project, which is largely compatible with it but is also in active development: https://github.com/go-gitea/gitea
Oh and there's also GitBucket which also attempts something similar to these: https://github.com/gitbucket/gitbucket
Now, you can probably hook those up with Jenkins or most other CI solutions, but personally i rather enjoyed how Gogs/Gitea integrated with Drone, which allowed for container based builds (no more plugin hell like in Jenkins): https://github.com/drone/drone
Then, you can throw in some additional tools, for example, for code analysis you could use SonarQube ( https://github.com/SonarSource ) and for security scanning of infrastructure you could look at OpenVAS ( https://github.com/greenbone ).
Oh, and on the organizational side something like Rocket.Chat ( https://github.com/RocketChat ) or Mattermost ( https://github.com/mattermost ) for communication and perhaps OpenProject ( https://github.com/opf/openproject ) for project management.
And there you have it! An open source based workflow that allows you to do most of the stuff that GitHub would let you! Of course, concessions might need to be made depending on what your definition of "open" is and whether you're okay with certain features being restricted to paid tiers in some software; if you do have a problem with that, there's also the possibility of looking at some libre alternatives, though that might lead to the occasional half-dead piece of software that doesn't really have financial incentives for maintenance anymore on anyone's part.
That said, i believe that few choose this approach, because it's somewhat complicated to run all of that and all of the sudden you become responsible for your own SLAs, which many don't want. It's often the same reason why people just provision VPSes from AWS, instead of running their own servers in a server room. I think the amount of links to GitHub for open source above speaks volumes about the state of the industry.
I don't think that there's an easy answer to the implications of this, maybe people should just familiarize themselves with the concept of "Service as a Software Substitute", so that they're at least aware of the trade-offs that their choices have: https://www.gnu.org/philosophy/who-does-that-server-really-s...
For example, GH Actions don't support YAML anchors but also have basically no other way of cutting down on repetition in your CI config files (actions can't call other actions, for example), so your CI config is full of brittle boilerplate.
Also noteworthy is how you can't rerun single actions. If your deployment failed, you might have to rerun the whole workflow, including the 10 min test run.
Meanwhile, if you use dependabot, PRs issued by that tool have no access to secrets, so if you need to connect to e.g. AWS to run tests, you need to implement weird workarounds.
I don't understand why GitHub is so popular, GitLab seems like such a better tool and it's also developed totally in the open. Some of the CI stuff is literally amazing (e.g. merge trains).
We know. We understand that it is technically correct. But it's completely useless in the discussion. You know perfectly well what the other person meant.
Oh ffs are you even aware that MS didn't originally build GitHub?
And your comment is super out of touch with what MS was doing in the 90s and early 00s. GitHub has plenty of competition, Gitlab for example is a fantastic platform, overall more powerful than GitHub as well. GH's strength is how much better it is for open source projects and if MS messes with that they'll be killing their golden goose.
There is no all-powerful benevolent deity you can hand your code to and say "here, take care of this for me, for free, for all eternity". At some point private companies will have to get involved (or would you rather have your government get involved instead? Because I don't want your government hosting my code). So you want their incentives to be nicely aligned.
Purchasing a popular product is definitely qualifies for the "embrace" part of the strategy.
But that's not unique to MS - AWS and Google follow similar playbooks, as does almost any large company that provide a platform-like product. The goal is to make the platform as sticky as possible for as many customers as possible.