IBM、Red Hat、そして自由ソフトウェア: ベテランmaddogの視点
(lpi.org)- Red HatのRHELソース提供条件の変更は、Unix、GNU、Linux、IBMの長い歴史の中で見るべきであり、IBM/Red HatはGPLの「バイナリ受領者にソースを提供する」という原則は守っているという立場である
- 初期のソフトウェアは研究者と利用者が必要に応じて作って共有していたが、1980年代以降著作権とライセンスが強化され、EULA、ソースコード契約、パーミッシブライセンス、GPLへと分かれていった
- GNUとLinuxは公開ソースとコミュニティ貢献によって成長し、IBMはLinuxへの10億ドル投資を発表した後、開発者の雇用とSCO訴訟への対応を通じてエコシステムへの信頼を高めた
- RHELはFedoraを実験基盤とするエンタープライズ向けサーバー製品であり、Red Hatはサポート、QA、ドキュメント整備、リリースエンジニアリング、グローバルサポート体制にかかる費用を顧客ライセンスで回収しようとしている
- RHELクローンの利用者は他のLinuxディストリビューションを選ぶこともできるが、クローン開発者は単純な複製よりもRHELと競合するディストリビューションを作るほうがより生産的である
Red Hatの変更を見る基本的な立場
- Red Hatの最近の販売条件変更は論争を呼んだが、核心はRHELバイナリを受け取った顧客にソースを提供する方式にある
- GPLの本質は、バイナリ受領者がバグを修正し、オペレーティングシステムを拡張できるようにソースと修正可能性を保証することにある
- IBM/Red Hatは契約顧客にソースコードと配布ビルドに必要な情報を提供し、GPLコードの変更点も引き続きupstreamへ送っていると見ている
- 「コミュニティ」という言葉だけで利害関係者をすべて束ねるのは難しく、同水準のエンジニアリングやサポートを必要としない利用者は別のLinuxディストリビューションを選ぶこともできる
ソフトウェア共有からライセンス時代へ
- 1969年ごろ、プログラミングは主に研究者、教授、エンジニアが自分の仕事のために行うもので、「プロのプログラマー」という職業は一般的ではなかった
- DECUSのようなユーザー団体は、顧客が作成したソフトウェアを複製費用程度で配布しており、多くの利用者がコードをPublic Domainとして公開していた
- 当時はソフトウェア著作権や特許の適用が限定的だったため、コードを保護するには営業秘密、契約法、バイナリ配布に頼る必要があった
- 1980年代初頭にバイナリとソースコードへ強い著作権法理が適用されるようになり、開発者は利用者に権利を説明するライセンスを必要とするようになった
- 最終利用者向けにはEULAが登場した
- 開発者向けにはソースコード契約が別途適用された
Unix、BSD、GNUが築いた基盤
- Unixは1969年にBell Labsで始まり、その後UC Berkeley、MIT、Stanford、CMUなどの研究大学へ広がった
- UC BerkeleyのBSD Unixは、demand-paged virtual memory、native TCP/IP、豊富なユーティリティを提供し、多くの初期Unixベンダーの基盤となった
- SunOS、Ultrix、HP/UXのような製品がBSDベースを採用した
- John LionsによるUnix Version 6解説書は長らく正式出版が妨げられていたが、複写版を通じて無数のUnixプログラマーにカーネル構造と設計思想を教えた
- AT&TのUnixソースライセンスは高価で制約も大きく、一部企業はバイナリ専用のUnix-likeシステムを販売する再配布契約を選んだ
- Richard M. Stallmanはバイナリしか提供されないUnixディストリビューションに触れた後、利用者が必要な修正を行えないという問題意識からGNUプロジェクトを始めた
- GNUの目的は、バイナリを配布する者が受領者にソースと修正可能性を保証する自由なオペレーティングシステムを作ることだった
- emacs、コンパイラスイート、ユーティリティのように、プログラマーに直接役立つソフトウェアが先に作られた
パーミッシブライセンスとGPLの違い
- MITやUC Berkeleyのような大学は研究コードを販売するより配布したいと考えていたが、著作権適用後は利用条件と責任制限を含むライセンスが必要になった
- こうしたライセンスは後にオープンソースのパーミッシブライセンスと呼ばれるようになった
- 開発者はバイナリ専用配布を作ることができる
- 元々受け取ったソース以外の変更点を最終利用者へ公開する必要がない
- GPLは、バイナリを受け取った最終利用者が変更点を見られるよう強制する制限的ライセンスとして整理される
- GPLについては初期にさまざまな誤解があった
- GNUコンパイラで作成したバイナリもGPLの適用を受けると考えた人がいた
- GPLコードは販売できないと考えた人もいたが、RMSはこれに反論した
- Walnut CreekやPrime Time Freeware for Unixのような企業は、さまざまなオープンソースコードをCD-ROMやDVDにまとめて販売した
Unix市場の圧力とLinuxの台頭
- DEC、HP、Sun、IBMなどのシステムベンダーは、AT&T System VまたはBSD系を基盤とするUnix-likeオペレーティングシステムを作り、そのためにエンジニア、ドキュメント作成者、QA要員、プロダクトマネージャーを雇用した
- 競争力あるUnix-likeシステムを作るため、各社は年間およそ10億〜20億ドル規模のコストを投じていたと見られる
- MicrosoftはPCメーカーに依存せず同じオペレーティングシステムを販売し、サーバーOS市場へ進出することでUnixベンダーに圧力をかけた
- Linuxカーネルプロジェクトは複数の条件が重なって1991年末に始まり、1993年末には複数のディストリビューションが成長段階に入っていた
- GNU、MIT、BSD、独立プロジェクトのソフトウェアがすでに存在していた
- オペレーティングシステム内部に関する情報がインターネット上に増えていた
- 高速インターネットが家庭に入り始めていた
- demand-paged virtual memoryが可能な低価格プロセッサが普及していた
- 運と機会があった
- 頑固でカリスマ性のあるプロジェクトリーダーがいた
- Soft Landing Systems、Yggdrasil、Debian、Slackware、Red Hatのようなディストリビューションが登場し、一部は商用ディストリビューションとして、一部はコミュニティプロジェクトとして始まった
Linuxとコミュニティモデル
- LinuxがBSDより先に大衆的な注目を集めた理由の一つは、BSDが「Unix Systems Labs Vs BSDi」訴訟に縛られていた状況にあったためである
- GPLはバイナリとともにソースを配布させる動的な効果を生み、誰でも許可なくディストリビューションプロジェクトを始められるため、数百のディストリビューションが生まれた
- X Window SystemはMITのProject Athenaから生まれ、Kerberosも同じプロジェクトから出た
- X Window Systemの開発はMITとProject Athenaを超えてX Consortiumへ移され、X Consortiumは1993年に発足し1996年に終了した
- OSFはUnixシステムのソースコードとAPI標準を定めるために作られ、1996年にX/Openと合併してOpen Groupとなった
- 複数のコンソーシアムは当初は資金が豊富だったが、参加企業が「他社が費用を払うだろう」と考えて離脱し、資金が枯渇していくパターンを示した
FOSS開発の持続可能性の問題
- 初期のFOSSでは少数の開発者が少数の利用者のために情熱を持って働き、無報酬であることも多かった
- 利用者が増える速度に開発者の増加が追いつかず、保守の圧力が高まった
- とくにQA、リリースエンジニアリング、ドキュメント作成、翻訳のような「華やかではない」領域で開発者不足が目立った
- 一部の開発者は、自分たちが無償で貢献したコードで他人が金を稼ぐことに不快感を覚えたが、企業がLinuxで利益を上げられなければLinuxは急速に前進できないという立場である
- 時間が経つにつれ、コミュニティはコードを書く人だけでなく、ドキュメント、翻訳、広報を担う人まで含むようになり、後にはgratisソフトウェアだけを使ってfreedomソフトウェアを理解しない人も増えた
ソフトウェア海賊版と自由ソフトウェアのコスト
- ソフトウェア海賊版とは、ライセンスに反して違法に複製し利用する行為である
- 一部のFOSSコミュニティ参加者は知的財産権や著作権を軽視するが、著作権がなければソフトウェアに対する統制も失われる
- Brazilのカンファレンスで「Free Softwareを使うべきだ」と話した際、聴衆が「私たちのソフトウェアは全部freeだ」と答えた事例がある
- 当時のBrazilのデスクトップソフトウェアのほぼ**90%**が海賊版だった
- この状況では、Free Softwareの低コストという利点の一部が失われる
- Linuxカーネルを使うすべての人がハードウェアプラットフォームごとに1ドル払うだけでも、大半のFOSS開発は容易に支えられるはずだと見ている
IBMのLinux参加
- IBM内部にはFOSSを信じて自分の時間でプロジェクトに取り組んでいた人々がおり、Daniel Fryeは彼らをIBM内部のFOSS組織としてまとめ、Linuxを前進させようとした
- IBMのLou Gerstnerは、以前はビジネス上の理由があるときだけオープンソースだったが、今後はビジネス上の理由があるときだけクローズドソースにする、という趣旨の手紙を送ったと記憶している
- IBMはこの時期にLinuxへ10億ドルを投資すると発表し、これは大きな衝撃を与えた
- その後IBMはLinux開発者を雇用し、さまざまなLinux関連分野でフルタイムで働かせ、Apache Web Serverのような分野でも開発者に給与を支払った
- IBMは約1年後に最初の10億ドル投資を回収し、さらに別の10億ドルを投資すると発表した
- IBMはノートPC・デスクトップ事業をLenovoに売却し、Price Waterhouse Cooperを買収してビジネスソリューション企業へと方向転換した
- 以後、ビジネスソリューションはIBMのハードウェアやソフトウェアだけに縛られなくなった
- Open Sourceは、IBMのソリューション提供者がより低コストでより良いソリューションを作れるようにする要素として扱われた
SCO訴訟におけるIBMの役割
- Santa Cruz OperationsはAT&TコードベースのUnixディストリビューションを作っており、後にCaldera Groupへ売却された
- Calderaは名称をSCOに変更した後、LinuxにAT&Tのソースコードが含まれライセンス条件に違反しているとして、Linuxベンダーを相手取る訴訟戦略を取った
- Linuxコミュニティの多くはこの主張を虚偽と見ており、AT&TとNovellの契約を読んだ経験からも、Santa Cruz OperationsがAT&Tコードの著作権を所有していたという主張は信じがたかった
- IBM、Novell、Red Hatなどは訴訟戦に参加し、裁判所は最終的に、SCOはIBMとの消滅した契約問題を提起できるだけで、Linux自体には問題がないという結論に至ったと整理される
- この過程でBig Blueが法廷闘争に参加した事実は、Linuxベンダーと利用者に物事がうまく進むだろうという信頼を与えた
Red HatとRHELの事業モデル
- Red Hatは、技術力は高いがビジネスとマーケティングが弱かったRaleighの小さな会社として始まり、Bob Youngの参加によって会社の方針と方向性づくりに助けを得た
- Bob YoungはRed Hatを「LinuxのHeinz ketchup」のようにしたいとたとえ、Red Hatはサービスを販売するモデルで収益を上げた
- 時間が経つにつれ、Red HatはRHEL中心のエンタープライズ事業に集中した
- デスクトップはRHELの開発プラットフォームとしてのみ重要であり、デスクトップ開発はFedoraに委ねた
- Fedoraは新しいアイデアを後でRHELに取り込むための試験基盤の役割を果たした
- RHEL顧客は企業や政府のような「mission critical」「always on」を求める組織であり、数十台や数百台ではなく数千台規模のシステムを運用することも多い
- こうした顧客は、MTTF、MTTR、99.999%稼働時間のようなサービス条件やペナルティ条項を扱い、一般的な一次サポートではなく二次・三次サポートを期待する
- Red Hatはエンタープライズサポート、QA、ドキュメント、認証、リリースエンジニアリングに費用を投じ、顧客はその対価を支払う
Full Stack企業とIBMによるRed Hat買収の論理
- OracleがSun Microsystemsの知的財産を取得した事例は、ハードウェア、オペレーティングシステム、アプリケーションをすべて統制するfull-stack戦略として扱われる
- full-stack企業はスタック全体を変更してアプリケーションに利益をもたらすことができ、スタック全体をテストして非効率や弱点を見つけることもできる
- IBMとAppleはfull-stack企業に分類され、製品は高価でも多くの真剣な顧客がその費用を支払う
- IBMはビジネスソリューション事業で使えるLinuxベースのfull-stackソリューションを必要としており、Red HatのRHELはエンタープライズソリューションとしての評判とエンジニアリングを備えていた
RHELクローンとRed Hatの条件変更
- 時間が経つにつれ、一部の顧客は少数のRHELシステムだけを購入し、残りのシステムにはRed Hatとbug-for-bug互換の別ディストリビューションを使うというパターンを作り上げた
- この方式は顧客コストを下げたが、Red Hatが同じ量の仕事をしても受け取る収益を減らし、Red Hatはライセンス価格を上げるか、人員を削減するか、他のプロジェクトを断念するかという圧力を受けるようになった
- IBM/Red Hatは、すべてのRHEL実行システムに対してライセンスを購入する顧客にのみ、ソースコードとビルド情報を配布するという事業判断を下した
- この条件はGPLの核心に合致すると見ている
- バイナリを受け取った人はソースを受け取り、バグ修正や拡張ができる
- Red HatとIBMはGPLコードの変更を引き続きupstreamへ送る
- より大きなコミュニティとのアイデア共有も続ける
- クローン開発者を「freeloader」とは呼ばないが、クローンを使いながらどのような形でもコミュニティへ還元しない利用者は、freeloadingに近いと見ている
クローンの代わりに競争を生み出せという提案
- Red Hatの変更後、複数のディストリビューションが「not RHEL」を作り続けると表明したが、これは一般利用者にどのディストリビューションを使うべきかをさらに混乱させる可能性がある
- 複数のクローンを別々に作るより、協力して一つの優れたディストリビューションを作るか、RHELの真の競合相手を作るほうがよいという立場である
- SuSEがRHELの競合を作るために1,000万ドルを投資すると述べた点は前向きに評価している
- ただし、同じビジネスチャネル、世界中のサポートチーム、エンタープライズサポート体制を持つことは安くない
- 1,000万ドルは出発点にはなり得る
- RHEL顧客は、Red Hat/IBMとチャネルパートナーが提供するサポートの価値を見て選ぶべきである
- RHELを1コピーだけ購入し、残りを無料ディストリビューションで運用しようとする顧客とIBMがもはや取引したくないのであれば、その顧客はその種の需要を引き受けられる別のエンタープライズLinux供給者を探すべきである
個人的な結論
- Jon “maddog” Hallは、Open Source、Free Software Foundation、GNUプロジェクトが生まれる以前から、ソースコードを公開し顧客にソースを提供する仕事をしてきたと述べている
- コミュニティへの貢献はコードを書くこと、ドキュメントを書くこと、バグレポートに限られない
- 学校、企業、政府にFree Softwareを広めることができる
- Linux Clubを作ったり、Upgrade to Linux活動を手伝ったりできる
- 企業はライセンスに違反しない限りビジネス条件を定めることができ、顧客はそれを受け入れるか拒否するかを選べる
- Red HatとIBMを「悪」と描きながら、パーミッシブライセンスベースで最終利用者にソースを保証しない企業や、クローズドソースライセンスしか提供せずクローンも認めない企業を同様に見ない態度は不均衡である
- 研究者、学生、趣味利用者、ほとんどお金のない人々には、RHELが扱わないアーキテクチャまで支援する数百のLinuxディストリビューションが存在する
1件のコメント
Hacker News のコメント
90年代後半から Red Hat Linux（最初は90年代のクローンだった Caldera Linux）、Fedora、RHEL とそのクローン（Scientific、CentOS、Rocky）を個人用途、教育用途、業務用途で使ってきて、デスクトップやサーバーにも勧めてきた。
Linux を使いたいなら、安定していてサポートも手厚い選択肢は Red Hat と Debian の2つだ、とよく言っていたが、Red Hat は最近死んだと思っている。RIP
いまでは Fedora が活発なオープンソースプロジェクトとして残り続けるのか確信が持てない。IBM がいま RHEL クローンを潰しているのなら、Fedora が次の標的ではないとなぜリスクを取って信じられるのか、と思う。
「RHEL は Fedora から派生している」「Fedora は別個のオープンソースプロジェクトだ」という話は知っているが、いまの RHEL は CentOS Stream から派生している。なら Fedora はなぜ必要で、Red Hat はなぜ Fedora にエンジニアリングとインフラを提供しなければならないのか疑問だ。
Fedora が別個のプロジェクトなのは事実だが、貢献の大半は Red Hat 社員がしている。IBM が明日、CentOS Stream で十分だと判断して Fedora への支払いを止めたら、Fedora は独立して持ちこたえられるのだろうか。
これは単なる恐怖・不確実性・疑念（FUD）かもしれないが、もう IBM 所有の Linux ディストリビューションは信用しない。個人のマシンはすでに Debian に移したし、仕事でも Debian を勧めている。Linux インストールを大幅にカスタマイズする組織が、何の条件もない完全なオープンソースプロジェクトではなく、不確実な Red Hat/IBM ベースのディストリビューションを選ぶのは無責任だと思う。一度だまされたなら相手のせいだが、二度目は自分のせいであり、IBM にまたやられるつもりはない。
Fedora は今でも CentOS のすべて、したがって RHEL のすべてに対する試験場の役割を果たすことになる。Fedora のような「未来のディストリビューション」を置き、将来の RHEL リリースをモデル化する開発方式に反対する論拠が何なのか気になる。
Linux カーネルを身近に追っていない人向けに言うと、maddog は伝説的な人物だ。
彼の視点はとても興味深く、ありがたいもので、特に歴史を踏まえて問題を組み立てるやり方がよい。歴史を知ると文脈をつかむのに本当に役立つ。原文は長いが読む価値がある。
私は Jon Hall より約30歳若いので、口伝や文章で伝わったもの以外に、彼の業績を直接知ることはできなかった。大ヒットした本や私が使えるソフトウェアを残したわけでもないので（まあ、Linux for Dummies はあるが）、人々が彼を伝説と呼ぶのを何度も見てきたものの、なぜなのか理解できなかった。
結局 Linux カーネルコミュニティに尋ね、彼の貢献の範囲を説明してもらった。ある意味で、彼は Linus のメンターだった。1994年に出会ったとき、Linus は25歳の学生で、Jon は44歳の DEC マーケティングマネージャーだった。2人の会話を「坊や、よく聞きなさい。これから君がやるべきことはこれだ」といった場面として想像してしまう。
この点を考えると、Jon Hall の Wikipedia 略歴の一文が目を引く。Digital で勤務していた時期に Linux に初めて関心を持ち、Linus Torvalds が Digital の Alpha プラットフォームへの初の移植を行えるよう、機材とリソースを確保するうえで重要な役割を果たした、という内容だ。
LinkedIn の経歴の一行も同じ見方を示している。Senior Marketing Manager, DEC, 1983-1998: 1994年に Linus Torvalds と出会い、Linux の商業的価値を見抜き、64ビット Alpha プロセッサへ Linux を移植するための資金を確保し、Linux ベースの高性能スーパーコンピュータという数十億ドル規模の事業ラインを切り開いた、という内容だ。
WP: https://en.wikipedia.org/wiki/Jon_Hall_(programmer)
LI: https://www.linkedin.com/in/maddog/
「これらのクローンを使いながら、どんな形でもコミュニティに還元しない人たちを『ただ乗りする人』と見る」という言葉には同意するが、それはもともと自由ソフトウェアである程度受け入れられてきた部分でもある。何かを無料で提供するということは、誰もが何かを、あるいは何も、返してくれるわけではないという意味でもある
Oracle Awesome Linuxのようなものとの違いは、そちらはRed Hatの付加価値のある作業とエコシステムをサービスとして売っている点にある。実際には「当社の他製品と一緒にサポートを受けたいならこれを買え。当社はRed Hatが出したものをそのまま配布する」という感じだ
私の考えでは、Red Hatの変更は、独自の「Oracle Red Hat for X」のようなビジネスモデルを作ることをより高くつくようにする方向に近い。学術向けの高性能インフラでRHELを負担できなかった人たちは、今でも負担できず、単に別のものを選ぶ
ここでFedoraの話で騒ぐのはあまり意味がない。Fedoraは会社のニーズを満たす商業的目的を持つプロジェクトであり、存在しなくなる日まで存在し続けるだろう
Red HatはMicrosoftではない。誰もがディストリビューションは数多くあり、その中には優れたものも多いと認めている。今日すぐにディストリビューションを始めることだってできる。だが「よし、じゃあDebianを使えばいいか」も、特に有効な答えではない。Debianは素晴らしいプロジェクトであり製品だが、1998年に雑誌の付録CDをもらったからではなく別の理由でRed Hatを選んだのなら、Debianは多くの作業なしには理想的ではない可能性が高い。結局は、人が直接やるコストと、Red Hatに任せて人には別の仕事をさせるコストとの間のお金の問題だ
以前、Fedoraプロジェクトにサーバーとホスティングを寄付していたことを思い出す。サーバーを設定しながら担当者に「RHELを動かしたいですよね？」と聞くと「はい」と言われ、「使えるライセンスキーはありますか？」と聞くと「入手はできますが面倒なので、そのままCentOSをインストールしてください」と言われた
講師は講習後の演習用にCentOSを使うよう勧めた（CentOSが買収される前）。その後、プロジェクトの一つでは最終的にRed Hatを使うことになった
その後はCentOSとクローンで、しばらくの間、人々がRHELと言うとき、実際にはCentOSを意味しているようにも思えた
Qtも似ている。ソフトウェアのほぼすべてがQtに依存していても、Digiaにお金を払いたくないためにQt 4.xにとどまる
Red Hat社員として、maddogの見方をありがたく感じる。他の人たちも、企業がオープンソースに対して行っていることを彼のように広く見られるといいのにと思う
内部で物事がどのように作られているかを見ると、見方が変わる。私たちが実際に何を売っているのか、人々に知らせられたらいいのにと思う。私たちはソフトウェアやソフトウェアライセンスを売っているわけではない
オープンソースライセンスを迂回しているわけでも、ライセンスを変えているわけでもない。顧客にとって価値のある仕事をする私たちの人員が、仕事を続けられるようにしようとしているのだ。私たちが行う多くの仕事は上流プロジェクトに上がり、競合他社、コミュニティ、ユーザーと共有される
maddogからこうした素晴らしい歴史的な話を聞けるのはいい。彼が記事で触れていたAustin訪問の一つのとき、私はLTCで働いていて、昼食を取りながら話す機会があった。およそ20年前のことだ
70代の人が自分のキャリアの何を「転換点」と見ているのかを聞くのは、いつも興味深い。私の転換点と彼らの転換点が絡み合っている様子も特に印象的だ
私はSCO騒動の真っただ中にいたが、その一部を話してよいのかは分からない。もしかすると今なら会社の弁護士たちも十分に退職したか亡くなっているだろうから、言いたいことを言ってもいいのかもしれない。やる気が出ればだが
maddogが今も自分の話を共有してくれているのはうれしい。歳を取るほど、インターネット上で誰かに何かを共有することへの関心がどんどん薄れていく。自分にとって意味のある会話は最近ほとんど対面で起きているので、個人的に知らない人と共有したり関わったりする価値はあまりなさそうに思える
私が勤める会社は、私たちが作る高性能サーバー機器にRHELを載せようとしたが、ライセンスあたり約100万ドルを提示され、交渉不可だった。そうなると私たちの製品は高くなりすぎてしまう
そのため最終的にCentOSに行き、その後Rockyに移り、これを管理するために約30人規模のチームを雇った（他のプロジェクトも併せて担当）。Red Hatと、彼らが望む形でソフトウェアを管理する権利は尊重しているが、ここ数年の経験からすると、彼らはブランドから最大限搾り取ろうとしているように感じる。今後5年間でどうなるのか気になる
「1969年にプログラミングを始めた」「実際、ソフトウェアを売るのが難しかっただけでなく、著作権を適用することもできなかった」という部分について、1969年に実際の法的状況がそうだったのか気になる。ソフトウェアに著作権を適用できなかったというのは正しいのだろうか？
1969年に筆者がそう信じていたというのは十分あり得るが、その認識が法的に正確だったのかは気になる
当時、法律実務に携わっていたわけではないが、伝え聞いた理解では、著作権がソフトウェアに適用されるのか、適用されるならどのように適用されるのかは明確ではなかった。ただし賢明な主体は、営業秘密を超えて、作成されたソフトウェアに何らかの形の保護が生じるだろうとは概ね予想していた
それが著作権法の下で実現するのか、それともソフトウェア専用の制度を通じて実現するのかについて、あらゆる疑問、理論、提案があった。米国での答えは、著作権法の範囲の定義に「computer program」が入ったことで明確になった。今でも残る論点を論じる際には、その勧告を推し進めた委員会であるCONTUが引き続き引用されている
https://en.wikipedia.org/wiki/Software_copyright#History
Jon Hallは信じないのに、ソーシャルメディア上の見知らぬ誰かは信じようとするのは奇妙だ
2000年ごろ、Parisで私が共同主催したイベントでmaddogに会った。私たちは多くの質問をし、彼は洞察に富んだ答えをくれた。時にはリンク先の記事のように、長い話に包んで答えることもあった
いちばん記憶に残っているのはこれだ。「質問: Linuxがデスクトップで既に持っている数パーセントポイントを超えて市場シェアを獲得できるようにするには、どう支援すればよいでしょうか？」
「回答: それはできません。今コンピューターを使っていない市場を探し、その市場のニーズを解決する製品を作り、その製品にLinuxを使わせてください。たとえばスマートフォンを考えてみてください」
maddogが今でもFOSSに積極的に関わっているのはうれしい
90年代後半ごろ、ChicagoのCOMDEXで、彼が展示会場を見て回れるように、数時間自分のブースを任せてほしいと私と友人を説得したことがあった。LPIだったのかLIだったのか、それとも別のLinux関連団体だったのかは覚えていない。私たちはディストリビューションのCDを配り、人々にLinuxについて説明していたように思う
LinuxがPCの世界を席巻していた狂ったような時期で、Tuxはどこにでもいた