|
オープンソースプロジェクトコミュニティでは、利用状況の指標について多くの質問を受けます。これらの指標は通常、ユーザー数や知名度を通してソフトウェアの重要性を測るために用いられます。私たちが知りたいのは、ソフトウェアをどれくらいの人が利用しているか、何回インストールされたか、そして日常生活でどれくらいの人が触れているかといったことです。 つまり、上記の質問にはまだ直接答えることはできません。 決定的な解決策をお探しなら、残念ながらご期待に添えません。指標の使用に関する質問には、完璧な答えはありません。少なくとも、正確な答えはありません。 幸いなことに、ソフトウェアの使用状況に関する知識への渇望を少なくとも部分的に満たすことができる、近似値や代替指標が存在します。この記事では、これらの代替指標について、それぞれの長所と短所とともに考察します。 ダウンロードソフトウェアを提供するウェブサイトを閲覧すると、通常、ダウンロード数が表示されます。例えば、かつてダウンロード数カウンターを備えていたFirefoxが挙げられます。Firefoxのダウンロード数は驚異的な数字で、Firefoxが人気ブラウザであるという印象を与えていました。実際、一時期は確かにそうでした。 しかし、個人の行動はこの数字の正確性に直接影響します。例えば、デバイスを定期的にリセットする人は、リセットのたびに個別のダウンロードが発生します。こうした現実を踏まえ、ダウンロード数は一人の個人によるものであるため、合計から数十（あるいは数百）のダウンロード数を除外する手法を設計する必要があります。 ダウンロード数は、使用状況を過大評価することも過小評価することもできます。例えば、システム管理者はFirefoxの新しいバージョンを一度ダウンロードし、USBドライブにコピーして、数百台のデバイスにインストールするかもしれません。 ダウンロードメトリクスの収集は簡単です。サーバー上のすべてのダウンロードリクエストをログに記録できます。問題は、ダウンロードされたソフトウェアがその後どうなるかがわからないことです。ダウンロードしたユーザーは、期待通りにソフトウェアを使用しているのでしょうか、それとも問題に遭遇して使用を中止してしまうのでしょうか？ オープンソース プロジェクトの場合、次のソースからのダウンロード メトリックなど、さまざまなダウンロード メトリックを検討できます。
下流プロジェクトではソースコードが使用される可能性が高いため、ソースコードのダウンロード数にも注目すると良いでしょう（「オープンソースプロジェクトの影響を測定する方法」の記事を参照）。関連するダウンロード指標には以下が含まれます。
ソースコードのダウンロード指標は、バイナリコードのダウンロード指標よりも信頼性が低いです（ただし、このことが真実であると実証された研究はまだありません）。開発者がソースコードの最新バージョンを入手したいと考え、ビルドパイプラインを設定して、ビルドごとにリポジトリをクローンするようにしたとします。次に、自動ビルドプロセスが失敗し、リビルドを試行しながらリポジトリをクローンし続ける状況を想像してみてください。また、ダウンロード数が予想よりも少ないシナリオも考えられます。ソースコードリポジトリがどこかにキャッシュされており、ダウンロードはこれらのキャッシュによって制御されているからです。
まとめると、ダウンロード指標は現在の使用状況とトレンドの探究を示す優れた指標です。1回のダウンロードがどのように使用状況に繋がるかを明確に定義することはできませんが、ダウンロード数の増加は潜在的なユーザーの増加の兆候と捉えることができます。例えば、ソフトウェアを宣伝し、キャンペーン中にダウンロード数が増加した場合、広告がダウンロード数の増加につながったと推測するのは妥当です。ダウンロード元とメタデータも、使用状況に関する追加情報を提供します。ソフトウェアのどのバージョンが現在も使用されているか？どのオペレーティングシステムや特定の言語バージョンがより人気があるか？これらは、コミュニティがサポートとテストを優先するプラットフォームを決定するのに役立ちます。 問題オープンソースプロジェクトであれば、課題追跡システムを導入しているかもしれません。誰かが問題を提起する場合、一般的には2つの目的があります。脆弱性の報告と機能追加リクエストです。提案者はおそらく既にあなたのソフトウェアを使用しているでしょう。ユーザーとして、脆弱性を発見したり、新機能の必要性を認識したりしているかもしれません。 明らかに、ほとんどのユーザーは問題を報告するという余分な手間をかけることはありません。提案者は私たちの忠実なユーザーであり、私たちは彼らに感謝しています。さらに、問題を報告することは、非コード貢献者となり、コード貢献者になる可能性を秘めています。経験則として、ユーザー10,000人あたり約100人の提案者と1人のコード貢献者がいると考えられます。もちろん、この比率はユーザーの種類によって異なる場合があります。 指標の問題に戻ると、提案者の数を利用状況を評価する下限値として使用できます。関連する指標には以下が含まれます。
メーリングリスト、フォーラム、Q&Aウェブサイト多くのオープンソースプロジェクトは、ユーザー向けのメーリングリストやフォーラムを運営し、Stack OverflowなどのQ&Aウェブサイトにも掲載されています。質問者と同様に、これらのプラットフォームに投稿するユーザーは、ユーザーベースのごく一部に過ぎません。メーリングリスト、フォーラム、Q&Aウェブサイトにおけるコミュニティ活動に関する指標は、ユーザー数の増減を反映することもあります。これらの指標は、以下の分野における活動に焦点を当てることができます。
レポート機能正確なユーザー数を取得するための 1 つの解決策は、ソフトウェアの使用状況に関する情報を報告させることです。 これは恐ろしい話です。システム管理者のファイアウォールが、サーバーへの予期せぬネットワーク接続を報告してきたらどうなるでしょうか。ソフトウェアのレポートが届かなくなるだけでなく（ファイアウォールによってブロックされるため）、将来的にソフトウェアが禁止される可能性もあります。 レポート機能を設定する際の責任あるアプローチとしては、アップデートの有無を確認し、ユーザーが最新バージョンを使用していることを通知するオプションサービスを含めることが挙げられます。また、テレメトリに焦点を当てたオプション機能として、ユーザーにソフトウェアの使用状況を匿名で報告するかどうかを尋ねることができるようにすることも可能です。このアプローチを慎重に実装すれば、ユーザーは自身の使用パターンを通じてソフトウェアの最適化に貢献できるようになります。例えば、「私は通常、このような使用状況情報の共有を許可しませんが、一部のソフトウェアについては、開発者が長期的にソフトウェアをより良く最適化してくれることを期待しているので、許可しても構いません」といった意見を述べるかもしれません。 スター付きで再発行スター付けと再投稿は、GitHub、GitLab、Gitee などのソーシャルプログラミングプラットフォームの機能です。これらのプラットフォームでは、ユーザーはプロジェクトにスターを付けることができます。なぜプロジェクトにスターを付けるのか？GitHub のドキュメントには、リポジトリやトピックにスターを付けることで、興味のあるプロジェクトを追跡したり、ニュースレターで関連コンテンツを見つけたりできると説明されています。プロジェクトにスターを付けると、ブックマークと同じ効果があり、リポジトリのメンテナーへの感謝の気持ちを表すこともできます。スターの数は、プロジェクトの人気度を示す指標となっています。プロジェクトが重要な発表を行い、大きな注目を集めると、スターの数は増加する傾向があります。スターの数はソフトウェアの使用状況を反映するものではありません。 ソーシャルプログラミングプラットフォームでは、フォークとは、プロジェクトリポジトリのコピーを自分の名前で作成することを意味します。リポジトリのメンテナー以外のユーザーは、自分のクローンに変更を加え、プルリクエスト（PR）を介してレビューに提出できます。フォークは、スターを付けるよりもソフトウェアコミュニティの規模を示す指標として優れています。開発者は、元のリポジトリが消失した場合でもアクセスできるように、コードのコピーを保存するためにプロジェクトをクローンすることもあります。コード貢献ワークフローに適用されるフォークの数は、開発コミュニティを測る優れた指標です。ただし、フォークの数は通常、開発者以外のユーザーによるフォークの使用状況を反映しません。なぜなら、彼らは通常フォークを作成しないからです。 ソーシャルメディアFacebook、Instagram、LinkedIn、Reddit、Twitterなどのソーシャルメディアプラットフォームは、同じ興味を持つ人々が集まる場を提供しています。オープンソースプロジェクトは、ソーシャルメディア戦略を活用することで、これらのプラットフォーム上に専用のスペースを作成し、関心のある人々を引き付けることができます。これらのソーシャルメディアチャンネルを通じて、オープンソースプロジェクトはプロジェクトのニュースや最新情報を共有し、貢献者やユーザーをアピールすることができます。また、これらのチャンネルは、他の方法ではプロジェクトと関わる機会のない人々とつながるためにも活用できます。 以下の指標に焦点を当てることはお勧めしません。なぜなら、実際のソフトウェア利用状況との明確な関連性がなく、多くの場合、肯定的、否定的、そして中立的な感情を分析する必要があるからです。人々は様々な理由でプロジェクトに興味を持っていても、実際には使用しないかもしれません。しかし、前述の指標と同様に、ソーシャルメディアでオーディエンスを惹きつける能力自体が、プロジェクトのエンゲージメントを測る総合的な指標となります。様々なソーシャルメディアプラットフォームの指標には、以下のものがあります。
ウェブサイト分析とドキュメントウェブサイトのトラフィックも有用な指標です。この指標は、ユーザー数よりも、主にサービス内容やマーケティングキャンペーンの影響を受けます。しかし、もう一つの切り札があります。それは、ユーザー向けドキュメント、チュートリアル、マニュアル、APIドキュメントです。これらを活用することで、ウェブサイトやこれらのドキュメントの中で、どのトピックが最も注目を集めているかを把握できます。ドキュメントへの訪問者数は、ソフトウェアユーザー数に比例して増加するはずです。そのため、ウェブサイトのトラフィックからプロジェクトへの関心度合いを測り、ドキュメント訪問者をモニタリングすることで、ユーザーの動向をさらに観察することができます。これらの指標には、以下のものがあります。
活動プロジェクト関連のイベントを開催する際には、イベント指標を活用することができます。これはコミュニティ構築に非常に効果的な方法です。イベントで講演を希望する概要を提出した人は何人いましたか？イベントには何人が参加しましたか？対面式イベントでもオンラインイベントでも、これは非常に重要な指標です。もちろん、イベントのプロモーション方法によって参加者数が大きく左右されます。また、参加者が遠方から訪れるような大規模なイベントとイベントをグループ化することで、参加者の参加を容易にすることもできます。一貫したイベント戦略を採用すれば、講演者から提出された資料の増加と登録者数の増加によって、ソフトウェアの人気とユーザーベースの成長を測ることができます。 有用な指標を収集するために、独自のイベントを開催する必要はありません。オープンソースイベントでプロジェクトに関するディスカッションを開催している場合は、プロジェクトに主に焦点を当てたセッションにどれだけの人が参加しているかを測定できます。FOSDEMのようなイベントでは、オープンソースプロジェクトのアップデートやリリースに特化してディスカッションが行われるため、会議室は満員になります（FOSDEMの他のセッションも同様です）。 次の指標を検討することができます。
オープンソースソフトウェアの利用状況の推定に関する結論上記で示したように、ソフトウェアの使用傾向を反映できる指標は数多く存在し、完璧な指標は一つとして存在しません。多くの場合、これらの指標は個々の行動、システム設計、ノイズの影響を大きく受ける可能性があります。したがって、各指標の相対的な不確実性を考慮すると、単一の指標を単独で使用することは推奨されません。しかし、さまざまなソースからさまざまな指標を収集すれば、ユーザーの行動やソフトウェアの使用状況の傾向を検出できるはずです。類似した機能、強い相互依存性、同じインフラストラクチャ上でのホスティングなど、共通点を持つ複数のオープンソースプロジェクト間で同じ指標セットを比較する手段があれば、ユーザー行動のベースラインをより深く理解することができます。 この概要では、使用状況を直接評価する指標に焦点を当てていることにご留意ください。しかし、ほとんどのソフトウェアは様々なパッケージに依存しており、ソフトウェアの依存関係チェーンにおける間接的な使用の大きな影響を無視することは見落としとなります。そのため、上流および下流の依存関係の総数を、分析の別のデータレイヤーとして含めることをお勧めします。 最後に、データや指標の利用者として、ステークホルダーの権利と責任を認識することをお勧めします。公開する指標は、ユーザーの行動に影響を与える可能性があります。ベストプラクティスとして、背景情報（根拠、情報源、推定方法、その他の重要な文脈情報）を定期的に共有し、他の人が結果を解釈できるようにすることが重要です。 このブログ記事の執筆にあたり、アイルランドのダブリンで開催されたCHAOSScon EU 2022において、CHAOSSコミュニティの皆様からいただいた洞察に満ちた議論に感謝申し上げます。また、本記事をレビューし、改善にご協力いただいたCHAOSSコミュニティの皆様にも感謝申し上げます。 |
