Embrace, extend, and finally extinguish - Microsoft plays their hand
@sir found a typo, thought I'd report back
@awalvie thanks, pushing a fix
@sir well written. In Addition I think is is really maddening how many developers and their managers think that git and github are identical... or that Micro$oft acquiered git..
> “Relying on plain-text email is a ‘barrier to entry’ for kernel development, says Linux Foundation board member”, a title which conveniently chooses to refer to Sarah Novotny by her role as a Linux Foundation board member, rather than by her full title, “Sarah Novotny, Microsoft employee, transitive owner of GitHub, and patroness saint of conflicts of interests.”
I’ll look into what you are doing with sourcehut and if that makes it any better, but I’m not 100% ready to chalk this up as one of Microsoft’s crimes just yet.
Question. Is sourcehut just a website, or can we download and install it in our own servers for public or private use?
Looks a bit complicated for the layperson but I'm glad there are already Debian packages for it.
Let's hope it gets widespread adoption.
BTW, the page says it's distributed. Does that mean I can fork a repo from another sourcehut server into my own? Or what do you mean exactly when you say "distributed"?
@sir I really liked the bluntly phrased "open source is a means to an end for us" part in the article. The end being to sabotage all competition.
To me it's pretty obious MS still treats FOSS like the cancer they believe it is.
@sir This is well-written. I'm always impressed by your blog posts.
You seem to have strong opinions about stuff like this, but you put in the work and put your money where your mouth is. More power to you
@sir One would assume that a person competent enough to patch the kernel, will be able to configure their client for plain-text email, right?
rather than saying, "use one of 50 possibly maintained email clients that somebody has used successfully. plus also probably some other fun stuff that you may not have experience with, but you can figure that out." and feeling smug about having jumped through those (technically unnecessary) hoops yourself, you *could* say, "download this program that speaks both git and email and you're good to go."
somehow nobody thought of that since the 90s
I think it's fine to say that there should be arbitrary and artificial barriers to entry for things like contributing code to the Linux kernel, or whatever rules you have for your own project. It's yours, after all.
I don't think it's fine to tell people that setting up and using 'plain-text email' (as needed to participate in this particular thing) is actually easy or straightforward or a good use of every person's time if they weren't already required to be using it.
For me in particular, it wouldn't be a good use of my time. I don't have any use for that particular style of plain-text email patching workflow anymore, since I'm not involved with any projects that use it.
If I wanted to make a one-off patch to fix some small thing, but I was mandated to jump through the hoops to set up all of that stuff to submit it, I probably wouldn't. (1/2)
It's fine for other people's projects to use or mandate it, though. It's their projects! They can do whatever they want. But it is a barrier to entry. That may be a good or bad thing.
I've done this at least twice over the years. Setting up maildir or mbsync and mutt or alpine or the emacs thing and notmuch... the thing I end up with in the end is only good for that particular style of email, not support emails with customers or w/e
@sir Ha! It was only a matter of time, like the scorpion riding the frog across the river, it’s their nature.
Npm is next.
@hxii "There is a reason(few reasons, actually :) ) why GitHub has more than 50 million active developers using it, and why it became the de facto home of Open Source."
Yeah, marketing and money.
Note that they didn't bother explaining any of those reasons
@clacke @sir @hxii And also why can't both approaches coexist? It's not as if there was any vendor lock-in with Github; open-source GitLab with a similar workflow existed since 2013; and nobody is preventing a repo owner from ditching GitHub and going with an email approach.
And overall it reminds me of a Stallman rambling how he does not use a web browser. At least Stallman does not say we should all ditch web.
@clacke Network effect, yes (and not just as in "all my friends are on GitHub, I need to connect with them" but mostly as in "all my friends are on GitHub, why would I look for alternatives"; remember that GitHub is 5 years older than GitLab).
But for the most people GitHub is the same as GitLab feature-wise, and nothing prevents anybody from migrating to GitLab. Of course their metadata (pull request comments etc) won't be mirrored to GitLab, but it's the same with git+email.
@clacke And what's most important, lock-in is basically impossible in that context. If I used GitHub for my whole life, then it will be extremely hard for me to adapt to git+email reviews. But contributing to projects on GitLab almost won't require any adaptation beyond registering a new account there.
GitHub does not own a copyright on "extended" part, the "extension" is not proprietary, others can use it as well. Just like gmail does not "Embrace, Extend, Extinguish" email.
@clacke @sir Just a thought experiment of "Embrace, Extend, Extinguish".
What would happen if MS said in 2001 that they're replacing HTML with some entirely incompatible (but easy to migrate to) proprietary standard only supported by IE? Most of the web would probably migrate to that new standard.
What would happen if GitHub said today that they're replacing git with some entirely incompatible (but easy to migrate to) proprietary source control? Most active projects would probably leave GitHub.
@clacke @sir I don't see how it is a chicken and egg situation. There is a project, there is a community, right now they're on GitHub. The migration to GitLab is possible and quite easy but still adds some friction (while in case of vendor lock-in it would be impossible or would add a lot of friction). The project only stays on GitHub as long as the drawbacks of staying (which in the future might also include "they're getting rid of git and increasing friction") do not overweight the friction.
> But what Github does have over GitLab is familiarity. While there were people who publicly said they would prefer not to go with GitHub but would begrudgingly use it if we chose to go that route, I had multiple core devs email me privately saying they hoped I would choose GitHub.
[ . . . ]
> And while I said it wasn't a goal to make things easier for external contributors, I also can't ignore the fact that the vast majority of people out there who might want to help out are already familiar with GitHub.
> Python is a huge project with a foundation and infrastructure, and before this they were hosted on a DVCS written in their own language. They moved onto github in spite of feature parity and the proprietary factor.
You say "proprietary factor", but they moved from quazi-proprietary (presumably unique?) source control to open source well-known git?
@clacke Yes, which is why I said "quazi". Obscure free software shares some characteristics with proprietary software (not all characteristics, of course).
But now I'm not sure we're talking about the same thing. What do you mean by "hosted on a DVCS written in their own language"? I'm just not an expert in Python history. What is it exactly that we're comparing there?
@clacke Yes, I know about mercurial.
The way I see it: there are source control systems (hg, git, etc), and then there might be a collaboration frontend on top of that (github, gitlab, bitbucket etc).
So I'm not entirely sure how saying that some project migrated from hg to GitHub makes sense. It might make sense to say that it migrated from hg to git; and that they started to use GitHub collaborative features.
Or maybe it's just some misunderstanding?
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!