
The biggest thing with small patches (2004) - ohmygeek
https://lkml.org/lkml/2004/12/20/255
======
doughj3
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.

------
efuquen
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.

~~~
chimeracoder
> 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.

[0]
[https://en.wikipedia.org/wiki/Enron_Corpus](https://en.wikipedia.org/wiki/Enron_Corpus)

~~~
autarch
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.

~~~
ivanca
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.

~~~
codingdave
You've turned the logic around. The statement being made is more like: "It
isn't OK to be a prick just because you created a major advance in tech."

------
shurcooL
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:

[https://codereview.appspot.com/97280043/patch/40001/50001](https://codereview.appspot.com/97280043/patch/40001/50001)

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/](https://codereview.appspot.com/142360043/)
now.

------
vezzy-fnord
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.

~~~
SEJeff
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 :)

------
munificent
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.

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

~~~
dankohn1
Better than any other open source project. Linux is, I believe, second to
Wikipedia as the largest collaborative project in the history of the world.

(Although, unfortunately, they hide the report behind an email wall, so here's
a summary.)

[http://www.zdnet.com/who-writes-linux-
almost-10000-developer...](http://www.zdnet.com/who-writes-linux-
almost-10000-developers-7000020717/)

------
post_break
Reminds me of Lawrence of Arabia. "Big things have small beginnings" I've
contributed tiny bug fixes and the feeling was great. I did that, me.

------
GhotiFish
That's a good attitude. If I find myself heading an open source project, I'll
take that advice with me.

~~~
sho_hn
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.

------
JacobEdelman
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.

~~~
dasil003
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.

~~~
asgard1024
I think, to some extent, Linus cultivates this image himself. Reminds me of
Richard Feynman threads here on HN:
[https://news.ycombinator.com/item?id=8030010](https://news.ycombinator.com/item?id=8030010)

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.

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

------
tehwalrus
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.

------
mwfogleman
Woah, mentoring Linus had a good day!

~~~
serve_yay
Yes, this ended up in an unexpected place.

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

~~~
kasbah
How would you unit test device drivers?

~~~
qwerta
Virtual machines...

~~~
ayrx
You may want to rethink your statement. How are virtual machines going to help
in unit testing drivers that work with real hardware?

~~~
qwerta
You sound like my old boss :-) I used VMs to develop USB drivers with great
success.

At my university we wrote basic operating system, VESA and SATA drivers were
mostly developed using VMWare.

And it is possible to connect PCIe devices to VMs, but it requires lot of
work.

~~~
pm215
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".

