Drupalのコミュニティモジュールを評価する方法
Collection :
本記事は Evaluating Drupal Community Modules の抄訳記事です。
Drupalコミュニティから提供されるモジュールを使用する場合、機能的な使用方法だけでなく、自身の組織が使用するのに適した品質とサポートであるかなど考慮すべき要因が多くあります。
Drupalサイトを本番環境にデプロイするとき、誰がその保守に責任を持つのか、そのサイトはどれくらいの期間存続するのか、などの問いはプロジェクトのリスク許容度を具体化します。例えば、Drupalの経験値が低い場合、多くのコミュニティサポートと安定したモジュールが必要になります。
Drupal.orgのすべてのモジュールはGPL v2ライセンスで公開されたオープンソースソフトウェアです。自己責任の元、自由にダウンロードして使用できます。プロジェクトごとにメンテナとサブコミュニティがあり、モジュールを利用したり、issuesで会話したり、バグ修正や機能強化に貢献できます。
| モジュールの品質、それを取り巻くコミュニティのボリューム、コミュニティの活動やモジュールの安定性を知ることで、モジュールを使用する際のリスクを概算できます。 |
それでは、実際に存在するコミュニティモジュールの「Feeds」を例に、評価基準について紹介します。
コミュニティかカスタムか
コミュニティから必要な機能が提供されていない、もしくは組織として使用するにはリスクが高い場合、次のような選択肢があります。
- 必要な機能を絞り込みます。求める機能に最も適しているプロジェクトを見つけ、機能リクエストを送信します。これはコストとリスクを最も削減できる方法です。
- 既存モジュールの追加開発に資金を提供し、許容できるリスクレベルまで引き上げます。
- メンテナンスと機能拡張に向けたコミュニティの貢献を期待して、新しいモジュールを開発しコミュニティに提供します。
- オーダーメイドで機能を開発し、その機能をコミュニティに還元しません。
各アプローチには異なる度合いのコスト、労力、リスクが伴います。特に最後の選択肢のカスタムコードは、リスク、労力、コストをコミュニティと共有することができないため、常に高いコスト、労力、リスクを伴います。
| 機能を提供する必要がある場合、既存のモジュールを利用するのが最善の方法です。開発時間が短縮され、メンテナンスコストをコミュニティで共有することができます。 |
モジュールの選定基準
Drupalコミュニティのプロジェクトを評価する際には、以下の基準を考慮することをお勧めします。モジュールが提供する機能的な付加価値に対して、どの程度のリスクを許容するかによって、組織がとりえる適切な閾値を決める必要があります。
メンテナのコミット数
プロジェクトへのコミット数は、メンテナの活動とプロジェクトの成熟度の両方を示す指標となります。
- コミット数が多いということは、メンテナが活発であり、プロジェクトが成熟していることがうかがえます。これは、モジュールがより安定している、もしくはより優れた機能を備えていることを示しています。
- コミット数が少ないということは、そのモジュールが新しい、もしくは最小限の保守しか行われておらず、狭い範囲の機能しか持っていないことを表します。
| コミット数が少ないことは欠点ではありません。そのプロジェクトに活発なメンテナがいたり、ダウンロード数（使用量の指標）が多ければ、コミュニティのサポートが期待できるため、モジュールを使うことを選択できます。 |
コミット数はソースコードプロジェクトページから確認できます。Feedsモジュールの例では、プロジェクトページの右サイドバーの下の方にSource codeのリンクがあります。このリンクをクリックすると、ソースコードプロジェクトページに移動し、リポジトリのコミット数を見ることができます。
プロジェクトが古ければ古いほど、基本的にコミット数は多くなります。Feedsモジュールは公開されてから13年経過しており、年間平均135コミットとなっています。これはDrupalのコミュニティプロジェクトとしてはかなり良い数字です。このレベルに達するものはそう多くはありません。また、Feedsは多くの機能を持つ包括的なプロジェクトです。より狭い機能セットを持つモジュールでは、もっと低い数字になることが予想されます。
最後のコミットがいつ行われたか
コミュニティプロジェクトは、メンテナ自身がモジュールを必要としている時に活発になる傾向があります。もちろん、その活発性が長く続かない場合もあります。
- 最新コミットが直近1ヶ月である場合、活発なメンテナであることを示します。
- 最新コミットが3ヶ月以上空いている場合、メンテナやコミュニティが活発ではないことが示唆されます。
| プロジェクト周辺のコミュニティが活発でないほど、バグ修正や機能強化に対してコミュニティからサポートを得ることが難しくなります。 |
コミュニティの活動が少ないモジュールを使用すると、リリースサイクルが遅くなることが予想されます。つまり、サポートやバグ修正を自身で行わなければならない可能性があるということです。
モジュールが複雑であればあるほど、活動の低いコミュニティに対するリスクは大きくなります。
Feedsモジュールのソースコードプロジェクトページを見てみると、アクティブブランチの最終コミット日が表示されていることがわかります。
モジュールを使用しているサイトの数
コミュニティのメンテナは、プロジェクトのリリースの安定性を完全に制御できるため、リリースのバージョン管理が信頼できない指標になる可能性があります。代わりに、モジュールの使用を報告するサイト数を参考にして、多様なユースケースへの露出度を示す指標として使用できます。issueキューにある未解決のissueの数と組み合わせることで、実際の安定性がわかります。
| モジュールがより多くのサイトに公開されていればいるほど、自身のユースケースでモジュールが規定通りに動作する可能性が高くなります。 |
Drupal.orgは、DrupalコアのUpdate Managerモジュールから取得される使用情報を提供します。このモジュールがサイトで有効になっていると、どのモジュールが使用されているかをDrupal.orgに報告します。この情報はDrupal.orgのプロジェクトページで見ることができます。
上記は、Feedsモジュールのプロジェクト情報です。98,000以上のサイトで使用されていることがわかります。これだけ使われているということは、多様なアプリケーションに適していること、そして安定性があること、つまりこれだけ採用されていることを示す素晴らしい指標です。
プロジェクトリリースの安定性
メンテナは、安定性とサポート性を考慮して、プロジェクトのバージョンをリリースします。一般的な定義はありますが、コミュニティのメンテナが全てそれに従っているわけではないことに注意してください。
| リリース | 説明 |
|---|---|
| dev | リリースブランチでの最新の変更が反映されるリリースです。例えば 1.x-dev は 1.x ブランチの最新のコミットが含まれます。 |
| alpha | alpha(アルファ)リリースは、リリースブランチのスナップショットポイントにタグ付けされます。これは本番環境では未検証とされておりまだ安定していません。また、メンテナやDrupalセキュリティチームからのサポート対象外とされています。 アルファリリースは、いかなるアップグレードパスを約束しません。メンテナはアルファリリースから分岐して、アップグレードパスを維持しない可能性があります。 アルファリリースの目的は、対象のモジュールを使うことに興味がある人たちが、様々なフィードバックやコードの提供を通じて貢献できるようにすることです。場合によっては、本番アプリケーションで使用できるほど安定していることもありますが、そのサポート性には高いリスクが残されています。 |
| beta | ベータ版はプロジェクトのAPIを固定して、安定版へのアップグレードパスを提供することを目的としています。ベータモジュールもまだメンテナやDrupalのセキュリティチームからのサポートはありません。 |
| rc | RC(Release Candidate)はリリース候補を意味します。この時点で、モジュールがほとんど安定していると見なされ、x.0リリースを確定するためにさらなるテストを行います。多くの場合、リリースブランチの最後のRCリリースが x.0リリースになります(例: 1.0 や 2.0)。 |
| stable | 安定版は、メンテナがモジュールを維持することを望んでおり、Drupalセキュリティチームによってセキュリティカバレッジを提供できることを意味します。 |
| ほとんどのコミュニティプロジェクトは、安定したリリースポイントに到達していないにもかかわらず、活発なコミュニティと高い採用率を維持しています。それは、提供する機能がそのモジュールを使うことに伴うリスクよりも大きな価値があるからです。 |
Feedsモジュールの現在のリリースを見てみましょう。
Feedsモジュールは13年前に開発され、Drupal 8から利用可能であるにもかかわらず、まだベータ版です。しかし、このプロジェクトは高いコミュニティエンゲージメントを経験し、活発なメンテナがいます。ベータ版であるため、Drupalセキュリティチームによるセキュリティカバレッジはありません。
| セキュリティカバレッジ対象外の場合でも、コミュニティモジュールを使用することが優先されることがあります。将来的にセキュリティカバレッジが提供される安定リリースが提供される可能性があるためです。新しいモジュールを作成するとより大きなコストがかかり、セキュリティカバレッジももちろん適用されません。 |
未解決/解決済みの問題、未解決のバグ
これらの数字は2つの重要な指標を提供します。
- プロジェクトがどれだけ発展しているか (記録されたissueの数で示される)
- メンテナがどれだけ活発か (解決またはクローズされたissueの数で示される)
サイトの利用が多く、issueの量が少ないことは、プロジェクトの安定性が高いことを示しています。モジュールを使用するサイトの数によってチケットの量が増加することを予期しています。したがって、チケットの数はモジュールを使用しているサイトの数に比例していると考えてください。
以下は、Feeds モジュールのissueの統計です。
Feedsモジュールには、833件の未解決のissueがあります（81%は解決済み）。そのうちの30%はバグレポートです。このモジュールを使っているサイトが98,000以上あることを考えると、約0.26%のインスタンスで未解決のバグが報告されていることになります。これは、安定版リリースがないにもかかわらず、非常に安定したモジュールであることを意味します。
| 上記の数値は、13年間にわたるプロジェクトの総体的なものです。現在の3.0-betaの使用状況やキューにある特定のissueは、ベータ版の状態をよりよく反映しているかもしれません。しかし、モジュールを評価するとき、将来への影響を評価したいので、過去のパフォーマンスはその有用な指標となり、この文脈では、Feedsモジュールはかなり信頼性の高い使い方になるでしょう。 |
Drupalとの互換性
そのモジュールはDrupalの最新バージョンをサポートしていますか？次バージョンのDrupalはサポートされますか？このように、将来的な互換性のあるモジュールを選択することで、アップグレードパスに早くアクセスできます。Drupalコアのサポート終了のバージョンを使用せざるを得ないようなリスクを軽減することができます。
例えば、Drupal 9を使用していてまだ10を使用していなくても、Drupal 10の互換性は重要です。Drupal 10と互換性のないモジュールを使用することは、アップグレードパスのリスクとなります。
歴史的に、DrupalコミュニティはDrupalの次バージョンへのアップグレードを維持するために、アップグレードパッチを発行するアップグレードBotを実行してきました。issueキューでこのようなissueを探すことで、プロジェクトがDrupalの次のメジャーバージョン（本記事の執筆時点ではDrupal 10）の互換性にどのようにアプローチしているかを確認することができます。例として、Feedsモジュールのissueを紹介します。
| Drupalコアの開発サイクルが今どの段階にあるのかで、コミュニティモジュールの将来的な互換性の判断は異なる場合があります。しかし、モジュールの利用率が高く、コミュニティが活発であればあるほど、コミュニティが提供するアップグレードパスを確保できる可能性は高くなります。 |
まとめ
オープンソースソフトウェアでは、使用するソースコードの所有権をしっかり確保することで、最終的にリスクを管理することができます。コミュニティの機能とサポートを活用することで、コストを削減することが可能です。リリースのバージョンの安定性を示す指標よりも、高い採用率、強力なコミュニティ、メンテナを持つDrupalモジュールを探してみてください。
プロジェクト初期段階では安定性の低いモジュールを受け入れて、プロジェクトが成熟するにつれてその安定性に貢献することができます（これはしばしばUAT/QAバグ修正作業を通じて組織的に行われます）。
組織によってDrupalの開発能力やリスク許容度は様々であり、一律に対応できるアプローチはありません。
Director of Product Management Acquia
