1. 58

    my partner submitted a patch to OpenBSD a few weeks ago, and he had to set up an entirely new mail client which didn’t mangle his email message to HTML-ise or do other things to it, so he could even make that one patch. That’s a barrier to entry that’s pretty high for somebody who may want to be a first-time contributor.

    I think it was actually Gmail that was a barrier. And he also couldn’t do it from Apple Mail. It is just that the modern mail client has intentionally moved towards HTML

    I am flabbergasted someone is able to send a patch to OpenBSD but is not able to set the web interface of GMail to sent plain-text emails. Or install Thunderbird, which might have been the solution, in that particular case.

    I also never used git send-email, but I don’t think it is the barrier to become a kernel maintainer.

    Actually, that might work as an efficient sieve to select the ones who want to be active contributors from those who are just superficial or ephemeral contributors.

    In my opinion, although Github supposedly decreases the barrier of first-time contribution, it increases the load on the maintainers, which has to interact with a lot of low-quality implementation, reckless hacks and a torrent of issues which might not even be. That is my experience in the repositories I visit or contributed.

    1. 41

      Patching some component or other of OpenBSD is not a skill that transfers well to making some random application do what you want.

      1. 40

        I agree with you.

        On the other hand, if someone knows how to install OpenBSD, use cvs (or git), program in C and navigate the kernel’s souce-code, I supposed they are capable of going to any search engine and find the answer on how to send plain-text email via the GMail interface.

        1. 16

          GMail mangles your “plain-text” messages with hard-wraps and by playing with your indentation. You’d have to install and configure thunderbird or something.

          1. 3

            One of the many reasons why I use Mutt.

        2. 14

          Note that this is anecdotal hearsay. This person is saying their partner had to set things up… they may have misunderstood their partner or not realized their partner was exaggerating.

          Also, one might expect the amount of patience and general debugging skill necessary to transfer rather well to the domain of email configuration.

          It’s also possible that guiraldelli is assuming it was an excepted OpenBSD kernel patch, wheras we don’t know if the patch was accepted and we don’t know if it was a userland patch. It doesn’t take much skill to get a userland patch rejected.

        3. 30

          I am flabbergasted someone is able to send a patch to OpenBSD but is not able to set the web interface of GMail to sent plain-text emails.

          You can’t send patches, or indeed any formatted plain text emails through the gmail web interface. If you set gmail to plain text, gmail will mangle your emails. It will remove tabs and hardwrap the text. It’s hopeless.

          1. 26

            Think about impediments in terms of probabilities and ease of access.

            You wouldn’t believe how many people stop contributing because of tiny papercuts. There is a non-trivial amount of people who have the skills to make meaningful contributions, but lack the time.

            1. 18

              Lobsters requires an invite. That’s a barrier to entry, so those who make it are more likely to make good contributions, and have already extended effort to comply with the social norms.

              1. 8

                You may be willing to jump a barrier of entry for entertainment (that is lobsters) but not for free work for the benefit of others (because you have already done that work for yourself).

                1. 4

                  If you want to save yourself compiling and patching your kernel every time there’s an update, you might want to submit it to the project maintainer.

                  1. 18

                    If the project wants to have contributors in the future it might want to consider using modern, user friendly technologies for contribution.

                    Linux is considering it, a discussion is started, which is positive (for the future of the project) in my opinion. It is a sign or responsive project management, where its conservatism does not hinder progress, only slows it to not jump for quickly fading fads.

                    Other communities are closing their microverse on themselves, where it is not enough to format your contribution in N<80 column plain text email without attachments with your contribution added to it via come custom non-standard inline encoding (like pasting the patch to the end of the line), but you may even need to be ceremonially accepted for contribution by the elders. Also some such projects still don’t use CI, or automated QA. These communities will die soon, actually are already dead, especially as they don’t have large corporations backing them, as someone getting paid usually accepts quite a few papercuts a job demands. This is why Linux could actually allow itself to be more retrograde than the BSD projects for example, which I think are even more contributor-unfriendly (especially ergonomically).

                    1. 2

                      I tend to agree, however that discussion was started by someone with a very striking conflict of interest and therefore their opinion should be questioned and considered to be insincere at best and maleficent at worst.

                      1. 5

                        That doesn’t matter, the discussion can be done despite that. I think a forge-style solution is the key.

                        Despite Microsoft having 2 “forge” type solutions in its offering (both quite usable in my experience, github being a de-facto standard) I still cannot see a conflict of interest in this topic. There are other software forges available. The current process is simply outdated.A custom solution could also be developed, if deemed necessary, as it was the case with git.

              2. 14

                Pay attention my comment talks about maintainers, active contributors and superficial or ephemeral contributors.

                From the article:

                a problem recently raised by Linux kernel creator Linus Torvalds, that “it’s really hard to find maintainers.” Maintainers are the gatekeepers who determine what code ends up in the widely used open-source kernel, and who ensure its quality. It is part of a wider discussion about who will oversee Linux when the current team moves on.

                And later on…

                “We need to set up a better or a different or an additional way to view tools and the work that’s being done in the Linux project as we’re trying to bring in new contributors and maintain and sustain Linux in the future,” she told us.

                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.

                “Having that ability and that perspective into Linux is one of the ways we hope we can help bring newer developers into the kernel track.”

                So I understood Sarah Novotny is addressing the problem of new contributors, not the one Linus Torvalds see, of new maintainers.

                So, your comment that

                how many people stop contributing because of tiny papercuts. There is a non-trivial amount of people who have the skills to make meaningful contributions, but lack the time

                is not the problem the Linux Foundation has, but the one that Microsoft’s Sarah Novotny wants to solve. Those are two different problems, with two different solutions. On the surface, they might seem the same, but they are not. They might be correlated, but the solution for one problem does not necessarily mean it is the solution for the other.

                Therefore, my argument still stands:

                [having a plain-text email list as central communication and collaboration to the Linux’s kernel] might work as an efficient sieve to select the ones who want to be active contributors [i.e., maintainers] from those who are just superficial or ephemeral contributors.

                If we are going to address, though, that it might hinder new contributors, then I tend to agree with you. :)

                1. 21

                  Let’s not let Microsoft decide how Linux is developed.

                  The waning popularity of their own, proprietary kernel is no excuse for telling other projects how they need to be run.

                  1. 5

                    This is just my opinion but I think that while she’s totally missing the mark on finding Linux kernel module maintainers having anything at all to do with plain text email patch submission systems, the general issue she’s speaking to is one that has generated a lot of discussion recently and should probably not be ignored.

                    Also, in the spirit of the open source meritocracy, I’d prefer to let people’s actions and track records speak more loudly than which company they happen to work for, but then, lots of people consider my employer to be the new evil empire, so my objectivity in this matter could be suspect :)

                  2. 8

                    So I understood Sarah Novotny is addressing the problem of new contributors, not the one Linus Torvalds see, of new maintainers.

                    Bingo!

                    My first thought after reading this was “Does this person ACTUALLY think that having to use plaintext E-mail is even statistically relevant to the problem of finding module maintainers for the Linux kernel?”

                    In a general sense I believe that the open source community’s reliance on venerable tools that are widely rejected by younger potential contributors is a huge problem.

                    Martin Wimpress of Ubuntu Desktop fame has spoken about this a lot recently, and has been advocating a new perspective for open source to increase engagement by embracing the communications technologies where the people are not where we would like them to be.

                    So he streams his project sessions on Youtube and runs a Discord, despite the fact that these platforms are inherently proprietary, and has reported substantial success at attracting an entirely new audience that would otherwise never have engaged.

                    1. 5

                      is not the problem the Linux Foundation has, but the one that Microsoft’s Sarah Novotny wants to solve. Those are two different problems, with two different solutions. On the surface, they might seem the same, but they are not. They might be correlated, but the solution for one problem does not necessarily mean it is the solution for the other.

                      GKH even said that there are more than enough contributors in his last ama, so having contributors is “a priori” not a problem right now.

                      1. 2

                        So I understood Sarah Novotny is addressing the problem of new contributors, not the one Linus Torvalds see, of new maintainers.

                        Every maintainer was a new contributor at a point! Also better tooling would be beneficial for everyone.

                        1. 1

                          Every maintainer was a new contributor at a point!

                          That is true, but it is not the current problem: see /u/rmpr’s reply and his link to the Reddit’s AMA to verify that.

                          Also better tooling would be beneficial for everyone.

                          That is not necessarily true: the introduction of a tool requires a change of mindset and workflow of every single person already involved in the current process, as well as update of the current instructions and creation of new references.

                          I saw projects that took months to change simply a continuous integration tool (I have GHC in mind, except the ones in the companies I worked for). Here, we are talking about the workflow of many (hundreds for sure, but I estimate even thousands) maintainers and contributors.

                          As I already told before, RTFM [1] [2] does not take long for a single individual that wants to become a new contributor; in [1], there is even a session specially about the GMail’s Web GUI problem.

                          If the problem is retrievability of the manual or specific information, than I think that should be addressed first. But that topic is not brought up in the article.

                    2. 20

                      I am able to deal with email patches, but I hate doing it. I would not enjoying maintaining a project which accepts only email patches.

                      Actually, that might work as an efficient sieve to select the ones who want to be active contributors from those who are just superficial or ephemeral contributors.

                      Ephemeral contributors evolve to maintainers, but if that initial step is never made this doesn’t happen. I don’t know if this will increase the number of maintainers by 1%, 10%, or more, but I’m reasonably sure there will be some increase down the line.

                      Finding reliable maintainers is always hard by the way, for pretty much any project. I did some git author stats on various popular large open source projects, and almost all of them have quite a small group of regular maintainers and a long tail of ephemeral contributors. There’s nothing wrong with that as such, but if you’re really strapped for maintainers I think it’s a good idea to treat every contributor as a potential maintainer.

                      But like I said, just because you can deal with email patches doesn’t mean you like it.

                      1. 14

                        GMail, even in plain-text mode, tends to mangle inline patches since it has no way of only auto-wrapping some lines and not others.

                        Not a major issue as you can attach a diff, but from a review-perspective I’ve personally found folks more inclined to even look at my patches if they’re small enough to be inlined into the message. I say this as someone having both submitted patches to OpenBSD for userland components in base as well as having had those patches reviewed and accepted.

                        I personally gave up fighting the oddities of GMail and shifted to using Emacs for sending/receiving to the OpenBSD lists. I agree with Novotny’s statement that “GMail [is] the barrier.” The whole point of inlining patches like this is the email body or eml file or whatever can be direct input to patch(1)…if GMail wraps lines of the diff, it’s broken the patch. Text mode or not.

                        Obviously, this doesn’t mean if the Linux kernel maintainers want to change their process that I don’t think they shouldn’t. (Especially if they take a lot of funding from the Foundation…and as a result, Microsoft/GitHub.) OpenBSD is probably always going to take the stance that contributions need to be accessible to those using just the base system…which means even users of mail(1) in my interpretation.

                        1. 5

                          You can’t attach a diff – nearly all mailing lists remove attachments!

                          OpenBSD is probably always going to take the stance that contributions need to be accessible to those using just the base system

                          Heh, if you add arc to the base system, you can adopt Phabricator without violating that principle :)

                          1. 2

                            Good point…so basically GMail (the client) doesn’t really work with an email-only contribution system. It’s Gmail SMTP via mutt/emacs/thunderbird/etc. or bust.

                        2. 5

                          I have found several Linux subtle kernel bugs related to PCIe/sysfs/vfio/NVMe hotplug. I fixed them locally in our builds, which will ultimately get published somewhere. I don’t know where, but it’s unlikely to ever get pushed out to the real maintainers.

                          The reason I don’t try to push them out properly? The damn email process.

                          I did jump through the hoops many years ago to configure everything. I tried it with gmail, and eventually got some Linux email program working well enough that I was able to complete some tutorial. It took me some non-negligible amount of time and frustration. But that was on an older system and I don’t have things set up properly anymore.

                          I don’t want to go through that again. I have too many things on my plate to figure out how to reconfigure everything and relearn the process. And then I won’t use it again for several months to a year and I’ll have to go through it all again. Sometimes I can get a coworker to push things out for me - and those have been accepted into the kernel successfully. But that means getting him to jump through the hoops for me and takes time away from what he should be doing.

                          So for now, the patches/fixes get pulled along with our local branch until they’re no longer needed.

                          1. 4

                            I have no idea how dense they need to be to not be able to send text-only email from Apple Mail. It must be anecdotal, because I cannot believe that someone is smart enough to code anything, but dumb enough to be able to click Format > Change to text in the menu bar.