Open Source Builders: An Inside Look

Amazon Web Services (AWS) sponsored this post.

There are tens of millions of open source projects scattered across GitHub, GitLab and other repositories, yet most people would struggle to name ten. Among tech circles, we might do better (Linux, Kubernetes, MySQL, um…), but very few would rattle off cURL, Wireshark, fio, Matplotlib, GDAL, or PowerDNS — despite the fact that millions, maybe even billions, of people depend upon these and other similarly unheralded, but widely used, projects.

So let’s do something about that. Let’s name some names.

Over a series of posts, let’s shine a spotlight on an array of open source projects (and their founders and/or lead maintainers) that quietly serve behind-the-scenes. In the process, I hope that we’ll gain insight into both why and how these critically important projects have managed to thrive for so long. This, in turn, just might provide useful information on how best to sustain open source projects.

But wait! There’s more…

What Kind of Contributions Count?

In talking with a number of such project founders and leads, it’s been surprising to see the different perspectives they bring to open source contributions. Musl founder Rich Felker, for example, believes that “the users, the testers, the adopters, the bug reporters [are] so much more valuable than writing any code.” After all, given enough users of a particular project, other software products or projects are forced to interoperate well — which, of course, creates value for the original project’s users, in addition to the integrating software.

By contrast Jens Axboe, founder of the fio project, argues that users who are capable of contributing code, and do so, are the best contributors. “They send in a patch (or patches), fixing issues they ran into, or adding [a] feature that they need. Love these users!”

Meanwhile, Gerald Combs, founder of Wireshark, highlights the usefulness of so-called “drive-by contributions” from users of the software. “Our drive-bys usually come in the form of a new or updated protocol dissector. Each new dissector makes Wireshark incrementally more useful and grows our community a bit, which means more useful feedback for long-term developers.”

But Even Rouault, lead maintainer on the Geospatial Data Abstraction Library (GDAL) project, stresses that drive-by contributions have a downside: developers make changes to the parts of the code that matter to them and then leave, making it hard to “build up a cadre of sticky core contributors to help for bug triaging, fixing, issuing releases, reviewing pull requests, ensuring continuous integration keeps running, and all the other countless maintenance tasks.”

These developers aren’t really disputing each other’s points, but rather pointing to the complexities inherent in open source software development. While there are general principles that more-or-less apply across open source, there are also particulars that may apply to a certain kind of project (say, a complex database project), but not to others.

In the trenches

In this series, we’ll dig into such diverse perspectives, while also trying to surface meta themes. As we go, I hope you’ll appreciate the impressive work these open source builders have done, in some cases for decades — generally without much recognition and often for free. In every case, they say they do it because it’s fun. Let’s find out why.

Visit the AWS Open Source Blog to learn how open source projects can apply for AWS promotional credits.

Feature image via Pixabay.