僕たちは Drupal 7 を（Drupal 6 よりも）使いやすくした。その一方で、サイト構築者にとっての機能をより豊富にした。コア開発者たちにとってはより複雑なものになったが、それは驚くようなことではない。１つのソフトウェア アプリケーションが進化するにつれて、その複雑さを保持または減少させる作業が行われないかぎり、複雑さは増大するからだ。
そうなるとフラストレーションが増える可能性がある。ソフトウェアの複雑性は（コードに）変更を加える障害になり、バグが生じる原因にもなり得る。新しいコントリビューターも参加しにくくなる。（こうしたことから）コア開発者たちの間には、Drupal の複雑さを減らすための処置をとらなくてはならない、という全般的な心情がある。僕も心からそれに同意する。
Drupal コアの複雑度を減らすため、コミュニティー内の人々が大勢、いい提案をたくさん寄せてきてくれた。それは「不必要な機能を取り除く」に始まって「システムを分離する」や「API と抽象化を改良する」にまで至る。実行を検討すべきものばかりだ。実際、僕たちはすでに、Drupal 8 開発ブランチから不必要なモジュールと機能をいくつか取り除いた。（話の順序としては）最後になったが大事なことをもう１つ。僕は Drupal 8 のコーメンテナーを１人、任命しようと思っている。それは Drupal コアの複雑性を調整するサポート役を担えるだけの技術的なスキルをひととおり備えた人物になるだろう。
みんなに考えてみてほしいこともある。歳月が経つにつれて Drupal の複雑度がどう進化していくかを（数値の形で）測定できたらいいなと思う。測定できれば「Drupal 7 は Drupal 6 よりも 30% 複雑になった」とか、「この Drupal サイト構造の複雑度スコアは 420」とか、「このパッチは複雑度を 12 ポイント下げてくれる」とか言えるだろう。
「Drupal 複雑度スコア」なるものを案出できるかどうか見てみたいと思う。それには当然のことながら、次のようないくつもの測定基準を組み合わせるのが大事だろう。(1) 関数あたりの呼び出し数、(2) 関数あたりのモジュール間の呼び出し数、(3) 関数の平均サイズ、(4) API 関数の入力引数の数、(5) 関数あたりのコメント数、(6) グローバル変数に対する参照の数、(7) 異なるコード パスの数、などだ。
「Drupal 複雑度スコア」は万能薬ではないし、完ぺきなスコアリング システムを得ることなど不可能だろう。しかし（僕たちのテストボットや DrEditor を含めた）パッチ レビューのワークフローにベーシックな「Drupal 複雑度スコア」を統合するだけでも大きな利益になるだろうと僕は信じている。測定できないものを管理調整するのは難しい。（だから、このスコアができれば）最小限（の手間）でレビューアーとメインテナーひとりひとりの目の前に「複雑度の軽減」を掲げることになるだろう。
いい考えはあるかな？