Select a language
Working in open source in these modern times is, for me, a lot of fun. The advent of tools like git (and services like GitHub and GitLab), collaborative platforms like Etherpad, and chat services like IRC have made sharing collaborative projects a much more streamlined process than in days past.
But what if members of your team prefer Slack to IRC? Or Google Docs to Etherpad? Is it time to get the holy water and exorcise these heretics from your community? Or can a more ecumenical embrace be employed?
I know there are a lot of people, including quite a few of my teammates, who would argue that it is important and necessary to work with as many free and open source tools as possible. From a long-term point of view, I agree. Even tools that are free of charge (like Google Docs and Sheets) are still maintained and controlled by a single corporate entity under a proprietary license. Not to pick on Google, but if they decided at some point in one of their Fall or Spring services cleanings to drop Google Docs and the lot, many users would feel a lot of pain.
Yes, files could be downloaded and used in OpenOffice, so presumably no data would be lost, but the ease-of-use of collaboration would be removed. End of the world? No. Pain in the tuchus? Most assuredly. The same would hold true for Slack. Or GitHub. Or any of the other corporate-run platforms that many of us use to collaborate today.
It would seem, then, that I have made the case for all open, all the time. But, there is such a thing as network effect, and not every open source tool out there is optimized for ease-of-use. I am old, have no problems moving around IRC, and often wonder what the hooplah is around Slack. But if I come into a community and they are mostly using Slack as a messaging service, then I am very likely going to use Slack to talk to them too. Getting them to IRC would be redundant.
The network effect of tools like GitHub and Google Docs are very hard to ignore. It's a lot easier to onboard new community members if you can just say "use your GitHub account to visit our code repositories," rather than setting up yet-another account on a self-hosted git repo.
To me, it's a lot like cooking. Cooking your own meals is better than buying processed foods. But when I make spanakopita, I'm not going to take the time to make phyllo dough. I'm going to pick some up at the grocery, thaw it out, and use that instead. Phyllo dough is hard enough to handle pre-made. Nor am I growing the spinach or churning the butter.
Fresh ingredients are always better to store-bought, I will always agree. But to get things done in a timely manner, sometimes you need to run to the grocery. The analogy will hold for open source collaboration as well. As long as care is taken to assure consistent data access, using the popular tools at hand should not make your project less open.
Image by Paulk, licensed under the Creative Commons Attribution-Share Alike 2.0 Generic license.
About the author
Brian Proffitt is a Manager within Red Hat's Open Source Program Office, focusing on content generation, community metrics, and special projects. Brian's experience with community management includes knowledge of community onboarding, community health, and business alignment. Prior to joining Red Hat in 2014, he was a technology journalist with a focus on Linux and open source, and the author of 22 consumer technology books.