Embrace, extend, and finally extinguish – Microsoft plays their hand

drewdevault.com

139 pointsMartijnBraam140 comments

This feels like an advertisement wrapped in a bad take. Speaking as someone who has a couple commits in the Linux kernel, yes the email thing is a pain to get started. Configuring your client to do the text thing, keeping up with conversations, learning who's who, you definitely can't jump straight in. The only way I was able to stay sane is setting up a bunch of filters to tag conversations and people. And that's not even mentioning the different patch submission guidelines, perl scripts I have to run, and other random things to make the patch even just readable by the community.

Configuring all this stuff is definitely a barrier to entry. Now what tooling looks like to make it easier, that's an entire different conversation. Email has worked for the Linux dev community for decades and that should be protected and not disrupted. However, anyone who says there's no room to improve the onboarding experience, well, I just can't take their opinion seriously.

>However, anyone who says there's no room to improve the onboarding experience, well, I just can't take their opinion seriously.

From TFA:

> I agree that the UX of email-driven development could be better!

This is followed by six examples of such improvements, the first of which is explicitly targeted at improving onboarding:

https://git-send-email.io

All of that vs git pull/push.. best of luck to your thing but that sounds absolutely horrible

This isn't a great take. I recorded a demonstration which shows the differences between the workflows more clearly:

https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-...

After the initial setup, send-email is way faster.

I work at a web agency. Initial setup is frequent

I don't understand how those follow. Note that your "initial setup" follows you from project to project and even machine to machine if you sync your config files.

Ok that's fair and I overlooked a lot of it being a global config setup.

It still stands though that you can cut out an entire page and a half of your instructions with "step 4: git push origin main" for each repo

This isn't even taking into account getting other devs working with it, contractors we're working with, outside agencies that may be involved in this one

How do you even get the patch into the repo from an email? I couldn't see that instruction but may have overlooked that too

Watch the video I linked to, please.

You can't just `git push origin main` - you have to do that, then go to the web browser, create a fork, and open a pull request. And that's only if you already have a GitHub account. If you don't, add answering the registraiton email and adding your SSH key to those steps.

In your situation, having a single shared git repo might make sense, sure. But we're not talking about that, we're talking about code review strategies.

> You can't just `git push origin main` - you have to do that, then go to the web browser, create a fork, and open a pull request.

Not if you're using GitHub, because they have APIs for that:

    hub fork --remote-name origin
    git push origin feature
    hub ci-status --verbose
    hub pull-request

https://hub.github.com/

Install and learn how to use more third-party software to use a propreitary API on a centralized, proprietary, unreliable service... or just use the built-in git tooling?

Where is the builtin git tooling for showing side by side diff with proper syntax and different parts highlighting, and make it possible to turn my review comments back to the "bottom-posting" style text emails interleaved with the inline diff everyone on the mailing list strongly insisting? I'm sorry but I'm a stupid noob and my eye is not able to parse codes without syntax highlighting.

It's called your email client.

When I git push main it's instantly available and deployed to the live server(s) - but you're right I wouldn't push direct to main, I'd click the link that the push process output (Self hosted GitLab for context) and create a merge request

I've got a feeling I'll never properly see your point of view on this, as these tools exist and I'm not planning on dropping them for an unfriendly email version of the same, but I will give the video a proper as open minded as I can watch after work

I reckon you've never tried the email based tools. Ditch the assumption that they're unfriendly until you're knowledgable about it.

I felt your video was dishonest right from the start. If your password manager doesn’t easily meet those password requirements with default settings you need a new one.

Also who is registering a new account each time? I’m sure you recognise this argument :)

“I’ve got greylisting enabled on my server” which would affect your git email flow, but you don’t mention that. [edit: oooh, what about spam filtering? How many requests are lost to that?]

The slow back button presses as if it takes that long lmao. You’re proper at it.

Shocker you’re typing nice and smoothly in the email flow. Didn’t see that coming.

No mention of getting changes into the repo after receiving the email patch. Where’s your merge request equivalent? That step must be so easy and so much faster than using a web interface you just forgot to record it.

Context switching is moving a mouse to the other screen.. come on, just be real with me! I’m trying to learn your thing - just stick to it. Focus..

I’m sorry but this video contains too much bullshit and not enough info. I want to learn, not accept FUD. Hit me up with a clean version if you make one. May I suggest a side by side video edit?

At best they seem evenly matched. In which case I choose the path of inaction

You’ve gone from interesting tech person to PR spinner in my mind. Quite disappointing.

> And that's only if you already have a GitHub account.

Come on, I get that you hate being locked in a proprietary service which requires an "account", but if you want to make this point then I'm sure people could say "And that's only if you already have an email" and your tutorial should include setting up your own mail server.

Come on, I know that you hate the idea of facing your cognative dissonance, but there are different things.

When was the last time you met someone who didn't have an email account? And you can set up an email address on any of dozens of email providers, and use them to communicate with any of the rest. I can't sign up on GitLab and use that account to post on GitHub.

My man, those tools are great and I really respect the contribution of those tools to the community. But here's the kernel guidelines, which I am sure you are already familiar with: https://www.kernel.org/doc/html/latest/process/submitting-pa...

Even with the tooling you provided, it's still a crappy experience (maybe a little less with the Sourcehut stuff). I know it's easy to read into the comments and be like "well this person just wants to shove the kernel into Microsoft's product," but it doesn't have to be this way. The sad thing is, for better or for worse, Github can handle almost all of those steps in the patch submission process, save for the ones where you have to actually describe what's changing. that's like, 15 steps that a newcomer does not have to even deal with.

I think we all agree on "No Linux Kernel controlled by Microsoft platforms, please" but Sarah's comments that "this workflow sucks", and then your actions on "this workflow sucks" - y'all are saying the same thing.

These "15 steps" are 90% unrelated to the email workflow, and would not be solved by GitHub. Did you read this document? It's telling you how to be a good contributor and the mechanics of how to contribute. That being said, this documentation is sorely in need of a git-oriented overhaul, assuming the programmer isn't using git is not doing any favors for the 99% who are.

80% of my interaction with github is via email. I and am sure most people once they get used to email workflows will find email lot more effective than the UI. It is true you can only comment via github officially today and not create a pull request itself.

It is trivial to use their read the email and use their API to create one. There are projects doing the other way [1] generating a email pull request.

If there were "open standards" for pull requests/ Merge requests then git should have implemented it as part of the protocol the transportation medium is explicitly left out of the protocol for a good reason.

[1] https://github.com/google/pull-request-mailer

If you only use emails for github issues and PRs, you’re missing edits made to comments after their publication.

Using plain-text email for sending patches is fundamentally broken because it's just not a reliable transmission medium. SMTP is very old and very moldy and it's not something that you want to force your contributors should deal with.

The first step is to always push you candidate commits to another inside a public git repo first. Unlike email the protocols underneath git push (ssh or https) are easy to use and operate reliably in all circumstances.

> Email has worked for the Linux dev community for decades and that should be protected and not disrupted.

No, it's wrong to protect workflows simply because they "old". There are many web-based code review solution out there and most of them are preferable to email.

OLD == BAD

No, wrong. SMTP works fine and has done so for a long time, and it's incredibly easy to set up. It's the least of your problems when the rest of your task is patching the freaking Linux kernel.

And as far as reliabilty is concerned, SMTP is one of the most reliable protocols on the internet. Compare with this:

https://www.githubstatus.com/

SMTP is terrible, especially for people with corporate accounts behind firewalls. I've contributed to linux in the past and dealing with corporate IT was a miserable experience and saw lots of other kernel developers waste their time fiddling with SMTP parameters.

Those same firewalls can pass https or git+ssh just fine, it "just works". SMTP is not worth dealing with.

Email is also not very good as a forum, for example you can't edit your posts for spelling fixes, archives are unreliable and hard to browse and it's difficult to map git commits to reviews.

It's also wrong to claim that linux code review is somehow "distributed", it is very much centralized on a couple of mailing lists servers on vger.org.

It would be much better if kernel maintainers kept their trees on github and started accepting PRs.

It's not problem of SMTP or email in general that Outlook is trash. I get it, ages ago you bought into Microsoft's ecosystem, but can't you acknowledge it's flaws? If the server you're using doesn't let you send emails the way you want to, it's the problem of the server, not the email ecosystem in general.

Problems with corporate SMTP are widespread and configuring your own gets you easily marked as spam. The email ecosystem is very old and not very good and it's better to avoid relying on it entirely.

Fuck plain-text email.

OLD == BAD

SMTP is not just OLD, it is genuinely BAD

So far your only justification for this has been that your employer has a shitty firewall.

Your corporate firewall being run by morons has nothing to do with what's a good or bad protocol. A lot of people have the SSH port blocked, and git:// too. By your argument we shouldn't be doing literally anything on any port other than 443.

>Email is also not very good as a forum, for example you can't edit your posts for spelling fixes

So what? You learn to get it right. There are other advantages to emails that forums don't have, like...

>archives are unreliable

This utter bollocks. Archives are plenty reliable and everyone on the list has their own copy of everything. Many mailing lists are mirrored mulitple times. You simply cannot do this on GitHub.

>it's difficult to map git commits to reviews

Fair that this could be improved, but it's not exactly difficult. You can just search your mail archives for the subject line, or even just google it. Still, it could be improved.

>It's also wrong to claim that linux code review is somehow "distributed", it is very much centralized on a couple of mailing lists servers on vger.org.

Hundreds of mailing lists, not all of which are on vger.org, and some of the development doesn't take place on mailing lists at all. Some of it takes place on GitHub!

Don't particularly agree with the tone of this "advertorial" but I agree that the issue of the ecosystem becoming excessively github-centric is real.

I wish Github, Gitlab, sourcehut and (why not) Atlassian, would sit down and hash out a bunch of formats and protocols that make it easy to collaborate across and off them. A galaxy of tools, with everyone using their favorite one, would be a fabulous step forward for developers everywhere.

I know it's not going to happen anytime soon, but one can dream.

It's already trivial to move code between git service providers, or even run your own.

Code review and issue trackers are harder because they're effectively forums are only useful when centralized.

They’re also fiendishly hard to design right.

>Code review and issue trackers are harder because they're effectively forums are only useful when centralized.

What? This claim requires evidence.

GitLab has been at least tracking federated instances as a wishlist item since 2018, and it was marked for a time as "Vision FY20": https://gitlab.com/gitlab-org/gitlab/-/issues/6468

I doubt that GitHub would have much incentive to come to the table on any of this, but if GitLab can at least figure it out between instances of itself, it seems likely that sr.ht and BitBucket would be motivated to implement whatever the system is, and eventually social pressure would force GitHub to cooperate with it as well.

Yeah I think there's a strange focus on vindicating plain-text email in that article instead of criticizing GitHub for being a closed ecosystem. Plain-text email is kind of a huge pain in the ass to use, and the PR web GUI system is nice. The focus should be on interoperable PRs, not resurrecting plain-text email.

I started trying out the plaintext email workflow recently. One thing is very clear - all that pain is only because of bad tools and nothing to do with workflow itself. Regular email clients (incl webclients) garble the workflow horribly - HTML by default, top posting with no easy way to correct it, and attachment handling that assumes the user to be an idiot. I use neomutt. It's hard to learn and it's not the best an email client can be. But it makes git-email workflow and mailing list handling much more pleasant.

There is more that can be done. Better GUI and web clients for plain text email can help. Clients can display issue threads better. Patch mails can be combined. There can be an interface to import the patches easily. There can be optional markdown/ReST/asciidoc rendering. Similar improvements can be made with mailing lists too. With good tools, email workflow can be more pleasant and more intuitive than Fork-PR.

The gist of the article is that protocol you want already exists and is integrated into git- email. Everything that people complain about that workflow (barrier to entry, initial setup and difficulty to track) is merely because the tools are primitive and unpolished. We wouldn't be considering the Fork-PR workflow if even a fraction of effort that was spent on improving the email workflow tools. There is no reason why email workflow can't be easier than Fork-PR. Consider this - sourcehut is only a pretty interface to discover projects. You don't need to create an account to contribute to the project. You can collaborate even if everything other than the mailing list is down (even that can be overcome). How can Github/lab surpass that even if they bolt on a federation protocol on top of their PR-Fork model?

> merely because the tools are primitive and unpolished

Sorry, but I believe this is the evidence that it's the abstractions behind these tools being primitive and these tools can't be polished, putting more efforts on an impossible task does not help.

OT but I guess after Black Lives Matter we should have Noob Lives Matter.

SMTP is just a protocol to exchange information. It's no more primitive than the mechanisms that power fork-PR workflow. What makes it impossible for a client to display issue threads and patches like Github does? What makes it impossible to import patches directly from client into a git repository? What makes it impossible to design a simple utility to 'push' a git branch as a set of patches? If the evidence for that is the current state of affairs, I consider it simply as a result of no one having an incentive to invest in a non-centralized workflow - that's not a proof of it being unviable. Making it noob-friendly takes work that nobody has yet put in.

There is a plan for that called ForgeFed, not sure if GitHub is involved in that or not though.

https://forgefed.peers.community/ https://news.ycombinator.com/item?id=23572576

This is a bit tangential, but I wanted to mention how the (GPL'ed) ardour project decided to view github.

We got burned by the SourceForge apocalypse back in the mid-2000's, which led to me (the BDFL) declaring that the project would never use a 3rd party host for our source code repository ever again. Granting a 3rd party the level of control that SF had (and then abused) is a non-starter for us. This means that github was never an option for us.

.... as the canonical repository.

However, we recognized the value of the tools that github offered, particularly allowing random 3rd party developers to create patches in quite effective ways. Some of the their other tools are useful, too.

So, we self-host a gitlab instance at ardour.org, and that acts as our canonical repository, but we use hooks to push all commits to the github version automatically. Random 3rd parties can use any and all of the github toolset with our code (as can we), but we have no reliance on github in any important way. We don't even have much reliance on gitlab either - it exists only to provide access roles and account management on top of the bare git server. We don't use any of gitlab's "features" either.

After about 5 years, this continues to work well for us.

>They embraced git, and then rather than building an interface on top of email — the collaboration mechanism that git was designed to use, and which is still used for Linux kernel development — they built their “pull requests” mechanism.

How is git designed to use email?

>Sarah Novotny, Microsoft employee, transitive owner of GitHub, and patroness saint of conflicts of interests

Followed by:

>I represent sourcehut, a GitHub competitor which does what GitHub wouldn’t — interoperate with open, distributed protocols, and in the form of 100% free and open-source software

Yeah no conflict of interest there /s

Love the pricing page. It literally doesn’t list features to distinguish the variations by...

Isn't the whole point that there aren't any differences? All users get the same features. You choose how much you pay.

If you read the big, ~read~ red and nearly glowing banner above it you'd see that:

> Notice: sr.ht is currently in alpha, and the quality of the service may reflect that. As such, payment is currently optional, and only encouraged for users who want to support the ongoing development of the site.

There are no features to distinguish the variations by - they're all donations, effectively.

Though i admit they could improve that UX further still. But, imo - the entire product is not super polished for "mainstream users" (of which i mean nothing against), so polish in this specific area might be cart-before-horse.

Literally the first lines of text on the page:

> sr.ht is the hosted instance of sourcehut and provides paid services to its users. On sr.ht, all plans have access to the same features, at the same level. You should pick the plan which best matches your financial needs and best represents the level of investment you have in sourcehut.

From: https://sourcehut.org/pricing/

>How is git designed to use email?

git was designed for use with the Linux kernel, which has collaborated over email since its inception. It includes many features for email-based collaboration out-of-the-box with no need for a centralized hosting service of any kind.

https://www.git-scm.com/docs/git-send-email

https://www.git-scm.com/docs/git-request-pull

https://git-scm.com/docs/git-am

https://git-scm.com/docs/git-imap-send

Both Linux and git itself are developed via email, along with dozens of other projects, *BSD, gcc & clang, coreutils, busybox, ffmpeg, qemu, PostgreSQL, vim, emacs, most Linux distros...

Those projects have found git's email collaboration model to be a great bozo filter.

All those don't sound like git was designed to be used with email.

>It includes many features for email-based collaboration out-of-the-box with no need for a centralized hosting service of any kind.

What many features?

I listed these features. Email is in the name of one of them, IMAP (an email protocol) is in the name of another, one is short for "apply (e)mailbox", and the fourth one generates an email.

If you're not going to argue in good faith then don't leave a comment in the first place.

All those don't sound like git was designed to be used with email, those projects using email to collaborate sounds like a coincidence and orthogonal to me.

>It includes many features for email-based collaboration out-of-the-box with no need for a centralized hosting service of any kind.

What many features?

(you replied twice)

I listed these features. Email is in the name of one of them, IMAP (an email protocol) is in the name of another, one is short for "apply (e)mailbox", and the fourth one generates an email.

If you're not going to argue in good faith then don't leave a comment in the first place.

That's a weird argument. Linus wrote git to be his tool for developing the Linux kernel. Every single thing about the Linux kernel workflow is what git was designed to be used with.

The fact that you refer to those internal commands that are part of every Git installation as "projects" shows that you're likely unfamiliar with Git CLI.

Because git is so large, every individual command is documented in a separate manual page, with `git diff` being documented in the `git-diff` manual page, and so forth.

All the mentioned commands are probably present on your Mac in Apple's distribution of Git, for example. Even though Apple probably doesn't use any of those commands for internal development (because big corp, and not invented here).

> How is git designed to use email?

https://git-scm.com/docs/git-send-email

https://git-scm.com/docs/git-format-patch

Still for those unfamiliar -- these are standard utilities that are part of every git installation.

There's also `git am` (as in "apply mail"), also standard part of git.

https://git-scm.com/docs/git-am

The whole workflow of git is based around email: the commit message requires a Subject line, then a blank line, followed by the description of what the patch attempts to solve.

The reason patches are required to be sent as plain-text for Linux and OpenBSD is that you can save the whole email, and pass the contents of the whole email to git (in case of Linux) or the patch(1) command (in case of OpenBSD -- the patch command will automatically ignores all the headers and non-patch part of the body of the email). This guarantees you won't end up with undocumented random patches on your filesystem -- each patch has the accompanying documentation as part of the same file, metadata on authorship etc. But if you use weird encodings, then the workflow breaks down.

> How is git designed to use email?

https://www.git-scm.com/book/en/v2/Appendix-C%3A-Git-Command...

>Yeah no conflict of interest there /s

It is amazing to me that anyone could seriously look at (1) a virtually unknown company celebrating FOSS principles and (2) a trillion dollar company working to undermine those same principles and be so foolish as to conclude that those are comparable examples of conflict of interest.

Pull-requests and forks are only a piece here.

It's not the only one implemented by tools that extend Git (Phabricator and Gerrit, for instance, support pre-commit workflow).

Github also brings a bug tracker (albeit a simple one), discoverability, hosting (obviously) and integration with many useful tools (CI, documentation generators, etc). All of this is easy to use.

These pieces greatly contribute to the success of many open-source projects (of various sizes). Github "extinguishes" alternative because of this, not because it designed an alternative to email-based workflows.

I suppose that many projects (open-source or not) want to use tools that extends Git. Maybe what we need is a standard making these tools interoperable and open.

Yeah, I agree. There are open-source Github clones like Gitlab and Gitea that still follow Github's web UI model, so I think it's weird to pose this as a conflict between Github and plain-text email when it's two separate conflicts: one between proprietary Github software and other open-source hosted git systems, and the other between the plain-text email model and the more popular web UI model.

I responded to this argument in another comment: https://news.ycombinator.com/item?id=24295610

TLDR: the alternatives are also centralized and give you vendor lock-in since issues/PRs are tied to the instance.

What has always suprised me about open source software is that the source is always 'out of band'. I can imagine a future where all open source software you use has an 'edit source' function (as opposed to a mere view-source function we have on the web currently).

Even more useful would be the ability to make a change within a certain context, similar to how 'inspect element' works in the browser.

A change in the source would result in a patch which can then stay 'personal' or be automatically shared with others looking for similar functionality, or getting noticed by the maintainers who might incorporate it in the main releases after a refactoring.

Of course I realise that this workflow is not technically possible in the way software is currently built, but it does seem worthwhile in the future.

There used to be an assembler called RosAsm in the early 00s, whose author insisted on including the full source of the assembler inside the PE executable. That way you could edit RosAsm's source (written in the same assembler dialect) and assemble it by itself and produce a new PE executable.

That's exactly how emacs works actually[1]. Getting the documentation on a function or variable contains a link to the file that defines it, which you can then edit. If you eval the expression then all later uses of the function will have the new behavior, otherwise it'll take effect on next startup. I've done exactly this to backport some changes from future versions.

[1] http://prntscr.com/u6yfnp

Yes, I really like how easy it is to view the definition (which might be written in Emacs Lisp or C) of any function callable from Emacs Lisp.

(But I never edit any Emacs Lisp files that come with Emacs: sometimes though I will make sure such a file has been loaded, then override a function definition with one I wrote myself.)

Yeah, overriding (or advising[1]) the function in init.el is probably the better thing to do if it's a long-term behavior change. In this case I knew that it would be right once I upgraded, so the dirty hack won the day haha.

[1] https://www.gnu.org/software/emacs/manual/html_node/elisp/Ad...

That's how Smalltalk worked in the 70s (or Squeak for a modern dialect). You can edit any part of the running system and it takes effect right away. One classic example is redefining "true" to "false" and watching the system grind to a halt. Genera was similar for LISP machines in the 80s, you had full access to the code and could modify it on the fly.

Ironically one reason that always comes up when people here talk about why Smalltalk never took off is that it's hard to integrate with source code control systems like git that are file-based.

> What has always suprised me about open source software is that the source is always 'out of band'

From "Open Source is not enough" by Adam Spitz[1]:

The Open Source movement is great, but it doesn’t go far enough. […] When I feel the Urge To Tinker, only rarely does it feel like a loud voice shouting in my brain with enough energy to propel me to find the website and download the source code and figure out how to find the part of the code that corresponds to the thing I’m looking at on the screen and make the change and restart the program and retrace my steps. Much more often it’s just a quiet voice mumbling, “Hey, it’d be kinda neat if…” and then I think, “Well, it’s Open Source, I guess I could go download the source code… but… meh, it’s so far out of my way, not worth it,” and the urge fizzles out. I think that a lot of potential human creativity is being wasted this way.

> Of course I realise that this workflow is not technically possible in the way software is currently built, but it does seem worthwhile in the future

I've been thinking a lot about this and working on it. On a technical level it's more possible than it seems—even with "conventional" toolchains—but the primary obstacle is going to be social rather than technical. Funnily enough, GitHub's popularity and its measurably less-than-optimal workflows actually serve as a preview of how difficult it will be overcoming stalwartism from people who are technophiles first and only think of productivity as an nth-level concern—somewhere at a lower priority than social media presence and ginning up demand for the skills and practices they've alrealy invested in.

1. https://web.archive.org/web/20151016184630/http://adamspitz....

Thank you! My thoughts exactly. I just reposted this article:

https://news.ycombinator.com/item?id=24295133

Can you share some of your thoughts how this might be technically possible even with conventional toolchains?

I've written about it before, but nothing I've worked on is in a good state that I can point to as an example. A big part of turning the tide is going to be about getting the messaging right, because even with the ability to grandfather in conventional toolchains, it requires a perspective shift/attitude adjustment on the part of developers, and oh boy are developers going to revel in shitting on the idea and downplaying the costs of continuing to do things the same way we always have. It involves non-destructive compilation and the ability to (re)publish tooling for a common platform.

I've seen multiple comments here on HN in threads about compiler development where chrisseaton points out that compilers are pure functions. All you really need to do is combine that observation with the observation that we already have a near-universal substrate for doing computation. (And it might help further to recognize that releasing an open source project is fundamentally an act of publication, almost-but-not-quite in the vein of Knuth's literate programming.)

The author took an article about somebody suggesting that having email be the only mechanism for contributing to the Linux kernel might be a barrier to entry for new developers, and construed it into this piece on how the evil Micro$oft is looking to dismantle distributed git development.

From the original article:

> Picking her words carefully, she said work is being done towards “moving from a more text-based, email-based, or not even moving from, but having a text-based, email-based patch system that can then also be represented in a way that developers who have grown up in the last five or ten years are more familiar with."

That seems like an entirely fair statement to make for somebody who is on the board of The Linux Foundation.

The interesting thing to note is that the "way that developers who have grown up in the last five or ten years" refers to the way of working on GitHub, and that GitHub made it deliberately difficult to interoperate with other development models (like the kernel's, or old-style Bugzilla-and-patches) for business reasons. When you start out with trying to be a social network for developers, you'll happily take inspiration from the way Facebook divides the world into "Facebook" and "not Facebook", which naturally results in erecting barriers between your userbase and outsiders so long as those barriers can feed into your growth strategy of converting the outsiders into even more users.

Having said that, this blog post is foremost not actually a criticism of Microsoft/GitHub, but instead trying to draw attention to Sourcehut. Sourcehut is not a good example of how to solve GitHub's problems; if we were in a hypothetical world where the choices were GitHub or Sourcehut, the skew would remain forever what it is today, and the lead developer doesn't seem capable of understanding why and fixing Sourcehut's flaws.

I feel that the author is drawing attention to Sourcehut because there are no alternatives that use the workflow he is pitching. It's not as great as Github at the moment, but he is trying to show what it can be. He always comes off as incapable of fixing sourcehut's flaws because a lot of suggestions he gets are contradictory to the fundamental design he has in mind. Despite this, sourcehut is making steady improvements. Drew also puts up invaluable resources which helps people like me get into the email workflow. Sourcehut currently has a steep learning curve, after which you would immediately recognize the design as a safer bet in the long term.

> That seems like an entirely fair statement to make for somebody who is on the board of The Linux Foundation.

You have to follow the money.

Even the original article admits that she's on the board specifically from Microsoft. That means she's representing Microsoft's interests. Thus has to choose words carefully to not be discounted like a total shill from Microsoft.

To put it in other words: Microsoft pays her 200k+/year to represent their interests at Linux Foundation; Microsoft also pays Linux Foundation XXXk/year to have their representative at the Foundation. The title of the original The Register article is kind of sensational and incorrect, in that it portrays the speaker as having the allegiance to the Foundation, which doesn't appear to be the case on closer examination.

There are an awful lot of people in the comments here calling this an advertisement and being upset about it. How are those that are upset about it not upset that this is an obvious conflict of interest and advertisement for microsofts github platform.

This is the most upsetting part about it, IMHO. The reason Microsoft pays a salary to this person is precisely to get GitHub mentioned into these sorts of conversations -- even though it's widely known that GitHub doesn't support such usecases.

But, of course, there's never any time to mention such facts; but here's an example if anyone's curious: https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kerne....

Yet when a one-person team tries to provide relevant examples on the issues of dealing with Microsoft, pitching a potential solution, and offering their take on it -- fully open-sourced -- they get discounted as advertisement -- even though their service is free and open source.

> Yet when a one-person team tries to provide relevant examples on the issues of dealing with Microsoft, pitching a potential solution, and offering their take on it -- fully open-sourced -- they get discounted as advertisement -- even though their service is free and open source.

it's upsetting indeed.

I'm 100% sure had he didn't mentioned SorceHut the same people would've complained instead that how there were no projects for improving mail based workflow, why didn't OP offer a suggestion, or that it's open source so why he didn't shut up and wrote a patch instead.

Calls to mind the way Google, Facebook, etc. took over OAuth by flooding the committee with their own representatives and turned it into something completely different with OAuth2.

Reminded me of a quote from another one of Drew's blog posts: "The web and web browsers have become Lovecraftian horrors of an unprecedented scale. They’ve long since left “scope creep” territory and entered “oh my god please just stop” territory, and are trucking on through to hitherto unexplored degrees of obscene scope." [1]. I sometimes feel like many standards and software (incl open source) are designed to make it impossible for an individual or small team to implement or manage.

[1] https://drewdevault.com/2020/08/13/Web-browsers-need-to-stop...

This is an ad for sourcehut, a GitHub/Microsoft competitor.

Sourcehut is competing with Github/Microsoft? That's new to me :-D

Focusing on a niche hardly counts as competition to me.

'an alternative to Github' sounds more realistic.

This person seems very upset about something that customers actually love. Speaking for myself —- GitHub pull requests are amazing. I have an easy way to collaborate and propose changes to my projects through a human-friendly interface that doesn’t require me to use tech from early 90s.

Surprise - technology evolves. We’re not all going to stick with BBS just because “it’s a standard everyone uses, ZOMG don’t extinguish it!”

Wait until you need a Microsoft account for accessing github, wait until your account gets blocked. All of sudden all of your code is out of reach.

Wait until your mail server goes down or experiences a malfunction that erases all mail threads. Wait until your hard drive fails and you lose all the code.

There can be a lot of hypotheticals. GitHub does not preclude you from using git for what it’s intended to be - a distributed source control management system. If you don’t have backups, that’s on you.

"GitHub does not preclude you from using git for what it’s intended to be", yet. Never trust MS, FB, Amazon, etc. Sooner or later they lock you in or kill the service you rely on.

IMAP allows you to have multiple synchronized copies of the entire mailbox. And you can depend on multiple email servers (and IDs) if the mail server is unreliable. Email has fewer single point failures. Git may help you backup code against failure of Github/lab. But it doesn't prevent you from losing ability of issue PRs or accessing issue trackers.

Ah yes, because apparently no one besides GitHub is qualified to run reliable services.

https://status.sr.ht/

https://www.githubstatus.com/

https://sourcehut.org/blog/2020-07-03-how-we-monitor-our-ser...

https://drewdevault.com/2019/01/13/Backups-and-redundancy-at...

When your mail server goes down, nothing happens, the internet continues to function normally and then when it comes back up you will receive all of the emails that were sent to you when it was offline. If the mailing list goes down, you can still send emails and you're collagues probably won't even notice the outage because they were CC'd. When the mailing list comes back up, it'll receive all of those emails in the same way and get caught back up.

When GitHub goes down, everything stops. And GitHub goes down often!

I started trying out sourcehut out of curiosity and only recently started understanding the resilience and convenience of email workflow compared to Fork-PR workflow. It's also is clear to me that the pains with the email workflow is the user experience and not the workflow itself. None of this was apparent in the beginning (and hence the complaints). It would be great if there was a single page listing comparison of both workflows against specific technical points like these.

SMTP is designed to not lose mail in the event a mail server goes down. It's generally days before an email is abandoned (bounced) if the dest server is down for that long. Every other hypothetical you list applies to all services involved.

The problem isn't the code, it's the workflow. Every git fetch gets up-to-date code history. What I can't easily replace is the CI/CD pipeline attached to pushing to the repo or the review process before merging.

> Surprise - technology evolves

Evolution != constant re-implementation to fit the latest UI trends. (Neo)Vi(m), emacs, terminals, REPLs, email, etc. are still common because they’re the best tool for the job. Hell, even IRC refuses to die because enough realize its advantages over modern “shiny” alternatives.

All the tools I mentioned have improved and evolved without being reimplemented into obsolescence. The closest thing to “reimplementation” is Vi -> Vim -> NeoVim, but everything in that chain built off its predecessor without intending to replace it.

I have a hard time taking this seriously. Email is a pain to use compared to a dedicate feature UI.

I think the real problem is the need for a standardized pull request protocol that people can wrap. Then let people use email, a website, an API or whatever they want.

100% this. I will take GitHub’s PR process over emailing diffs any day. It’s just a matter of improving user productivity.

Absolute nonsense. Emails are far more productive. I've made a video demonstrating the difference here:

https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-...

Literally nothing from what you showed is a pleasant customer experience. Overly complex workflow that can be simplified by what GitHub is doing.

Think of a beginner developer who wants to learn how to contribute to an open source project. If they would be put through the process you showed, it will be a meat grinder that is going to be error prone. Zero need for that when GitHub has a great UX that focuses on getting shit done instead of fiddling with conventions from the 90s.

That's why there's shell completion, and history search; then with practice, keyboard shortcuts as well; all vastly improve productivity.

I think a lot of people wrongly assume that GitHub is so "easy" that you don't actually have to spend any time to learn how to use it.

But that's not the case at all.

Moreover, GitHub has so many quirks, that most Enterprise shops don't use it internally for their own internal projects (unless they release said projects into OSS); so, when you work for any company that's not just a startup, you likely have to learn yet another set of tools. And again if you switch the company.

Compare this with email. As the original article reveals, Linux and OpenBSD happen to have almost entirely identical workflows for patch submission, which is actually REALLY weird, considering that the two projects have entirely different histories, methodology, and use entirely different revision control systems, where OpenBSD still uses CVS, yet Linus Torvalds hated CVS so much, I recall that he refused to use it even before Git was ready and the licences for the predecessor system have already been withdrawn (I recall he hated CVS so much he simply used plain patches or tarballs).

> I think a lot of people wrongly assume that GitHub is so "easy" that you don't actually have to spend any time to learn how to use it.

For a lot of people, probably the large majority of people, GitHub's (or GitLab's) UI is simpler to work with than a terminal. The overwhelming success and popularity of GitHub has demonstrated the value of it's UI. I just don't see how you could convince the Atom/VSCode generation of developers to go back to mailing lists.

> so, when you work for any company that's not just a startup, you likely have to learn yet another set of tools. And again if you switch the company.

As far as I am concerned, the email workflow is just "another set of tools" too. Except no company I've worked with or worked for has used it.

> For a lot of people, probably the large majority of people, GitHub's (or GitLab's) UI is simpler to work with than a terminal.

The topic isn't about majority of users. It is specifically about Linux kernel developers.

Fair point, I've strayed from the topic at hand.

For what it is worth, I watched the video.

I'm sorry, I just disagree. I think there are plenty of devs that agree with you, but I don't.

Some points:

- Working with the UI of GitHub is pretty painless to me.

- On the other hand, I hate dealing with email and prefer tools like slack or even teams to checking and responding to emails. The thought of emailing patch diffs sounds crummy to me after being spoiled on the interactive UI flows of GH pull requests.

- I think the big bifurcation is on the concept of staying in the terminal at all times. I don't develop that way. I also don't send emails from the terminal at all. I primarily work in C# and F# on Windows with VSCode and VS as my daily drivers for editing code. I use the IDE UI to switch branches, merge, rebase and commit most of the time. Perhaps I'm not your target audience.

- I find Git's commands to be rather fiddly most of the time. And why bother remembering complex syntax when I can click familiar buttons. I prefer the ergonomics of the UI even if incurs a mental context switch. But really, that context switch doesn't hurt much compared to the cognitive load of my normal work.

- The last point I'll make is discoverability. Just last week a friend of mine made her first contribution on GitHub in less than 10 minutes. Without needing to look up docs or google workflows. The GitHub UI made a complex concept such as Git branching and merging very simple for her. That alone is worth alot.

It’s not a conspiracy. If customers demanded decentralized, companies would be pushed down that path. They don’t. Customers demand ease of use, features, and speed, and all that is technically easier to deliver with a centralized model. Why impose extra engineering cost for decentralization almost nobody cares about?

GitHub’s largest value add IMHO is search, and that is probably the hardest thing to decentralize.

can you elaborate on the 'indexing git repo for search is hard to decentralize' part?

Fast search over huge data sets in distributed networks of unreliable and possibly untrustworthy nodes is really really hard. Nobody has all the data in one place and the indices are huge and cross cut the data.

It can be done, but making it perform like GitHub search with sub-second returns on most queries and with full coverage of the entire data set would be an amazing achievement. The CAP theorem means you can’t do it without making some sacrifices.

There is a reason nobody has even seriously attempted a decentralized web search engine despite the obvious motivations.

The whole point of "extend" is that the extensions are proprietary. If GitHub's fork and pull request features were standards that are portable and that other repository vendors could implement this wouldn't be a problem.

I see the same interface present on GitLab and Gitea, both great open source projects that provide selfhosted (and hosted) alternatives to Github. It was pretty novel when it was introduced, but not anymore.

Just because others have copied the interface doesn't make it 1) portable 2) part of the standard 3) a protocol. You'd ideally want all three for a viable alternative to email-based patches.

That's exactly what is needed. But we will likely just reinvent SMTP. Why not just build better interfaces (web, gui and cli) around SMTP? On the other hand, SMTP is starting to show its age - too many parts, lack of privacy and abuse. Wish there was a new protocol in the spirit of SMTP, but modern design - something like what Matrix is to IRC.

Github absolutely would not make itself interoperable just because users wanted it to. That would be a terrible business move -- it would lead to Github hemorrhaging users and projects as they left to other, smaller competitors while still begin able to interact with the users and projects that remain on Github.

It's not Github's job to do what customers want. It's Github's job to do whatever will make them money, whether it's good for customers & the broader tech community or not. You're right that it's not a conspiracy though -- there's nothing secret about this at all. It's just business.

You can already mirror a repo easily to/from GitHub, and moving is pretty easy unless you are deeply invested in GitHub proprietary features.

People use GitHub because people use GitHub. It’s a classic network effect.

I mean like me forking your Github repo to Gitlab and then submitting a PR from my Gitlab fork to your Github repo. Can't do that. If I want to contribute to a Github project, I need a Github account. That doesn't apply to interoperable protocols like email -- you can use gmail and I can use yahoo mail, or even a self-hosted mail server, and we can still send messages to each other.

This would certainly be doable, but they wouldn't do it, because it would damage their market share.

What is Microsoft extinguishing here? Email?

Distributed git development. Moving us back to central repos.

But you can still do distributed repos with github... nothing it preventing you from changing your remote origin...

Only issue is if you decide to use GitHub features like issues/prs or comments on code, those won't be transferrable I think. At least easily.

Is it really though? The tools might be proprietary, but the workflow should be easy to move. E.g. You need to have a code review before a commit is merged. It happens that Github has a good set of tools for this, but if you decided that on date X you wanted to move away I don't think it would be that hard to shift away. You'd have the same mandate about code review, you just point people at a different tool set to do it.

Email archives are even harder to transfer, and to make sense of in general.

For example if you want to find the review comment thread for linux commits there is no reliable way to do it, your best bet is to google the title.

> Email archives are even harder to transfer, and to make sense of in general.

Email archives are very easy to transfer, you simply download the mbox file from the old system and import them to the new one [0].

> For example if you want to find the review comment thread for linux commits there is no reliable way to do it, your best bet is to google the title.

In my experience, projects that use a ml-based workflow have higher standards for commit messages and so the information about a commit is usually in the commit.

[0] https://wiki.list.org/DOC/How%20do%20I%20import%20an%20archi...

> Email archives are even harder to transfer

Mailing lists are trivial to distribute. Thanks to maildir and mbox, everybody has a full copy of the mailing list just as they have a full copy of the repository.

> Thanks to maildir and mbox, everybody has a full copy of the mailing list.

No, that only covers emails that you personally received. You need another mechanism for older emails.

A mechanism which is provided by mailing list archives in the form of mbox downloads. If you question the reliability of this (but apparently not the proven unreliability of GitHub), as a fallback you can just ask an older subscriber to give you their mbox.

If GitHub goes down, you can still use a different remote; however, you lose issues, PRs, and code review.

If your remote goes down but you have an email based workflow, you can continue as if nothing happened. One could argue that your mail server might go down, but it’s better than having your centralized GitHub-like forge go down for two reasons:

1. If not all contributors use the same mail server, it’s much less of an issue since not everyone goes offline at the same time. Additionally, your maildir doesn’t care whether or not you’re online; both the git repo and all mailing lists have offline copies distributed to all collaborators out-of-the-box by default.

2. GitHub’s reliability is significantly poorer than the vast majority of email providers. The great thing about decentralization is that getting good uptime on a small mail server for under 1000 users is much easier than getting good uptime on a centralized forge re-implementing email’s features for millions of users.

You still have a single, centralized mailing list server. That's what you should be comparing to GitHub -- not the individual mail servers for each user.

If your mailing list server goes down, no one can use the mailing list. Taking it a step further, if its data is lost, everyone has to re-subscribe.

On top of that, you have a mailing list archive. If that's down, or not operating, you've made thing even less open, because now any non-subscribers can't even read what's going on, and if they do subscribe, they only get to see new messages. Existing long-time subscribers have an archive, sure, but it's very possible no one user has a complete archive, and it's a certainty that most users don't.

Someone can run a redundant mailing list archive server, but then someone can also mirror the GitHub repository, PRs and issues.

---

That said, the mailing list server and archive are likely simpler to run, less likely to go down, and easier to move somewhere else.

Transferring from github.com to something else is going to be painful, and I suspect most FOSS authors simply don't think about it or see the ease and benefits of using it as outweighing the risk. Companies should look at that risk much more closely, but ultimately it's the same situation as if they decide not to have fire insurance: if their building burns down, they're SOL, but that was the decision they made.

Sorry, I wasn't clear enough. I meant that you still have an offline copy of the mailing list and can see the full picture of what's publicly going on, and you have everybody's contact info. You can see who's involved with what problems and get to work during the downtime.

Microsoft isn’t doing that, end users did that. Developers seem to overwhelmingly treat their git host as a centralized thing, even for closed source work.

These proprietary extensions for git are wildly popular, and are commonly cloned for open and closed source alternatives to github; I think blaming github or Microsoft here is incorrect.

You should read that statement in context of what Microsoft's Linux Foundation member said about LKML. They want a community who is fine with emails to adopt PR workflow too. We don't see Github doing the same for federated workflows.

Choice.

I represent sourcehut, a GitHub competitor

Maybe lead with that?

Good: Fuck plain-text email.

We should stop relying on duct-taped solutions from the 70s. Web-based code review solutions are vastly better.

Agree. The problem with github is not that it is web-based instead of email-based. The problem is that it is a proprietary walled garden.

An open source direct competitor to github is what's needed, not going back to email as the UX for development.

I don't see a shortage of github competitors.

For example GitLab works well and also allows for self-hosting.

But Gitlab is its own walled garden (albeit an open-source one). What we'd ideally have is a platform-agnostic PR protocol. Sadly, we're not likely to get one.

That being said, I agree that "let's all use plain-text email" isn't a very good alternative. It's perfectly possible to use Gitlab or Gitea and have the web UI experience without marrying yourself to a proprietary ecosystem.

Is the plain-text the problem? Because Gitlab/hub use them too - as markdown. Their UI layer is built on top of it. Why not do the same thing for emails? Plain-text in SMTP as a communication layer, but a rich UI layer on top of that at client level? Make a combined mail + list + git client?

I don't have any inherent problem with plain text, I just think that the pull/push/PR workflow is nicer than emailing patches to a mailing list.

But Gitlab is its own walled garden (albeit an open-source one)

if it's open source then the garden is not walled -- by definition.

This is the kind of scenario where body from gitlab would have all the rights to chime in and say "patches are welcome".

But it is walled. If you use Gitlab and I use Gitea, I can't submit a PR from a Gitea fork to your Gitlab repo. I have to create a Gitlab account or host my own Gitlab server. Because it's not interoperable, it's a walled garden.

Like... Gitlab and Sourcehut ?

> stop relying on duct-taped solutions from the 70s

I wonder how you feel about age discrimination. Some old tools and ideas (vim, emacs, the UNIX philosophy, etc.) are still going strong because they haven't been beaten by decades of venture capital and SV "disruption"

tl;dr: A Github competitor is looking for reasons to rage against Github/Microsoft.

Reply on news.ycombinator.com