OSSの長期利用とメンテナンス に参加した

本ブログは個人のものであり、所属する団体の意見等では一切ございません。
というか、参加自体も仕事じゃなくて個人ですし。私はプラント系の人ではないので推測が多分に含まれています。
間違っていたりしたらこっそり教えてください。いつもにまして脳内ダンプ・ポエム感。

OSSの長期利用とメンテナンス

昨日はCIPは元の意味で塩漬けを作ろうとしていることを十分に理解することができた。
CIPの通りすがりの人が、こっちの塩漬けと良くない意味での塩漬けの意味が違うと言っていた意味が今ならわかる。https://t.co/8xvfbzQMLp

— nekomatu (@nekomatu) 2018年10月5日

塩漬けってそもそも腐敗を防ぐ知恵でしたよねみたいな。

— nekomatu (@nekomatu) 2018年10月5日

最初のきっかけは、とある人のCIPに対するツイートを見てうーん、CIPの人がそんな事を考えていないはずがないけどどうなってるんだろー？と気になったからでした。それだったら会場提供するよ的な話になって20人近く参加するイベントになっていました。
ガチ勢の方が多くびっくりしました。

CIPというのはLinuxFoundation配下のプロジェクトで、 Civil Infrastructure Platformのことです。社会インフラ向けのLinux・OSSの利用についてやっていこう的なプロジェクトです。プラント系なのでサポートがミニマム10年とからしいです。
https://www.cip-project.org/

CIPの活動の中でLinuxカーネルのSLTS（SuperLongTermSupport)というのがあるのですが、長期に渡ってバージョンを固定化してFixPatchを当て続けるのはどうなのか？みたいなのが最初の問題提起的なものでした。

Civil Infrastructure Platform Announces First Super Long Term Support Kernel at Embedded Linux Conference Europe
Linux4.4を10年はサポートしていくというブログ

理屈上は十分なテストケースとバリデーションを通せれば、カーネルのバージョンをBump-upしても問題ないのではないかという前提があります。古いカーネルにパッチを当て続けることは容易では無いため、これらの工数やお金をテスト等に回すほうが健全ではないのかという発想です。
これに対しては、やはりバリデーションの難しさ・過去のアセット利用等が背景としてあることが述べられました。

例えば、最終的な受け入れテストなどはプラントに入れてから行ったりします。機能安全については第三者機関に出すことなどもあります。このような体制は比較的昔からあるものだという理解が必要です。こういった時、セキュリティパッチだけを当てて影響範囲はこれだけですというレポートの提出で済むか、テストケースが全部通っているのでバージョンのBump-upしますが通じるかというシチュエーションが容易に想像できます。

過去のアセットとは、ソフトウェア資産を想定した私が最近好んで使うタームです。（ルー大柴みたいな表現になっているのは許してほしいです）
つまり、プラントのような規模が大きいシステムを毎回1から作るのは非合理的ですし、機能安全規格をPASSしたモジュールなどがあれば使いまわしたいと考えるのが一般的です。つまり、枯れたコンポーネントを積極的に使う動機があります。しかしながら、弱点もあって設計そのものがモダンではない、テストが不十分であるといった時代的な課題も抱えていることが想定されます。そうすると、バージョニングの固定が現実的な最適解になルノではないかと思われます。
これはプラントに限らずあるある話なような気がしています。

バージョニングの固定が最適解になりがちというのを過去のアセットという観点で述べてみました。もう一点、これを正当化(Justification)している根拠としてはプラント系はEOLがおおよそ定まっているという要素があるのではないかと私は推測しました。端的に言えば設計寿命であり、一度入れたものをノーメンテナンスで壊れるまで使い続けるということはあまり考えにくいです。ですから、メンテナンスサポートも含めて収益でありビジネスになっているのであれば、バージョニングの固定はシンプルな発想です。

ところで、製品寿命は存外自明ではありません。
皆様は「長期使用製品安全表示制度」というのをご存知でしょうか。最近、扇風機などを買うと「設計上の標準使用期間 ： 10年」とか書かれているシールが貼られていたりします。どうゆうことかというと、扇風機とかうっかりすると30年ぐらい使い続けたりします。すると、コードやモーターの劣化に起因して火災が発生したりとか出てきたりしたんですよね。これを防ぐために注意喚起情報を付与することが今では行われています。
他にも「補修用性能部品の保有期間」といって、修理に必要なパーツを何年保持しますと表示しているメーカーもあります。（この辺りは法的なものかは未確認）

さてソフトウェアという観点ではどうでしょうか。スマホはプライバシーの塊とも言えるかと思いますが、ソフトウェアのセキュリティ的な安全性は何時までどのように担保されているか考えている人はどれくらいいるでしょうか。
IoTマルウェアのMiraiや監視カメラの初期パスワードアタックなどはかなり有名ですが、どこまでどのようにサポートされるべきなのでしょうか。
ソフトウェアも製品に組み込まれている部品の1つですが、これがクリアリーになっているケースはそこまで多くありません。
スマホの例だと、Googleが出しているブランドのNexus・Pixcelシリーズはセキュリティアップデートの日付を明示しています。一方で、これを認知しているユーザーの割合や、サポート期間を超えて使い続けた場合についてはまだまだ社会的なコンセンサスや認識が無い状況だと認識しています。

目指していきたい方向性

ここから脳内ダンプ。ポエムがさらに深刻になってきます…。とほほ。

主にWeb系でマイクロサービスアーキテクチャという話がありますが、これは組込みとかにも言えるんじゃないかなーと思っています。
コンポーネントを疎結合にというのもあるのですが、もう少しトータルデザインとして。APIやインターフェースを界面として個々の品質や実装については担保されていて入れ換えの自由が効くように。

転換期のつらみ

私の考え方としては、今は転換期のつらみと捉えています。
コンピューターテクノロジーの進化はどの産業よりも変化が早く急速に社会を変化させていきました。ここに、コネクティビティ（ネットワーク）が加わったことにより物理的な制約条件をしばしば突破する強烈なインパクトをもたらしています。現代のソフトウェアは一人では見きれないほどの複雑で非常に高度なものになっていて、しばしばセキュリティ的な問題が含まれ時に狙われるという状況になっています。

高度なソフトウェアを新規でほいほい書けるかというとまだ世の中はそうはなっていないようです。そのために、過去のアセットを使わざる得ない状況があります。ベンチャー企業とか新規参入者はこの辺りが付け入る隙になっていると思います。逆の観点から言うと新規参入障壁とかそういった言葉が出てくる気がしています。

Amazonは元々本の流通をやっていたわけですが、電子書籍を始めちゃうように自分自身で破壊的なイノベーションをしていけるのは相当強いし、やっていかなければいずれか新規参入勢にやられちゃったりするんじゃないかなーと思っています。

終わり。