Open Source, Tech, and Tribalism

The open source community can be a turbulent place, and this turbulence often plays out in public. Periodically, people leave a community, and when they do, the swirling drama can be fun or bemusing from a distance. The “Why I’m leaving community X” blog post from a prominent Community X member is common enough to qualify as its coming-of-age milestone.

But recently, as I found myself and people I care about involved in one of these situations, I no longer had that bemused objectivity. Wait a minute, Community X is my community, and it was being harmed. I felt personally attacked. I watched others become defensive, which seemed to justify my own feelings.

As I started seeing lines being drawn, I realized that my reaction over someone deciding not to use a thing that I use was putting relationships at risk.

I had to stop and do some personal soul-searching around this topic, so I’ll try to be sensitive to the fact that others may, like me, have their identities wrapped up in the various communities and tribes they belong to. This is tribalism. It’s perfectly normal, but it’s crucial to understand, and I don’t think it gets its due when talking about open source.

A person could create a college-level course defining and exploring tribalism. For the sake of definition, I’ll leave it at this: Tribalism is the act of attaching one’s own identity to a shared group identity.

And it’s a tough one to fight: as a pre-programmed default, tribalism was key to the survival of the human species for hundreds of thousands of years. 

Coalitions, communities, tribes, and cults: a spectrum

Let’s call this the identity spectrum: the degree to which one’s identity is subsumed by the shared identity of their affiliation with a group.

Coalitions are, essentially, “frienemies”. A federated group of people, in Ayn Randian self interest, unite to achieve some common goal.

Communities are also loosely united by a common goal, but often act in the group interest above self-interest.

Tribes are communities that are bound by a shared identity as members.

Cults are a tribe that shun all identity except as a member of the tribe.

The tribe of open source

It’s easy to spot an open source developer from across a crowded room, as we usually broadcast our preferences. Borrowed perhaps from skateboarders, we wallpaper our laptops in stickers representing our interests. Everything’s fair game: Products we use, technologies we love, perhaps even our favorite My Little Pony character.

This was a big deal for me.

I’ve felt like an outsider for pretty much my entire life. Even my other “tribes” (professional, religious, etc.) never really fit me quite right, until, at 30 years old, I discovered a new sense of inclusion and belonging in the software community.

Like most tribal affiliations, I got some amazing benefits: lasting friendships, support, and a sense of purpose outside oneself. As a new developer I was welcomed, guided, mentored, and offered opportunities in a way entirely new to me.

And thanks to the network of open source developers on Twitter and elsewhere, I now know hundreds of wonderful people in cities around the world who share many of my interests, passions, and values. I can visit a conference on the other side of the country and be welcomed as if I was a longtime neighbor. It’s amazing stuff, and it deepens my faith in humanity every time I experience it.

And I should take a moment to note that I do not have the GitHub profile of a prolific open-source contributor. GitHub is not my CV.

I have my own ways of helping: writing, organizing, hiring, etc., and no one has yet stopped me to tell me I’m a fraud and kick me out of the community. In open source, your best is good enough. (Perhaps that’s just until you manage a popular project, but that’s another post.)

Tribal affiliation as a shortcut

The tribes I belong to offer some great shortcuts in describing myself to people: Rubyist, Javascript programmer, Embereño, Mormon(ish), Beatles fan.

These are great for allowing someone a small insight into my activities and interests. A shared interest in Javascript development means I’m probably game for interesting conversations on the subject. Knowing I’m Mormon lets people know I’m a pretty good bet as a designated driver.

But if I’m not careful, it can be easy to slide toward the right side of the spectrum, and start letting these shortcuts define who I am.

Bad tribal habits

If we’re not aware, we often fall into habits programmed into our brains from thousands of years before we were born. Here are some common net-negative tribal behaviors:

Blind evangelism: A sense that your tribe’s cause is a one-size-fits-all solution, and that the entire world would be best served by relentless evangelism until they join.

This allows you to feel confirmed in your belief, but it erodes empathy for the desires and needs of others.

Buying into one ecosystem: Have you ever been to the home of an Amway family (or lived in one, as I did)? All of their products are Amway. Is Amway shampoo the best? Their detergent? Eyeliner? It doesn’t matter, because the Amway families are so financially locked into the system it doesn’t make sense for them to buy anything else. (But if you ask an Amway family, yes, the Amway everything is the best.)

Using Windows makes me physically ill. Is Windows really that terrible? Or am I conditioned to think that Windows is terrible because I’ve spent a decade building an Apple fortress? Either way, counting business expenses, I fork over the cost of a decent car, every year, on Apple products.

Narcissism of small differences: Few things divide tribes more sharply than being ideological next-door neighbors.

It pains me greatly when I see communities (in religion and in technology… but I repeat myself) who all want the same thing bicker incessantly about the right way to do it.

Burning the heretic: People who speak against a tribe are often vilified. And you’ll rarely see as vitriolic a reaction as when a person leaves a tribe. And if they don’t have the decency to go quietly, they receive ten times the furor, thus justifying their decision to leave.

It’s enormously satisfying to burn the heretic. When someone leaves the tribe, they’ve just questioned our collective identity. Our rightness. Our specialness. The natural reaction is to fight back, and invalidate that person and their obviously wrong opinions.

But know this: Every time you defend a tribal identity, you sacrifice a little more of your own. And a tribal identity is incredibly fragile, encouraging defensiveness and fear.

Cult behavior: when tribalism turns evil

What’s ironic is that people who are opposed to a given tribe are themselves defined by tribalism. In fact, the notion of “enemies” pretty much only exists at the tribe/cult end of the spectrum.

For example, consider the childish, abhorrent behavior of those within the “Gamergate” pseudo-movement. It’s a form of tribalism carried to the “cult” extreme. They’ve spent so much energy defending an inherited group identity that their individual identities are completely subsumed.

This invites the mental laziness of stereotyping those outside your tribe, dehumanizing them to the point where violence becomes a natural-seeming option. Opposing, heretical voices so threaten the fragile identities of the group members that the offenders must be silenced.

It’s a textbook example of the danger and potential dark side in allowing a group identity to become your only identity.

Taking back your identity: a self-check

After all this, you might think I’d warn away from tribes and tribalism, but that’s not my point. The trick is simply owning your own identity.

Personally, I don’t enjoy coalitions. I have friends who say “get over it, these are just tools you use to make money”, and that’s great for them, but I like communities. I even like tribes, when I’m on guard against my biases. Cults, though… I’ve had enough of those for one lifetime.

Whatever your personal preference, my request, my plea, is this: be aware. Keep some self-check questions at the back of your mind:

Do you define yourself by your job? It’s easy to catch oneself saying “I’m Prestigious Title X at Recognized Company Y”. Or “I’m the creator of Cool Thing Z.” It’s incredibly tempting to lead with this stuff when talking (or thinking) about yourself.

Does your social media profile offer any hints? When given 140 characters to describe yourself, what do you say? “Cat expert, sandwich artist, alligator hunter”? I mean, that’s super cool, but are you 100% sure that’s who you are?

Do you perhaps feel like you are enlightened in a way that others aren’t? A good test of this is how much of your time you spend evangelizing the things you like vs. listening to things others like.

How do you react when someone leaves the tribe? Do you write them off? Get mad at them? Gossip about what a huge mistake they’re making?

These are your cognitive biases. It’s OK! They’re helpful in daily life. But becoming aware of them, while painful, is crucial. Every bias you recognize, acknowledge, and work to compensate for allows you to reclaim more of your individual identity.

What owning your identity buys you

As you internalize more of your own identity, it becomes less fragile, and you’ll find the freedom to enjoy the benefits of participating in communities and tribes without the same drawbacks. It increases your “cult resistance”, lowering your susceptibility to manipulation by sociopaths, which is pretty handy in the workplace.

You’ll be able to manage and maintain cross-community relationships, which often has a positive effect on all sides. You may even find yourself as an influence for good, helping focus community efforts away from tribal wars, and toward shared purpose and inclusion.

This is far from a complete formula, but separating personal from tribal identity is a crucial step in truly being yourself, which, as far as I can tell, is a key ingredient in living a happy, regret-free life.

A few cautions on open source and tribalism

If you think it’s all about the code, you are deeply and dangerously mistaken. Any person can write code, but participation in an open source community absolutely requires understanding and empathy around basic human behaviors. If you can’t accept that responsibility, prepare for a pretty lonely and frustrating road. Ignoring this means you’re likely to run roughshod over the feelings of others and cause a lot of harm to people and your own community in the process.

When you’re part of a community, you’re an ambassador. Your responsibility is to embody the kind of community you’d like to see, because those are the people you’ll inevitably attract to join you. It doesn’t matter whether you like it or not, or whether you go on TV to say “I’m not a role model,” every public interaction you have is someone else’s window into your community.

When someone leaves your community, they’re not betraying anyone. People’s interests change. Their preferences change. They may even take occasion to vent frustration with your own community, tools, or ecosystem. That’s OK too. Related: if people defect from another community to your community, it’d be wise to let them know that disparaging their previous community is poor ambassadorship for their new community.

Get out of your bubble. I spent my first few years as a Rubyist feeling a sense of superiority to PHP developers, despite never having written a line of PHP. Now I’ve interacted with so many communities that I have a deep and abiding respect for anyone who builds things in the toolset of their preference.

Cross-community competition is less valuable than cross-community pollination. In free-flowing ecosystems, you get the benefit of people taking the best of a different community and trying to bring it to the new community. Tribes that prefer the “way we’ve always done things” miss out on these improvements.

And lastly, a piece of advice I received a few years ago:

Don’t yuck someone else’s yum. It can be unfathomable to me that someone would use some outdated, obtuse, or clearly-inferior technology to get their jobs done. If they’re doing it with a smile on their face, trying to make them realize how wrong they are is petty, egotistical, and unkind. I’m as guilty of this as anyone I know, and have worked to add “don’t yuck someone else’s yum” as a mantra for myself.

I haven’t yet seen an argument about tribalism that wasn’t also an argument against it. I hope this helps make a little bit of a case for the value of hopping into a shared culture and identity with people, just so long as you know who’s in charge of your own.

Getting newbies involved in open source

Newbies: Play your cards right, and this could be you

I’d never expected much response from my last blog post, much less the overwhelming one it received. From following up on the comments alone, I’ve learned more about open source in the last couple of weeks than in the 2 years since I started coding. If you left a comment here or on HN, please trust that it was read and left an impression on me, and I thank you.

Here’s the gist of what I’ve been digging into since then, after dozens of hours of research, writing, and notes inspired by responses to that article.

It’s broken up into 2 parts:

1.) Getting newcomers involved

2.) How newbies can get started

While the emphasis changes, I believe there’s something of value for both maintainers and contributors in both sections.

Part 1: Let’s get newcomers involved in open source

 

“It’s the small things that count”

Some of the responses to my last post literally said “Get over yourself.” While that’s good advice, the fact that so many others came out as “OSS wallflowers” means that there’s room for improvement in our communities.

The loss of newcomers in OSS really is “death by a thousand cuts”. I can’t really describe to you how many times I’ve nearly given up, persevered, and then finally just quit on a project due to the cumulative friction of trying to pitch in. Besides my prior points, here are a few other places I think people get stuck:

Ugly, painful-to-use mailing lists – So many projects have a barebones mailing list that requires constant monitoring and/or huge amounts of work to pick through to find something relevant. Ugh. Google Groups is a godsend. If you don’t trust Google, you should realize it’s the minimum standard for mailing lists: Mailing list technology from 1996 doesn’t cut it; you’ll need to have forum-like organization for the archives.

IRC – You’ll be surprised how many newcomers don’t realize IRC still exists. Now that I know IRC, I absolutely love it… but don’t assume people know what it is or how to access it.

Jargon – What the hell is “diff and patch”? Is that like “clone and commit” or “fork and submit pull request”? Don’t assume people know your lingo, you might want to put up a glossary. In fact, “help us build a glossary” might be a great way to get someone involved.

Rejection – When turning down a patch, remember to include the long view. It’s easy to say “that’s not how we decided to solve that problem”, but take an extra minute to suggest something that they may be able to do with what they learned during the process.

This is a bigger problem than I realized

The quote from the headline for the previous section is from a report by Karen Rustad that’s so good and well-researched, it makes my prior article completely irrelevant.

The same kinds of obstacles that keep newbies out of OSS also affect women and minorities. This is a huge problem, and one we need to deal with soon.

I know it’s long, but I beg of you, read her paper if you care at all about why there are so few newcomers, women, or minorities involved in open source software:

http://www.littlegreenriver.com/stuffs/Outreach-Diversity-FOSS.pdf

Does a solution even exist yet?

After writing my last article, I felt compelled to prove that I’m interested in solving the problem of the “open source obstacle course” (as Greg Brown so deftly put it). I wanted to build a simple site to connect newbies with maintainers & supporters of open-source projects that could break down a lot of these walls.

I was surprised to find that such a site already exists:

This sounded familiar:

“Free, open source software loses tons of prospective contributors because it is difficult to learn how and where you can fit in.

OpenHatch is an open source community aiming to help newcomers find their way into free software projects. We work toward this goal through this website and in-person outreach events.”

This was exactly what I was looking for. I’ve had several chances to speak with Asheesh Laroia, the maintainer of the OpenHatch project, and his passion is infectious. While I’ve been loudly complaining, he’s been quietly building, and I love him for it.

Right now, the focus is on larger-scale projects, and my beloved Ruby is quite poorly represented there. But that could change if just a few Ruby maintainers started adding their projects there (i.e. RubyDoc) and using it to recruit contributors.

OpenHatch isn’t perfect. I’d like to see more of a focus on helping me find a project whose purpose, needs, and support structure are a good match for my skills and interests. I’d also like to see less of a focus on specific bugs within projects (not to mention the use of the word “bug” to describe any kind of potential contribution).

But most of the ingredients are there to create something really great: a marketplace for project owners and contributors to court one another and start building amazing stuff together.

For my part, I’m going to be putting my effort into OpenHatch, because I believe in their vision and their community.

Have the conversation.

In digging into this, I was stunned to realize that this conversation is novel in the Ruby community, but has been going on for some time in the Python community.

I think much of this is due to to the fact that Jesse Noller, who seems to carry a lot of weight in the Python community, cares about checking in and having the community self-examine to find the points of friction for new people and trying to smooth them out.

That’s an example I think every OSS community ought to learn from.

Part 2: Help! I’m a newbie, where do I start?

 

Why contribute?

Many commenters frowned on “contribution for contribution’s sake”. That’s missing the point: there’s no such thing as “contribution’s sake”, there’s always a bigger “why”. Some will say you should never help unless you’re solving a problem you specifically have, but I disagree strongly with that notion. If that were the case, you’d never loan a neighbor a cup of sugar unless they were baking you a cake.

Yes, it’s important to pick a project you care to see implemented or improved, but if your motivations are largely to participate in the OSS ecosystem, I think that’s a perfectly reasonable place to start.

Big project or little project?

There are pros and cons to both. Big projects are intimidating, with lots of nooks and crannies, with their own lingo, and they often make “celebrities” of core contributors. To a newbie, this looks like a party that you won’t get invited to for a long, long time.

But if you can find a project that is geared toward supporting contributors, your best bet may actually be in trying to help document, test, or patch a big project. Most large projects (Ruby, Python, Mozilla, Debian, and many others) have groups dedicated to helping new contributors make an impact.

Smaller projects with a single maintainer might seem easier to break into, but these maintainers rarely have the bandwidth or knowledge to support contributors very well. Either way, look for a support structure that can help you dig out when you inevitably get stuck.This includes looking for some semblance of existing documentation, which sort of means a catch-22 for projects looking for documentation help.

“Start with documentation” may be an uphill battle.

It’s amazing how much you can learn about a technology by documenting it. It’s also amazing how much context you need to have in order to document a piece of software.

I’m extremely pleased that I’ve recently started contributing documentation to an open-source project, but I drastically underestimated the difficulty of “documentation”. This is not creative writing, it’s technical documentation that requires an understanding of the technology you’re writing about.

If you’re a newbie, and a project has essentially zero documentation, it’s not likely you’ll be of much help, unless there’s someone there who will walk you through the ins and outs of the project, at length, again and again, until you get it well enough to explain to others.

Don’t expect too much handholding

In the future, I believe we’ll have systems to help onboard newer developers, but for now, you are going to have to get out a machete and clear your own path much of the time.

A good rule of thumb is that if you haven’t spent at least a few minutes searching and trying to solve an issue yourself, don’t bug a maintainer about it. If you can’t get help from a maintainer even after trying to do a lot of that legwork yourself, you may want to start looking for another project to invest your efforts in.

A few projects you can help with right now

Ruby Mendicant University – Free, community-oriented Ruby education

There are many projects in need for RbMU, and if you’ve read my earlier posts (or have attended RailsConf) you know it’s a worthy cause.

ThinkUp – Social network aggregation

They tout “100% nice people” on their front page. It’s safe to say they value contributions.

RDoc – Help document Ruby

The incomparable Steve Klabnik has created a video and instructions on how you (who, me?) can help document the Ruby programming language.

BDSM – Bash shell scripting framework

Wayne E. Seguin is a machine sent from the future to be nice to developers and make their lives easier. You should check this project out for that reason alone, but he also gave me my first OSS commit, so YAY.

Sproutcore – Super-awesome “desktop app on the web” framework

Yehuda Katz posted the understatement of the decade: “Having contributed to a number of open source projects in the past…” They put together one of the best contribution pages I’ve seen.

Sadly, this guide would be VERY hard to find if Yehuda hadn’t linked to it directly:

http://blog.sproutcore.com/dispatch-from-the-edge-contributing-to-sproutcore/

Resources you didn’t even know you had (at least, if you’re like me)

Don’t know how to get started? Here are some things you can do:

Bugmash – The recent Rails Bugmash in Boulder, CO was wildly successful. Several people got their first-ever commit to the Rails codebase.

User Groups – If you have one in your area, go. If not, start one.

Hack Nights – Whether or not you have a project to bring, don’t be shy, show up and ask if you can pair with someone on an open source project.

Remote Pairing – Ask programmers via Twitter if they’ll pair with you on a project–many will say yes.

Talk to a maintainer – Use a mailing list or IRC to just chat with a maintainer of a project… you may find you have an ability to contribute beyond bugfixes.

Teach others – Creating tutorials or screencasts about a project you use is a great way to discover its ins and outs, as well as a great way to help, without writing a line of code.

Speak out! – It was amazing to see the number of people who feel or have felt like I did. Unexpectedly, writing about my fears and frustrations drew an outpouring of ideas (yes, and criticism) about specific ways I can start contributing, as well as offers for guidance.

Don’t be shy, your community is waiting for you

If you’re wanting to help with open source software but don’t know where to start, the most important thing to realize is that you’re not alone, and that others want to help you make an impact. While it’s nice to know where you’re going, the next best thing is to stop and ask for directions from the locals.

The process of doing so for me has been to realize that the best communities in Open Source foster a culture that is going to be supportive of you asking for help, which tells me that the community is probably deserving of your help. Then, you have an opportunity to help remove some of the roadblocks that scared you at first, and upward it spirals in a virtuous cycle.

Lastly,  OSS culture is great, but there’s not a lot of time taken to come back around and thank people for their work. I want to publicly thank Mike Moore and Jake Mallory, who tirelessly organize the Utah Ruby User Group meetings, as well as Greg, Jordan, and Jia (and my fellow students) from Ruby Mendicant University.

Each of those groups has dramatically impacted my life, and if you’re not participating in them (or something very similar), you’re missing some incredible opportunities.

OK, so maybe OSS is not a shark tank after all. Please do jump in, the water really is fine.

P.S. If you’re a maintainer and care as much as I do about this topic, please visit all the links in this article. They’re written by people much smarter than me, and I could only scratch the surface of the insight they contain.

Why I still don’t contribute to open source

Via zen on Flickr

I am such a hypocrite. A few months ago, I posted about overcoming my fear of contributing to open source software.

Since then, I still haven’t really participated. On Twitter, I commented that OSS looks like a shark tank to newbies, and I need to back that up.

The fact is, I actively contribute in some fashion or other in several open source projects. But I still feel very much like an outsider, as my contributions aren’t typically code-related.

So why am I (and I assume, many others) still an OSS wallflower?

At the profound risk of projecting my feelings onto other people, I would like to share some objections that I feel may cause new(ish) devs to shy away from contributing to open source software.

There’s no certification, ceremony, or merit badge that says, “you’re ready to contribute to OSS”. (Though there is one for afterwards.)

It’s not obvious where to start. From what I hear, a lot of OSS contribution comes because a person needs functionality in a piece of software that isn’t there, or finds a bug. They can submit a failing test case or even a patch. In my daily use, I don’t run into many of these situations. There aren’t many devs sticking their hands out asking specifically for help on a project, and fewer still who would be willing to take a newer developer under his or her wing.

Guidelines often make a maintainer’s life easier, and mine harder. Yes, maintaining an open-source project is an arduous, thankless task. But I’ve looked at contribution rules/guidelines that turn a simple idea for a fix into a bureaucratic brick wall worthy of Microsoft. A notable contradiction to this would be Wayne Seguin’s welcoming contribution page, complete with tutorial video.

Open source is for people who are better at this than me. I realize this is probably a copout for not shipping, but I am just not comfortable that I’m at a place where I could release software that’s good enough for actual developers to use.

Trying to contribute and failing makes me feel stupid. I’ve submitted several pull requests now and had 0 accepted with no comments as to why. It’s like the universe is confirming that yes, I am an idiot, and my “help” is not helpful. What a profoundly embarrassing waste of time!

There’s no time. I have a kid, a new gig, and a mounting set of responsibilities. It takes me 3-10 times the amount of time to write code as a more experienced developer. Now, my non-code-related contributions are now eating up my former “coding time”. Yes, it’s the universal excuse, and one that I think melts away when the other excuses are removed, but it bears mentioning.

It’s pretty lonely. I think most people figure this stuff out on their own, and so maybe expecting a hand to hold is too much. But is this really some spirit walk, where no one is allowed to accompany you, lest you learn nothing?

So yes, OSS can feel daunting, even like a shark tank. I don’t have all the answers to these issues, but I’d like to see more maintainers seeking contributions with some specificity, and then actively responding to pull requests. A call for additional test cases. Bug fixes. And yes, documentation.

For all the openness of Github, there’s no Quora/StackExchange-type system to let you know which projects are in need that you might be a match for. Seems like that’d be a good feature.