Ask HN: あまりに早く中断・終了してしまったプロジェクトはありますか？ その理由は？

 (news.ycombinator.com)
6 ポイント 投稿者 GN⁺ 2025-10-13 | 6件のコメント | WhatsAppで共有
  • 時代を先取りしすぎていた、あるいは市場の準備ができていなかったために消えていったプロジェクトについての質問と回答
    > ただ気になっただけです。誰かがこれを採用するのか、あるいはこのアイデアをもとに新しいものを開発するのか、誰にもわかりません。

Plan 9 オペレーティングシステム

  • Unix の 真の後継者 と評価されたが商用化に失敗した Bell Labs の分散オペレーティングシステム

    • 「すべてがファイル」という哲学を ネットワーク共有 にまで拡張した革新的な設計
    • マウスコーディング、入れ子型ウィンドウマネージャ、Plumber など 独創的な UI 機能 を提供
    • モバイル、デスクトップ、クラウド、IoT をつなぐ 分散環境に理想的 だったが採用に失敗

  • 失敗の原因

    • ライセンス問題 と訴訟により業界から敬遠された
    • 集中型コンピューティングが衰退し パーソナルコンピュータが台頭 していた時期と噛み合わなかった
    • 研究用 OS としてのみ位置づけられ .com ブームを活かせなかった
    • AT&T の電話事業収益の減少で Bell Labs が 何度も売却 された
    • Version 3 は 1 ボックス $350 で販売 されたが非商用目的にしか使えなかった
    • 2004年までまともに オープンソース公開されなかった

  • 遺産

    • 9P ファイルシステムプロトコル は WSL2、VM エコシステム、Kubernetes で今も使われている
    • 9front のような 活発なフォーク プロジェクトが存在する
    • Plan 9 Foundation が オープンソースコードと権利 を管理している

Google の終わったプロジェクト群

  • 30〜40個使っていた Google 製品が 3〜4個にまで減った というユーザーの体験談

    • Google Picasa: ローカルベースの 高速で優れた写真管理 ツール
    • Google Hangouts: 混乱したメッセージングアプリ戦略 の犠牲者
    • G Suite Legacy: 「永久無料」 の約束を破って有料化
    • Play Music: 何千もの MP3 ファイルをアップロードしていたが、サービス終了で データ損失
    • Google Finance: 株価追跡機能があったが終了
    • Google NFC Wallet: Apple が 同じ機能で市場を制圧
    • Chromecast Audio: 単機能に徹していた が終了

  • Google Reader: 史上最悪のビジネス判断

    • 長期的には ほとんどメンテナンス不要 なサービスだったにもかかわらず終了
    • 創業者、CTO、VP of Engineering など 影響力のあるユーザー層 が多かった
    • Google 製品を 信頼してはいけないという教訓 を業界に残した
    • サービス終了が 数百万ドルの節約 として評価される組織文化の問題

Adobe Flash / Macromedia Flash

  • 15年経った今でも代替しにくい マルチメディア制作プラットフォーム

    • ゲームやマルチメディア制作を Lego ブロックのように簡単に 作れた
    • MovieClip、タイムラインアニメーション など直感的なツールセットを提供
    • HTML Canvas に置き換えられたが ツールの品質は比較にならない

  • iPhone が Flash を殺した理由

    • 2007年当時のハードウェアでは 性能問題とバッテリー消費 が深刻だった
    • Flash が アプリ生態系の抜け道 になり得たため
    • iPhone を 「粗悪な製品」だと認識 させる危険があった

  • 現状

    • Adobe Animate は JS/Canvas 出力 をサポートするが原作とは異なる
    • Ruffle のような エミュレータ で一部のレガシーコンテンツは実行可能
    • Roblox がある程度 似た役割 を果たしているが、より制限的で商業的

Microsoft の失敗したプロジェクト群

  • Silverlight: C# ベースの Web プラグイン

    • JavaScript の代わりに完全な C# が使えた
    • ベクターベースの DPI 対応 UI、MVVM パターン、双方向バインディング
    • Expression Blend による デザイナーと開発者の協業
    • すべてのブラウザで 完全に同じようにレンダリング された
    • iPhone が Flash とともに Silverlight も衰退 させた

  • Midori: Capability ベースのセキュア OS

    • Windows コードを実行できるレベルまで発展したが 社内政治で中止 された
    • 多くの研究成果が .NET に統合 された
    • リテンションプロジェクト（優秀なエンジニアをつなぎ留めるため）として 100 人以上が投入された

その他

  • Apple の Copland（MacOS 8 プロトタイプ）

    • コマンドラインのない 近代化された MacOS バージョン
    • モバイルへの移行を 容易にできたはずの 機能群
    • 機能クリープ と不安定さでリリース不能
    • Apple の NeXT 買収を正当化するため 意図的に廃棄 されたという噂

  • Songsmith: メロディから自動伴奏を生成

    • 2009年に リアルタイムのコード検出と伴奏生成 を実現
    • 現在の Suno、Udio のような AI 音楽ツールの先駆け
    • キャンピーなプロモーション動画で ミーム化したが 技術力は高かった

Heroku の衰退

  • 初期の シンプルさと集中 が成功要因

    • 単一言語、単一デプロイ基盤、単一データベース
    • 意思決定疲れを最小化
    • 15年前に AI があったなら 一貫した学習データ によりもっと効率的だったはず

  • 失敗の原因

    • Salesforce 買収後に 巨大なブランドバナー が追加されユーザーの反発を招いた
    • Docker と Kubernetes の登場で代替可能になった
    • 無料ティア廃止 で多くの顧客が離脱
    • 暗号資産による 無料コンピューティングの乱用 問題

  • 現状

    • 今もなお一部のユーザーは 本番環境で使っている
    • Vercel、Coolify、Dokku などが 似た体験 を提供している

ReactOS - Windows NT 再実装

  • 30年近く開発 されてきたが、いまだ実用には至っていない

    • Wine + カーネル + デバイスドライバ互換性 + 動くターゲット という難題
    • Windows 10 のサポート終了を前にしても 代替にはなれていない

  • 失敗の原因

    • Windows のソースコードは 十分に文書化も理解もされていない
    • クリーンルーム・リバースエンジニアリング の原則上、Windows コードを見た人は貢献できない
    • Windows XP ソース流出後も 進展速度は依然として遅い
    • Wine、Proton、仮想化技術が 実用的な代替 として定着した

Delphi と Pascal

  • 教育用途に理想的 だったプログラミング言語

    • 超高速コンパイラ により試行錯誤型の学習に適していた
    • すっきりした型システム（Rust ほど複雑ではない）
    • プログラミング基礎概念の学習に 言語固有機能に頼らず 忠実だった

  • 現状

    • Delphi は バージョン 13 までリリース され健在
    • Lazarus が オープンソース代替 として存在する
    • Python が教育用言語として 置き換えたが型システムは混乱している

革新的だったが失敗したハードウェア

  • MicroChannel (IBM): チャネルベース周辺機器アーキテクチャ

    • メインフレームの チャネル概念を PC に 導入
    • 簡単なチャネルプログラムを実行可能
    • 独占ライセンス により市場で失敗
    • 現代のあらゆるシステムが似た機能を使っているが 統一インターフェースは存在しない

  • Motorola 680x0: マイクロコンピュータ時代の基盤になれたかもしれないプロセッサ

    • 1978年に登場したが MMU の投入が遅すぎた
    • Amiga、初期 Macintosh の 心臓部 だった

  • Optane 永続メモリ: RAM とストレージの境界を壊した技術

    • データ構造を直接永続化 できる
    • 起動やアプリ実行が不要で 中断した場所から即再開 できる
    • 高価すぎて 失敗したが技術的には革命的だった
    • ビジネス意思決定者の忍耐不足

  • Lytro ライトフィールドカメラ: 撮影後にピント調整

    • すべてのデータを取得 してから後でピントを決められた
    • Gaussian splat、Meta Ray-Ban のような 現代技術とも完全に相性が良かった はず
    • プロ写真家が必要とする画質 には届かなかった
    • Polaroid/Instax のような ノベルティ市場 を狙うべきだったかもしれない

Web 技術を巡る論争

  • XHTML の失敗

    • 厳格なパース で HTML の混乱を解決しようとした
    • HTML5 は 壊れた HTML の意味まで標準化 した
    • Postel の法則は誤りだった: 寛容なパースはセキュリティ脆弱性と互換性問題を招く
    • 「最初のエラーで停止してエラーメッセージを表示する」 原則のほうが良かったはず

  • 反論: XHTML が失敗した本当の理由

    • IE6 が application/xhtml+xml をサポートしなかった
    • ほぼ 15年間 IE6 サポートが必要 だった
    • JSX、JSON は 厳格な文法 でも成功している
    • すべてのバックエンド言語は 厳格な文法 を使う
    • 参入障壁の問題ではなく ブラウザサポートの問題だった

  • HTML の現実

    • 不正な属性の引用 でページ全体がレンダリングされないことがある
    • 一般の人でも書ける フォーマットであるべき
    • HTML は 命令ではなく文書形式
    • PDF、ZIP、CSV も壊れたファイルを読む（データはフォーマットより重要）

ソーシャルネットワークとコミュニケーション

  • Google Wave: 未来を見せたが早すぎた革命

    • リアルタイム翻訳、さまざまなメッセージング統合 など豊富な機能
    • 完全に オープンソース だった
    • 複雑すぎる UI により 「入れ子になったリアルタイム更新スレッド」 が圧倒的だった
    • 現在は Slack、JIRA、メールに 分散している機能 を統合していた

  • Vine: TikTok より先に登場したショート動画

    • 2013年の時点で既に かなりの規模 に成長
    • Twitter が どう収益化するか分からず 終了
    • TikTok は Vine 終了 数か月後 に登場
    • 正方形動画に 広告バナーを入れるだけで よかったのに機会を逃した

  • Skype: 祖母でも使えたビデオ通話

    • 電話のように簡単 で、しかも国際電話より安かった
    • 最高の P2P ソフトウェア だった
    • Microsoft Teams に ひどい形で置き換えられた
    • 外部ハードウェア設定の難しさ、互換性問題、昔の音質テストサービスの不在

オペレーティングシステム

  • Maemo/MeeGo: Nokia が推すべきだったモバイル Linux

    • N9 は優れた端末 だったが 1 台しか出なかった
    • ハック可能で、洗練され、安全 だった
    • 今日では Android と iOS 以外の 2 つの主流モバイル Linux になれていたかもしれない
    • Sailfish OS として一部受け継がれている

  • BeOS: マルチメディア最適化 OS

    • BeOS や Amiga への言及 までスクロールが必要だったことに驚く
    • Haiku OS として from-scratch 再実装が進行中
    • Linux+X+Qt+KDE より 目に見えて高速で応答性が高かった

  • OS/2: IBM と Microsoft の協業が生んだ悲劇

    • 優れた API を持つシステム
    • Workplace Shell と SOM コード が公開されていれば他の OS でも活用できたはず
    • 銀行 ATM で長く使われ、しかもハックされなかった

開発ツール

  • Quartz Composer: Apple のノードベース視覚プログラミング

    • パッチベース のビジュアルプログラミング環境
    • USB デバイス監視を 3つのノードで 実装可能
    • 2016年以降 更新停止、最新 OS では 多くのノードが壊れている
    • Blender、Unreal Engine の ノードベースプログラミング人気 を踏まえ再評価が必要

  • Atom コードエディタ: VS Code の代替になれたかもしれない

    • GitHub 製の メインストリーム代替
    • Microsoft の GitHub 買収後に Atom の運命が決まった
    • Electron の元祖 プロジェクト
    • 元開発者たちは Zed エディタ を開発中

  • Non DAW: 機能別に分離された DAW

    • 各機能を 独立アプリケーション として提供
    • 必要な機能だけ使うとき 他機能に邪魔されない
    • 25 行のサンプルで すべてのコンセプトを紹介
    • メイン開発者は Microsoft に雇われ Rust OSS 作業に従事中

プログラミング言語

  • Elm: 不完全で活発に開発されていない関数型言語

    • カスタム演算子削除 でコードが壊れ momentum を失った
    • Elm Architecture が硬直的すぎるのが問題
    • F# (Fable)、ReasonML、OCaml (Bucklescript)、Haskell、PureScript が 代替

  • Opa: 2012年の型付き Next.js

    • TypeScript より前に 型のあるフルスタックフレームワーク だった
    • 市場が サーバーサイド Node.js に懐疑的 なときに登場
    • AGPL ライセンスが致命傷 で、後に MIT に変更したが 二度目のチャンスはなかった

  • Austral: 明晰さと思考の独自性を備えた言語

    • 独特な 明快さを持つ仕様 を提供
    • 作者が もはや積極的には取り組んでいない
    • 趣味プログラマには コミュニティとエコシステム が不足

  • Ceylon: Red Hat の JVM 言語

    • Groovy、Kotlin、Scala と 競合 した
    • 匿名ユニオン型、内包表記、適切なモジュールシステム
    • Java 上の 単なるシンタックスシュガー以上 を提供
    • Kotlin との 競争に敗れ、Eclipse で放置された

商業的失敗

  • Google Stadia: クラウドゲーミングプラットフォーム

    • 堅牢なストリーミング基盤 を構築
    • 魅力的なゲーム不足 で失敗
    • 既に他所で入手できる 少数のゲーム だけでは不十分だった

  • Fire Phone: Amazon のスマートフォン

    • 市場ゼロ を狙っていた
    • 振り返ると 成功すると信じていたこと自体が信じがたい

  • Project Ara: Google/Motorola のモジュラー式スマートフォン

    • カスタマイズ可能 なスマートフォン
    • もう数回の 反復開発 を見てみたかった
    • 競争するには 厚すぎた かもしれない

データベースとバックエンド

  • RethinkDB: リアルタイムデータベース

    • Horizon BaaS へと範囲を広げる中で失敗
    • Linux Foundation の下で技術的には存続しているが momentum は失われた
    • 元のコンセプトは デモには非常に向いていた が実運用のユースケースが不足

  • Yahoo Pipes: RSS とデータフローの組み合わせツール

    • インターネットが本来あるべき姿 を示していた
    • ツール間接続 は Unix パイプ程度の水準にとどまっている
    • Zapier、n8n は現代的代替だが 同じ感覚ではない
    • Node-RED、Apache Camel、Apache Nifi が エンタープライズ向け代替

その他の注目すべきプロジェクト

  • Sandstorm: 2014年の分散 Web プラットフォーム

    • BitTorrent のアイデア に基づく
    • 完全に 分散された Web サイトのコードとデータ
    • 既存サイトにも 統合可能 だった
    • Grain（データ分離）メカニズム が既存アプリの適応を難しくした
    • アプリ移植よりも プラットフォーム上でゼロからアプリ開発 を訴求すべきだった

  • Keybase: 暗号化ベースのソーシャルネットワーク

    • 強力な 暗号化と本人確認 を提供
    • Zoom 買収後に 事実上停止 した
    • FOKS が元開発者たちの新プロジェクト

  • del.icio.us: ソーシャルブックマークサービス

    • 実際に知っている人たちと ブックマークを共有 できた
    • 便利なカテゴリタグ付け を提供
    • Reddit や Twitter に 置き換えられた
    • Pinboard も 似たサービス だったが、管理不足と創業者の政治的見解でユーザー離れが起きた

関連記事

6件のコメント

 
soonil 2025-10-20

懐かしさを呼び起こす技術ですね
 
roxie 2025-10-13

ああ…Keybaseプロジェクトは頓挫したんですか？？
 
click 2025-10-13

Vine は本当によく使っていましたが、ショートフォーム時代まで生き残っていたら、ショートフォーム業界の先駆者としてかなり稼げていたでしょうね
 
unknowncyder 2025-10-13

Berryz WebShareでしょうか…？ 子どもの頃、まったく知識がなかったのにかなり簡単で気軽に使えた記憶がありますね。
 
chicol 2025-10-13

サイワールドがないね..
 
GN⁺ 2025-10-13
Hacker Newsの意見

  • Plan 9オペレーティングシステム。Unixの後継に最も近いシステムで、「すべてはファイル」という哲学をさらに一段推し進め、ファイルをネットワーク越しに容易に共有し、分散システムを構築できた。Plan 9ではリモートリソースへのアクセスが容易で安定していた一方、他のシステムでは用途ごとに互換性の低いソフトウェアをインストールする必要があった。また、マウス操作中心のテキスト編集、入れ子のウィンドウマネージャ、システム全体でテキストパターンに応じてコマンドを実行する Plumber など、革新的なUI機能もあった。分散アーキテクチャのおかげで、今日のモバイル、デスクトップ、クラウド、IoT機器が相互接続された時代に最適だったはずだが、現実にはそう設計されていないOSのままになっている。現在は 9front のようなフォークが生き残っているが、Bell Labsのオリジナルは消えた。衰退の原因は、法的問題（ライセンス、訴訟など）で主要業界への導入が進まなかったこと、分散OSが求められていた時期に人々がローカルコンピュータを好んだこと、研究用OSとしてしか知られずドットコムブームを十分に活かせなかったこと。最後に、AT&Tの収益源喪失、Bell Labsの売却、コアメンバーの離脱も影響した

    • Plan 9最大の失敗要因は、Unixと違ってハードウェアベンダーが安価にライセンスを受け、自由に自社ハードウェア向けへ改変できなかった点だ。Bell LabsはPlan 9を商用ソフトウェアとして350ドルで売ろうとし、そのため産業界でまともに採用されなかった。私が何度も強調してきた投稿があるので、参考にするとよい: リンク1, リンク2, リンク3

    • Plan 9のファイルシステムプロトコルは、WSL2の内部で今も生きている

    • なぜ他のUnix系システムが「すべてはファイル」の哲学を積極的に採り入れないのか気になる

    • Plan 9ではシンボリックリンクの問題を解決していた

  • QNXのPhotonグラフィカルインターフェースもリアルタイム重視でありながら、ウィジェットやゲージなどの機能が充実していて、Webブラウザも2つ対応しており遅延がなかった。真のリアルタイムOSという感じだった。そして Copland と呼ばれた Mac OS 8 は、オリジナルのMac OSを近代化しつつコマンドラインのない伝統を維持していた。コマンドラインがないなら、あらゆる機能のインストールと設定が簡単かつ一貫していなければならず、もしモバイル移行期があったなら滑らかに移行できていたのではと思う。実際には開発者向けに実働版が提供されていたが、AppleがNeXTを買収する必要があったため、Coplandプロジェクトは棚上げされた。さらに、トランザクション処理OSという概念も革新的だった。IBMのCICSのように、プログラムを呼び出して実行し終えたら終了する方式で、UnixやLinuxが本質的に端末ベースのタイムシェアリングシステムであることと対照的だ。次に、IBM MicroChannelはメインフレームのチャネルの利点をPCに持ち込もうとしたが、実質的な独占方針のため失敗した。今日ではほぼすべてのシステムが似た概念を使っていても、OSを単純化する統合インターフェースとしては機能していない。そして、まともに動作するハイパーバイザを搭載したCPUについても、過去のIBM VMシステムと違ってx86の各種レイヤーはどれも継ぎはぎだ。Motorola 680x0シリーズはマイクロコンピュータ時代の基盤になるべきだったが、MMUの投入が遅すぎてMacを主導できなかった。Modula-2と3はかなり良かったが、Oberonは失敗し、DECもともに衰退した。XHTMLについては、HTML5でエラーが公式化され、かえって不要に寛容なパース規則が導入された。広告や外部コードでタグ1つが正しく閉じられていないだけで、ページ全体が無意味に壊れてしまった。最後に、Word Lensのようにスマートフォン越しに世界を見ると機械翻訳やオフライン処理までできる革新もあったが、Google翻訳に統合される形で消えた

    • Coplandプロジェクトについて事実関係を正したい。このプロジェクトは深刻なまでに管理が杜撰で、新技術も無秩序に追加されたため、機能膨張と安定性低下が甚だしかった。流出ビルドを使ってみると、基本的なデスクトップ機能だけでも頻繁にフリーズしクラッシュする。1996年にApple社内ではCoplandのリリースは不可能という結論に達し、外部OSのライセンスを検討した末にNeXT買収へ至った。Coplandを捨ててNeXTを買ったのではなく、Coplandが絶対に出荷不能な水準だったため、やむを得ず下した決定だった

    • XHTMLに没頭していた時期があったが、自分の制御外にある広告などでタグ1つでも閉じ方が間違っていると、ページ全体がまったく表示されず、大きなエラーメッセージだけが出るという経験をした。残りを「Times New Romanで出力する」というアプローチも現実的ではない。結局HTMLをパースするなら以前の位置と大差ない。熱心な人間として自分の側のコードは完璧に書けても、現実には大半の人は雑に作る。XHTMLは論理的にはもっともらしく見えても、現実には人間の性質上不可能なアプローチだった

    • XHTMLのような厳格なスタイルを好むことはできても、実際に広く共有されるWeb文書には容赦のないフレームワークは向かない。さらにファイル形式を2種類に分けると、(1) 利用者が作者に連絡できないオープンループ（HTML, pdf, zip, csv など）では、データ自体が形式より重要なので、不良な pdf や zip でも読めなければならない。(2) 利用者が作者を制御できるクローズドループ（プログラムのソースコードなど）では、厳格なパーサが許容される。XHTMLは(2)でしか通用しないモデルで、HTMLは(1)だ。本質的に閉じた環境（社内文書など）でない限り、XHTMLの適用は難しい

    • HTML5で不正なタグエラーを寛容に許す流れには批判的だ。他の形式はほとんど最初のエラーで止まるのに、HTMLだけが例外になっている。そのせいでセキュリティ脆弱性が多くなり、開発者全員にとって難しくなるばかりだった。HTML5のパース方針は、旧来の慣性に浸ったInternet Explorerに対抗していた人々が、理想を追いすぎるか、標準という名目でバグを文書化する方向へ流れてしまった。関連RFC

    • タグを「正しく」閉じろという要求は、言語への参入障壁を上げるだけだ。昔はHTMLを手書きしていてミスしても、とりあえず画面には何か表示されたので、多くの人が挑戦を続けられた。本物のプログラミング言語は小さなミスでも恐ろしいエラーメッセージを吐き、簡単に挫折させる。最近の言語はRustのように改善されたが、XHTMLの時代は小さなミスでも把握しやすくはなかった

  • Google Waveを挙げる。最初にChris DiBonaのデモを見たとき、本当にすごかった。リアルタイム翻訳、さまざまなメッセージングの統合、オープンソース化と、魅力的な機能が満載だった。だが実際にリリースされたWaveは縮小版で、市場にも見放され、とても残念だった。結局、JIRA、Slack、メールのようなものが残り、Wave不在の大きさを痛感する

    • Google Waveは技術スタックは素晴らしかったが、UI設計で致命的なミスを犯した。Waveを単一文書ではなく複数の個別項目として扱ったため、複雑に見えるだけで長所が失われた

    • デモを見て感嘆したが、少し考えると恐ろしいという結論に至った。Slackのように各チャンネルの更新を逐一追う必要があるのに、Waveはその構造がはるかに複雑で、絶対に追い切れないだろうと直感した

    • Waveの技術力はすごかったが、デモ映像を見返すと、あまり良い製品ではなかったと分かる。すべてを包含するオールインワン製品を作ろうとしたが成功しなかった。むしろこれらの技術は複数のGoogle製品に分散して適用され、機能ごとに別UIを置くほうがずっと直感的だと分かった

    • 友人たちとの旅行日程などの共有管理にぴったりで、文書やリンクを含むアドホックな議論にもWaveのフォームファクタは有効だった。未来を見ている気がして、初心者だった頃にサーバー管理プラグインを自作したこともある: Wave-ServerAdmin。16年たったので、そろそろアーカイブするときかもしれない

    • 実際にオープンソースのWaveサーバーを入手して何か製品を作ろうかと思ったが、最大の制約はデータを永続保存できないことだった。このせいで私には将来性がないように見えたし、Waveチームの反応も現実を知らず幻想に浸っているように感じられた。それでもクールなコンセプトではあった

  • Adobe Flash / Shockwave。何十年たった今でも、ゲームやマルチメディアを作るのにこれほど簡単なツールはない。人類は常に一方向へ進歩するわけではなく、むしろ大切な何かを永遠に失うこともあるのだと気づかせてくれる

    • 初心者でも簡単にゲームを作れたので、ゲーム業界全体に新鮮なアイデアがあふれた。たとえばZachtronicsのようなインディー開発者もこのやり方でデビューした。一方で、Flashゲーム1本ごとに大量の広告や粗雑なFlashベースのナビゲーションが氾濫し、一時期はレストランのWebサイトがどこもFlashだったほど乱用された。Flashベースの動画プレーヤーはLinuxでは厄介で、ブラウザのまともな動画対応を遅らせた主犯でもあった

    • FlashはWebにとって災厄だった。拡大も、テキスト選択も、戻る操作も何もできない黒い箱として存在していた。これが死んだことは、スティーブ・ジョブズ最大の功績に思えるほどだ

    • Godotがかなり近い。習得しやすく、2Dと3Dの両方を支援し、HTML5/webasmで主要OSやモバイルまで幅広く書き出せる。まだ完璧ではないが、ここ数年で飛躍的に進歩しており、Blenderのような大きな転換点が来ている気がする

    • Adobeがセキュリティ問題を完全に解決していたとしても、Appleはいずれにせよ潰していただろう。Flashの大衆的成功はAppleにとって脅威だった。HTML canvasブームも落ち着いた今に至っても、デザイナーがサブスクなしで魅力的なインタラクティブデザインを作り、どこにでも埋め込める代替手段は依然としてない

    • Flashがあまりに乱用されすぎたのが問題だった。会社であるアプリが最後までFlashに固執していて理由を調べたら、ページの単純な横罫線をFlashで作っていた。Flashのドロップダウンメニュー、自動車サイトのスプラッシュスクリーンなど、どれも誤用・乱用だった。モバイル時代が来てようやく死ぬことができ、その頃には惜しむ人もほとんどいなかった

  • killedbygoogle.com に載っている数多くのGoogleサービス。かつては30〜40個使っていたが、今では3〜4個しか使っていない。Google Picasaはローカルで高速に使えたし、Google Hangoutsは複数のチャットアプリのせいで混乱した。G Suite Legacyは永久無料と言っていたのに結局有料化され、それでGoogleを離れた。Google Play Musicにはアップロードした何千曲ものMP3があったが、サービス終了で再アップロードする気にはなれない。Google FinanceやNFC Walletもデータへの信頼が崩れて移行した。Chromecast Audioは必要な一つの機能だけをきっちりこなし、生産終了の知らせでほどなく売ってしまった。Chromecastまで終わっていたことは、使っている最中に知った

    • Google Readerも永遠に惜しまれる。運用コストもそんなに大きくなかっただろうし、長年修正されなくても何の不満も出なかったであろう機能だった。昔も今もRSSは同じように使っている

    • Google Play Musicにアップロードした音楽が全部消えたわけではない。YouTube Musicへ移行したユーザーなら、新しくアップロードしなくても曲はすべて移されている

    • Chromecast Audioは今でもちゃんと動く。ただもう販売していないだけなので、中古もいつもチェックしている

    • Picasaの顔認識は時代を先取りしており、オフラインパッケージが本当に良かった。残念ながら最終版には顔タグがランダムに入れ替わるバグがあり、何千枚もの家族写真の認識が台無しになった。Digikamはかろうじて似た役割を果たすが、代替としては力不足だ

    • Google Notebookを終了してから数年後にGoogle Keepを作ったのだが、機能はほとんど同じだったのが興味深い

  • Lytroのライトフィールドカメラは技術的に印象的で、製品も2つ出たが、プロ写真家向けの解像度には届かなかった。しかし、Meta Ray-Banのライトフィールドディスプレイや gaussian splats のような媒体が登場したことで、今ではより多くのセンサーデータを活用できる時点に来ている。技術以外の面では、ポラロイドやInstaxのような低解像度でも楽しいカメラ市場は大きいので、最初のLytroは面白いフォームファクタにプリンターを載せても問題なかったはずだ

    • ライトフィールドは複数の焦点深度でピクセルを混ぜて記録するので、結果として解像度が通常のカメラより低くならざるを得ない構造だ。製造は難しくないが、物理的限界が惜しい

    • 最近はスマートフォンもこの機能を一部実装しているようだ。Lytroカメラが出たときはかなり興奮したのを覚えている

  • Optaneパーシステントメモリ。データを直接保持することで、起動やアプリのロードなしにそのまま作業を再開できるという革新的な価値があった。高価すぎて失敗したが、それ以前からすでに限界は明らかだった。VMのメモリスナップショットやmacOSコンテナなどのため、この流れが完全に消えたわけではない

    • 3dxpoint技術には絶対的な信頼を置いている。何十年も熟成された技術だったが、ビジネス側に世界が追いつくのを待つ忍耐がなかった

    • 既存システムの考え方がRAMとディスクの区別に縛られていて、Optaneのような新しいハードウェアを受け入れる準備が足りなかった。それでもサーバー分野ではいくつかの応用例が出ており、関連研究プロジェクトも多く登場している

    • Optaneは技術的に驚異的だった。RAMとディスクの境界を消し去りかけた存在で、1本のスティックで全メモリを賄える可能性があった

    • 私は実際にカーネルをOptaneドライブに置いて、即時起動の体験をしている

    • 価格だけの問題ではなく、エコシステムの基盤が十分に広がらず、既存の発想もまだ準備不足だった。初期のLispやSmalltalkのような（ライブ）イメージベース環境により近いモデルだ。私自身も、ファームウェアと小容量Optaneをサポートしていたシステムを持っている。容量は小さく古いOSに縛られるが、実験する価値は大きい。RAMが十分に多ければ suspend/resume のように真似ることもできる。SSDの進歩と合わさると速度差はほとんどなくなり、残るのはTBWのような耐久性だ。両者を混在させて使うこともできる

  • Ricochetネットワーク。電話回線の時代に、無線パケットメッシュでISDN級の速度を提供していたユニークなシステムだ。23都市のネットワークに50億ドルを投じたが、顧客がほとんどおらず、2001年に閉鎖された。マーケティングは「モバイル専門職」に集中していたが、実際にはより高速なインターネットを求めていた家庭向け市場を見過ごしていた。今日の5Gフェムトセルは物理的コンセプトこそ似ているが、冗長性や自己ルーティングの概念に欠けている

    • Ricochetは時代を先取りした素晴らしいシステムだった。Joel Spolskyの感想もおすすめだ: Ricochet Wirelessモデムレビュー

    • Ricochetモデムを本当に愛していた。第2世代RicochetとPowerBookを持ってパロアルトのカフェで56kのWebブラウジングや ssh セッションをしていた思い出がある。今でも家のどこかの箱に入っていて、starモードで遊び半分に接続してみようかと考えている

    • 98〜99年にサンフランシスコでRicochetモデムを使っていた。10年後にiPhoneが3G時代を切り開き、性能向上も圧倒的だった。Ricochetが生き残っていたら人生はもっと良くなっていたかと考えると、むしろ技術の進歩はずっと正しい方向へ進んだと感じる

    • 完全に忘れていたサービスだが、考えてみると当時は本当に優れていた。私も4人しかいなかった顧客の一人だったのかもしれない

  • MicrosoftのMidoriは、権限ベースのセキュリティを目指したOSだった。噂によればWindowsコードを実行できるところまで開発されていたが、社内政治で破棄されたという話もある。Fuchsiaの前身のような存在だ。Midori Wiki

    • Midoriは本当に興味深かった。Joe Duffyのブログが、今のところ最も詳しい資料だ: Midoriブログ。Microsoft内部では moonshot であり、重要人材の引き留めプロジェクトでもあったという評価もある。100人以上、それもかなりシニアなエンジニアが大量投入されていた。一部の研究成果は .NET に活用され、完全に消え去ったわけではない

    • Windowsコード実行の噂がどこから来たのか分からない。公開されているすべての文書によれば、Midoriは既存コードとの完全な非互換を目指していた。内部で移行を夢見た人はいたかもしれないが、設計そのものが移行抜きの根本的に新しいシステムだった

    • 技術的な基礎は面白いが、Microsoftのことだから、結局は新種の専用問題を山ほど抱えた肥大化ソフトウェアになっていた気がする。今ごろは、そもそもユーザーが望んでいないスパイウェアやAI機能まで大量に入っていただろう

    • Genode(genode.org)を知っているだろうか。Midoriに近い領域にいて、今も活発に開発されている

  • Yahoo PipesはRSSフィードとカスタムワークフローを作るのに本当に素晴らしかった。今ではZapierやn8nのような代替があるが、私は特にPipesが好きだった。Google Readerへの回顧にも同意する

    • Pipesの歴史 のアーカイブはぜひ読むべきだ。実際の開発陣の回顧が載っている

    • Yahoo Pipesは、インターネットが進むべき未来だった。何十年たった今でも、ああしたツール間連携は本物の unix pipes レベルにはようやく届く程度だ

    • 実際に使ったことはないが、Pipesについての好意的な回顧を聞くたび、とてつもないツールだったのだと感じる。本当に死んだのがPipesなのか、それともオープン標準とプロトコルに基づく大衆インターネットのほうなのかは分からない

    • Pipesが大好きだった。複数サイトのコンテンツを集めてPipesで整形し、PHPブログへRSSで取り込んでいた。だが、サイトが一つまた一つとRSS対応をやめるにつれ、Pipesも意味を失い、ついに終了した。しばらくは riko というPythonライブラリを使って、ビジュアルエディタなしで似た機能を使っていた。それがPHPからPythonへ移るきっかけにもなった

    • Yahoo! Pipesのアイデアを復活させたいなら、Node-RED(nodered.org)が良い出発点だ。オープンソースで、しっかりしたAPIがあり、10年以上の蓄積、堅牢なバックエンドなど強みが多い。Node-REDのフロントエンドだけを取り出した Browser-Red、Erlangバックエンドとして作り直した Erlang-Red も実際に使った。Node-REDはすべてのノードが入力ポート1つかゼロなのに対し、Pipesは複数入力線を持てる違いがある。フロントエンドは jQuery を知っていれば簡単に習得できるのも良い。Node-REDや flow-based programming について気になることがあれば、いつでも連絡してほしい