RoTシリコン設計のオープンソース化、着実に進行：プロジェクト担当のlowRISCが報告（2/3 ページ）

[Gavin Ferris（lowRISC），EE Times]

「オープンソースシリコン」、開発を成功させる鍵とは

　オープンソース設計／開発を成功させることは重要な課題の一つだが、それを実現するには、長年にわたる協業的な取り組みが必要だ。歴史的に見ると、オープンソースのシリコン開発を目指すプロジェクトが、産業用途においてその可能性を最大限に発揮することができない背景には、以下のような欠陥があることが多い。

商業的適合性やビジネスプランの欠如

　明確な存在理由がないプロジェクトや、エンドユーザーに明確な付加価値を提供することができないプロジェクトは、失敗する。また、有効な資金調達モデルがないオープンソースのハードウェアプロジェクトは、さらに深刻な失敗をおかすことになるだろう。数年間にわたるシリコン開発には、膨大なコストを要するからだ。もちろん、必要とされる高品質の保守やサポートなども、無料で提供することはできない。

リポジトリの不在

　プロジェクトがオープンソースとして発表され、リポジトリのリリース時期が不確かな場合、失敗する確率は高くなる。本当にオープンソース化を目指しているとしても、最初からリポジトリをある程度組み込んでいなければ、実際のリリース／開発プロセスは、予想外に困難なものになる可能性がある。

検証のための担保やインフラ、公に可視化された成果が存在しない

　商用シリコンの中で最もリソースの集約度が高いのが、設計検証（DV：Design Verification）だ。高額なインフラを用意したり、問題が検知された場合に対処できるよう大勢の待機スタッフを確保したりする必要があり、膨大な実装コストを要するため、オープンソースのプロジェクトリーダーは単純に、設計検証を無視する場合が多い。しかしそれ故、インテグレーション実現に向けた普及を推進していく上で障壁が生じ、長期にわたる技術的な不具合が発生する状況を作り出しかねない。

高品質なドキュメンテーション／トレーニングの欠如

　オープンソース設計アーチファクトがドキュメンテーションなしで提供された場合、エンジニアたちは、必要な情報を発掘する“考古学者”にならざるを得なくなる。それは実世界での普及を推進していく上で、大きな障壁となる。同様に、既存のウォーターフォール型のハードウェア設計フローに慣れ親しんでいるエンジニアたちには、オープンソースパラダイムで効率的に作業できるようオリエンテーションが必要だろう。オープンソースプロジェクトで適切な基本トレーニングを提供できなければ、期待外れの導入結果に終わることになる。

ガバナンス構造やコミュニティー指導、プロセスの不在

　健全なオープンソースプロジェクトは、コミュニティー全体で継続的な開発を行う必要がある。こうした取り組みはその名の通り、“オープンに”実行しなければならない。そのためには、プロセスを明確かつ公正に均一化し、小さな修正だけでなく大規模な変更案も認める必要がある。開発に携わる者たちは同じ標準規格を順守し、その内容や実施方法を明確化し、問題を公に追跡して優先順位を付け、（有効な場合は）対処する必要がある。

　残念なことに、実に多くのオープンソースプロジェクトがこのような根本的真理を無視している。その結果、使われなくなったり不適切に修正されるなどして、存続の兆候がほぼ見られなくなるのだ。