Not every open source project lead agrees with Rich Felker, founder of the Musl project. Felker puts a premium on users of Musl, even more than those that contribute code: “The users, the testers, the adopters, the bug reporters [are] so much more valuable than writing any code.”
But do not misunderstand him. Felker adds that even users who contribute back no code or bug fixes, or anything at all, are still valuable. That is because they create demand that pushes other software to interoperate and may fix interoperability with other software even if we never see it.
This makes intuitive sense, but it is not the whole story on open source contributions. Nor, to be fair, is it Felker’s entire argument.
For other project leads, for example, users who complain without offering fixes are a time sink. Users who offer fixes for their problems, they are golden, as Jens Axboe, founder of the Fio project, said: “I love testers, if they can also provide fixes. I don’t want what amounts to a pure QA team that just files bug reports, that’s too much for me to deal with, and even for the regular contributors of the project.”
So what kind of open source contributors are best? As with much in life, the answer is… “it depends.”
Lots of users, lots of good?
It is hard to argue that having lots of users of your software is a bad thing. It is what gets the world to take the project seriously, right?
For a project founder, however, “lots of users” may not be the goal. And it can prove to be a poison chalice of sorts.
Just ask Jens Axboe, founder of the Fio project, the industry standard for modeling nearly any storage workload. “Just having users by itself doesn’t mean anything to me,” he says. “I wrote something for myself that I found useful, and just shared that with the world. I’m not in it for having tons of users, as I think that metric is useless by itself. It’s a nice side effect, but I’d put that very low on my list.”
So what is a higher-order contribution? Well, code, says Axboe.
Some projects actually eschew external contributions. For Roy Rubin, founder of Magento, the project was built in tandem with his company, and he worried that inviting outside contributions to the core of Magento would make it harder to support for customers.
“If I can’t guarantee them a quality product in a reasonable timeline and control that, then it’s going to be very hard for me to market this as a commercial solution,” Rubin says. Instead of encouraging contributions to the core, Rubin architected Magento to make it really easy to contribute extensions or add-on functionality, and a booming industry of third-party developers grew up around Magento to complement that core.
Making code a conversation
For those who do want code contributions, “want” and “get” can be hard to reconcile. According to Salvatore Sanfilippo, creator of Redis, it can be tough to find people capable of committing code. “You tend to get serious contributions only from folks that are paid to write such contributions most of the time,” he says. It is hard to get deep into a project without full-time commitment.
When your users become contributors, however, it is magical. As Gerald Combs, founder of the Wireshark project, tells it, one of the things that has made the Wireshark community so robust is that users tend to be developers who can contribute. “It’s an easy thing to take your knowledge about a protocol, and then write a detector for Wireshark, and that’s contributed to the growth of our capabilities as far as analysing different protocols. But it has also helped the project itself grow.”
Code contributors also make a project that much more social. If you are stuck on the idea of the lonely hacker, munching pizza and code in the privacy of her parents’ basement, it might be time for an upgrade. As Sanfilippo puts it, “I’m convinced that software is a human process and needs people telling stories. Stories to market the project, but also just stories as communication between people.” Open source developers are a social lot, one reason that GitHub just capitalised on this proclivity with the introduction of GitHub Discussions to facilitate conversations around code.
But just to show, yet again, how differently projects can be run, Bert Hubert, founder of PowerDNS, says that their community has consciously chosen to use IRC rather than the easier-to-use Slack for communication. Why? Because “it’s a little bit of a barrier to entry… [and] takes a little bit of effort to join us and that does filter out a lot of lazy people.” You want to contribute? Step up!
However the community chooses to chat, take away the conversation through code, says Daniel Stenberg, founder of Curl, and open source becomes much less interesting.
“It’s really the [code] contributors that make up the best part of the community for me,” Stenberg says. “They are the team I hang out with and communicate with, bounce ideas with and try out things against in order to figure out where to go next and how to fix the most complicated things. It would be a lonelier place with ‘only users.’ I wouldn’t like that. It would make me get bored quickly.”
OK, so code contributors are good, for a variety of reasons. But how can a project get more of them?
Making contributions too easy
From the beginning of the open source movement, it has been a foundational principle that modularity invites code contributions. Ask Combs, for example, and he says the ease of “drive-by contributions” enriches Wireshark.
“Our drive-bys usually come in the form of a new or updated protocol dissector,” Combs says. “Each new dissector makes Wireshark incrementally more useful and grows our community a bit, which means more useful feedback for long-term developers.”
So making it simple to contribute is good, right? Well, yes… usually.
Even Rouault, lead maintainer on the GDAL project, sees both good and bad with such contributions. GDAL, Rouault says, “is quite modular… allow[ing] unfamiliar contributors to focus on their need without worrying about GDAL’s entirety.”
This has helped the project to attract lots of support for over 250 file formats, but it has also created problems. Roualt explains: “By enabling high velocity contribution without massive time investment, [our] ability 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, has been limited.”
Which brings us back to where we began: The value of a particular kind of open source contribution depends upon the project and its community. What all projects seem to seek as a way of encouraging more contributions is better documentation. It turns out that the qualities that make someone a great software developer do not necessarily make them a great writer.
But that is a different post.
IDG News Service
Ltd
