|
オープンソースプロジェクトの品質を評価するために、星の数以外にも使用できる指標について以前議論しました。もちろん、ここでの「品質」とは、オープンソースソフトウェアの活用度だけでなく、プロジェクトコミュニティの健全性と持続可能性も指します。最近、業界の専門家がオープンソースプロジェクトコミュニティの発展を評価するための2つの新しい指標を提案しました。 今日、オープンソースプロジェクトに関する参考となる指標は数多く存在します。例えば、スター、フォーク、プルリクエスト（PR）、マージリクエスト（MR）、コントリビューター数などです。PingCAPの元グローバル戦略・オペレーションディレクターであるKevin Xu氏は、これらの明白な指標は、スターやフォークの数を人為的に水増ししたり、PR数を増やすために大きなコンポーネントを意図的に小さな部分に分割したりするといったマーケティング戦略の影響を受けやすいと考えています。ほぼすべての指標は悪用される可能性があり、オープンソースプロジェクトの健全性と持続可能性の評価に不正確な結果をもたらし、場合によっては重大な歪みが生じる可能性があります。 そこで、Kevin は次の 2 つの新しい指標を提案しました。
これら 2 つの指標を継続的に追跡、測定、最適化することで、オープンソース コミュニティの健全性をより客観的かつ継続的に評価し、プロジェクト マネージャーが強力で自己改善するオープンソース コミュニティを構築できるように支援します。 なぜこれら 2 つの指標なのでしょうか? ケビンは、あらゆるオープンソース・プロジェクト・コミュニティの長期的な目標は、初期の作成者やメンテナーが去った後もプロジェクトが繁栄し続けることができる転換点に到達することだと考えています。この目標は、オープンソース技術に基づくオープンソース・ソフトウェア（COSS）を商用化する企業にとって特に重要です。創設者の離脱によりオープンソース・プロジェクトが停滞した場合、それを商用化する企業は壊滅的な結果に直面するでしょう。 これは高い目標ですが、それを達成できるプロジェクトはほとんどありません。 メンテナーの燃え尽き症候群は広く蔓延している問題です。最近の例としては、Redisの作者であるSalvatore Sanfilippo氏が挙げられます。彼は昨年、オープンソースのメンテナーとしての苦悩を語り、今年初めにRedis LabsのCEOを辞任しました。実際には、規模を問わず、様々なプロジェクトのメンテナーが日々同様の燃え尽き症候群に苦しんでいます。 したがって、特にプロジェクトのオープンソース化の早い段階でこれら 2 つの指標に焦点を当てると、持続可能性を確立できる可能性が高まります。なぜなら、これらの指標は、プロジェクトの持続可能性を推進する 2 つの重要な要素である所有権とインセンティブを示すからです。 細分化されたPR/MRレビュー担当者 = 所有権 この指標は、コミュニティ内で誰が積極的に貢献をレビューしているかを追跡するため、所有権の指標として有効です。プロジェクト開始当初は通常、作成者がレビュー作業の大部分を担当しますが、プロジェクトが成長するにつれて、この状況は維持できなくなります。コミュニティ管理者は、早い段階で積極的にこの状況を育み、潜在的に優秀なメンテナーを採用し、適切な権限委譲を行うことができます。リーナス・トーバルズがLinuxカーネルのサブメンテナーを採用したように、より多くの人々に、受信したプルリクエスト／レビューをレビューするための背景知識、自信、そして積極的な姿勢を与えることは、プロジェクトの長期的な持続可能性にとって不可欠です。 一方、貢献のレビュープロセスは顧客サービスに似た要素を持っています。レビュープロセスに十分な数のメンテナーが関与していない場合、PRやMRが2週間、あるいはそれ以上も見過ごされてしまう可能性があります。これは熱心な新規参加者にとって大きな打撃となり、コミュニティにおける新規参加者の成長に影響を与える可能性があります。 コミュニティ交流リーダーボード = インセンティブメカニズム コミュニティ指向のインタラクションを追跡し、コミュニティ内での報酬などを活用してゲーム化することで、経験レベルの異なるコミュニティメンバー間の積極的なエンゲージメントを促進することができます。コミュニティ管理者が追跡できるインタラクションには、PR/MRの提出数、コメント、提案などが含まれます。これらのインタラクションの価値や質は様々ですが、より大きな目標は、誰が何をしているか、誰が何に優れているかを把握し、人々の強みや興味に基づいたユーザー行動を意識的に育成することです。 例えば、有益なコメントを提供するのは非常に得意だが、PR/MRをレビューするだけの技術的背景がまだ十分にない人がいるかもしれません。そのような人を特定し、より多くの情報を提供することで、将来的にメンテナーへと成長できるようにすることが最善策です。また、頻繁に返信するなどプロジェクトのモニタリングに非常に熱心であるものの、コメントや提案には積極的に参加しない人もいるかもしれません。そのような人を把握し、より多くの背景情報を提供してプロジェクトの内部事情を理解できるように支援することは、彼らが大切にしているコミュニティにさらなる価値をもたらす上で有益です。 これらの指標の使い方 では、これらの指標をどのように追跡し、解釈すればよいのでしょうか？ケビンはオープンソースプロジェクトの2つの例を挙げて説明しました。
Kevin は、オープンソースのデータ視覚化ツール Apache Superset を使用して、Kong および Apache Pulsar プロジェクトからいくつかのデータを収集しました。 PRレビュー担当者のメトリクス 以下の 2 つの画像は、過去 2 年間の GitHub における Kong と Pulsar の PR 応答を示しており、異なる色は異なる PR レビュー担当者を表しています。 このデータに基づくと、KongのPRレビュアー比率はPulsarと比較してより「バランスが取れている」ことがわかります。この「バランス」は、Kongプロジェクトが成熟するにつれて達成されました。最も重要なのは、Kongの開発者であるAghiとMarcoが、PR対応に最も積極的に参加するメンテナーではないことです。これは良いことです。言い換えれば、プロジェクトが成熟するにつれて、Kongコミュニティはコードレビュー作業の一部においてプロジェクト創設者に代わるだけの十分なメンテナーを育成してきました。これは、プロジェクトの持続的な発展にとって明るい兆候です。 Pulsarは比較的新しいプロジェクトであるため、まだこのレベルには達していませんが、このバランスの実現に向けて着実に歩みを進めています。プロジェクト管理委員会のメンバーであり、PulsarのCOSS企業であるSteamNativeのリーダーであるSijie、Jia、Penghuiが、レビュー作業の大部分を担当しました。Splunk（特にStreamlioの買収後）をはじめとする他の主要企業もプロジェクトに貢献しており、これは最終的にバランスが実現されることを示す良い先行指標となっています。 注：Kevinは、Apache Software Foundationプロジェクトと他のプロジェクト間のガバナンスプロセスの違いを意図的に無視しました。この違いは、コントリビューターがレビュアーやメンテナーになる際のスピードや資格に影響を与える可能性があります。したがって、この比較は実際の状況を完全に反映しているわけではありませんが、コミュニティのガバナンスプロセスがプロジェクトメンテナーに与える影響についての洞察を提供することができます。 コミュニティインタラクション指標 以下は、PR、コメント、レビュー、その他のインタラクション データなど、最後のデータ収集以降の 90 日間 (およそ 2020 年 3 月から 5 月) にわたる Kong と Pulsar の GitHub でのコミュニティ エンゲージメントを示す、インタラクション メトリックの 2 つのリーダーボードです。 インタラクション リーダーボードには、前の指標と同じ「バランス」が反映され、誰がどのようなインタラクションを行っているか、何回インタラクションが発生したか、これらすべてを誰が行っているかが明確になります。 適切なインセンティブ構造を確立するために、このリーダーボード形式のビューは、コミュニティ マネージャーがインタラクションのソースを理解し、これらの肯定的なインタラクティブな行動を促進するための適切な報酬またはインセンティブ システムを設計するのに役立ちます。 このデータは、社内管理や外部コミュニティの構築にも役立ちます。詳しく見てみると、これらのチャート上のリーダーの多くは、プロジェクトのCOSS企業であるKong Inc.とStreamNativeの従業員であることがわかります。実際には、コミュニティに積極的に貢献する人がプロジェクトの商業化企業の従業員になることは珍しくありません。これらの人々がどこで働いているかに関わらず、初期のクリエイターの枠を超えた持続可能なプロジェクト（ひいてはCOSS企業の持続可能性にも影響します）を育成するには、ポジティブな交流を測定、追跡し、インセンティブを与えることが不可欠です。 最後に、どんなに美しいグラフでも、データだけで全てがわかるわけではありません。また、プロジェクトがどれほど成功しても、その経験をテンプレート化して他のプロジェクトにそのまま適用すべきではありません。プロジェクトマネージャーは、これら2つの指標を巧みに活用し、誰がプロジェクトに貢献しているかを把握し、プロジェクト関連のドキュメントを積極的に維持管理し、プロジェクトの貢献度に明確な品質基準を設定し、適切な採用基準を設定する必要があります。新規メンバーの量と質のバランスをとることによってのみ、真に持続可能なオープンソース・プロジェクト・コミュニティを構築できるのです。 この記事はOSCHINAから転載したものです。 記事タイトル: Windows/Linux コード共有、Linux カーネル開発者: 否定的なレビュー この記事のアドレス: https://www.oschina.net/news/120749/linux-graphics-why-sharing-code-with |
