Memo from Freesoftwareburg: How to effectively address the free software community

Winds of change are sweeping through the software industry. Today, it's no longer fashionable to decry free software types as it was just a few years ago -- the cool kids are all "leveraging" and reaching out to free software communities. But not everyone's doing it right, so let's explore seven principles to start a positive relationship with free software.

This is a work in progress. I expect and will take your contribution into consideration -- use the comment form below to voice your doubts, tips or flames.

With so many companies finally realizing the potential of free software and open source, it's not surprising at all that some are failing miserably to engage free software communities effectively. Instead of focusing on what they're doing wrong, let's focus instead on what they must get right.

With that intent in mind, let's explore seven principles that will make your life easier when engaging free software types. In summary:

1. Know your audience
2. Your argument must rely on facts and reason
3. Respect community members' time, rules and terms
4. Develop a thick skin
5. Contribute
6. Be humble
7. Make it interesting, make it fun

Here's each principle explained.

Know your audience

We're not all the same. Before even attempting to address us, do your research and figure out the "rules" of the particular community you're trying to touch base with.

Despite the title of this article, there is most definitely no single "free software community" to address in the first place. It's all a multitude of communities centered around their own projects, and collaborating between each other in a loosely coupled fashion.

You see, the closest thing we get to have in common is the common core value of sharing = good -- and even so, many in our own collective of communities do not necessarily place that value up high in their own scale of values (witness Linus Torvalds, for example). You could possibly argue we all share a passion for technology -- which might be true -- but we all most definitely do not share even technical proficiency; modern free software communities are chock-full of people doing translation, usability and multimedia artwork.

Some communities are led by consensus. Others, by meritocracy. Some have benevolent dictators. Many projects out there have no defined leadership and are in a stage of transition.

Corollary: do not assume. Do your homework.

Fortunately, this homework is easy:

• You can easily poke around a project's Web site, skim over technical documents, and invest a couple of minutes reading mailing list archives, to get a general idea of how that particular community beats its drum.
• You can also look stuff up (Google is very free software-friendly).
• Try to familiarize yourself with the issues (esp. technical details). That goes double if you're a reporter -- there are reams of inaccurate stories out there, just because the reporter was lazy enough not to "go to the source".
• Some communities (the most mature ones, usually) even list guidelines for contributors and explicit rules of engagement.

Therefore, be informed. An ounce of prevention beats a hundred pounds of hammering.

Your argument must rely on facts and reason

In general, free software communities place extremely high value on the ability to argue and persuade using facts and reason.

The reason this is so pervasive in free software is quite clear: every single last drop of development and communication happens absolutely in the open -- usually with easily accessible public records. Think about it: past discussions, decisions and the reasons behind each and every one of them are archived somewhere and usually accessible by poking around search engines with the right keywords.

Another reason (I love to call it the "doers factor") is that, since new ideas can be tested quickly and pitted against each other. Do you think Project X will fare better with wings rather than legs? Prove it! In fact, cloudy proposals usually meet head-on with that sentence in our public discussion forums.

As you can see, "conventional politics" stand little chance against the gospel of "try it and support it" (though they infrequently win some points).

So don't attempt to convince a community of developers by using slick persuasion. You will be called on it and asked to provide facts backing your points of view. You might also get reprimanded by project leaders because you weren't diligent enough to "check the archives". In the worst case, you will be shunned for long.

Respect community members' time, rules and terms

You need to understand that many people involved with the free software movement are volunteers. Though a large subset of those people will be happy to help you fix any issue you may have, efficiency is key.

That's why we:

• use mailing lists with public archives,
• use bug tracking systems,
• idle a lot on Internet relay chat channels,
• respond sparsely and oftentimes with the dreaded RTFM acronym.

If you find a bug, please don't just mumble to yourself -- report it through the appropriate channel. Doing so, while requiring a bit of an extra effort on your part, multiplies the effect your report has, because it benefits everyone -- not just you.

If you have an idea that you think it may be worthwhile to pursue within the scope of a community, bring it to the table. Try to address everyone in the conversation, not just particular project authors. That way everyone gets an opportunity to shape the idea or to strike it down (in case it's a bad one).

Same goes if you need help. Especially in this case, you should try to consult with the Lazyweb -- mailing lists and search engines should be your first stop. Chances are, someone else already asked and got a publicly available reply.

Develop a thick skin

If you make a mistake, most free software types will call you on it.

Some of us are callous individuals. Sometimes, everyone is distressed or tired. We all are guilty of calling people names at some point. Don't get discouraged by these events. We might call you an idiot today -- that doesn't mean you're really an idiot, and sometimes we don't even mean it!

Some communities appreciate sparseness in discourse. This might be construied by some people to be the equivalent of "go away, outsider; we don't need you here". Nothing could be further from the truth -- most free software aficionados are efficiency buffs, and talk is expensive. Imagine yourself dealing with hundreds or thousands of e-mails daily in addition to coding or management tasks, and you'll have a clear idea of what managing a free software project is like. Efficiency is key.

Source code and conversations may contain tons of expletives. I read years ago a report on profanity in the Linux kernel. It's not pretty if you're into political correctness but, come to think about it, doesn't it work just fine that way? Then who cares about the cuss thrown around sparsely?

So try to develop thick skin. Become immune to callous comments, and keep pressing important issues calmly.

And comfort yourself with the fact that, in the medum-to-long run, projects with truly contentious members drown anyway.

Contribute

The whole notion of free software is based on quid pro quo.

We give you something for you to take advantage in any way you please. We expect you to share in equal terms with you. And your contribution has value. We need you. Here are some clever ways you can contribute in effectively:

• We hate bugs, so please report them. Try to provide as much info as you humanly can within time constraints. Try to keep yourself "in the loop" during the process.
• Maintain Web sites and blogs.
• Help with project marketing.
• Write manuals, guides or tips on public sites.
• Deploy a project across the board -- then report your issues so everyone benefits.
• Publish improvements to free software projects.
• Develop new code.
• Allocate manpower on collaboration with non-engineering tasks: artwork, translations.
• Fund or donate to projects. A million dollars is fine, but $10 may do it as well.

If you do any of these things (OK, OK, I'll recognize, some of them are more valuable to us than others), your message is way more likely to come across. Bonus points (yay!) for directly helping the project build its next "killer feature".

Fact is, if you have something to show, you'll generate an incredible amount of goodwill towards you.

Be humble

I've heard all manner of derogatory comments against us free software developers, from the classic "pinko" to the Cold war-era "hippie", through the equally ignorant "amateur".

We're not amateurs, so get rid of those misconceptions. Each and every one of us is highly likely to be much more proficient and professional in our field of expertise than you. We've made a career out of seeding high-quality products and harvesting respect and reputation out of it. Technical prowess is the name of the game for us.

In each field of technical expertise, there probably are a handful of gurus in the closed software industry -- and probably an even smaller group of free software developers which are in all likelihood as proficient or even more so than their counterparts doing closed source. This should be self-evident, since free software developers have had access to much more code and learned much more from collective experience resources while having fun at it, whereas the rest probably did it for the money only. You might be recognized by anywhere between ten and a hundred punks in your company, but we're recognized, revered and relied as sources of opinion and technical expertise for considerably many more people -- some of us count their fans and users in the tens of millions.

Each and every one of us has made a name for ourselves. Can you say the same of you? Even if you could, can you co-opt your reputation and technical expertise for the community you're about to address?

So coming with an attitude of superiority (whatever your reason for that attitude) isn't going to help your cause.

Be humble, punk.

But don't get the idea that we're arrogant just yet. 99% of us are eager to share a few beers with anyone else in equal terms. The other 1% usually die young from lack of human warmth (and alcohol?).

Make it interesting, make it fun

Free software types, believe it or not, are much more play than work. We are honestly entertained by what we do, and when we no longer have fun, we usually delegate our project to someone else with a more pressing need or a newfound passion for our project.

In a sense, we are probably the luckiest people in the world. People who actually enjoy what they do from the outset (as opposed to people who secretly want to hang their boss, or people who have had to learn to like what they do by sheer necessity) are far and few between. And some of us even get paid doing it. I know I do.

Moral: If you can wrap your message around fun and challenge, you'll benefit.

Conclusion

Let's recap, one more time:

1. Know your audience
2. Your argument must rely on facts and reason
3. Respect community members' time, rules and terms
4. Develop a thick skin
5. Contribute
6. Be humble
7. Make it interesting, make it fun

These principles might sound like common sense, mixed with a few unexpected nuggets of unique free software idiosyncrasies. Even so, every day people fail to heed this advice -- hey, I'm guilty of it myself! But it's never too late to bump the steering wheel and change course.

I hope this article enriches your future experiences with the free software community as much as writing it has enriched me. I wish you the best of luck, and welcome to the free software world!