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

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

@sir
Question. Is sourcehut just a website, or can we download and install it in our own servers for public or private use?

@sir
Noice.

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?

@sirjofri @x @sir Even better: imagine complaining about "learning to use plain-text email" after patching *OpenBSD*.

@am @sirjofri @x @sir
I haven't looked at OpenBSD source code, but I'd expect it to be more readable than Linux.
Whether your patch is going to meet their high standards is a different qeustion.

@sirjofri @x @sir my stance on this is similar to Taleb's (below): forcing cultural and procedural shifts in the name of abstract accessibility makes that way of living the only way of living, and wow, it plays into corporate playbooks too?

sometimes you have to learn the way it works to be a member, and everyone is better for it.

medium.com/incerto/the-most-in

@am thanks for sharing, I'm not done reading but so far it's excellent, I was hoping it would talk about linguistics and it does!

@am @sirjofri @x @sir An effect I usually call "When there is only one anglophone at a gathering of 30 bilinguals - everyone speaks English."

@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

"take notes"

are you sure you want them to do that? it's not like they do this by accident.

@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 I don't like GitHub. Didn't like it before the Microsoft acquisition.

I can't trust it. The "de facto home of Open Source" which is closed source itself.

Developers also choose GitHub for the visibility it gives to their projects, for the "everybody is there", "it's easier to get people involved", etc.

It's the path of least resistance.

People just don't give a f*ck.

I hate it.

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

nitter.net/ManishEarth/status/…
nitter.net/mjg59/status/129947…
nitter.net/mjg59/status/129947…

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.
Sign in to participate in the conversation
Mastodon

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