0059 号 巻頭言
初稿：2019-01-27
世界を飲み尽くした後のソフトウェアとその保守
あまり Ruby と関係ないことを書く。
先日、epubcheckというツールの最新版である v4.1.1 がリリースされた。
epubcheck は epub をチェックするという、その名の通りの epub validator ツールである。 Web の開発に関わっている方であれば、HTML に対する HTML Lint や Nu HTML Checker、CSS Validator 等は使ったことがある方もいるかもしれない。 それらを合わせた上、さらに EPUB 固有の validation も追加したようなツールである。validation というと比較的賢いツールを想定されるかもしれないが、Ruby で言うと rubocop というよりは ruby コマンドの -c オプションつきの実行に近い。「ダメなやつを弾く」ためのツールとして使われている。
epub の制作者であれば、epubcheck を使ったことがある人が多いだろう。というのも、epubcheck を通らない epub は一般的な電子書籍書店で販売できなかったり、ツールによっては表示できないことがあるためだ。
epub は雑に言うと HTML と CSS で作る電子書籍用のファイルフォーマットである。これらのファイル群の概要とメタデータを記述した XML ファイルと合わせて zip で固めて 1 ファイルにして配布できるようにしたようなものなので、Web ページを作れるような人であれば比較的簡単に作ることができる。が、簡単に作れるのと同じくらい簡単に壊れたファイルも作ることができるのに加え、電子書籍の閲覧に使うリーダーアプリは各社独自に作られているため、動作検証が困難になる。そこで最低限の検証としては、「epubcheckで通る」ということを条件にすることになっている。そのため、電子書籍の制作工程の最後には epubcheck で error や warning が出ないことを確認する、というプロセスが現れる。
ところでなぜ epubcheck の話を書いているかと言うと、v4.1.1 には私が書いた Java のコードがいくつか入っているためである。そう、Java である。
自慢ではないが現代的な Java プログラミングは素人である（こう見えても Web のキャリアだけは無駄に長いので、遠い昔に Struts のコードを触ったことはあるのだが、それくらいである）。maven の使い方もよく知らないというか、epubcheck をビルドするとき以外、mvn コマンドを実行したことがない。
そんな私がなんで Java を書いているかというと、他に誰も直していなかったからだ。少なくとも私が pull request を投げるまでは他に直しているのを見かけなかった。
繰り返しになるが epubcheck は epub の制作者なら普通によく使われているツールである。にも関わらずメンテナンスには苦労しているようで、開発継続のための資金援助の呼びかけが行われたりしており、それなりに支援もあるようだが、一時期よりはアクティブに見えるとはいえ、開発が盛んになっているようにはあまり感じられない。
もっとも、中身はあまりわかりやすい構造になっているわけではない。epub の規格自体、HTML の仕様と CSS の仕様を適当に組み合わせた上でちょっといじり、さらにバンドルするための XML ファイルと zip の形式を定めた、悪くいうとツギハギ的な仕様になっている。電子出版で Web と異なる不思議な独自仕様を作られるよりはよほどマシだと言えるが、そうはいっても出版とは別のコンテキストのものをそのまま持ってきたため、うまく統合されているとは言い難い。
epubcheck はこの epub 自体の経緯に加え、スキーマ記述言語として RELAX NG や Schematron による制約記述があったり、また途中で大量にコントリビュートがあったものがうまくマージしきれていない（Java のコードが org.idpf.epubcheck と com.adobe.epubcheck に分かれているのはこのためだと記憶している）というのもあり、整理されていない感が強い。とはいえ、単純に開発をするだけなら Java の知識に加え HTML や CSS の仕様書が普通に読めれば大抵はなんとかなるだろう。
私よりまともな Java が書ける人は日本だけでも何万人といるだろう。日本に限定する必要はない（EPUB の新し目の仕様である EPUB 3 には縦書きの標準が含まれているため、日本では特別に EPUB 3 が広まっている傾向があるかもしれないが）。epubcheck は海外でも普通に使われており、その需要があるのは日本に限らない。にも関わらず、手を挙げる人はほとんどいない。
もちろん影響はそれなりにあっても修正の規模としてはさほど大きくないバグがあるということであれば、普通に仕事として誰かに発注されればそれで済む程度の話ではあるのだろう（というかバグがあるんなら W3C に限らず誰かが発注するべきだったのでは……？ と思わないわけではない）。しかし、長期的なロードマップを考えれば個別の不具合に対し積極的にコストを投下し続けるのも難しそうである。
Marc Andreessen の書いた「Why Software Is Eating The World」は、ここ数年いろんな文脈で参照されている。彼の言う通り、ソフトウェアがあらゆる産業を飲み込みつつあるのは確かだろうというのは、執筆時点よりも今の方が切実に感じられる。そしてそのソフトウェアの中でも、それなりの割合は無償で利用できるオープンソースソフトウェアが含まれているのも確実だろう。
一方で、オープンソースソフトウェアがあらゆる産業を支えきれるほど潤沢に開発リソースを持っているわけではない。あっという間にさまざまなプロダクトの開発が停滞し、または破棄されるだろう。その時点で代替があれば移行も可能かもしれないが、そうではないものもあるだろう。
ソフトウェアが世界を飲み尽くし、ソフトウェアなしに動かなくなった世界において、誰がどうやってソフトウェアで使われる無保証で免責されたオープンソースソフトウェアを保守し続けるのだろうか。無事に修正版がリリースされたことに安堵しながらも、どうにも釈然としないものがあったので、この場を借りて疑問を吐露してみた。
(るびま編集長 高橋征義)