How open source -

[ad_1]

Commentary: Open source isn’t really about kumbaya, but does that necessarily mean it needs to stress out project leads?

Table of Contents

How to Remove Weather From Taskbar?

How many beers in a keg? Also Learn About Different Types Of Kegs

burnout — Image: Getty Images/iStockphoto

There’s how open source is “supposed to” work, and how it actually works. The “supposed to” involves “rainbows and butterflies, with everybody working together in harmony,” as OBS (Open Broadcaster Software) project founder and maintainer, Hugh “Jim” Bailey, said when I interviewed him. But the reality is, “People only contribute stuff that’s useful for them, almost exclusively,” as he went on to relate. Not open source for the good of all–open source for the good of one.

Sure, there’s some Adam Smith “invisible hand” in play here, with everyone looking out for their own self-interest and thereby improving code for all. But the burden of making this philosophical principle actually play out in practice requires a fair amount of work from a project maintainer.

SEE: How to build a successful developer career (free PDF) (TechRepublic)

Selfishness is a feature, not a bug

As Linux kernel maintainer Greg Kroah-Hartman has said, “Everybody contributes to Linux in a very selfish manner because [they] want to solve a problem for [them].” This isn’t a problem, he went on, but rather a Very Good Thing because “it turns out everyone has the same problems.”

In general, he’s correct. But not always.

For example, it’s awesome that Apple announced at its Worldwide Developers Conference (WWDC) that it would be contributing code to a slew of open source projects like Redis and nginx and Blender. But those contributions aren’t to make Redis generally better, for example–it’s just to add support for Apple’s new ARM-based chips. Many will benefit from this, but it’s not an altruistic contribution.

The same is true of contributions to GDAL, an omnipresent open source geographic information system (GIS) that is found in Google Earth, Uber’s mapping technology, and more. As project lead Even Rouault said when I interviewed him, organizations tend to contribute specific drivers for the format or remote service that ties into their own products (or country). Such contributions help to make the project incrementally more useful for a wider group of people, but they don’t directly sustain the core upstream project.

Bailey concurred:

I expected open source to be like rainbows and butterflies, with everybody working together in harmony, like, ‘Oh, this is open source. I’ve got this great code. Here you go.’ But it’s not like that. People only contribute stuff that’s useful for them, almost exclusively. They usually don’t contribute code that is useful to everybody, though sometimes they do. Sometimes people are trying to improve the project, but most of the time, maybe 80% of the time, whenever you get a pull request for something, a request to merge code, it’s almost always [for their narrow self-interest].

It turns out that this can be a major burden for the maintainer.

Burning out on others’ open source contributions

As Google Cloud engineer Tim Hockin colorfully described it, “I call this ‘pooping in someone else’s yard’. Show up, drop off some … stuff … and disappear, leaving them to clean up the mess when they inevitably step in it. Fairly common in OSS.” That “clean up” has led to “many times where I’ve been burned out and I just need to take a week or two off. It’s been happening too much.”

Whence the burnout?

Well, such self-interested, sporadic code contributions often aren’t particularly high-quality or tuned to the project, said Bailey: “It can be very difficult to review people’s code, because you want everything to be consistent in your project. There’s a lot of bad code that people try to contribute.”

SEE: 10 ways to prevent developer burnout (free PDF) (TechRepublic)

Of course there’s also good code (particularly from regular contributors), but what does Bailey do to improve incoming code? “I try to communicate with them first. I try to understand what they’re trying to do. If it’s something that can’t be reconciled, then I just have to tell them, ‘I’m sorry, you wrote this for yourself, and this just isn’t going to benefit most users.'” However, if the code is bad, but the idea/feature is good, he’ll try to work with them (and sometimes will just fix the code himself). But it’s always time-intensive. “It could burn you out really, really easily,” he said.

So, yes, open source is about self-interest, and the contributions people are making to Kubernetes and Linux and Envoy are always reflective of the personal (and corporate) interests of the developers involved. Sometimes, to Kroah-Hartman’s point, this can result in the good of the project. But just as often it can lead to burnout among project maintainers.

Disclosure: I work for AWS, but the views here are mine and don’t necessarily reflect those of AWS.