今年はDrupalのバージョンが9から10に上がる年である。外から見える機能に大きな変化はなく、むしろ基本機能(core)は小さくなる。deprecated code＝非推奨コードがcoreから切り離される。一見奇妙なことだ。
3年前にDriesがブログにDrupal8から9に向けてのブログでdeprecated codeの事を書いていた。
What is deprecated code?
非推奨のコードとは何ですか？
Code in Drupal is marked as "deprecated" when it should no longer be used. Typically, code is deprecated because there is a better alternative that should be used instead.
Drupalのコードは、それがもはや使用されるべきでない場合、「非推奨」と指定されます。一般的には、より良い代替手段がある場合に、非推奨とされます。
ぱっと考えると重複する機能はできるだけ統合して、コードを小さくして品質をあげるのだと受け取れる。
言ってみれば、リファクタリングのプロセスをオープンソースソフトウェアコミュニティに埋め込んだことに等しい。基本的にはD8上のコードはD9でそのまま動く。D8の最後からD9の最初のコードの違いは非推奨コードが落とされたか否かの違いでしかない。現実には、代替手段として提供された機能が代替手段として満たすべき要件を満たしていないことが分かってトラブルになるケースはある。contributionモジュールでは、既存非推奨コードを利用したバージョンと非推奨コードを用いない異なるバージョンのベータ版を併存させるケースは多く見られた。マイナーバージョン（リビジョン）アップでトラブルを出したくないから本番を管理している人からすれば、非推奨コードを呼んでいても安定的に動いているバージョンを使いたいのは自然なことだ。ただ、少し長い目で見れば、あるいは全体最適の視点から見れば、テスト量を含む管理コストは統合を進めたほうが安くなる。
SIで大規模システムのプロマネをやっていた時はリファクタリングの重要性は理解していたものの、ほぼ全ての顧客が「トラブルは出すな」を最優先事項とする。だから、ちょっとした機能拡張はコードをコピーして手を入れてリリースする。コードの呼び出し部分で新旧どちらを使うかを切り替えれば、従前の機能でトラブルが出ることはないが、両方のコードに共通する機能修正が起きるとかける手間は倍になり、修正漏れが発生することもある。時間が経過すれば、コピーしたコードは独自に進化するため、どんどんコード量は増加し、品質が低下していく。そういう環境で機能は変えずに異なるプラットホームで再構築してくれというリライト案件は地獄の苦行となる。機能を変えないなら、ビジネス上の利益はないわけで、そのシステム開発はコストでしかない。できるだけ安くしたいから、リファクタリングが行われることは稀で、本当に必要なコード量の10倍の腐る寸前の脆弱なコードが新環境に移行されることになる。
失敗する大規模システムの移行の多くは元システムが増築を重ねて既に朽ちていることに原因があるのだ。ソフトウェア製品もしばしばその隘路に落ちて消えていく。
MITライセンス等のオープンソースは自由にコピーして書き換えることができる。品質保証はない。下位互換があればコピーして新しいものが増えていくよりは、バージョンアップの方が好ましい。当初のコードの利用者が100人、新コードが出現した時に20人が移行し50人が新たに利用するようになったとすると、トータルユーザー数は150人で、それぞれの利用者は80人と70人ということになる。バグフィックス等にかかるコスト負担は下位互換のバージョン管理ができていれば、150分の1の負担のはずのものが、80分の1、70分の1を負担しなければならなくなり、オリジナルを使っている人の負担額は100分の1で済むはずだったのが割高になってしまう。新規参入者にとっては過去のしがらみに巻き込まれたくないからコピーして独自に手を入れるほうが楽。でもベースとなるコードの進化は止まってしまう。
Linuxがすごいのは、コア部分を管理できている点にある。言い換えればgitの凄さと言って良いだろう。
オープンソースのシェアの大きさは利用者の参入障壁の低さがキーになる。特定目的に合致したものがあれば、それをコピーして手を入れると使えるというのはお手軽で人気の源泉となる。ただ、全体の系で考えると持続性は低い。
そういった事を考えるとDrupalの非推奨コード落としは理にかなっている。モジュールの単位で、coreから落としたとしても、それがcontributionモジュールとしてメンテナがつけばその機能を利用することはできる。しかし、少し長い目で見れば、代替可能なコードがcoreにあるのであれば、それに切り替えたほうが長期的にはコスト優位となる。もちろん、切り替えコストがかかるから、長く使う覚悟がなければ切り替えのインセンティブはない。
公共システムは、本質的にオープンソースと相性が良いのだ。個別にバリアントはあっても類似機能が人口数分必要となり、長期に渡って使い続けられないといけない。政治家は自分の任期期間の事を考えがちだが、官僚は本来ずっと長期視点で取り組むものだ。短期的に目を引く施策も必要だが、メインストリームは持続性があって進化し続けることができるプロセスを確立しなければいけない。同じことを繰り返しているだけでは衰退していくだけだが、アドホックな事を繰り返していても進歩にはつながらない。
今回のDriesnoteを見て感じたのは、Drupalのコミュニティに全体最適を実現できるプロセスを確立させる意思の強さだ。
PHPのバージョンやTwigのバージョン、CKEditorのバージョン対応など、外部環境への対応は不可避だし、常にリファクタリングが機能するプロセスが働かなければ、やがて手に負えなくなるのは明らかだ。堅牢なcore機能を保つにはできるだけコンパクトにしなければならない。一方でテストコードはどんどん拡大する。テストコードの充実は品質に寄与する。
同時にcontributionの品質向上、メンテナ以外の機能向上、品質向上への貢献contributionの容易化に力を入れようとしているところがすごい。正直なところ、gitlabがどのくらい有効なのか、どのくらい壁が下がるのか、プロセスの自動化がどの程度効果を出すのかはまだ理解できていないのだが、方向性は間違っていないと思う。自分が貢献できることはわずかだし、ひょっとするとむしろ邪魔をしているかも知れないと思うのだが、Driesがリードして制定した方針に従いたいと思う。
D11に向けては、もっと積極的に入れ替えを進めるようだ。coreにある機能は、代替機能が育ちにくい。だから、利用率が低いものなどルールを決めてcore機能の流動性を高めようとしている。恐らくcoreとcontributionの境目は、今のようなものでは無くなっていくだろう。今でもcoreでデフォルトでオンになっていないモジュールは複数あるし、ほとんど必ず利用するcontributionモジュールも複数ある。やがて変わっていくが、信頼できる環境としてDrupalあるいはDrupalコミュニティへの求心力は上がっていくだろう。
オバマ時代にアメリカは一歩を踏み出しかけたと思うが、行政はオープンソースにコミットすべきだと思う。通信事業者や電気電子事業者など高度成長期に貢献した事業者に政府が頼るのは分からないでもないが、インフラのコストは安いほうが良い。もちろん、高品質でないと困るが、重要なのは品質が上がっていくプロセスを織り込むことだ。今、頑張っている事業者には申し訳ない気もするが、大きく考えれば舵を切るべき時期が来ていると思う。
ちなみに、Driesnoteではウクライナのcontributionは世界で6位であることが発表されていた。エストニアの政府システムも多くはオープンソースになっている。大金持ちでない国々の成長を支えているのはオープンソースで世界総人口で考えればもうプロプライエタリ全盛の時代は終わるだろう。
DrupalはCMSの世界では、長期的に買いであることは間違いないと思う。もちろん、適材適所でDrupalで全てが解決できるわけではないが、やるべきことをちゃんとやっていればだんだん資産が積み上がっていく。それは利用者の利益となり社会福祉への貢献となる。WordPressのお気軽さの魅力は減ることはないだろうが、長く使うものならDrupal一択だと思っている。