ハクソク

世界を動かす技術を、日本語で。

オープンソースはあなたのためのものではない (2018)

2026年2月13日原文(gist.github.com)

概要

  • オープンソース の運用方針は、 プロジェクト運営者 のみが決定権を持つという主張
  • ユーザーは 権利や要求 を持たず、期待は自己責任であることの強調
  • Clojure開発チームの 実情と姿勢 の説明
  • オープンソースへの 誤解や神話 への警鐘
  • コミュニティ貢献 の多様な方法と、前向きな行動の呼びかけ

オープンソースの本質とユーザーの立場

  • オープンソースの「あるべき姿」を語る資格は、 プロジェクト運営者 に限定される
  • その権限は 自身のプロジェクト の範囲に限られる
  • ソフトウェアをオープンソース化しても、 開発者に役割転換（例：コミュニティマネージャー） を強いるものではない
  • オープンソースのユーザーは、 貢献・機能追加・他者の注意・苦情への価値付与・説明 など、何も「当然の権利」として持たない
  • 期待が満たされない場合、その期待は 自分自身の責任
  • 必要なものがあれば 自分で作る姿勢 の重要性
  • オープンソースは ライセンスと配布の仕組み であり、それ以上でも以下でもない

オープンソース神話と現実

  • 「コミュニティ主導開発」などの 社会的付加価値 は、最近作られた神話であり、実態とは異なる
  • この神話は、多様な運営方法を認めず、 共同体の権利意識 を助長する傾向
  • CognitectやClojureチームが「コミュニティのために何もしていない」との批判は 事実誤認
  • 望む「努力・集中・反応」が得られなくとも、それは 運営者の自由裁量

CognitectとClojure開発の現状

  • Cognitectのメンバーは 生活のために働いている。Clojureからの ロイヤリティ収入はゼロ
  • Clojureユーザーの 1%未満 のみが直接Cognitectの顧客
  • 収入の一部を Clojure開発やコミュニティ活動 に充当し、時には 退職金を削って 投資
  • チームや開発作業への 誇りと情熱
  • Alex Millerは コミュニティ対応 に非常に熱心
  • コアチームは 定期的にコミュニティ課題を議論 し、機能設計やパッチ対応に多くの時間を割いている

コミュニティ貢献とオープンソースの贈り物性

  • Clojureのリリースには 多くの外部貢献 が含まれる
  • 大多数のユーザーは 貢献していないし、その意志もない が、それで問題ない
  • オープンソースは 無条件の贈り物 であり、全参加者がそれを認識すべき
  • Clojureの開発プロセスは「 閉鎖的」ではなく、 保守的 であることが特徴
  • この保守性が、 機能過多や高頻度な変更 を避け、Clojureの品質を保つ要因

意見の相違と行動への提案

  • Clojureの運営方針に 納得できなければ、自身でプロジェクトを立ち上げる選択肢
  • 本チームが「 貢献の妨げ」になっているとの主張は事実と異なり、 多様な貢献機会 が存在
    • ライブラリ開発
    • アウトリーチ活動
    • トレーニング・チュートリアル・ドキュメント作成
    • 講演やツール開発
    • コアへのパッチ提供
  • 多くのパッチやIssueは 問題記述・計画説明・テスト・設計 が不十分な場合が多い
  • コミュニティによる トリアージ活動の重要性 と感謝

オープンソースへの認識転換と創作者の士気

  • オープンソースへの 先入観の見直し の必要性
  • クリエイターの モラル低下 は現実問題
  • 先入観や行動は 各自の責任
  • Clojureのやり方に合わなければ、 無理に従う必要はない
  • コミュニティを 否定的な言動で破壊しない よう呼びかけ

前向きな参加と個人の意見

  • 否定的な態度 よりも、できることに 前向きに取り組む 姿勢の推奨
  • 本メッセージは 個人の意見 であり、Cognitectの他メンバーは関与していない
  • Clojureコミュニティの 大多数は素晴らしく前向き であることへの感謝
  • 本文に 自分が当てはまらない と感じるなら、それで問題なし

Hackerたちの意見

これについてもう少し背景が知りたいな。多分、「Cognitect」っていう団体に関する何かドラマがあったんだろうね。Clojureに関わってない自分には、なんでこの投稿が作られたのか理解するのが難しい。

└

おそらくこれだね: https://news.ycombinator.com/item?id=46990729

└

これは2018年のClojureサーベイへの反応だったんだよね（https://danielcompton.net/clojure-survey-2018）。その中で、Clojureがもっとコミュニティ主導の開発プロセスに変わるべきだって議論が起きたんだ。

└

当時の背景はこれだよ: https://old.reddit.com/r/Clojure/comments/a0pjq9/rich_hickey... MinIOについての議論を読んでいるときに、この内容を思い出した。

最近、期待を明確に書き出すことの重要性を感じるようになった。特に、人々の期待に対する暗黙の前提がずれているときはね。リンク先の内容は、プロジェクトのオーナーとユーザーの期待が合ってないことを主に説明しているみたい。背景は知らないけど、フラストレーションから書かれたように見える。期待のセットを表現しているけど、防御的でイライラしたトーンになってる。もし今日、自分がそんな状況にいたら、プロジェクトのルートにCONTRIBUTING.mdファイルを作って、自分の期待（例えば、PRは歓迎かどうか、プロジェクトの決定はXの方法で行われる、など）を冷静に説明するかな。もしユーザーが自分の意図とずれた期待を表明したら、CONTRIBUTING.mdを指摘して、議論を終わらせると思う。フラストレーションが高まる前に、こういうステップを踏むようにしてる。これをリンク先の投稿を批判するために言ってるわけじゃないよ。最近やっとこの理解に至ったんだ。ただ、フラストレーションや恨みが時間とともに増すのを放置するよりは、こういうアプローチの方が健康的だと思う。

└

リンク先の投稿を批判するために言ってるわけじゃないよ。 あなたが書いたことは、明らかにリンク先の投稿への批判だよね。

└

同意するよ、TFAは期待を明確に書く良い例だね。でも、ヒッキーが最終的にストレートに書かなきゃいけなかったことを責めるのはちょっと違うと思う。オープンソースのチームに無料で働いてもらうのが当然だと思ってる人もいるし、どんなに説明してもその考えは変わらないよ。彼らはその主張を理解してるけど、同意はしないんだよね。

└

さらに、契約を冷静に書き下ろすことは、フラストレーションを抱えながら叩き出す必要がなくなり、悪い印象を残さずに済むよ。

└

誰かが言ったことがある：虐待と期待は協力の文化を蝕む。今、$workでこれをリアルタイムで見てる。フラッグシップ製品が私たちが構築しているプラットフォームに載せられたけど、営業・マーケティング・プロジェクト文化は全然調整されてない。人々は押しが強くて、虐待的で、コミュニケーションが下手で、すべてをCレベルにエスカレートさせてる。その結果、私たちプラットフォームエンジニアリングは、昔ながらのシステム管理者の心を呼び起こして、サポートプロセス、チケット、ルール、期待を整備して、他のことは全部捨てることにした。今はみんな苦しんでるけど、自分のメンタルを守るためにこれをしなきゃいけない。少なくとも私にとっては、これが多くのOSSインフラプロジェクトで起こっているように感じる。人々はこれらのプロジェクトから必要なものに対して、すごく押しが強くてイライラしてる。私は、必要なもののためにPRを設定するために上司と話したいけど（それはうまくいってる）、他の人たちはOSSプロジェクトが彼らのニッチなニーズを満たさないことにすごく怒ってる。そうすると、怒りやフラストレーションが生まれて、メンテナーにとって有害だけど必要な境界を設定することになる。「CONTRIBUTING.mdに送る」だけでも。職場の数人だけで、ドキュメントや私たちと効果的に働く方法について、毎週何十件もリマインダーを送ってる。これは、自由な時間に一日だけやるようなことじゃないし、痛みを和らげるための給料も今のところ薄い。

自分はオープンソースの代替品と競合する商業製品を作ったんだけど、この緊張感は常にあるね。人々は、オープンソース版を使えるのに、なんで自分にお金を払うべきなのかって聞いてくる。正直な答えはこうだよ：もし自分でオープンソースツールを運用、維持、解釈する時間と専門知識があるなら、絶対にそうすべきだ。リッチが君の貢献を当てにされるのと同じように、君も自分のお金を当てにされるべきじゃない。でも、その質問をするほとんどの人は「誰かがその難しい部分を無料でやってくれない？」って本当に聞いてるだけで、リッチが言ってる特権意識そのものだよ。

└

確かに面白い世界だね。自分はそこそこ人気のあるパッケージを維持していて、ある時デロイトのコンサルタントからセキュリティに関するフォームを記入するように求められたことがある。 complianceフォームを記入して、パッチのコミットメントを無料でやるつもりはないって言ったら、彼らは本当に困惑してたよ。どれだけのメンテナーが自分を利用されているのか、考えさせられるね。

└

もう一つのよくある「権利意識」は、自分が提案した改善が実現しないと不満を持つことだね。実現するかもしれないけど優先度が低いからすぐには無理って場合も同じ。よくある反応は「コミュニティのために再考すべき」って言ったり、SNSで文句を言って他の人に圧力をかけようとすること。あるいは「別のものを使うぞ」って脅すこともあって、これには昔からちょっと笑っちゃうよね。セキュリティの問題に対する迅速な対応を期待するのは全然アリだと思うけど、新機能や大きな変更（他のワークフローを壊すかもしれない、特に自分の！）は全然別の話だよ。 --------- [0] 何年も前に自分がf/ossのコードを公開してた時は、「じゃあコミュニティのために自分でやってパッチを送れば？」って言ったこともあったけど、だいたいは不満の反応が返ってきた。でも今後コードを公開することがあったら、「オープンソースだけどオープンな貢献は受け付けない」ってスタンスになると思うから、そんなパッチは受け付けないし、「フォークして自分でやってね」って感じになるかな。

Hacker Newsで議論の続きを見る