はじめに
こんにちは。久々の執筆になります。今日はプライベートで開発(と言うよりかは議論ばかりだけども)を進めているOSSのやり取りを共有したいと思います。ほぼ体験談なので、これをやれば全てのOSSプロジェクトは上手く進められると言う保証はない訳ですが、OSSって何だか難しそう...と言った最初の登竜門は超えられるかと思います。
関わっているOSS
上記は、FreeBSDの準仮想化機構であるjailを管理できる強力なバックエンドライブラリです。
当初は、libiocageという名前のプロジェクトで、元となったpython-iocageのPRから始まったプロジェクトでしたが、iocage, iocellの互換性のために新たに独立してプロジェクトが構築されました。
筆者も最初はiocageを使っていましたが、iocageのコードの規模が大きくなるにつれて、CLIコマンドインタフェースとバックエンドライブラリが一緒に入っているとコードが複雑になる事もあり(そもそも、バックエンドライブラリを使いたかっただけなので、CLIコマンドインタフェースを提供している方は冗長だった)、コードの理解に難航していた所がありました。そんな際に、助け舟としてlibiocのプロジェクトを知り、コードの理解を深めつつ(Pythonも初心者なため、苦労も2倍だな)PRを送っていたら「君も強力して」と言われたので、積極的に関わる事にしました。そのため、まだそれ程長くやっている訳ではないためここからが正念場です。今回は、このプロジェクトで筆者が私的に気をつけている事を共有したいと思います。
OSS開発で気をつける事
1. 基本、仕事と思ってやった方が良い
もうこれが結論であり、一番的を得ている事かもしれません。勿論、あくまでプライベートなコミュニティであるため、お金が発生している訳ではありませんし、途中から関わった人間がいきなり全部できる訳でもありません。
しかし、OSSコミュニティに「参加する」のと「コミットする」のでは関わり合い方が当然違ってきますし、責任の重さも違ってきます。そのため、まずはContributorsに敬意を払いつつ、何か不具合があって、issueやPRを起こす場合は、必ず「何を」「どうした」というのは明確にしておきましょう。
2. Contributorsの責任の所在を明確にする
中途入社の会社と違い、何かチュートリアルがある訳ではないので、途中から参加した人間からすれば、「誰が」「どういう責任の元で」「何をやっているのか」という事は、ログを追い続けていかないと基本的には分かりません。
そのため、ここは多少面倒でも、積極的に議論して誰が何をやっているかというコンテキストを引き出してもらいましょう。ある程度議論すると、issueからいくつかのコンテキストが引き出す事に成功したので、ディスカッションがかなり重要になってくるかと思われます。
3. 中学英語で良いので自分のコンテキストを明確にする
途中から入ってきた人間でもディスカッションに参加する権利はあります。ディスカッションですから、Contributorsの意見に全部Yes,Noで返答するのは良くありません。
なぜなら、そこで会話が終わってしまうからです(うちの会社の英語部でもショートアンサーは会話が終わってしまうから使わないようにと指摘されました...)。OSSプロジェクトに関わる全員、プロジェクトを良くしていこう!という気持ちは全員同じです。そのため、中学英語でも良いので自分のコンテキストはしっかりと表現するようにしましょう。因みに、筆者は現在、中学英語からやり直して勉強中なため、かなり短い文ですが表現はできているかと思います(おそらく)。文法間違いとかあるかもしれないので、あえてここではエビデンスは載せないですが汗。
因みに、機械翻訳は(特に日本語から英語に変換する方)使っていないです。これは次節のライセンス(とは言え、筆者が英語を使う時はissueの議論の場合のみなので、それだと私的利用なためライセンス問題には引っかからないとは思いますが)問題以外にも、基本的に日本語から変換した英語は文意を理解するのが困難なレベルの英語(恐らく英語にもなっていない)にしかならないと言うのが明確なためです。
4. OSSライセンスについては敏感になっておく
OSSライセンスには敏感になっておきましょう。これは、相手のコードを取り込む時だけでなく、自分が送るPRも同様です。
Contributorsからすれば、ライセンス汚染があった時のrevert(reset?)は苦痛でしかありません。まだ、筆者のPRはmergeされていませんが、レビューが完全に通った後にはPRのコードはパブリックドメイン宣言する予定です。因みに、OSSライセンスの勉強をするのであれば、現在私も読んでいるOSSライセンスの教科書がオススメです。
5. PRが古くなった場合は、mergeではなくrebaseを使う
最後に技術的な話になります。PRがcheckoutしたブランチの後の更新により、新しい差分を取り込む場合はmerge commitではなく、rebaseを使うようにしましょう。
Contributorsからすれば、現在のmasterブランチから差分が何も発生していない余計なmerge commitログが入ってしまうと確認作業がややこしくなるだけです。そのため、rebaseコマンドを使って、既存のPR用のブランチが最新のmasterブランチから紐づくように訂正してあげましょう。
git rebaseについてはこちら→.6 Git のブランチ機能 - リベース
今回のプロジェクトでは開発プロセスが決まっていた訳ではありませんが、元となるリポジトリをforkした自分のリポジトリにcommitしたPRをオリジナルリポジトリに送るGitHubの基本的な開発プロセスに基づいていたので、ローカルでrebaseします。
Desktop/Develop/libioc
% git remote -v (git)-[feature/add_config]
develop git@github.com:bsdci/libioc.git (fetch)
develop git@github.com:bsdci/libioc.git (push)
origin git@github.com:himrock922/libioc.git (fetch)
origin git@github.com:himrock922/libioc.git (push)
% git pull develop master
% git push origin master
% git checkout feature/add_config
% git rebase master
% git push -f origin feature/add_config
まとめ
という訳で、筆者がOSS開発に初めて関わった事、またそこで私的に気をつけている事の共有でした。まだ、関わり始めて1ヶ月程度でもありますし、今後どういう関わり方になるかはまだ想像もつきません。
ですが、基本気をつけていることはContributorsの気持ちを汲み取って、作業を行っているだけです。
単純な話に行き着いているのは、現在、OSSに積極的に関わっている方々から反感を喰らう事かもしれませんが、大事なのは、正当な手順で正確に貢献することが大事であり、作業する事が偉い訳ではないと言うのがミソになるのかもしれません。
無駄な作業に対してのrevertや議論はモチベーションが下がるだけではなく、最悪OSSプロジェクトを潰す事になる恐れがあります。残念ながら、筆者にそうなった際の責任は取れません。
そのため、最終的に仕事と思ってやった方が良いと言うのはその理由で行き着いているのかもしれませんね。こういう考えができるようになるだけで、エンジニアとしても人としてもより成長していけるような気がします。
と言う訳で、最後ちょっと自慢みたいな与太話を挟んでしまいましたが、まだそれ程貢献できている訳ではないので、これからも貢献し続けていこうと思います。
それでは。