The Social Currency of Open Source

June 24, 2020

Come In We're Open

I spent the first year of my first programming job afraid to ask for help. I was the new guy on a team full of older, more experienced engineers and they didn’t know if I was in the right place. I didn’t know if I was in the right place. I made little lists of all my teammates, careful not to ask any one of them too much and certain to never ask the same question twice.

There was a hierarchy on the team and I was on the bottom. The rules were simple Book of Dead Slot Machine. Help was our currency; the people above you gave it and the people below you needed it. Every time someone helped you they went up a little and you went down a little more.

At the end of that first year I climbed to the next rung on the ladder and someone finally asked me for help. Nobody asked again for another six months. And so it went. I slowly climbed a little higher, careful to never ask for help from anyone below me.

Hierarchical teams are common everywhere. Giving help is seen as strength and asking for help as weakness. The catch-22 is that asking for help is the best way to get better at your job and move up the ladder. Open source software turns this pattern on its head.

Open source projects can’t afford the overhead of making their members climb the ladder, but they also don’t have much to offer those who do. Raises, promotions, and corner offices don’t mean much to a group of volunteer hackers working remotely. Open source projects (at least some of them) rebuild the ladder and trade help in a different way.

Open source projects also change the way they exchange help because they fear forks. Like a fork in a the road an open source project can split in two. Forking in open source happens when one or more project members decide to copy the code and start their own project. If the project community doesn’t encourage new members well enough the project will either fork or fail.

It was Jim Blandy from Mozilla and the Subversion project that first introduced me to the social currency of open source. Jim’s a hacker who leads with teamwork as well as technology. Instead of rewarding the people who give help, open source projects reward the people who take it.

The infectious enthusiasm of Jim Blandy

Jim is an open source zealot and one of the first people I interviewed for The One Minute Commute. I spoke with Jim for about 20 minutes before I was ready to quit my job and work wherever he was. Common sense and restraint stopped me from asking him to take my resume, but I couldn’t stop wondering how he did it.

I felt refreshed and excited about my new book project after talking with him, but Jim was no cheerleader. He asked hard questions and really wanted me to figure out the answers. He made it clear I was asking for his help when I interviewed him, but he did it without even a hint of any negative connotation.

It makes sense in his view of the world. Open source teams need contributors who can accept help and be part of the team. All the rewards of open source are in your ability to contribute usefully to the project.

The social currency of open source creates an open team structure completely different from the ladder I started climbing when I was a young engineer. You can stand up and ask for help. You’re required to. It creates an openness on the team and open teams make you smarter much faster than closed ones.

Open teams also feel better to work in. Instead of being afraid to ask for help the entire team can work together. The less experienced team members get smarter, and so do the more senior ones. It doesn’t matter how much you know, there is always someone who knows something you don’t.

Open teams are also much nicer places to telecommute since climbing that ladder is tough when you aren’t in the office.

How to ask for help

So far we’ve seen the good sides of open teams, but if everyone asked for help with everything the team would grind to a halt. Open source projects solve this problem by telling you how to ask for help. They usually call it a hacking document.

With this document the project makes it very clear how to ask questions. Each project is a little different, but most open source projects want you to take the following steps before asking a question:

Read the manual. Don’t ask a question you could easily look up.

Read everything else. Don’t forget about mailing lists, wikis, and FAQs.

Ask the right group. Most projects separate questions about how to use the project from questions about how to develop new features.

Try to figure out the answer yourself. Get informed about the question by trying to find your own solution.

The last point is the most important. Help works best when it isn’t one way. If you bring something to the table and start a discussion then people will join in. Show them that you’re making good progress and they can help you help the team. Never ask passive questions.

Pry your team open

If your team is closed you can pry them open. The open team environments are so much better than the closed ones that they sell themselves. You just have to show your team the way.

Lead by example. The first person your your team who should be open is you. Show your teammates what an advantage being open can be.

Look for excuses to ask for help. Any excuse will do. Ask for help from someone more junior than you. Make sure it is in an area they know well.

Show the results. After you ask for help don’t hide it. Let your entire team know how it went. You don’t need a status report, a simple email about the cool new thing you learned from Bob will do.

Open teams help everyone, not just teleworkers. They encourage communication and make everyone smarter. However, teleworkers are in a better position to pry their teams open. As a telecommuter you do more of your work in public and have more of a chance to show your team the positives of collaboration.

Ask for help today

I don’t normally assign homework, but this one is worth it. Ask someone for help today. You can start with something small, but do it publicly. Make sure everyone on your team knows the results even if it went badly. Then try again.

Openness is a habit your team needs time to cultivate. It takes a little work, but it makes a much better working environment. So how will you ask for help today?

The photo in this article by thebirdwells is used in accordance with the CC BY-NC 2.0 license.

Previous post: