OSS出身エンジニアが感じた、OSSコミュニティと会社で異なる開発手法

はじめに

こんにちは、おかりょーです。

私はアトラスで働く前から、オンライン上のコミュニティでオープンソースソフトウェア（OSS）の開発に参加しています。アトラスではサービス開発にGitHubを採用していますが、LinuxやNode.jsなどの多くのOSSも同様にGitHub上で開発されています。

当然ですが、OSSコミュニティと会社では開発手法や文化に大きな違いがあります。本記事では、主にGitHubの運用方法について、私が参加しているコミュニティとアトラスを比較しながらご紹介します。

README.mdの運用

OSSコミュニティの場合、README.mdには主に次のような内容が記載されます。

• ソフトウェアの概要
• ビルド方法
• 貢献方法
• 謝辞・ライセンス条項

アトラスの場合、主に次のような内容が記載されます。

• ソフトウェアの概要
• ビルド方法
• 関連ドキュメントのリンク

比較してみると、どちらもそのリポジトリを見る人を対象とした情報を載せる傾向にあることがわかります。

OSSの場合、不特定多数の人が有志で関わる性質があるため、コミュニティに貢献するうえでの注意点、貢献する手段（不具合報告や機能追加要望の場所等）やライセンス条項を重点的に掲載する傾向にあります。

アトラスの場合、Googleドライブでサービスに関するドキュメントを管理しているため、それらへのリンクを掲載することが多いです。

Issueの役割

OSSコミュニティにおいて、Issueは次のような役割で用いられます。

• 不具合報告
• 機能拡張の要望
• タスク管理

アトラスでは次のような役割で用いられます。

• サービス監視ツール「Bugsnag」による自動的な不具合報告
• プロジェクトの課題管理
• タスク管理

アトラスの場合、エンジニアではなく顧客対応の部門が不具合や機能拡張を起票する場合が多いです。そうした不具合や拡張の要望は他のサービス（Slack等）で連絡・周知したうえでスプレッドシートで管理しており、優先度や対応方針の検討後にタスクとしてIssueに登録しています。

多言語対応

昨今のWebサービスは様々な国の言語に対応することが多いです。多くのOSSも同様に取り組んでおり、主に次のような方法を採用しています。

• 翻訳文ファイルを直接変更し、プルリクエストを送る
• CrowdinなどのGitHub対応の翻訳サービスを利用する

アトラスではサービスによって多言語への対応方法が異なります。Confitは日本語と英語の2つの言語に対応しており、次の2通りの方法を採用しています。

• 翻訳文ファイルを直接変更し、プルリクエストを送る
• Googleスプレッドシートで翻訳文を管理する

どちらにも共通するのが「翻訳文ファイルを直接変更し、プルリクエストを送る」です。これはGitおよびGitHubの機能のみで実現できるため、比較的小規模なサービスに向いていると思います。

Crowdinなどの翻訳サービスは、ウェブサイト上で多くの人からの翻訳を受け付けるためのサービスです。例に挙げたCrowdinは、1つのメッセージに対して複数の翻訳候補が投稿されたときに投票で翻訳文を決める機能が備わっています。OSSの場合、多くの人に貢献してもらう関係上、このようなサービスが重宝されます。

一方、アトラスでは翻訳文の編集に携わる人はあまり多くないため、そのようなサービスは用いていません。比較的開発時期が新しい 発表データ収集公開機能では、スプレッドシートで翻訳文を管理し、スプレッドシートから翻訳文ファイルを自動生成しています。

まとめ

OSS開発は不特定多数の貢献者からなるオープンな場であり、社内開発は会社に所属する開発メンバーからなるクローズな場です。例に挙げた3つは、どれもその環境の違いに起因するものであることがわかります。

OSSコミュニティでの開発手法を社内に持ち込んだり、逆に社内での開発手法をOSSコミュニティに持ち込むと、せっかくの環境に適した開発手法が崩れてしまいかねません。もし仕事とOSS開発を両立するのであれば、その違いをしっかりと認識することが重要です。私自身もこういった違いに最初は戸惑いました。

この記事が、OSSへの貢献をきっかけにエンジニアとして働こうと思った方への参考になり、また現職エンジニアの方が少しでもOSSコミュニティに貢献してみたいなと思うきっかけとなれば幸いです。