Once upon a time, perhaps a decade and a half ago, developers chose whether to engage or ignore open source projects. Today it is different. The industry claimed victory for the open source model of development recently, and the exception is now the rule for the enterprise application landscape and the creatives that cultivate it.
Open source culture characterizes the lofty idealism of computer science as a profession. As such, approach it with the utmost professionalism. This might prove difficult at times. Think of that officemate that grates on your nerves. Now imagine working with that person behind a veil of internet anonymity. It’s a potentially toxic recipe.
What makes open source software good or garbage?
Those who have been around open source development long enough know it can get tedious, ugly, and disheartening. All it takes is one foul-mouthed Linux troll to dull the shine of the illustrious philosophy. Blow the essence and it dooms the project to failure.
Basic manners and professionalism--the struggle is real in some communities. One prominent developer colors it as “a rudeness in the Linux kernel development community and in many, if not most, open source software projects whereby mailing lists, IRC, social media and other outlets can become breeding grounds for disrespect, harassment and bullying." This according to Jay Lyman, a senior analyst for enterprise software at 451 Research, as reported by Linux Insider.
“Good software arises when one or more very good programmers work closely full time together over a period of time developing, maintaining and improving it,” asserts Mark Tarver, a computer scientist credited with developing the Qi Lisp language, and author of prominent CS textbooks. “And for that you need capital and that is exactly where FOSS (free open source software) falls down."
Git optimistic, git excited, git real
Still, pockmarks and all, enthusiasm around open source ideals resonates today in FOSS repository communities like OpenStack and GitHub. Closed source software companies stopped fighting it and opened source code (to a limited extent) to the dev community. Even though open development caught on in a big way, projects frequently derail. In many cases it’s lack of cohesion that is to blame.
Harmonious team play is the key to keeping the wheels on a project, and executing its concept to the highest level. Project leaders need to bring specific traits to the boards in order to succeed.
- Codify coder conduct - If you want law, order, and manners to prevail, it serves to write out what is acceptable and what isn’t for a project. It doesn’t need to be long. Want to see a good example? Check out the Debian Code of Conduct.
- Value of time - For everyone involved this is a passion project or a way to immerse and learn. When the paradigm is “work for beer” as they say, project managers should not expect to schedule mandatory conference calls or IRC sessions. Rely on a timely response to an e-mail or thread posting instead.
- Value presence - Is more always merrier? Not really. If anything larger projects add some managerial difficulty. Remember to put the community first, and approach a big team with gratitude and open lines of communication.
- Value contributions of all types - Every project has its share of grunt work. Be mindful to avoid farming that out to the same person each time. A publicly posted thank you note commending a developer on their attention to the boring items goes a long way.
- Maintain order when scaling - Once a project gets a handful of people working on it, the maintainer might develop a sense of losing control. It gets nerve wracking for some when devs start making features outside of the initial vision. Frequent requests for direction might fuel that anxiety as well. Know that scale is something to manage and be ready for it.
- Critique with honesty, criticize with care - Nice work debugging that code. Step two is don’t be a jerk about it. Do not forget that coders of all levels work on these boards. Nuance like sarcasm does not lend itself to hypertext in many cases. Be mindful of that, and if you need to rant, do it somewhere else other than the project thread.
- Handle criticism like an adult - If someone gets snippy or rude on the job, then ramp up your EQ and debug the tension that arises. Just like any job, you will encounter people who are inept at communicating in a sensible fashion much of the time. That is the literal definition of a git; somehow this profession is rife with them. As for you, git over it and avoid adding venom of your own.
- Beware of illegal code use - Probably the most misunderstood aspect about FOSS is that you still have to ask permission to use source code. Simply taking it and building onto it is not only rude and disingenuous, but it fragments the patching process which opens the door for vulnerable open source applications.
- Don’t be a language bigot - It’s called the World Wide Web because it literally reaches worldwide. That means not everyone’s first language is English. In fact, English might not be in the top five for some developers. That said, patience is the key. Do not talk over someone that speaks slowly, and do not ignore their contributions because you don’t feel like navigating a language barrier.
