"A slip of the foot you may soon recover, but a slip of the tongue you may never get over." Benjamin Franklin
Communication is central to the vitality of an open source project. It is one of the key characteristics that separate and distinguish a healthy open source project from the vast clique of abandoned ideas, defeated plans, and failed forks. Healthy projects communicate, and they do so extensively and openly. Yet, each project has its own etiquette conventions and interaction protocols; unfamiliarity with these can result in an unfavourable experience that can be particularly devastating to newcomers and outsiders.
The benefits that open source offers, however, are still proving to be exceptionally compelling. In particular, commercial industry is becoming increasingly aware of the vast potential held within open source communities and the millions of lines of source code written by impassioned developers around the world that improve and maintain those codes for free. Business institutions often get involved in order to make modifications that support their needs and quickly find themselves ill-prepared to be thrust into the realm of open source software development.
Business institutions tend to structure and manage projects very differently from open source projects. Dan Woods wrote about this "collaboration gap" for Forbes, describing how the difference in management styles and communication mechanics often creates a distinct collaboration disconnect. Learning to bridge the differences makes it considerably easier for business institutions to garner the greatest long-term benefits of participating in open source.
A successful open source project thrives on extensive and pervasive communication and on sharing information. Most businesses are not good at sharing information -- at least not for free and rarely without monetary gain. Some organizations avoid sharing as a means to protect their business secrets. Some don't share in order to minimize risk - legal, competitive, or otherwise. Others don't share simply because that takes time and they don't perceive a financial benefit.
Institutions venturing into the realm of open source for the first time often have difficultly figuring out how to communicate effectively, particularly beyond the domain of their marketing departments and while keeping their risk-averse management happy. Many fail to interact effectively due to significant differences in priorities and protocols. So, how does a company share information without giving away business secrets, without taking on additional risk, and while still realizing a financial gain? The key is to find common ground for communication and collaboration.
Delegate Individual Responsibility
Business institutions tend to participate in open source projects differently than individual open source contributors. Understanding how to communicate with an open source community provides the greatest benefits to an organization and helps establish a long-term mutually beneficial relationship with the largest potential gains. The first crucial step along that path is to delegate responsibility down to individual contributors.
Open source communities don't care about the company behind an individual or effort. They care about contributions and the abilities of contributors. Often, great open source communities are meritocracies. The best ideas win because they are great ideas, not because they are from someone important. Corporate reputation holds little credence. In a meritocracy, individuals with a reputation for good ideas are in charge. Companies have to empower and pay their workers to make connections and network. Individuals make contributions, not institutions. Realizing this difference is a big first step.
Go Where they Go
Open source communities have a plethora of resources at their disposal for interaction. While private e-mail communications and face-to-face meetings may be the norm for corporate business, most open source projects operate over chat networks, discussion forums, and other internationally-accessible on-line mediums. When getting involved with a new community, figure out where the existing contributors predominantly interact.
Three of the most common communication mediums that developers use are e-mail mailing lists, on-line discussion forums, and Internet Relay Chat (IRC). Some projects operate exclusively over one medium while others will utilize multiple mediums simultaneously. IRC is particularly interesting as the medium provides group discussions in real-time. Users are often connected to an IRC network 24/7 and communication etiquette can be unfamiliar, strict, and unforgiving to new users. The Freenode IRC network is a particularly common home for many open source projects due to the network's focus on open source software communities.
Know How to Talk
Once you find them, there are still several matters of etiquette that have to be taken into consideration. Failure to follow common etiquette, rules of conduct, and interaction protocols is viewed by many open source developers as an unforgivable offense. Responses can range from helpful guidance to correct misbehaviour to outright permanent bans without warning. Here are some summarized tips for establishing good communication rapport and hopefully avoid some of the more common pitfalls:
- DON'T WRITE IN ALL CAPITAL LETTERS: this is considered SHOUTING. It's considered rude. Don't do it.
- speling n grammr r imprtnt: poor grammar might work for talking to teenagers over text messaging, but most open source developers are pedants for accurate communication. You don't necessarily have to capitalize your words or end every phrase with a period, but using shorthand is usually a big no-no. It's viewed as lazy, distractive, and annoying.
- Don't top-post: one of the most common reply styles in business e-mails will infuriate many open source developers. Instead of replying at the top of a message, reply in-line or at the bottom. Particularly on open source mailing lists, be conscious of how you reply to messages.
- Be concise: and get to the point. Basic context is helpful, but many open source developers consider their time more sacred than yours. If you need help with something, say what you need help with and only the details that are immediately pertinent and relevant. Whether you're developing a source code patch or asking for help, don't mix topics.
- Do your homework: if a quick Google search will answer your question, you are wasting the time of others by asking. Read the README file, read the developer guidelines, read their forum FAQ. If you think your question might be covered somewhere but you're not sure where, then specify what you've read that pertains to the problem at hand. This will prove that you have been doing your homework and will also help them refine their documentation.
- Be polite: the project does not owe you anything. Many open source developers have a tendency to provide very blunt or tort responses, but your tone, particularly as a newcomer, should always remain cordial. Leave cynicism, arrogance, egos, and emoticons at the door.
- Be patient: while you may be paid to talk to them, they are often not paid to talk back to you. Particularly for IRC, responses are often instant but they can come hours or even days later. You are expected to wait patiently and quietly if you are seeking interaction.
- Ask smart questions: see How To Ask Questions The Smart Way for a good overview.
Communicate Early, Communicate Often
It's a rare open source project that enjoys someone showing up, dropping off a patch file, and disappearing. If you're working on a modification that you intend to contribute back to an open source community, you should be communicating as early as possible. You will be seen as an active participant, not just a passing visitor. Discuss your goal, your needs, and how you currently plan to proceed from a technical implementation perspective. Be flexible, prepared to work with others, and willing to adjust your plans. Ideally, you should be communicating continuously while you're working. Daily updates while you are working are encouraged. The more the better.
Be Honest and Earnest
The final note I'd like to leave you with is about the forthrightness of most open source communities. Many open source participants have a highly tuned BS sensor and low-tolerance for masked intentions. Honesty is highly valued and reflects directly back onto the contributor. An individual contributor's merit within a meritocratic community will grow if: i) they are contributing constructively to the project and ii) they are deemed trustworthy through openness and honesty. It should go without saying, but a little common sense honesty can go a long way towards earning respect.
Posts
No comments:
Post a Comment