The biggest thing with small patches (2004)

I think this is great advice. While I&#x27;ve only contributed to a couple open source projects and haven&#x27;t lead my own large ones, I completely agree. There&#x27;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&#x27;re starting out.<p>Plus, no one wants to make a big helpful functional contribution only to be thrown away because they weren&#x27;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.<p>Though this seems somewhat obvious, it&#x27;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&#x27;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.

That makes a lot of sense. If I look at any project I&#x27;ve contributed to, it always started out with something small. Taking the time to make a small PR that makes a tiny improvement:<p>- shows you care about improving the project; you took the time to improve something small that others would ignore<p>- 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&#x27;t reply for 2 weeks. You wouldn&#x27;t want to spend a lot of effort just to find that out.<p>- gives you a chance to become familiar with the process, the tools, gain practice, and hopefully get rewarded with your change being accepted<p>For example, my first CL to Go was a trivial change:<p><a href="https://codereview.appspot.com/97280043/patch/40001/50001" rel="nofollow">https:&#x2F;&#x2F;codereview.appspot.com&#x2F;97280043&#x2F;patch&#x2F;40001&#x2F;50001</a><p>But without having done that (and having a good experience) I couldn&#x27;t have been working on more complicated changes like <a href="https://codereview.appspot.com/142360043/" rel="nofollow">https:&#x2F;&#x2F;codereview.appspot.com&#x2F;142360043&#x2F;</a> now.

Seems like it&#x27;s good to remind people every now and then that Linus is a human with empathy, since a lot of them really don&#x27;t understand the reasons for when he rants, and then start to draw conclusions.<p>On a related note, Theo de Raadt rants need far more attention than they currently get.

Small patches are the &quot;hello world&quot; of open source. They give you a chance to get familiar with and work through the contribution pipeline before you push something sizeable through.<p>There&#x27;s little useful about &quot;hello world&quot; <i>as a program</i>, but it ensures you&#x27;ve got your toolchain working correctly, which is a necessary precondition for doing real work. Trivial patches are like that.

Ten years later, how is the Linux kernel community doing in terms of cultivating new contributors?

Reminds me of Lawrence of Arabia. &quot;Big things have small beginnings&quot; I&#x27;ve contributed tiny bug fixes and the feeling was great. I did that, me.

That&#x27;s a good attitude. If I find myself heading an open source project, I&#x27;ll take that advice with me.

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&#x27;t a rhetorical question, I honestly want to know.

That, ladies and gentlemen, is how you grow a community.

I completely agree. The only thing that&#x27;s topped getting a tiny patch of my own accepted (into pylibtiff) was someone getting me to put a python module I&#x27;d written* onto pypi. Both were great feelings, and it&#x27;s extremely important to encourage such highs in new people contributing to open projects (Linux kernel or random bibtex editor alike.)<p>* the library was in fact just a python wrapper for some C++ code, but that&#x27;s where leverage for the original author starts, in bindings.

Woah, mentoring Linus had a good day!

You need good set of unit tests if you want to survive managing open-source project.