【しばらく編集不可モードで運営します】 編集(管理者用) | 差分 | 新規作成 | 一覧 | RSS | FrontPage | 検索 | 更新履歴

SituatedSoftware -

目次

馴染系ソフトウェア

この文書について

馴染系ソフトウェア

私は NYU の インタラクティブ・テレコミュニケーション・プログラム (ITP) で教えている。 そこの生徒たちの半分は美学を重んじる技術者、もう半分は機械を怖れない芸術家であり、未来を見通すにはもってこいの場所だ。

やがてくる未来ではソフトウェアの生態系がかわると私は信じている。その生態系を、ここでは 馴染系ソフトウェア (Situated Software) と呼ぶことにしよう。特定の場面や文脈のために設計されたソフトウェアのことだ。馴染系ソフトウェアを作る方法は、いわゆるウェブ学派(かつて私がプログラミングを勉強した場所)のやりかたとは対照的だ。ウェブ学派はスケーラビリティや汎用性、完全性を美徳としてきた。

私の生徒達はウェブ学派の流儀をあっけらかんと無視し、それでいて面白いものをつくっている。ここ一年ずっと、私はそれが気になって仕方がなかった。まだ未完成な状態ではあるが、 このパターンについて説明しようとおもう。なぜなら、これと同じものを他所で見たひとがいないか知りたいのだ。

ユーザは数十人から。

私達はいつも、エンタープライズな設計手法と David Weinberger のいう「小さな部品を緩やかに繋ぐ」 方法の板挟みになっている。後者の利点については、「Worse Is Better」(デザインの「悪い方がよい」原則, http://grape.mtk.nao.ac.jp/~makino/articles/worse-is-better-ja.html) や 「The Cathedral and the Bazaar」(伽藍とバザール, http://www.tlug.jp/docs/cathedral-bazaar/cathedral-paper-jp.html) でいくらか説明されている。馴染系ソフトウェアは 小さな部品方式に分類される。加えて、次のような特徴がある: 一般的な 「ユーザ」 のためではなく、特定の社会グループのために設計されている。

馴染系ソフトウェアと古典的ウェブ・アプリケーションの最大の違いは、数十人のユーザ向けのソフトウェアを作るのが非常に簡単になるという点にある。ユーザ数が数十人だなんて、現行の設計方式からするとありえない。小さなユーザのグループ向けにぴったり合ったソフトウェアを作るというのは、これまでだと地方の銀行や研究所の実験室での話だった。なにしろ費用がかかるので、ウェブ学派のアプリケーションは大人数を相手にすることに専念してきた。そしてスケールによる価値を手に入れた結果、別の種類の価値、特に社会的な価値はかやの外に置かれてしまった。

私達は 「スケールしない」 ソフトウェアについての議論を黙殺してきた。ずっと長い間そうしてきたせいで、スケーリングの問題が本質的には致命傷にならないことを忘れていたのだ。N の二乗の問題は N が大きい時にのみ問題になる。そして社会での場面をみると、N は大抵そう大きくない。読書会をやるならメンバーは 5 人から 15 人、セミナーなら 15 人から 25 人、多くても 50 人いない。他もそんなものだ。

そのおかげで、特定のグループ向けに作られたソフトウェアにはいくつか嬉しい特徴ができる。まず作る側にとっては安くて簡単。スケーラビリティの問題が少ない。対象となるユーザにわかりやすいものにしやすい。逆に明らかな弱みもある。もともとの場所の外では使いにくい。もし後から大人数のグループを扱おうとすると弱い。ソフトウェアの寿命は短くなるかもしれない。

私の生徒達はいくらかこうしたトレードオフに甘んじた。とはいえ、ウェブ学派がとりくんでいる難題、高価なハードウェア、優秀なプログラマの不在、疎に分布したユーザなどは、もはや制約にはならない。

Teachers on the Run

ウェブ学派の原則が弱まっていると感じた最初の徴候は、私のかつての教え子である Paul Berry と Keren Merimesh が書いたアプリケーションだ。2002 年 11 月のこと、Social Weather というオンライン空間の印象に関する授業のプロジェクトで、彼らは Teachers on the Run というソフトウェアを作った(なんという名前だ)。

Teachers on the Run は基本的に ITP の教員を相手にした HotorNot? だ。これを使えば、春の講義登録に先立って、生徒は私達教員についてコメントや格付けをすることができる。すべての教師がデータベースに登録されている。生徒は匿名でコメントを投稿したり、投稿済のコメントについて 同意/異議あり の投票ができる。コメントは投票の順位にソートされ、+5 のコメント (同意が異議ありより 5 人以上多い) の方が、+2 や -3 のコメントより上位に表示される。たったこれだけのことだ。名前一覧を表示して、コメントの一覧を表示して、クリックで投票、そして簡単なソートのアルゴリズム。

彼らは金曜にサービスを始めた。土曜の夜、ある生徒から私の家へ、それを見たほうがよいと電話がきた。ITP には 200 人かそこらの生徒しかいないにもかかわらず、Teachers on the Run は既に数百のコメントを集めていた。大半がポジティブ、いくらかはネガティブ、誹謗中傷は 2、3 個。それより重要なのは、24 時間で 1000 以上の投票が集まったことだ。月曜の朝、サイトでおきていることを知っているという生徒が幾人もいた。彼らは実際にサイトを見てそれを知ったのではない。週末の話題で聞いたというのだ。

ウェブ学派版の Teachers on the Run が失敗に終わっているのは興味深い。RateMyProfessors?.com は数年前からあり、Teachers on the Run に劣らぬシンプルな読み書き投稿機能をもっている。しかし ITP の誰一人として RateMyProfessors?.com を使おうとは言いだしたことがない。週末にあった格付け投票の乱痴気騒ぎが示すように、需要が潜んでいたにもかかわらずだ。

その溢れんばかりの社会的エネルギーをわかっていたのに、私は Teachers on the Run のもつ重要性をつかみそこねていた。これがうまくいったのは何かしら不公平な理由が色々とあったからだと自分に言い聞かせていた。利用者はプログラムした連中と知り合いだ。教授の名前データベースが前もって用意されていた。プログラマは学内のメーリングリストを使ってアプリケーションの告知をすることができ、プレスリリースやバナー広告が必要なかった。そして最低なことにスケールしないのだ。それがウェブ・アプリケーションが成功する必須条件だというのに。死亡決定。証明終。

そうこうするうち、私は最近教えた授業である設計プロセスを目撃することになる。

授業にて

昨秋私が教えていた Social Software という授業で、生徒達は小さな組になって何かしらのグループ間交流を支援するようなソフトウェアを作った。出発点を与えるため、ITP の学生に使ってもらえるものになるようプロジェクトをやらせた。この方式の第一の利点は単純: 設計者はユーザと同じ集団に属しており、したがって設計者自身が自分の直感を正しいとみなすことができる。ベータテスタは廊下でつかまえてくればいい。こうした利点のおかげで 「海を沸かす」 というような大言壮語へ走らずにすむ。

私は第二の利点を見落していた。授業のグループは何度も問題につきあたるのだが、そうした問題の一部は、社会基盤や文脈依存の情報という利点を活かして解決されていた。ウェブ学派のやり方にこだわっているとこうした利点を活かすことはできない。二つの戦略の違いは際だっている。

一番はっきりするのは信用が必要なシステムだ。The Orderer というプロジェクト (Vena Chitturi、Fa-yi Chou、Rachel Fishman、Cindy Yang らによって設計された) はグループでの食事の注文をまとめるためのソフトウェアである。深夜まで続く作業によくみられるシチュエーションだ。WeBe? (Brandon Brown、Yoonjung Kim、Olivier Massot、Megan Phalines) はチップやモーターのようなものを共同購入するのに使うツールだ。こうしたソフトウェアは金銭が絡むため、ウェブ学派のアプローチでは不払いに対抗する手段が必要になる。たとえば前払いやエスクロー、正式な信用評価システムなどだ。

しかしどちらのプロジェクトもそうした仕組みを用意しなかった。かわりにただ不払いユーザを記録し、不払いだったら名前をだすと威嚇するに留めた。ユーザはみな ITP コミュニティの一人だからだ。コミュニティで恥を晒されるという可能性がアプリケーションの設計にくみこまれている。コミュニティや恥をかくことは、アプリケーションの枠組みの外側にあるにも関わらず。

コミュニティからの注目

それとは別に、コミュニティからの注目を使う方法もある。上とは別のふたつのプロジェクト Scout (Karen Bonna、Christine Brumback、Dennis Crowley、Alex Rainert) と CoDeck? (Mark Argo、Dan Melinger、Shawn Van Every、Ahmi Wolf) は、文字通りコミュニティにとけこんだ。Scout は物理的にそこに居るという事実を使った。生徒が自分の ITP 内での居場所を登録し、Scout はその情報を表示する。CoDeck? はコミュニティで共有しているビデオサーバを使い、ビデオ・アーティストが互いの作品にコメントできるような仕組みを用意した。

どちらのプロジェクトでも古典的な更新通知の問題がある。ユーザは作業を中断して、見逃した更新がないよう気をつかわなければならない。ウェブ学派のアプリケーションでは、ユーザはサイトをブックマークし再訪するという前提のもと、あるいはメールでの通知をいそいそと読むという前提のもと、開発に億単位の投資がされてきた。しかし Schwab.com や eBay のような成功が広く宣伝されている一握りのサービスを別にすれば、ユーザは大抵 「まめにチェックする」 ことを嫌がるのだ。

Scout と CoDeck? のふたつは同じ解決策をとった: インターフェイスの大部分をごちゃごちゃした PC の画面から切離し、物理的なモノに移すことにした。ラウンジ、会議室、ダイニング、ITP フロアの真ん中にある テーブルゲーム機の間など。Scout も CoDeck? も、マウスやキーボードではない物理的なインターフェイスを持つキオスクを作ってラウンジに置いた。Scout は入退管理にバーコード・リーダを使った。CoDeck? は 70 年代中盤製のベータマックスから中身をぬきだし linux マシンを入れた。そしてベータマックスのボタンをビデオのコントロールに使えるようにした。Scout も CoDeck? もウェブサイトがあって、ユーザはデータを入力したり取得したりすることができる。しかし核となる部分は物理的な場所にあり、そこでアプリケーションは社会的な文脈にとりこまれるのだ。

これらのプロジェクトはすべて授業のもともとの条件 ... アプリケーションはコミュニティにとって有用であること ... を満たしている。そして当然の帰結 ... コミュニティはアプリケーションにとって有用であること ... を使うことにもなったのだ。

グループの力

ソフトウェアの設計をする際、私達は常に個人の認知能力に依拠している。ユーザがマウスとカーソルを関連づけると仮定しているし、アイコンは意味がわかるものにする。私達がグループの認知能力をあてにすることは稀だ。しかし、実世界での私達はそうした力に依拠しているのだ。

ブレインストーミングをすると、グループは各個人が別々に考えたアイデアをまとめるより多くの方向性のアイデアをうみだすことができる。そしてグループの総意は、グループで一番ものをわかっている個人による推理より正しい場合が多い。グループはまた、自身についても多くを知っている。グループのメンバーは、他の誰に設計上の助言を求めればいいか知っている。ピンチのとき頼りにならないのは誰かも。正式な指名がなくてもこういう役割はわかる。社会的なグループのメンバーは、誰と飲みにいくのが楽しいか、誰に金を貸さない方が良いかを知っている。(大抵同じ人だ。) FAQ に文書化する必要はない。

ウェブ学派のソフトウェアはこの種の知識を無視している。それを明示化するのは難しいからだ。例えば大規模なメーリングリストではたった一握りの人間が議論を始め、大多数の投稿者はただそれに従う。より上のレベルでみると、たった一握りの人間が投稿し、大多数はただ黙って見ている。十年来の見慣れたパターンだ。にもかかわらずメーリングリストのソフトウェアはスレッドを始めたり続けたりするのを支援する仕組みを持たないし、大量投稿者と読むだけの人を区別もしない。

しかし、別の方法もある。ユーザがアイコンを見分けられるのと同じように、デザイナはグループがある能力を持つと仮定することができる。コードでそれを表現しなおす必要はない。共同購入で未払いをみつけたら、プログラムは単に 「未払い警告。処置せよ」 とメッセージを出すだけでいい。実世界のグループは何とかその問題を扱うだろう。ふつうはモラルに訴えかけるか、名声に傷がつくと言ってやるだろうし、極端な場合は未払いユーザを追放するだろう。

これはオフラインのグループで毎日起きていることと変わりない。しかしウェブ学派の語彙では、この解決策を間違っていると感じてしまう。なぜならそうしたウェブ・アプリケーションは暗黙の信用評価システムがあるとみなすことができないからだ。既存の社会的設備を使うため、馴染系ソフトウェアはウェブ・スケールのアプリのようにスケールはしないことが確定する。しかし同じ理由から、ウェブ学派のアプリにできないことができるのだ。

外の視点

こうしてようやく私は馴染系ソフトウェアを現実的なソフトウェア開発の戦略としてとらえるようになった。「本物の」 アプリケーション開発が縮退したものではないのだと。Social Software の授業の中間批評で、外部のレビュアを招いたのがきっかけだ。レビュアは実際のソーシャル・ソフトウェア開発場面で仕事をしている人達で、批評のセッションはとても価値あるものになった。しかし、2 点の提案については、私にはおかしなものに思えた。

最初の提案は CoDeck? に関するもので、ビデオのデータ置き場をウェブからも使えるようにした方がいいというもの。アップロード、ダウンロード、コメント機能など。第二の提案は WeBe? についてで、Mercata や MobShop? のようなウェブ学派の共同購入サイトを参考にした方がよいというものだった。

迷いの晴れる瞬間だった。これらのコメントは a) 私が他の授業に外部レビュアとして招かれて述べていただろうことと全く同じで、そして b) グループがとりくんでいる問題へのアプローチとしては明らかに間違っていたのだ。

CoDeck? インターフェイスのアクセシビリティに関する提案は、御丁寧な質問つきだった。「なぜできるだけ広くからアクセスできるようにしないのか?」 ウェブ学派。もちろん答えはこうだ。「そうしない理由はない」、なぜならユーザは 「多いほど良い」から。しかし CoDeck? にはそれを単なるウェブ・ビデオ・アプリにしないでおく良い理由が幾つかあった。

まず、ベータマックスのデッキを使ったインターフェイスの物理化はコミュニティでのアフォーダンスをもたらす。これをウェブ全体に再現することはできない。次に、CoDeck? はある一つの親密なコミュニティにとって有用であるように設計されていた。CoDeck? の一般的なアクセシビリティを高めると、ITP のビデオ・アーティスト達のコミュニケーション密度は薄まってしまうだろう。第三に、ラウンジにビデオデッキを置くことで自治がなされた。コミュニティに強く繋がることで悪用から逃れられたのだ。自由にアクセスできてパスワードのない 「アップロードと批評」ビデオサイトは、すぐにポルノの巣窟になってしまうだろう。最後に、ローカルなコミュニティにサービスを提供するならローカルネットワークの帯域を最大限活用でき、公開システムであれば帯域的に耐えられないような機能も可能になる。

WeBe? は小さい方がいい

同様に、WeBe? が Mercata や MobShop? を見習うべきという提案には、目標は大規模運用だという前提がある。しかし、Mercata や MobShop? はその規模ゆえに失敗している。

これらのサイトはポジティブ・スパイラルを前提としている。ユーザが多いほど安くあがり、安くあがるほどユーザは増える。しかし、どこかで誰かが楽をしているというだけではユーザを魅きつけることはできず、クリティカル・マスを越えられなかったシステムは悪循環におちいった。RateMyProfessors?.com と同じように、ウェブ学派のアプリはただそこにあるだけでは駄目だ。数万人のユーザ向けに作られたアプリケーションは、数十、あるいは数百のユーザを扱うことができない。

一方、WeBe? は小スケールのパターンを前例として真似していた。同級生の Scott Fitzgerald がはじめたパターンで、授業で使うマルチメディア編集ソフトウェアを買うのに最大 30 ライセンスの割引を使おうと調整役をした。彼は ITP のメーリングリストを使って買主を募り、それからフロアをまわり、迷っている人を口説いて現金を集め歩いた。これが上手くいくには社会的な道具立てが要る。つまり、皆 Scott を知っていたし、信用していた。

煽り役として、Scott はカルマも得た。参加した皆がいくらか金を節約でき、彼の信頼は増した。現金収入と違い、信頼はより小さく閉じたコミュニティから比較的容易に集めることができる。WeBe? が生まれたのは、Scott が、共同購入は成功だったけれどエネルギーが要りすぎる、と言ったこともある。ITP で共同購入するのを楽にするにあたって、WeBe? のグループは認証や信用評価のシステムを作る必要はなかった。ソフトウェアが特定の(そしてごく親密な)コミュニティの中で使われるものだったからこそ、そういうことを手間をかけずに実現できたのだ。

不足問題は消えゆく

ウェブ学派がうまくゆく場面があるのは、ある種の不足にたいする合理的反応だからだ。たとえば資金: サーバが高い、ロードバランスのルータ、テープのバックアップ、その他厳しい稼働に耐えうる装備。才能: 優秀なプログラマはなかなかみつからない。偉大なプログラマはいないに等しい。ユーザ: ユーザは忙しい。ユーザは習慣に従う生き物だ。気を引こうとする競争相手も多い。

しかし、こうした不足問題に立ち向かおうとして、ウェブ学派の設計方針は出口の見えないものとなっている。アプリケーションはスケールしなければいけない。なぜなら良くできたウェブ・アプリケーションは費用がかさむからだ。しかしスケールしろという要求自身からくる出費はずっと大きい。更に、ある物がない時は他のものも足りないものだ。スケールするアプリケーションを動かすハードウェアには大きな予算が必要になる。そうしたアプリケーションを作るには、優秀なプログラマや管理者が必要で、その人件費がかさむ。人件費を稼ぐには十分な数のユーザを得て支払いをうける必要があり、そのためには広告費がかさむ。

私の生徒がやっていることは、この流れから降りることではないかと思う。そうできるのは、ウェブ学派が挑んでいる不足問題はもう問題ではなくなってきているからだ。ムーアの法則同様ストレージは大きくなっているし、OS の機能はよくなりつづけている。そのおかげで 800 ドルで買ったデスクトップマシンが、そのまま十分にいいサーバになる。

次に、かつてはユーザの興味をひくことが難しかった。ひとつにはユーザの少なさが原因にある。90 年代に作られたウェブ・アプリケーションは実世界の特定のコミュニティと直接のつながりがなかった。インターネットのユーザは広く浅く分布していて、IT 産業以外の場所では、オンラインのメンバは実世界のグループのごく小さな部分でしかなかったからだ。

そうした時代は終わろうとしている。場所によってはもう終わってしまった。今日の米国では、35 歳以下か 年収 3万5千ドル以上の人はおそらくオンラインだ。したがってあなたがオンラインならあなたの知り合いもオンラインだろう。今や実世界のグループに合わせたアプリケーションをつくることができる。そのグループのメンバ皆がインターネットにアクセスできると考えてよい。

プログラミングのあり方と MySQL に起きていること

最後に、プログラミングのあり方も変わってきている。最近、今から 10 年以内に米国のプログラマは 23 万 5 千人少くなるだろうと Gartner が発表して騒ぎになった。これは 80 年代に、2004 年までにタイピストが減るだろうと予想するのとよく似ている。そうした予想はある意味で正しい。オフィスの専業タイピストは減り、データ入力業は海外へ移転した。しかし実際のタイピング ... 指でキーボードを打つこと ... はなくならなかった。それはあらゆる場所に広まった。

同じ事がプログラミングにもおこる; 全ての関心はアウトソーシングに集まっているが、多くのダウンソーシングもまた起こりつつあるのだ。プログラミングは職業上の技能から、より広く身につけられるスキルになりつつある。もしプログラマという言葉が 「コードを書いて給料を貰っている人」 ではなく 「コードを書く人」 を指すなら、2015 年にむけてその数は増えつづけるだろう。perl や JavaScript、Flash を使う人の多くは自分をプログラマだとは思っていないけれど。

様々なテクノロジがこの流れを推し進めている。perl、PHP、ActionScript、DHTML ..。色々な技術が混ざりあっている。どれか一つがコア・ツールというわけではない。ただし例外がひとつだけある。このパターンが見られるアプリケーションは、どれも MySQL を使っているのだ。

これはウェブサーバ・ソフトウェアと平行した現象だ。90年代なかば、ウェブサーバを動かすことは それ自体が目標となってしまうような厄介な仕事だった。それから Apache が登場した。ウェブサーバを立てるのは簡単な仕事になり、単純に、より大きな事ををするための構成要素となった。

MySQL はデータベースの分野で同じことをしている。これはグループ・アプリケーションを開発する上で意味のあることだ。なぜならソート機能は公共財だから。もし Teachers on the Run が単なるコメント付きの講師リストだったら、書きこみ専用のアプリケーションになってしまっただろう。ニュース記事によくある「あなたの考えを聞かせてください」 という(何の役にも立たない)コメント用フォームがあるだけ、というような。どんなグループでも、何より知りたい重要事項の一つは 「他の皆は何を考えているか」 だ。特にグループとしての知識が個々人の知識を上回るなら。「ユーザがコメントを格付けする」 機能をもたせ、更に時間ではなく格付けの順で表示するようにしたことで、システムは価値あるものになった。

もしろんこうした機能をデータベース以外の方法で実現することもできるだろう。しかし MySQL をつかえば仕事はずっと簡単になる。実際 MySQL 以後、問題は別の場所に移ったのだ。MySQL を使うか他のデータベースを使うかについては技術的に入り組んだ議論がある。しかしそうした議論はもう焦点ではなくなっている。理由はどうであれ、これら新しいアプリケーションでは MySQL がコア・ツールになっているようだ。

母に贈るソフトウェア

馴染系ソフトウェアは技術的な戦略ではなく、ソフトウェアとそれを使うユーザ・グループの密着度をどう考えるか、である。そしてスケーラビリティや汎用性、完全性を無条件に善として受け入れるのを拒むことだ。この境地のもとでは、ウェブ学派のソフトウェアがパーソナライゼーションに固執するのは自明な真実からの言い逃れに見える。大半のウェブ・アプリケーションはその設計からして個人向けでない。総称的なユーザを相手に作られているのだから。ユーザがウェブサイトのインターフェイスをカスタマイズできるのは便利かもしれない。しかしそれは ATM 現金を吐きだす時にユーザの名前を表示するのと大差ない。

馴染系ソフトウェアは、それとは対照的に、パーソナライズする必要がない。もともとがパーソナルなのだ。Teachers on the Run はそうして作られている。Paul と Keren がそれを作ったと皆が知っている。ユーザは Clay、Marianne、Tom や他の ITP の講師以外は格付けすることができない。ITP のメーリングリストに入っていなかったら、その存在すら知ることはない。アプリケーションとして汎用的だったり完全だったりしないこと自体が 「きみのために作ったんだよ」 と語りかけてくる。非パーソナルな作りの RateMyProfessors?.com はそうできないし、そう見せかけることもできない。

私の生徒の一人はウェブ・アプリケーションを母のために作ったという。学校の教員である母親が使う、授業の記録をつけるアプリケーションだ。ただひとり、給料を貰うわけでもなく、余暇を利用してアプリケーションを作っていても、すべての教員のために汎用的で完璧なものを作ることはできない。しかし、母親のためのものなら作ることはできる。

もちろん、目的がはっきりとした小さなアプリケーションはこれまでも存在していた。かつては PC の持主にメッセージを表示すべく BASIC を学んだものだし、投資銀行や研究所といったデータが重要な組織では小さなグループのユーザ向けにソフトウェアを書く。しかし今、良い道具や優れたユーザがあらわれ、またインターネットが社会の舞台となった。これらが組み合わさることでそうしたソフトウェアを作るのは簡単になり、できあがるものの品質はあがった。ユーザがそれを使うには単にリンクをクリックするだけでいい。数十人を相手にしたソフトウェアを設計する、かつては困難だったこのことがやがて一般的なものになるかもしれない。

次は?

では次に何がおこるのだろう? 私が目にしているのが一時的なものだったり、限られた一部の現象でないのなら、こうした小さく身の丈にあったアプリケーションが増えていくことになる。これははっきりし問題を抱えている。開発者はコミュニティのサポートを押しつけられるだろうし、こうして作られたソフトウェアの寿命は短いだろう。

しかし長生きを期待するのはある種のスケーラビリティだと言える。アプリケーションを長く使いたいと考えるのは、それを作るのにコストがかかるからだ。安く簡単にソフトウェアを組めるようになれば、この原則は弱まる。ビジネスでは稼ぎのいい人々に数百時間をかけて PowerPoint? のスライドひとつをつくらせることがよくある。そのスライドはミーティングで一度使うだけだ。ソフトウェアを多くのユーザに使えるようにする、あるいは多くのユーザのために残すというのは慣習にすぎず、ソフトウェアそれ自身の要件ではない。

実際問題、多くのユーザに長く使ってもらおうと作られた大抵のソフトウェアはその両方の目標を永久に達成しない。馴染系ソフトウェアはこう主張することができる: 「大抵のソフトウェアは短い期間、少しのユーザに使われるだけだ。なぜその利点を設計に生かさないのか?」

こうした事態は、奇妙なことだが、進歩といえる。馴染系ソフトウェアが他のアプリケーションを駆逐するからではない。そうはならないだろうからだ。現在のソフトウェアがつくる生態系のもつ価値はどれも、一握りのユーザが数ヶ月使うアプリケーションがもたらすものではない。私達は新しいソフトウェアのニッチをみつけたのだと思う。コミュニティは個々の特別な要求にぴったりのツールを手に入れる。そのツールはこれまでの設計品質や成功のための試験には落ちるだろうが、にもかかわらずよく機能する。そのソフトウェアは、それを使うコミュニティによく馴染んでいるから。