プロトタイプから導入後まで、 Linux の判断ポイント
Feb 09, 2022 • Linux
By Brandy Goolsby
私たちは皆、人生で一度は意図しない結果を招くような判断をしたことがあるのではないでしょうか。その判断は時に、経済的・品質的なリスクを生むことがあります。我々は最近、 Linux やオープンソースをベースにした製品を開発するかどうかを判断する際の、意思決定プロセスについて紹介する興味深いウェビナー「The Linux Journey from Prototype to Post Deployment」を公開しました。ウェビナーはこちらからご覧いただけます。
意思決定プロセスは、プロトタイピングから始まり、定義、開発へと進みます。そして、製品の生産、デプロイメント、メンテナンス、 EOL（End-of-Life）に至ります。組込み業界では、製品のライフサイクルは5年、10年、時には15年以上にも及ぶこともあります。
プロトタイプをクリアし、プロジェクトの開発予算が得られた後も、 Linux ソリューションに関していくつもの意思決定ポイントを通過していかなければなりません。これらの判断は、開発スピード、品質、リソースに影響します。また、将来の拡張性、収益性、プロジェクト全体の成功に直接影響を与える可能性もあります。間違った判断をすると、余計な負債や再リリースの必要性を招きますウェビナーでは、技術的負債について詳しく紹介しています。
このウェビナーで第一に意思決定プロセスについて取り上げたのは何故かというと、基本的に誰もが革新的な製品の開発やニーズに沿ったサービスの提供を実現したいからです。通常、「 Linux をベースにした製品の開発をしよう」と、プロジェクトを立ち上げることはありません。むしろ多くの場合、 Linux やオープンソースは、ソフトウエアプラットフォームの構成要素であり、目的の達成に使われます。 Linux はどこからか調達する必要があり、これはプロジェクトを進めるにあたり、最初に行う重要な決定の一つになります。ウェビナー中に、参加者の皆様に「どのように Linux を入手するか」投票機能を使って聞いたところ、少し意外な結果になりました。その投票では、4つの入手先の選択肢があげられました：
1）半導体ベンダーやボードベンダーから提供されている Linux： 17％
2）Yocto Project Linux や Debian などをベースにした Roll-Your-OwnLinux：27％
3）商用オープンソースプロバイダーからの Linux：10％
4） Linux を採用するかどうか評価を継続中：45％
興味深いのは、「商用OSプロバイダーの Linux を選択」と答えた参加者が10％に満たなかった点です。また、最近の組込み開発がLinux へ移行している傾向にあることを考慮すると、参加者の45％が未だLinuxを採用するかどうか評価の途中である事実には驚きでした。（もし、あなたがLinuxを評価中でしたら「ウェビナ―： OS Options for Edge Use Cases（RTOS vs Linux）」をチェックください。）長い間オープンソースコミュニティに参加している多くのメンバーは、Linuxをまだ採用していない人がこんなにいるとは思っていなかったでしょう。とはいえ、このような結果になったのは、ウェビナーの参加者が主に組込みソフトウェア開発者で、エンタープライズや WEB アプリケーションの開発者ではなかったからかもしれません。組込みの世界では、 Linuxはエンタープライズやインターネット／WEB開発ほど幅広く採用されていません。その理由は、セーフティクリティカルな認証などの多くの組込みユースケースでは、 Linux ではまだサポートされていない機能や性能が求められているからです。
意思決定プロセスの話に戻ります。例えば、上述の選択肢の中から Linux の入手先を選び、定義と開発のフェーズに入ったとしましょう。すると、すぐにまた別の新たな設計上の判断に迫られます。 Linux ディストリビューションを「そのまま使用する」か「変更を加えてから使用する」かの判断です。この判断によって技術的負債の大きさが決定します。
最初に、技術的負債を定義しましょう。 Linux Foundation の定義では、技術的負債は共同開発（コミュニティによる開発）が行われるメインブランチからの逸脱によって発生したソースコードの保守コストを指します。原則、この定義は、リリースされた Linux をそのまま使わないのであればパッチもしくは「フォーク」と呼ばれる変更をしなければない、ということを意味します。そしてほとんどの場合、製品のライフサイクルを通してとは言わないまでも、数回のリリースの間は、それらのフォークを維持するためのコストが発生します。リスクやコミットメントに見合うだけの、技術的負債を抱える正当な理由があるかもしれません。以下のリストは、技術的負債を抱える一般的な理由です。
・リリースまで時間が限られている：スケジュール内でのリリースの必要性から、最新の Linux と同期することができず、期間内にリリースするには、自社で作成したほうがはやく、後でオープンソースと同期する予定である。
・イノベーションを実現したい：自社開発チームが、オープンソースコミュニティが提供するどの機能よりも優れた機能を開発する可能性を秘めているため、アップストリームとオープンソースの調整に時間を割きたくなかった。
・競争優位性のある機能を実現したい：競合他社との差別化のために独自の機能を搭載するには、その機能をサポートする必要性から、オープンソースにパッチを適用しなければならなかった。オープンソースにパッチをアップストリームしない理由は、コミュニティがこれらの変更を受け入れないため、あるいはアップストリームせずに自社製品固有のパッチを保持したいため。
・ポリシー：組織によっては、オープンソースへの貢献に関して厳密なポリシーがあり、アップストリームを行わず、コミュニティと連携しないという社内判断がある。
・スキル/情報不足：組織がアップストリームのための情報やスキルを持っていない、もしくは、プロセスを経たコードを提供するオープンソースコミュニティとの間に必要なリレーションシップを築けていない。
どのような理由であれ、設計を決定しなければならない時点では、これらは正当な理由となります。そして現実的には、複雑で競争力のある組込み機器において、技術的負債を少しも抱えないということは、ほぼ不可能です。最終的に、 Linux プラットフォームは「使用するのに十分である」と判断するのか、それとも、望む機能性と市場投入までの時間という特性の両方を実現できる理想的なバージョンを使用するのかを判断することになるかもしれません。
苦労するのは、次のリリースの開発を始めるときです。「最新かつ優れた」Linuxがリリースされると、誰もがそのLinuxとの同期を望むでしょう。しかし、それをすることは、以前にリリースした製品全てにパッチを適用する必要があり、それら全てが技術的負債になります。したがって、エンジニアは、イノベーションにではなく、フォワードポーティング作業とパッチ適用テストに時間を費やすことになるのです。製品のバージョンが上がれば上がるほど、損失が積み重なります。以前、あるプロジェクトで、3回の製品リリースで累積された、3,000以上の技術的負債のパッチを適用したことがあります。約30人のエンジニアが1年がかりで技術的負債を取り除く作業を行い、オープンソースのメインブランチに同期しました。
プロジェクトの遅延や経費増は、技術的負債が累算することによって生じるコストの一部に過ぎません。比較するのは難しいですが、おそらく同じくらい重要なのは、企業がコミュニティに支払うかもしれないコストです。オープンソースコミュニティはフォークに難色を示しています。また、負債のフォワードポートにばかり時間を取られていると、エンジニアの士気も下がる可能性があります。そして最終的に、長期にわたって質の高い人材を採用することはとても困難です。特に、どこで変更が行われたかを判断するためにコードをフォレンジックできるエンジニアを見つけなければならない場合は、なおさらです。
企業は通常、「十分に良い」オープンソースソリューションを使用する必要があります。もしドライバや機能をサポートするために、 Linux を差別化したり、何か違うことをする必要があるなら、オープンソースコミュニティと連携し、パッチをメインブランチに適用するために必要なことは何でもしてください。
方針の一律化をはかるためのあらゆる努力をしたにもかかわらず、市場投入までの時間を短縮するためにその場しのぎの決断をした結果、技術的負債を抱えることになるかもしれません。このような場合、長期のサポートを行う、 CVE脆弱性監査を行う、またはIPコンプライアンスドキュメントにパッチの適用を組み込む、といったことが必要です。これら全てが、各リリースで積み重なっていくコストとなります。
こうした状況に陥ったとき、それを解決できるのがウインドリバーです。ウインドリバーは、どの Linux を選択したとしても、差別化された Linuxソリューションの導入スピードと品質を高めることのできる、包括的なサポートとインテグレーションサービスを提供しています。Yocto Project、ボードベンダー、他の商用ベンダーのいずれから調達したLinuxであっても、ウインドリバーのLinuxに関する深い専門知識により、お客様の商用Linuxソリューションの成功を支援します。