The biggest thing with small patches (2004)

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…

Obv. feel the same way, which is why I started being the trivial patch monkey which Linus refers to. That's long ago been handed over, but I like to think that it did expand the developer base. Not just for Linux, but for FOSS generally.

I feel the same was as Linus, which is why I started the Trivial Patch Monkey (and hence my mention in this post). Note that it's still going, as mentioned in MAINTAINERS: TRIVIAL PATCHES M: Jiri Kosina <[email protected]> T: git git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial.git S: Maintained K: ^Subject:.*(?i)trivial

Software longevity is something that I have bene thinking about for a little bit. At $dayjob, we use Openstack, an open source cloud infrastructure project. It's a pretty complicated set of projects that interact to each other in order to provide multi-tenancy for virtual machines at scale. It was initially all the rage, before the cloud starting really picking up steam. So now, you have a massive project that is slowly losing traction, but also relying on that notoriety to…