I'm fine with that. Github is 'too large to fail' already, adding the Linux kernel to the pile and forcing the kernel team into Github's workflow are two big negatives. It would be great for Github but bad for everybody else.
Seriously. Linux will likely outlive GH[1], and more importantly, it doesn't need GH. The current workflow works fine, and I hardly think any potential kernel hackers are choosing not to work on the kernel because it is email-driven.
[1] Nothing against them that I don't have with any other commons that depends on corporate beneficence. But companies fail all the time; I can't think of a reason GH is immune.
It's not like open source projects are immortal. Some die due to poor management, lost developer interest, lost funding, or some fork becoming more popular. Or all of the above.
Linux will likely outlive all of us. Network effects are massively strong for operating systems, we've been stuck with the same basic 3 for decades and that's likely to stay the same.
Mobile operating systems such as IOS have become huge and they're many new industries that look promising (my guess is IOT based one like alexa and Google home but who knows).
There are two major mobile operating systems, iOS and Android, both based on Unix clones, one on BSD and one on Linux. Mobile has dramatically increased Linux usage; what do you think Android is?
However, ios makes most of the mobile profit just as windows and Mac do over Linux for desktop (I have only used Linux in server industry so I don't know how they fair in those markets too much).
In that light, How about this prediction.
Linux will continue to dominate in the server market for a long time as businesses factor in the cost of os licenses and the supply of linux users is big.
Consumer markets like desktop, mobile, whatevers next will flock to the lower personal cost (through customer time investment in learning the os).
Well, it might happen that Google will fork Linux into their own thing, and it will be harder better faster stronger, and for some reason hard to merge back into Linux. And the ecosystem will move.
> The current workflow works fine, and I hardly think any potential kernel hackers are choosing not to work on the kernel because it is email-driven.
I'm not so sure. If the kernel development was on Github, I may have looked into contributing, but as it stands, its not worth the trouble to try to contribute (as I don't have anything specific to help with). And, I suspect there are more capable developers who are closer to the edge than me.
Anyway, having a slightly lower bar to get started may not get more developers involved, but instead my get them involved more quickly.
Linux is one of the few open source projects to with plenty of developers. They don't need or even want your help, especially if your attitude toward tools is rigid, and if you have nothing concrete to contribute.
Linus has said this a few times -- in general they don't actively try to onboard new contributors.
There was in fact a talk given by Greg Kroah-Hartman, one Linux's lead maintainers, about development for the Linux kernel which he titled "I Don't Want Your Code".
Haha, thanks for the video. I watched it, and I was surprised to see that it's about a specific company.
He's at Linaro, specfically taking their developers to task for sending bad patches. And they indeed sound horrible, but he's good natured about it.
I'm just starting to accept patches for my project, and honestly I'm flabberghasted that people will send patches that not only don't run, but don't build. And Greg was saying the same thing.
I guess I got spoiled at my last job, where people generally sent high quality patches / code reviews. Although toward the end, I noticed some sloppiness. It wasn't the main reason I left the company, but it started to feel like the downfall... I don't want to work with people who don't know how to submit code reviews / patches.
> I'm just starting to accept patches for my project, and honestly I'm flabberghasted that people will send patches that not only don't run, but don't build. And Greg was saying the same thing.
Indeed, I've seen the same thing. I have considered automatically rejecting any patch made with the GitHub online editor (obvious because the committer name is always GitHub). They are pretty much invariably of shit quality.
Linaro isn't a company; it's a "collaborative engineering organization". It does employ some number of engineers, funded by donations by their member companies, but they also accept "in-kind" donations where engineers are detailed to work at Linaro for some period of time. So it wasn't really directed at Linaro per se, but more at the member companies of Linaro.
80% of the kernel development is done by companies who want their code in the kernel (whether that's because they develop hardware or because that's less work than maintaining their own patchset).
It is important to understand development for Linux is heavily driven by a business need. There are more than enough companies (intel, google, etc) that would gladly contribute to Linux, since it makes business sense.
Kernel development shouldn't have a low bar, it should have a very very high one. Anyone that finds email a high bar for communication doesn't belong in Kernel development.
This is gate keeping at its finest. Email is a clunky tool to do development with compared with what is available. A persons willingness to use email (and all the quirks for submitting a patch) for patching the kernel has nothing to do with the quality of code that they write.
You can send a patch to a mailing list with `git send-email`. You can format it first with `git format-patch` and then send the patch with `git send-email`. Configuring it to use your email server takes a few minutes, and you only have to do it once.
I get the feeling most people who complain about how "clunky" email is have never actually tried to submit a patch to LKML. If I could figure it out when I was a high-school student, a professional developer should be able to figure it out as well.
> Email is a clunky tool to do development with compared with what is available.
The linked article explains at length why it works well for kernel maintainers. And since it does, why should kernel maintainers change it just to make things easier on newbies? It's much more reasonable to expect new participants to adapt to a workflow that works, than vice versa.
This is not "gatekeeping," it's just the reality that not everyone works the same way.
So clunky! :D — With 2000 commits per day, I don't think they need more people. I can't even imagine trying to fit that amount of source code change into any management style, let alone one that has little or no gatekeeping. Making the barrier to entry higher is probably only one step to prevent the project from self-immolation.
So they're gating developers by their appreciation of the chosen toolset? Wouldn't you rather see them challenged on their programming abilities? Do you suggest a correlation, I find it hard to believe there is one?
Well they are doing both of course, your patch will still get rejected if it's bad, even if you were able to figure out where and how to send it. But it reduces the amount of patches that need to be read and rejected.
Also we are arguing backwards here. They don't make it intentionally hard to keep out new contributors, it's just not important in any way to make it simpler. The goal is to make it work best for the thousands of existing contributors, especially the gatekeeping subsystem maintainers.
>Also we are arguing backwards here. They don't make it intentionally hard to keep out new contributors, it's just not important in any way to make it simpler.
Generally yes, but IIRC Linus has explicitly said that he likes the process being intentionally hard to keep out new contributors.
Personally I'm a fan (and user) of gitlab since GitHub's recent policies and that GitHub takes forever to implement simple things that all users would love (like free private repos)
Why on earth would they want to provide free private repo's, that's something they charge for... ON PURPOSE. They aren't taking "forever", they're simply not going to do that.
