4 ms·

> If you've ever tried to contribute something to the Linux kernel you'd know it's not an easy process. They say that they want to "encourage new contributors t

> If you've ever tried to contribute something to the Linux kernel you'd know it's not an easy process. They say that they want to "encourage new contributors to repeatedly contribute". So in this respect it is very different from the Linux kernel. I have contributed a small 1-time change to the Linux kernel. It was relatively easy and straight forward; I sent my first patch to the wrong list, but the maintainers helpfully corrected me. The difficult part is finding what to contribute, IMO.

rwmj 8y ago
I think you're forgetting the large learning curve to get to that point. You learned how to build the kernel, git, the kernel style guide, signed-off-bys, checkpatch, get-maintainer and finally running git-email. And there's the assumption that you knew what to change and how to fix it, but most kernel error messages are opaque - it can often be impossible to find out why a system call returns -EINVAL or where an error message comes from. And that's just for a small change. Large and/or controversial changes often involve multiple rounds of review and can take (literally) years to get upstream. I'm sometimes amazed when I read LWN about how long it has taken for features to get integrated into the kernel. I don't know what Unleashed OS is planning but it seems obvious we could make this a whole lot simpler.
- neuromantik8086 8y ago
  > I think you're forgetting the large learning curve to get to that point. Openness in general requires a large learning curve, and I think it's a mistake for any open source project to be marketing itself as a democratic entity that literally anyone can contribute to. If anything, open source is more like a technocratic government (ergo the "Benevolent Dictator For Life" position in a project). Even Wikipedia is a huge pain in the ass to add to at this point. I've noticed a similar phenomenon with the open science movement, where scientists publicly release their data. Unsurprisingly, few folks from the general public usually work with open data with the necessary assumptions to draw valid conclusions from it. Other scientists, as insiders who've built up decades worth of expertise in statistics and other analytical techniques (at least in theory; in practice not always) are usually the only people who have the ability to fully milk the data for what it's worth. Science, however, is possibly even slower and more political than linux kernel development, although I don't have enough knowledge to make a proper comparison.
- linuxftw 8y ago
  > You learned how to build the kernel, git, the kernel style guide, signed-off-bys, checkpatch, get-maintainer and finally running git-email. These are all pretty well documented tasks. It might not be 'one button simple' like a gitlab merge request, but I thought it was pretty easy overall. It did take some time investment on my part to learn the submission steps (about a weekend total, including the compiling and testing locally). > Large and/or controversial changes ... I suspect if they are large or controversial, that in itself implies the barrier to merging is going to be higher. How many new contributors (non-paid contributors especially) want to merge something controversial on the first go? Could it be simpler? Possibly. Sometimes complex systems do require complex processes for maintenance. I'm just saying I didn't think it was especially burdensome to contribute a small change as a brand-new, completely-unassisted by another person (before sending patch) contributor.

rwmj 8y ago

I think you're forgetting the large learning curve to get to that point. You learned how to build the kernel, git, the kernel style guide, signed-off-bys, checkpatch, get-maintainer and finally running git-email. And there's the assumption that you knew what to change and how to fix it, but most kernel error messages are opaque - it can often be impossible to find out why a system call returns -EINVAL or where an error message comes from. And that's just for a small change. Large and/or controversial changes often involve multiple rounds of review and can take (literally) years to get upstream. I'm sometimes amazed when I read LWN about how long it has taken for features to get integrated into the kernel. I don't know what Unleashed OS is planning but it seems obvious we could make this a whole lot simpler.

neuromantik8086 8y ago
> I think you're forgetting the large learning curve to get to that point. Openness in general requires a large learning curve, and I think it's a mistake for any open source project to be marketing itself as a democratic entity that literally anyone can contribute to. If anything, open source is more like a technocratic government (ergo the "Benevolent Dictator For Life" position in a project). Even Wikipedia is a huge pain in the ass to add to at this point. I've noticed a similar phenomenon with the open science movement, where scientists publicly release their data. Unsurprisingly, few folks from the general public usually work with open data with the necessary assumptions to draw valid conclusions from it. Other scientists, as insiders who've built up decades worth of expertise in statistics and other analytical techniques (at least in theory; in practice not always) are usually the only people who have the ability to fully milk the data for what it's worth. Science, however, is possibly even slower and more political than linux kernel development, although I don't have enough knowledge to make a proper comparison.
linuxftw 8y ago
> You learned how to build the kernel, git, the kernel style guide, signed-off-bys, checkpatch, get-maintainer and finally running git-email. These are all pretty well documented tasks. It might not be 'one button simple' like a gitlab merge request, but I thought it was pretty easy overall. It did take some time investment on my part to learn the submission steps (about a weekend total, including the compiling and testing locally). > Large and/or controversial changes ... I suspect if they are large or controversial, that in itself implies the barrier to merging is going to be higher. How many new contributors (non-paid contributors especially) want to merge something controversial on the first go? Could it be simpler? Possibly. Sometimes complex systems do require complex processes for maintenance. I'm just saying I didn't think it was especially burdensome to contribute a small change as a brand-new, completely-unassisted by another person (before sending patch) contributor.