This article is mostly a story about my attempt at getting new contributors involved in the glibc project, a summary of what I learned along the way, and an encouragement to contribute if you're on the fence.
My entire stint at Red Hat has been focused around glibc and its Fedora and RHEL packages, and my upstream contributions reflect that. I started off years ago with changes to the upstream testsuite. I slowly built from there, having fixed various bugs, overhauled a couple of features, discovered and fixed security flaws, and reviewed patches by now -- with hopefully more work to come as opportunities arise.
Obviously, while it's nice to "fix a deadlock in a POSIX interface implementation" as part of my day job, I feel that even seemingly small or minor contributions are valuable. FOSS means that everyone stands to benefit from every useful change. For example, every new memory allocator test can help ensure the continued quality/correctness of that subsystem and strengthen the guarantee that trillions of 'malloc' calls executed every hour on Linux systems around the world will continue to work as expected. Every user, whether or not a Red Hat customer stands to benefit. This is why it's important to make sure that projects like this continue to thrive and regularly attract new contributors to replace the (very natural and understandable) attrition.
The glibc community is fairly active, but an in-depth look at the commit log for the last decade (2013-2022; I skipped 2023 and 2024 because measuring attrition gets a bit inaccurate when you don't allow enough time for contributors to make another commit) shows me that we average an attrition of around 48 contributors each year, with around 46 new contributors replacing them. The number of commits made each year also appears to be in a very slight downtrend. While I wasn't really looking at these numbers in the past, the data seems to indicate a trend that the community should try to reverse.
Last summer, I got the idea of attempting to do some outreach for glibc in my head. I wanted to see if I can give a talk about contributing to glibc, and perhaps winning a new contributor for the community. Talk about a force multiplier! I submitted and gave a talk at DevConf CZ, the local annual FOSS conference in Brno, Czech Republic where I live. I titled it "Seven Easy Steps to Your First glibc Patch", hoping that the clickbait title will get me a reasonably sized audience. The talk initially felt like a success. I got multiple questions mid-talk and had discussions outside the hall with some interested attendees. But after a couple of emails and LinkedIn connections, I realized that there would be no new patches coming out of it. I spoke about this with seniors on my team and they reassured me that it's okay and that despite no new contributions, there's value in having done that talk. So I made a mental note to try again a year later and went back to regular stuff.
Eventually, Spring rolled around again and DevConf CZ was inviting new talk submissions for this year's edition and of course I applied. This time, I wanted to do a workshop aimed at getting your first patch into glibc. I wanted to show up with multiple small improvement ideas with limited and clear scope. Something that will actually convert to patches. At one of the weekly glibc patch review meetings (yeah! We have those), I asked some of the other developers for ideas, and one of the suggestions I got was to look for interfaces that go untested during "make check". I rolled with it, and with the help of a couple of objdump/sed incantations, I was able to come up with some specific ideas for patches of various difficulty levels, all around testing. This time, the workshop was actually a success. I handed out roughly twenty tasks and I got four actual patch submissions out of the workshop, each of them from a new first-time contributor. I know of at least one more patch that's in progress. Obviously, there's no telling if any of the new contributors will end up joining to community, but the easier it gets for new contributors to get their first patch in, the higher the chances of one that might end up staying and becoming a part of the community for good. Either way, I hope I did my part in trying to reverse contributor attrition for 2024. If DevConf allows it or if I get a chance to do the same workshop again somewhere else next year, I intend to do so again.
In the meanwhile, if any of this excites you, consider contributing! The easiest start would be to write to libc-help@sourceware.org indicating your interest in contributing, and one of the regular contributors could help you find an idea to work on. If you don't want to start off on a public mailing list, you're also welcome to write to me separately. You'll find my email address in glibc's commit logs. I'm curious to know if this blog post will convert to a patch or two.
