ブログを購読する

spanakopita 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.


執筆者紹介

Brian Proffitt is Senior Manager, Community Outreach within Red Hat's Open Source Program Office, focusing on enablement, community metrics and foundation and trade organization relationships. Brian's experience with community management includes knowledge of community onboarding, community health and business alignment. Prior to joining Red Hat in 2013, he was a technology journalist with a focus on Linux and open source, and the author of 22 consumer technology books.

Read full bio

チャンネル別に見る

automation icon

自動化

テクノロジー、チーム、環境にまたがる自動化プラットフォームの最新情報

AI icon

AI (人工知能)

お客様が AI ワークロードをどこでも自由に実行することを可能にするプラットフォームについてのアップデート

cloud services icon

クラウドサービス

マネージド・クラウドサービスのポートフォリオの詳細

security icon

セキュリティ

環境やテクノロジー全体に及ぶリスクを軽減する方法に関する最新情報

edge icon

エッジコンピューティング

エッジでの運用を単純化するプラットフォームのアップデート

Infrastructure icon

インフラストラクチャ

世界有数のエンタープライズ向け Linux プラットフォームの最新情報

application development icon

アプリケーション

アプリケーションの最も困難な課題に対する Red Hat ソリューションの詳細

Original series icon

オリジナル番組

エンタープライズ向けテクノロジーのメーカーやリーダーによるストーリー