monoculture-ja

From IndieWeb

This article is a stub. You can help the IndieWeb wiki by expanding it with relevant information.


Monoculture（モノカルチャー／単一文化）とは、特定のソフトウェアがその分野を支配（あるいは支配を試行）するアンチパターンを指します。多くの場合、同じコードベースの他のインスタンスとしか通信できないように制限することで支配を図ります。モノカルチャー（異なる人々が運営するサーバー上で同じソフトウェアが動作している状態）は、サイロ（同じ個人や組織が運営するサーバー上で同じソフトウェアが動作している状態）よりは一段階上の状態と言えます。

事例

時間の経過とともに形成されたソフトウェア・モノカルチャーの例：

  • Mobile WebKit：モバイルウェブのコンテンツをWebKitブラウザのためだけに設計するウェブデザイナーたち。これには `-webkit-*` というCSSプロパティのみの使用や、WebKitのユーザーエージェント文字列を持たないブラウザのアクセスをブロックすることなどが含まれます。
  • BuddyCloud：「オープンソースの分散型ソーシャルネットワーク」と自称しています。
    • 本来、特定の単一プロジェクトを「分散型ソーシャルネットワーク」と見なすべきではありません。
  • Diaspora：ある程度までは他のDiasporaインスタンスとの相互運用を強調していましたが、いくつかのオープン規格もサポートしていたため、単一プロジェクト限定の相互運用ではなく、オープンな相互運用に向けて進展を見せました。
    Main article: Diaspora
  • ...

モノカルチャー的なプロジェクトに共通するパターン：

  • 既存の有効なプロトコルの調査や再利用を厭う（あるいは最小限にしか行わない）。
  • 既存の健全なコミュニティに関与しようとしない。
  • すべてをプロジェクト内で解決しようとする。
  • 自分たちが他者のプロトコルに従おうとしなかった（あるいは検討して不採用にした理由や、自前の方が優れている理由を文書化しなかった）にもかかわらず、他者が自分たちのソフトウェアやプロトコルに従うことを期待する。（これに対し、webmentionはpingbackを意図的に改良したものであるという対照的な例があります）。

モノカルチャー・コミュニティ

モノカルチャー的なプロジェクトが陥りやすいもう一つの罠は、そのプロジェクトを中心に「モノカルチャーなコミュニティ」を形成してしまう傾向です。

活発な開発者／ユーザーコミュニティを持つことは、初期のオープンソースプロジェクトにとって絶対的な必要条件だとされています。

  • 本当にそうでしょうか？ ここにいる人々が自分のサイトのために構築している初期のIndieWeb プロジェクトのどれも、プロジェクト固有の開発者／ユーザー「コミュニティ」など持っていません。おそらく、これは「必要条件」という誤った思い込みです。オープンソースプロジェクトに本当に必要なのは、少なくとも一人の献身的なクリエイ���ーであり、それは絶え間ないセルフドッグフーディングを通じて得られるものです。どれほど多くの開発者／ユーザーコミュニティがあろうとも、献身的なクリエイター（あるいはその欠如）の代わりにはなりません。 - Tantek 2013年5月30日 11:43 (PDT)

しかし、コミュニティを作る際、本質的にモノカルチャーを永続させる（これが便利なデフォルトのようです）選択をするか、逆にプラットフォーム間の相互運用性と互換性を育む文化を選択するか、という選択肢があります。

例えば、有望な新ブログプラットフォーム「Ghost」のKickstarterのストレッチゴールから得られたこの賞品を見てみましょう：

「Ghostで書かれたストーリーをキュレーションする、オープンソースのデジタルマガジンを構築します」 Ghostブログプラットフォーム

たった一つのブログプラットフォームで書かれたコンテンツだけを扱うオープンソースマガジンを作ることが、果たしてオープンソースソフトウェア運動の精神にかなっていると言えるでしょうか？

特定のドメイン（例：コンテンツ出版）内の複数のプロジェクトが、より大きな何かを達成するために協力し合う方が、オープンソースにとって有益ではないでしょうか？

過去の事例

モノカルチャー的な取り組みは、通常、他の取り組みとの異種間相互運用性を進化させるか、さもなくば消滅します。

  • Tent.io：単一プロジェクトによる分散型ソーシャルネットワークの解決策として売り込まれました。
    Main article: Tent.io

引用

モノカルチャー的な取り組みや態度は、人々（特に推進者やアイデアマン）がそれについて語る様子から推測できることがよくあります。分散型や分散システムを議論する文脈において、以下の発言に含まれるモノカルチャー的な前提（しばしば皮肉なもの）に注目してください。

  • 私は、上記のすべてをそれぞれの立場で活用し、一つのプラットフォームの下で機能させるプラットフォームを開発しています。

    — https://chat.indieweb.org/social/2021-04-13#t1618353091983500 （太字は筆者）

  • 私は、地球規模の分散コンピューティングメッシュを構築するためにそれをやりたいのです。

    — 同上（太字は筆者。「地球」規模に対して、特定の個人による一極集中した願望と努力というポジショニングに注目してください）。

デメリット

モノカルチャーには、以下のような多数のマイナス面があります。

  • セキュリティリスク — 多くのサーバーで全く同じバグが存在することを意味し、攻撃を再利用して大量のサーバーに一斉に仕掛けることが可能になります。例：WordPress、MediaWiki、OpenSSL
  • ソフトウェアが価値観をコード化する — Facebookが意味する「いいね」は、Googleが意味する「+1」とは異なり、Twitterの「お気に入り」とも、WordPressの「スター」とも異なります。それぞれのセマンティクス（意味論）は異なります。ソフトウェアの選択肢が多様であれば、人々は自分が大切にする価値観の概念を、より幅広くソフトウェアにエンコード（コード化）する実験ができるようになります。
  • オープンソースのモノカルチャーは、協力者間の非生産的な意見の相違を助長する可能性があります。全員が同じプロジェクトに取り組んでいる場合、実装のすべての詳細に合意しなければなりません。一方、相互運用性と個人のユースケースに焦点を当てれば、誰かが妥協する必要なく、健全な議論を促すことができます。
  • モノカルチャーは「脆弱性の負債」を蓄積させます。相互運用性を犠牲にして内部的な接続を容易にすることで、最終的には接続されたすべてのデータが一気に失われる大規模な崩壊を招きます。ウェブのアンチフラジャイル（反脆弱性）を参照。
  • ...

認識されている利点

モノカルチャーにはいくつかの利点があるように見えます。例えば、同じコードベースの異なるインスタンス間であれば実装が容易であることなどです。

しかし、この「実装の容易さ」は相互運用性における進歩の「錯覚」に過ぎず、実際には、実装をまたいだ相互運用性という難題に取り組むための意欲を削ぐ障壁となる可能性があります。

回避する方法

ソフトウェアは、自システムの他のインスタンスと連携することよりも、他のコードベースとの統合を優先することで、モノカルチャーを助長することを避けることができます。

コミュニティとしては、多くの異なる実装を使用し、それらが連携して動作するように開発者に働きかけたり構築したりすることで、モノカルチャーを回避できます。

解決策

モノカルチャーに対する潜在的な処方箋：

  • あらゆる仕様において、複数の独立した実装を奨励する（多様性（Plurality）を参照）。
  • モノカルチャー的なプロジェクトに対し、IndieWebの��ルディングブロックのいずれか、あるいはすべてをサポートし、IndieWebにフレンドリーになるよう促す。
  • モノカルチャー的なプロジェクトの参加者にIRCへの参加やGuest Listへの登録を促し、次回のIndieWebCampへの参加を呼びかける。これらのプロジェクトに建設的に関与することで、プロジェクト自体やプロジェクト間の相互運用性を改善する手助けができるかもしれません。

私たちは、働きかけに成功し、より広いIndieWebコミュニティに統合されたモノカルチャー・プロジェクトを文書化していくべきです。

記事

関連項目

Retrieved from "https://indieweb.org/wiki/index.php?title=monoculture-ja&oldid=109032"