Home How To Avoid The Community Of Open Source Jerks

How To Avoid The Community Of Open Source Jerks

Open source is the new default for many areas of software. But open source is different, and that’s causing some problems for newbies. While some reduce open source to “free software I can download,” open source can be much more. 

To get the most from open-source software, companies and other big organizations must be willing to engage in the projects important to them. This can be a prickly affair, given how unwelcoming some communities can be. And yet, as Bert Hubert highlights, “community is the best predictor of the future of a project.” 

See also: How To Get Started In Open Source

Strong communities build strong software. But finding your way into a community that will welcome not just your adoption but also your contributions can be tricky. Here’s how.

Learning From Linux

First of all, it’s critical to find an open-source project with momentum behind it. But just because a community is large doesn’t mean it’s where you want to set up shop.

 Take Linux, for example. Linus Torvalds, who first released Linux over a decade ago, admits to making a “metric s–tload” of community mistakes in that time. Like, for instance, telling this developer that “*YOU* are full of bulls–t.” Or castigating Red Hat for “adding stupid code to the kernel only to encourage stupidities in other people.”

But it’s not just Torvalds. Other project maintainers can be equally caustic, or merely unwelcoming to would-be contributors. Others, like Docker, have occasional missteps where adversity reveals an undercurrent of antagonism toward community members that don’t fall in line with the project leader’s chosen path.

See also: Want To Start An Open-Source Project? Here’s How

These may be projects where you want to be a net consumer. But there should be other projects where you do more than download and actually give back to the community, thereby helping it to grow.

Your Community Mileage May Vary

To be successful, you need to learn the nuance of how a particular project operates. Linux, for example, is not one community. It is many. So what works for one subsystem won’t work for another.

For example, Greg Kroah-Hartman,  Linux kernel maintainer for the -stable branch, the staging subsystem, and other areas, was asked whether newbies should “make patches to correct superficial things like whitespace, comments, etc.” 

His response? It depends. 

Other subsystem maintainers consider whitespace and spelling fixes to be a waste of their time, and it is, as they don’t want to deal with that type of stuff. So don’t do whitespace fixes for their subsystems, do it in the areas of the kernel where it is encouraged and common. A specific example of that is the drivers/staging/ area of the kernel, I maintain that part and want you to send in whitespace fixes as I know it is a way to get people involved and that is what I want to encourage and do.

Kroah-Hartman wants to encourage new developers. Others do not. Picking the right community to match not only your interests, but also your pain tolerance, becomes critical. 

Learn Your Community

It’s also critical to follow the community before diving in. Even the most welcoming of project leaders will not appreciate someone making a lot of noise without first making the efforts to learn the rules of engagement for that particular community.

That’s always good practice, but in some communities it’s imperative. Take, for example, project lead Howard Chu’s recent message to would-be contributors on the OpenLDAP project:

If you post to this list and your message is deemed off-topic or insufficiently researched, you *will* be chided, mocked, and denigrated. There *is* such a thing as a stupid question. If you don’t read what’s in front of you, if you ignore the list charter, or the text of the welcome message that is sent to every new subscriber, you will be publicly mocked and made unwelcome.”

Chu’s comment leads Hubert to conclude, “Before picking a technology to depend on, investigate how they deal with feature requests, bug reports and questions.” Why? Because “what you will learn is the best predictor of how the project will serve you (and vice versa!) over the coming years.”

In short, not only do you want to piggyback on a solid community, but if you’re going to contribute to that project, you want to make sure it feels like home. If it doesn’t, you need to find a different project. Because ultimately, open source is all about community, not merely code.

Lead photo by Sarah_Ackerman

About ReadWrite’s Editorial Process

The ReadWrite Editorial policy involves closely monitoring the tech industry for major developments, new product launches, AI breakthroughs, video game releases and other newsworthy events. Editors assign relevant stories to staff writers or freelance contributors with expertise in each particular topic area. Before publication, articles go through a rigorous round of editing for accuracy, clarity, and to ensure adherence to ReadWrite's style guidelines.

Get the biggest tech headlines of the day delivered to your inbox

    By signing up, you agree to our Terms and Privacy Policy. Unsubscribe anytime.

    Tech News

    Explore the latest in tech with our Tech News. We cut through the noise for concise, relevant updates, keeping you informed about the rapidly evolving tech landscape with curated content that separates signal from noise.

    In-Depth Tech Stories

    Explore tech impact in In-Depth Stories. Narrative data journalism offers comprehensive analyses, revealing stories behind data. Understand industry trends for a deeper perspective on tech's intricate relationships with society.

    Expert Reviews

    Empower decisions with Expert Reviews, merging industry expertise and insightful analysis. Delve into tech intricacies, get the best deals, and stay ahead with our trustworthy guide to navigating the ever-changing tech market.