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.

Ruby DCamp: What I learned on summer vacation

Ruby DCamp is one of only a couple of my “can’t-miss” events of the year. This was my second time participating, and both times, I’ve come home with life-changing experiences. It’s incredibly special to me, and I want to share with you some of the reasons why.

What is Ruby DCamp, and what makes it so special?

Ruby DCamp is a code retreat and unconference (which I’ll describe later), and takes place about 45 minutes out of Washington D.C., in Virginia’s Prince William Forest state park.

It’s the brainchild of Evan Light, a Maryland-based Ruby developer and self-described hippie. It’s simple in concept: a three-day event, held in the forest, for programmers of all skill levels to get together, write code, socialize, and self-organize as a community.

What makes DCamp unlike most other events is a combination of the venue, the sessions, the community, and the event’s mission.

The venue

Unlike any other conference I’m aware of, DCamp takes place at a campground, the sort of idyllic summer camp depicted in movies and TV shows from the 1980’s and 90’s.

There’s no internet: it’s BYOWifi, and cell coverage is… meh. A lot of people (like me) don’t have tethering and have to borrow someone else’s device to connect.

The cabins are subdivided into rooms, with 2-4 cots per room. So there are some limitations on privacy and personal space.

The constraints imposed by the remote location, close quarters, and lack of connectivity are actually incredibly freeing. Without all the little caves we tend to retreat into, we’re encouraged to bump into one another, strike up conversations, and let serendipity happen.

Attendees wake up early, stumble into the bathrooms (which are about what you’d expect at a campground), and are ready for breakfast around 8. The conference proper starts at 9, breaks for lunch, and wraps at 6 each day.

The Format, Day 1: Code Retreat

Day 1 is a Code Retreat, which is a well-defined formula for honing programming skills. At DCamp, you pair up, work on solving Conway’s Game of Life for 45 minutes, follow up with a retrospective, and jump back in with a new pair programmer. Meanwhile, in each iteration, Evan throws a new wrench at you by adding a constraint.

One of the constraints is called “mute evil” pairing, where no speech is allowed, the code does all the talking, and the programmers are instructed to sort of antagonize one another through the code. It was all very challenging, and at times, frustrating.

By the end of Day 1, I was completely wiped out. It’s not my favorite part of DCamp, but in the discomfort there’s a tremendous amount of learning. It’d be quite difficult to spend a full day gaining that much exposure to people of varying skill levels, styles, preferences, and tools without learning a ton.

The Format, Day 2 & 3: Unconference

On Day 2 and 3, the group gets together and pitches each other on ideas for topics for the day. Then, you write down your proposed session and duct tape it to the wall.

Each member gets 5 votes. You cast your votes by dotting the duct-taped papers, they’re tallied, and Evan compiles it into a two-track schedule.

The schedule tends to fall into two tracks: one is code-oriented, and the other tends toward the philosophical.

Each track gathers at an end of the main cabin, and you’re free to “vote with your feet” and switch between tracks, spin off a session of your own, or just duck into your cabin for a nap. Or help out in the kitchen (more on that in a bit).

There’s also a third track for new Rubyists or non-programmers, held out on the picnic tables outside. For such a small group, it’s shocking how accommodating the schedule is for varying experience levels and interests. That’s the benefit of having the attendees determine the schedule, I suppose.

As for the sessions themselves, I’ll provide a “what I learned” section toward the end.

The Community

DCamp is essentially a self-organizing pop-up community. There’s no staff to speak of. Evan handles the logistics of making it happen, but once the camp starts, all sessions, planning, cooking, cleaning, and activities are the shared responsibility of the participants.

Some of the people there are well known in the community, and some are first-time programmers. But everyone pitches in, everyone teaches, everyone learns, and everyone enjoys each other’s company.

After dinner, it’s up to participants how they spend their time. Some retreat and read books, many bring card and board games, some hack on projects, and some just converse (you may not be surprised that I tend toward the latter).

I can’t overstate the quality of humans that DCamp attracts. It’s an awe-inspiring group of people. I’m still astonished at the backgrounds, knowledge, accomplishments, and depth of character of the people there. I actually feel a bit sad knowing that I don’t get to interact with many of them at that level more than once a year.

I got to hang out, code, and talk with some personal heroes of mine. I also met people who became new personal heroes to me.

The Food

It may seem strange to spend a section on the food, but DCamp has become known for taking food seriously: There are options for everyone from vegans to paleo adherents. Rather than burgers and hot dogs (as had been the case in prior years), the menu consists of a number of from-scratch items made in the dated, somewhat dangerous, but still-functioning industrial kitchen in the main cabin. This year, the food ranged from grilled portabello to a smoked whole pig (yes, seriously).

DCamp eats are also famous for improvisation. Last year, Brad Herrup made astonishingly good bread pudding from leftover hotdog buns, and this year we had to cut ice cream into cubes with knives, as we’d failed to remember an ice cream scoop.

The food in particular is a herculean task, from purchasing, to cooking, to cleaning. The kitchen is a hive of activity literally from dawn to dusk. Everyone gets a chance to participate: I had a couple of nights of dishes, and got my share of injuries while cooking 20 lbs. of pasta.

What I learned

One of my favorite things about returning for a second year was that it has become a yearly moment to reflect. I got to see the progress that my friends had made in the intervening year, and to realize how much of my own progress I’ve made.

Most importantly, I got to ponder on what I’m passionate about and what I want to accomplish by the next time DCamp rolls around.

Several of the sessions stand out in my mind:

Sexism in Programming: Sandi Metz and several other female attendees helped steer this delicate conversation, and the way the men participated made me proud to be a Rubyist. Without resorting to becoming “word police”, we can make the Ruby community a shining star for diversity until we reach 50% parity between men and women.

Raspberry Pi: I brought my Raspberry Pi (the $25 computer) and led a session on what they might be used for and how to get them set up. Even with technical difficulties with the TV, we had it all set up and running the programming language for kids called Scratch within the half hour session. (Later, we set up Ruby and Rails on it. That did not take half an hour.) I’m still terribly excited about the educational implications of this fun, approachable, and inexpensive computing platform.

If Money Weren’t An Issue: Adam Bachman (originally a philosopher and theologian by training) led a brave, deeply resonant conversation about the things we’d do if money weren’t an issue, or if failure weren’t an option. Pausing to think and openly discuss what we really want to be doing with our lives is not something I’d expected to participate in, but I’m so glad I did.

JRuby with Hiro Asahi: I learned more about JRuby, having used it for work in the past, but I was more struck with Hiro. He’s an example of the best of Ruby’s MINASWAN culture, and I was delighted to learn from him. (MINASWAN, for the uninitiated, stands for Matz [Ruby’s creator] Is Nice And So We Are Nice.)

Visualizing code: Avdi Grimm posed an open question about how programmers visualize concepts in software, and it developed into a rich conversation complete with drawings by people in the group. Sandi Metz showed how she uses Keynote to create a sort of animation to take a complex refactor and explain it to people in a simple, accessible way. I am passionate about using drawings to communicate, and this made me want to really develop those skills.

Spreading the wealth: Another Avdi-led session, he shared how he believes that every software developer can define and create jobs. We may not be a part of the “one percent”, but our responsibility is to share some of the prosperity of software development by looking at parts of our work that can and should be hired out to (real, not virtual) assistants, and start defining new roles and jobs that may not even have been invented yet.

DCamp’s mission

A lot of conferences put together a vision or mission statement. Some craft a nice explanation about how it’s the “conference for people who X”. All of these are great, but DCamp couldn’t possibly do that, because its mission and ideals largely emerge from the community that shows up to participate.

But what makes DCamp so difficult to emulate is that it is very much Evan’s baby. Its soul is found in his gifts, dreams, frailties, and flaws. It simply would not exist without the combination of his love, stubbornness, desire to include and be included, and his deeply-held idealism.

DCamp is Evan’s dream of what utopia might be like, and he cultivates it carefully. And for a few days a year, a few of us get together and sample it. And for two consecutive years, it rang my psyche like a gong.

Thanks to Evan and the attendees for another great DCamp, and I hope to see old and new friends there again next year.

Community is my lifeline

Utah Ruby Users GroupNovember 10th, 2009 marked a pretty dramatic turning point in my career. The startup I worked for was in a tailspin, and a friend who’d escaped invited me to visit his new workplace for a meeting of the Utah Ruby Users Group.

This was the first time I’d attended URUG, or anything like it, and it was scary as hell. There were smart people talking about things I didn’t understand, and a guy in a fez who seemed to be asking lots of annoying questions.

Mike Moore showed off a fascinating new technology called Ruby Version Manager by a fellow named Wayne Seguin. People talked about the dramatic changes in Rails that would soon take place due to the work of people like Yehuda Katz.

I was literally incapable of processing about 90% of the conversation in the room, and terrified someone would ask me to say something and expect me to do anything but make a fool of myself.

Even though I was so bewildered that I literally cannot remember who was at that first meeting, I’ve since learned that at several of the people were there are now some of my closest friends. Over time, I became a part of this community that literally saved my career.

Here’s why I think the URUG community’s been so important to me:

1. It’s consistent.

It’s easy to forget now that there were moments where I very nearly gave up on breaking into software development. It would have been so easy for me to go back to marketing, and I had several opportunities where I could hang up my still-new coding spurs and have a long, prosperous career with the word “product”, “process” or “manager” in the title.

But I got to associate with the people at URUG every month, and I was able to keep my eyes on the prize. It repeatedly connected me with me the kind of people I wanted to emulate, and the kind of work I wanted to do.

Just having a single night where I knew I’d be around great people was an anchor when becoming a software developer still seemed like a distant goal.

2. It’s accepting.

The guy in the fez may have been irritating, but nobody chased him off. I was irritating, I’m sure, and nobody chased me off.  It was the only time I was able to have a face-to-face discussion with experienced Rubyists, ask my stupid questions, and come back next month with more.

Never once have I seen behavior at a URUG meeting that I felt embarrassed by, nor do I hear people say negative things behind others’ backs. I’m very proud to say that the kind of people who show up to user groups seem to be the kind of people who are interested in building one another up.

3. It’s a chance to contribute.

I once wrote a blog post about why I don’t contribute to open source, and now I realize I missed the point entirely. A friend pointed me to an old talk by Chad Fowler, one of my heroes, where he mentioned that people should contribute in their own specific ways.

My problem was that I was trying to contribute to the community in exactly the same way as people who are the best coders can contribute. So contribution felt like an obligation that I was failing.

That’s why one of my favorite things about the URUG is that everyone is, at some point, asked to participate. Even as a brand-new coder, I was given a topic to research and come back to share the following month. I mangled it, I’m sure, but the group interacted with me, applauded, and I gained the confidence to do it again later.

User Groups are a wonderful way for people to ease into contributing to a community without feeling like they’re competing with ninja-coder strangers on the other side of the planet. In fact, it’s so sneaky that you may not realize that you’re contributing just by being yourself and showing up.

My opportunity to help

Last week, I was asked if I’d be willing to handle the responsibility of organizing the Utah Valley Ruby Brigade. It’s intimidating, as I haven’t done anything like this before, but I am so grateful to be getting a chance to contribute the best way I know how.

At lunch with Mike Moore this week, we briefly talked about what sort of “outreach” programs we might offer to newbies. I do teach a programming class to non-programmers and think that’s a fun and noble goal. However, the most valuable thing is what URUG already offers: consistent meetups with friendly, smart people who are actively invested in one another’s success.

I can’t begin to thank Mike Moore and Jake Mallory for their work in maintaining URUG, and hope I can put at least some of the value in that I’ve received over the last two years.

For now, the best I can hope for is to bring my newcomer’s enthusiasm, not break the things that are working, and learn the rest as I go along.