背景
オープンソースという手法を使って、ベクトルタイルに関するプロセスをこなすスクリプトを共有し、それによりベクトルタイルを活用推進したいと私は思っているのですが、そのスクリプトについてのオープンソースコミュニティを作るには、明らかに「ソースコードを公開したら終わり」ではなく、むしろソースコードを公開するところは始まりでしかありません。
ここでは、Ben Balter の Twelve tips for growing communities around your open source project を咀嚼し、いわば自分で自分を説得する形で、コミュニティを育てる方法を考察してみたいと思います。このエントリは、Ben Balter の記事の内容をすべてカバーしているとは限りません。Ben Balter の記事はこのエントリとは別にお読みになることをお勧めします。
1. 共通課題を解いているか
私は何をするか
私のプロジェクトは、ライブラリではなくてスクリプトを共有する試みですが、データに依存する部分は別個のスクリプトになるように切り出しを図っています。例えば、modify-spec や stratify-spec がこの切り出しに当たります。この別個のスクリプトを編集する方法をドキュメント化することで、共通課題を解く形に変形する必要があります。
何が利益か
ここに留意することで、プロジェクトはよりモジュラーな、よりロバストなコードを手に入れることができ、コミュニティによる改善も期待できるようになります。そして、コミュニティは、私が解決しようとしている課題以外の課題に、プロジェクトの成果物を使えることになります。
2. (広く使われている) オープンソースライセンスを選んでいるか
ここは留意しています。非技術的な判断を含むので、本稿では割愛します。
3. プロジェクトの頒布チャンネルから GitHub レポジトリへのリンクがあるか
プロジェクトの頒布チャンネルはまだしっかりしたものがありません。ここは留意しています。
4. 技術ドキュメントを公表しているか
私は何をするか
プロジェクトの構想が概ね固まってきた現時点の段階において、私がやるべきことは、まさに技術ドキュメントを公表することです。コミュニティ拡大の相手の姿を見ながら、ドキュメントを作成・公表していく、というのが私のするべきこととなるでしょう。ドキュメントには次の３つの種類があるそうです。
マーケティング資料
なぜあなたがこのプロジェクトを使う必要があるか書いたドキュメントです。重要ですね。
エンドユーザドキュメンテーション
このプロジェクトの使い方です。私が作っているようなスクリプトでは、README.md をしっかり書けば対応できるように思えます。
技術ドキュメンテーション
プロジェクトがどのように働いているか、あるいはプロジェクトをどのように実装するか、といったことを書く文書です。通常、こう言った情報はコードに頼ることも多く、また、コードとの乖離が怖いので、書くことを避けてしまうような気がしますね。実際、一般的にもこの文書が描かれないことは多いようです。
技術ドキュメンテーションの目的は、メンテナのプロジェクト知識を潜在的なプロジェクト貢献者に移すことです。メソッドや関数のレベルでの機能について記載します。コードの中にインラインでも、自動生成であっても、手製であっても、プロジェクトをもともと期待していたものよりも大きくすることを主眼として書きます。
詳しい技術ドキュメントを用意することは、コードをより明確で目的に応じたものにします。また、曖昧さの余地を少なくします。
何が利益か
私のプロジェクトは短いスクリプトが多いので、技術ドキュメンテーションの規模は大きくならなさそうですが、大きくならなそうであればなおさら、短い時間をかけて技術ドキュメントを整備しておいた方が良さそうです。
5. 貢献の仕方を文書化する
いずれやらねばならぬでしょう。
6. サポートと開発を区別する
誤解を防ぐために、いずれ明確にしておいた方が良さそうです。
7. 新規貢献者を歓迎する
8. 自動テストを設定する
9. コードスタンダードを施行する
私のプロジェクトは JavaScript なので、StandardJS をコードスタンダードとしています。
10. コミュニティ管理を自動化する
11. コードオブコンダクトを採用する
12. 引き取ってくれる人を探す
結論
私にとっては、以下の３点が重要でした。
1. 共通の課題を解決する
2. 技術ドキュメンテーションを公開する
3. コードスタンダードを施行する