- UbuntuのRust導入は、技術採用ライフサイクルにおいてRustがアーリーアダプターからキャズムを越えて主流段階へ移行しつつあることを示している
- CanonicalはRustを新しい基盤ソフトウェアのデフォルト言語として採用し、C、C++、一部のPython利用を置き換えつつあり、メモリ安全なユーティリティ開発に資金面・評判面の両方で投資している
- 初期多数派（Early Majority）の利用者は**「業界標準」と既存ワークフローとの互換性**を求めるため、ドロップイン方式のユーティリティ置き換えがキャズムを越えるための中核戦略となる
- Rustの標準ライブラリ拡張の問題が再浮上しており、2016年に退けられた「Rust Platform」の概念が初期多数派にはむしろ適している可能性があるという再評価
- 採用拡大を投資へつなげる仕組みと、オープンソースコミュニティの共感（empathy）に基づく包摂性がRustの次の成長段階に不可欠
Rustの「キャズム越え」は領域ごとに異なる
- RustがTechnology Adoption Life Cycleでキャズムを越えたかどうかは領域によって異なる
- Amazon社内では大規模なデータプレーンやリソース認識エージェントの構築でRustが確固たる地位を築いている一方、一般的な開発には依然として過剰だという認識もある
- Safety Critical Softwareの領域では成功事例があるが、業界の大半はいまだ「様子見モード」にとどまっている
「リファレンス顧客」の重要性
- キャズムを越えるための鍵は**リファレンス顧客（reference customers）**の確保
- 初期採用者は「変化の担い手（change agent）」を買うが、初期多数派は既存運用の生産性向上を求め、不連続性を最小化しようとする
- 自分たちと似た組織が成功した事例を見ることが、新技術導入において最も説得力のある要因になる
- S3チームにおけるRustの成功は大規模サービスチームには説得力がある一方で、CRUDサービスチームには直接的な説得力が乏しいことがその例である
Ubuntu（Canonical）のRust導入戦略
- Rust NationでCanonicalのVP of EngineeringであるJon Seagerが「Rust Adoption At Scale with Ubuntu」のキーノートを発表
- Canonicalは自社開発言語をPython、C/C++、Goに限定してきたが、近年Rustを追加し、新しい基盤作業のデフォルト言語として採用
- Lars BergstromによるGoogle社内でのRust採用キーノートと同様に、ビジョンと実用性を兼ね備えたアプローチ
- これはアーリーアダプターから初期多数派へ移行するために必要な、まさに的確な特性である
メモリ安全なユーティリティへの投資
- Jon Seagerは、Ubuntuが**メモリ安全な基盤ユーティリティの構築を「pay it forward」**の観点から支援すべきだと述べた
- CanonicalはTrifecta Tech Foundationのsudo-rs、ntpd-rs開発と、uutilsによるcoreutilsの取り組みを資金支援している
- Ubuntuが新しいものを先に試して検証し、その後ほかのディストリビューションが恩恵を受けられるようにする構図
- 既存ワークフローにそのまま入るドロップイン型ユーティリティは、初期多数派の「不連続性の最小化」という要件に合致する
新たな採用者の要求: 標準ライブラリの拡張
- 会食の場でJon Seagerは、Rustの小さな標準ライブラリ方針を見直すべきだと発言
- これは長年繰り返されてきた要望であり、単に大きな標準ライブラリを提供するのではなく、**「Battery Packs」**というプロジェクト形態の代替案が構想されている
- 2016年に提案されたRust Platform（特定のcrateを拡張標準ライブラリとして認める概念）は、当時の初期採用者には退けられたが、初期多数派には適している可能性があるとの再評価
- 当時は
Cargo.tomlに依存関係を追加すれば十分だという意見が優勢だった
成長のために必要な変化
- アーリーアダプターから初期多数派へ移るには、**「最先端（state-of-the-art）」ではなく「業界標準（industry standard）」**というメッセージが必要
- Rustは業界での認知獲得には成功しており、今後は**「なり得るもの」ではなく「実際に何であるか」**を基準に最良の選択肢である必要がある
- 実務家に向けてマーケティングするには、忍耐、その業界課題への理解、業界カンファレンスへの参加などが必要になる
採用を投資へつなげる仕組み
- Rust採用の拡大は、Rustプロジェクトとエコシステムに対する需要増加を伴う
- Canonicalのようなオープンソース組織にとっては、$$よりも組織間の関係構築と貢献の方が重要
- Rust for Linuxの開発者たちは当初Rustメンテナーの支援を受けていたが、徐々に自らバグ修正を行うようになり、メンテナーはメンター役へ移行した
- 興味深い傾向として、資金はRustをすでに導入した企業よりも、導入を検討中の企業から出ることが多い
- 社内のアーリーアダプター個人が組織導入を推進し、「テーブルステークス」機能の開発に予算を割り当てる
- Rust Foundation Silver Member DirectoryのAlexandru Radoviciによれば、多くの安全性が重要なソフトウェア企業はRustのギャップを埋めるための資金はあるが、どう使えばよいか分かっていない状況にある
オープンソースの役割と共感の重要性
- オープンソースはキャズムを越えるための優れたプラットフォームだが、**派閥（cliques）や「口伝文化（oral traditions）」**が参入障壁になり得る
- 用語の使い方を間違えたためにアイデアが退けられたり、たった一度の無礼な返答が新しい貢献者を離れさせたりすることがある
- Rustの次の成長段階に最も必要なのは、オープンソースにおける共感（Empathy in Open Source）
- Rustが人々を助けられる場所を見つけ、支援し、力を与えることが核心である
1件のコメント
Hacker Newsの意見
UbuntuがGPLではないライセンスのuserlandを使うということは、Linuxエコシステムでより多くのTiVoizationを許すことになり得るという意味だ
systemd陣営のAmutableが向かっている方向と組み合わされると、ユーザーによる改変が不可能な閉鎖的Linuxディストリビューションが登場するかもしれない
企業の立場からすると、完全な署名検証が可能な閉鎖環境は魅力的かもしれない。「ls」や「cd」すらクローズドソースになる世界とは、どこか黙示録的だ
Rustが越えるべき本当のチャズム(chasm) は、安全なABIを備えた動的リンク対応だ
あるライブラリを修正しても安全性が保証され、CレベルのABI安定性を確保できてこそ、C/C++陣営でRust採用が可能になる
UbuntuがRustを導入することより大きな問題は、いまだにcurl|bashスクリプトで重要なビルドを処理している点だ
firefox-snapのsnapcraft.yamlを見れば明らかだ
Rust CoreutilsプロジェクトがMITライセンスである点が気になる
FSFの哲学は批判されることもあるが、GPLはオープンソースを守る。CanonicalがUbuntu全体をMITに変えたら何が起きるのか分からない
rust-coreutilsのせいでCUDA Toolkitのインストールができなかった。関連するイシューはNVIDIAフォーラムにある
「Crossing the chasm」という概念は興味深い。Ubuntuのcoreutilsの件以外にも、Rustが越えようとしているギャップは多い
Rust for Linuxや自動車産業向けRustもあるが、まだドライバーレベルにとどまっているようだ
標準ライブラリを後で変えるという論理は危険だ。ユーザーが求めているのは「チャズム」より安定して高品質なシステムだ
Rustエコシステムの未成熟さが採用を阻む要因だ。多くのcrateは1.0未満のバージョンか、単なるCラッパー程度にとどまっている。暗号関連は悪くないが、SAMLのようなものは見つけにくい
libcのようにAPIに深く絡むcrateはバージョンを上げにくいこともある。個人的にはblessed.rsのようなキュレーションされたリストを参考にしているRustでC++コードを「雰囲気だけ翻訳(vibe-translate)」してライセンス変更する動きがある。たとえばsudo-rsはむしろC版より安全性の実績が悪い
.NETの巨大な標準ライブラリは本当に快適だ。たいていの作業が標準的なやり方で可能で、変な実装があれば多くの人が標準化を進める
Rustのstd/coreはすでに大きすぎて、マイクロコントローラではweak symbolのようなトリックが必要になる。
小さなstdlibはAPI安定性の維持と保守負担の軽減に有利だ。C++がこの問題で苦しんできた以上、Rustは慎重であるべきだ