@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..

Love this:

> “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.”

@bthall @sir I do agree with her though, as someone who has more than once been discouraged by plaintext email interfaces despite having at one time read all my email in Emacs.

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 @rick_777 it would be interesting to see this deploying onto something like k8
@sir @rick_777 how about sprinkling in some aws services for that sweet cloud vendor lock in?
@sir Requiring a github account is a barrier to entry for contributing to many more open source projects.

@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?

@x @sir @neauoire board member of american medical association and definitely not owner of pharmaceutical conpany says FDA approval is a barrier to entry for medical contributions

@x @sir @neauoire learning to write with a pen on paper barrier to entry for writing prescriptions

@x @sir @neauoire learning maths barrier to entry for bridge engineering

@zensaiyuki @x @sir @neauoire

I remember when I first learned to program. I had to set up mutt and maildir before I was able to understand how to write for loops.

@cancel @zensaiyuki @x @neauoire aww that must have been SO HARD for you, is the writtle babby engineer gonna be okayz

@sir @cancel @zensaiyuki @x

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

@sir @cancel @zensaiyuki @x

and maybe they have, but it seems like the UX of the email workflow could be improved?

@sir @xj9 @cancel @zensaiyuki @x That even this purpose-built tool needs a five page tutorial kinda illustrates the problem.

@xj9 @cancel @zensaiyuki @x that program is part of upstream git and has been available for at least 15 years

@cancel @x @sir @neauoire it’s the linux kernel, the enigine of bilkions of servers, not hello world. if the email setup isn’t a deterrent, linus calling you a moron will be. (though i hear he’s promised not to do that anymore)

@x @sir @neauoire

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.

@cancel @x @neauoire and yet, it is all of those things: easy, straightforward, and a good use of your time.

@sir @x @neauoire

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)

@cancel @x @neauoire the "hoops" are literally two steps. One step the second time.

@sir @x @neauoire

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.

@sir They are trying to get others to use GH: dev.to/n3wt0n/comment/143f9
"It has just too many limitations and the overall experience is not as good as other tools."

I couldn't even reply back to the guy as I have no words.

@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

@sir @hxii Free software being developed on a non-free centralized platform is an awful situation, but I don't think it's fair to say that marketing and money are the only reasons people use GitHub. It had those, but it also solved a UX problem.

The mailing list UX *is* garbage, and just pushing your branch to your repo and submitting a PR to a dedicated conversation interface is better UX than subscribing to a mailing list and filtering out the 1% of the messages that are relevant to your patches, while the person doing the merges has no tooling to see what's been reviewed, what's been merged, what's been rejected etc. Structured interaction is a good thing, plain-text email was just the first iteration on the workflow.

The upside to your article is that you're admitting that the traditional tooling has issues and you're actually working on making the mailing list workflow better.
@sir @hxii mjg59 and ManishEarth aren't beginners, and they also aren't idiots. They've probably used git since its inception, at least one of them submitted patches to the project itself, they've been on mailing lists before, they can set up mutt if they have to. They're saying LKML is not a good place to submit patches.


On top of the first level, projects that require you to submit and discuss patches on a mailing list, there's the next level, the places that require you to submit patches inline, in a series of mails, rather than just attaching them.
I still haven't git around to trying #sourcehut issues and PRs. I'm sure they're good.

#pagure sounds good too, it keeps issues and PRs in git repos so you can take them with you, work with them offline, move them elsewhere, and it allows PRs in the form of "Here's the URL to my branch somewhere on the internet". It doesn't yet allow for bridging from a mailing list, but it sounds like they're working on it.
A web interface for CRUD is a genuinely attractive interface with low friction, and I quite enjoy it myself. We set up our Linux machines in the 90s and internalized all the pain and the interlocking issues and yak shaving, but for a lot of people who didn't, it's the only reasonable way.

I don't want to filter them out. I'm glad if people can focus on solving the problem at hand without having to learn 30 years of ancillary knowledge to just play around with things and improving things.

They web-based git forges all have genuine git interfaces too for the actual code, and the only real gripe I have with the whole thing is the web identity which is simultaneously too centralized and not centralized enough, as you end up registering on a hundred sites and yet 99% of people are going to github.

I smell an I-went-through-this-nonsense-so-you-should-too argument, and I don't think it holds. It's just hazing.

@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.

@IngaLovinde The fact that GitLab has existed for the better part of a decade, is open source, and for most of that time had a stronger feature set than GitHub, and yet most open source projects are on GitHub, indicates that there is indeed vendor lockin, and a strong network effect.

@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.

@IngaLovinde @sir Most people don't know the difference between git and GitHub. They'd call it GitHub 3 and people would just upgrade from git 2.

@clacke @sir "People" as in developers or as in project maintainers? Maintainers would migrate to GitLab, and developers will only have to register themselves a new account there.

@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.

@sir @IngaLovinde

> 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.

I don't imagine them taking leadership and leaving github in hopes of bringing their contributors with them, and I don't imagine other big projects like them doing it either. They're all on Discord too.

The ideologically-motivated fringe projects have already moved off or never entered.

> 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?

@IngaLovinde Free software but not as big as other free software doesn't mean proprietary.

@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?

@IngaLovinde Python was using Mercurial, which is not a niche project. It has git plugins and git has Mercurial plugins. It was about as big as git until it wasn't. E.g. Bitbucket supported only Mercurial back in 2008, but now they're all git.

Mercurial (hg) is written in Python.

@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?

Show more
Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!