I think this is great advice. While I've only contributed to a couple open source projects and haven't lead my own large ones, I completely agree. There's more to submitting patches than writing the patch- understanding contribution guidelines (code style, documentation, testing), responding to feedback, etc, these are all extremely important in actually contributing to a project. And having even just that little patch merged in feels great when you're starting out.
Plus, no one wants to make a big helpful functional contribution only to be thrown away because they weren't aware of how the community operates. Small patches have a low risk as far as learning about how to contribute, even if the patch is rejected for whatever reason.
Though this seems somewhat obvious, it's nice to have it stated and validated by the leadership of one of the largest open source projects.
Great attitude. Linus has had plenty of heated moments on the mailing lists, but 1) he's often right and 2) his venom is usually reserved for experienced developers that really should know better. Glad to him being so open and accepting with newbie kernel hackers.
> Linus has had plenty of heated moments on the mailing lists, but 1) he's often right and 2) his venom is usually reserved for experienced developers that really should know better
Also, his gain attention specifically because they're available, whereas most companies don't make all their internal emails visible to the public (which Linux does).
One of the few uncensored corpora of emails that we have is the Enron Corpus[0] - if you look through them, you'll see a lot of profanity, vitriol, etc. that helps put Linus's rants in perspective.
Also, the "Linus rants" are rather cherry-picked - they make the rounds here periodically (sometimes years after the emails were originally sent), but that's not to say that it's representative of a typical email that one is likely to receive from Linus.
I think you're overestimating how often that sort of vitriol happens in a workplace. I've been a developer for 16 years now and I've had very strong opinions about development for a long time. I can't remember the last time I made things personal, especially over email.
I think Linus's behavior is often reprehensible. He gets a pass from many because of who he is, which is sad.
Linux is over 20 years old at this point. How many "reprehensible" rants has Linus had over these 20 years? Maybe 20-30? So ~1-2 rants per year.
Does that really justify the statement "Linus's behavior is often reprehensible"?
I've seen dozens of developers let go over "cultural fit" over the years. I've seen dozens more laid off so a few suits could make a bit more money. Developers with bills to pay and families to take care of. In my opinion, going on a rant, however mean, once or twice a year is not even comparable.
No, it is not. Who you are should matter, we don't want to stop a major advance in tech just because the one who will lead its creation may be a prick.
Enron is probably exceptional due to the fact that they essentially created an out of control shark tank of type-A roid-raging traders who ended up running the asylum.
Another factor is that Linus' colorful rants are the only ones that people hear about. There's a sampling bias there. No one ever talks about the "uninteresting" day-to-day stuff.
That makes a lot of sense. If I look at any project I've contributed to, it always started out with something small. Taking the time to make a small PR that makes a tiny improvement:
- shows you care about improving the project; you took the time to improve something small that others would ignore
- lets you test the waters. Are the project owners receptive of changes? Is it pleasant trying to contribute to the project? Or do they ignore your patch and don't reply for 2 weeks. You wouldn't want to spend a lot of effort just to find that out.
- gives you a chance to become familiar with the process, the tools, gain practice, and hopefully get rewarded with your change being accepted
For example, my first CL to Go was a trivial change:
But without having done that (and having a good experience) I couldn't have been working on more complicated changes like https://codereview.appspot.com/142360043/ now.
Seems like it's good to remind people every now and then that Linus is a human with empathy, since a lot of them really don't understand the reasons for when he rants, and then start to draw conclusions.
On a related note, Theo de Raadt rants need far more attention than they currently get.
This ^. Theo rants with a whole lot more venom than Linus does as well. You'll start by pointing out a bug that needs to be fixed and suggest a fix. He'll end up insulting your mother for allowing you to be born.
I've literally been blown away at how the OpenBSD community stays together with such an outspoken leader. Then I realize this is technology :)
Small patches are the "hello world" of open source. They give you a chance to get familiar with and work through the contribution pipeline before you push something sizeable through.
There's little useful about "hello world" as a program, but it ensures you've got your toolchain working correctly, which is a necessary precondition for doing real work. Trivial patches are like that.
You should! One of the biggest challenges for any open source project is to figure out how to become multi-generational and turnover-proof, instead of fizzling out when the initial developer generation moves on. There are a lot of lessons to learn about organization and governance to get to that point, and about how to recruit and imbue newcomers with a sense of shared responsibility and emancipate them to step up and take on that responsibility.
I used to process many of the developer access rights requests for the KDE community for some time and wrote a few of the documents regulating that process, along with baking some of the things we learned into the KDE Manifesto. It took us a lot of thinking about the trust mechanics involved and has definitely been among the most rewarding things I've done in FOSS so far. And I'm really happy we've consistently been one of the largest organizations to participate in things like GSoC and Code-In (in number of students) and try to do a lot of mentoring in general.
Is it just me or is the main reason this is being upvoted so much is because Linus said something without a bad attitude? This isn't a rhetorical question, I honestly want to know.
Although I'm not a kernel developer, I strongly suspect that Linus' common reputation is driven by cherry-picking his nastiest rants and then exposing only those to the vast majority of current developers hanging out social channels who will never in their career look at kernel source code.
Someone commented (not sure it was on HN) that Feynman also cultivated a different, more "rough", image in public than he actually was in the real life.
For me, it's the generally pleasant and motivational post in itself.
Anything that can motivate people to contribute to FOSS and to make it less intimidating, I like.
I didn't know it was Linus Torvalds response until I went in and read it - so that had little impact on my decision to read it. But it certainly was a contributing factor to me upvoting it. It's insightful and a well chosen response regardless of who wrote it though.
Certainly a big part of the reason why I'm upvoting.
Every time I see a Linux rant making the rounds I think, "oh, what insult did he sling around this time?" It was nice for once to read something where he only insulted himself.
Pity that this is from 10 years ago. It would be nice to see more recent examples of this attitude from Linus.
you can look at the iOS 8.0.1 release as an example here based on the widespread reports [1] of issues following the "small patch". I think that is one reason why you are seeing the upvotes, and why I read the story.
I completely agree. The only thing that's topped getting a tiny patch of my own accepted (into pylibtiff) was someone getting me to put a python module I'd written* onto pypi. Both were great feelings, and it's extremely important to encourage such highs in new people contributing to open projects (Linux kernel or random bibtex editor alike.)
* the library was in fact just a python wrapper for some C++ code, but that's where leverage for the original author starts, in bindings.
This only works if you already have a virtual machine with a high quality model of the hardware you're trying to test the driver for. For core PC devices like VESA and SATA this is mostly OK (though you still have a high risk of introducing opposing bugs in the device model and the driver which cancel each other out, so it can't replace testing with real hardware entirely). But it won't scale to the huge range of drivers for more or less obscure hardware which the kernel has these days -- writing a device model is about as much work again as writing the device driver, maybe more, and often devices just don't have enough documentation to write an accurate model. Nor is it likely to identify regressions like "we accidentally reverted the fix for this hardware bug that only affects rev 0 SCSI adaptors from manufacturer X".
Yes, but you need the actual physical hardware to work with. It's completely impractical for the kernel to unit test drivers that work with hardware that most developers do not have access to.
Plus, no one wants to make a big helpful functional contribution only to be thrown away because they weren't aware of how the community operates. Small patches have a low risk as far as learning about how to contribute, even if the patch is rejected for whatever reason.
Though this seems somewhat obvious, it's nice to have it stated and validated by the leadership of one of the largest open source projects.