オープンソースは公開コミュニティを意味しない
(blog.feld.me)- オープンソースソフトウェアは (D)VCS 以前でも、HTMLページ、txtファイル、FTPのtarball、メール連絡先だけで配布でき、公開コミュニティがなくてもオープンソースだった
- メーリングリストやIRCチャンネルがあれば運が良いほうだったが、pull request、issue、wiki、core team、Code of Conduct はオープンソースの必須条件ではなかった
- Sourceforge は CVS/SVN とメーリングリストをほぼ無料で提供し、公開開発を容易にした。その後 git が DVCS 競争に勝ち、世界は GitHub に収束した
- GitHub 以後、オープンソースのメンテナンスは issue、範囲外の pull request、不満や要求、チャットグループの管理まで抱え込む 無給労働 のように変わり、バーンアウトやコントロール喪失につながりうる
- プロジェクトは必ずしも公開で開発される必要はなく、issue tracker や pull request を無効にしたり、bare git サーバーを使ったりして、信頼できる小さなグループまたは一人で オープンソース を運営できる
GitHub以後のメンテナンス負担
- GitHub はオープンソースをメンテナーにとって 無給労働 のように感じさせる
- 職場でチケット、利害関係者との会議、ロードマップ、政治、気の散る要素、締め切り、指標、KPI、変更された要求、standup、one-on-one、Agile、Waterfall に対応したあとでも、家に帰るとオープンソースの通知が積み上がる構造になった
- issue が溜まり、プロジェクトの範囲を外れた方向へソフトウェアを再設計する pull request が入り、不満や要求が増える
- チャットグループや「コミュニティ」ができると、メンテナーは短気な人々を管理し、1対1で対応する責任まで負うことになる
- その結果、オープンソースは 第二の仕事 のように変わり、メンテナーはバーンアウトを経験し、自分のプロジェクトの統制権や方向性すら失いかねない
もう一度シンプルに運営する
- 一部のプロジェクトは大きく複雑すぎてチーム管理が必要だが、これは例外であり一般的なケースではない
- 新しい人たちやAIボットに注意を奪われる状況に腹が立つなら、昔のやり方に戻ることはできる
- issue tracker や pull request を無効にしたり、コード公開用に bare git サーバーを運用したりできる
- 本当に知っていて信頼できる小さなグループと一緒に作業することも、完全に一人でプロジェクトを進めることもできる
- 見知らぬ人が自分の空間を侵すのを許す必要はなく、見せかけの Code of Conduct や LLM ポリシーも必須ではない
- オープンソースが「オープンソース」であるために、必ず 公開で開発 される必要はない
- 好きなツールを使い、好きなものを作り、クリスマスの午前2時に code drop してもよく、技術インキュベーターと保育施設が混ざったようなオペレーティングシステムへ引きずり込まれる必要はない
2件のコメント
Lobste.rsの意見
こういう考えから https://casuallymaintained.tech/ を作ったが、とても気に入っている
最も有名な例は SQLite で、外部からの貢献を拒否している
Airbusの航空機のような ミッションクリティカルなアプリケーション にも使われていることを考えると、合理的な方針だ
SQLiteはオープンソースなので、好きなだけコピーして制限なく使えるが、公開貢献（open-contribution）プロジェクトではない
SQLiteをパブリックドメインのまま維持し、独占的・ライセンス付きコードが混ざるのを防ぐため、貢献をパブリックドメインに捧げるという声明を提出していない人のパッチは受け付けない
かなり新鮮な視点だ
もしかすると著者は正しく、私たちはメンテナーに求めすぎているのかもしれない
壊れているのはオープンソース全体ではなく、オープンソースが何を提供すべきかに対する 期待のインフレ なのかもしれない
GitHubの社会的要素も一因かもしれない。スターと一般ユーザーが増えるほど、プロジェクトを見に来る新しい人たちを満足させなければならないという圧力が強まる
とりわけ、コミュニティの関心や要求が作り手の当初のビジョンと合わないときに危険になる
関連記事: Git without a Forge: https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/git-no-forge/
堅実なアプローチで、もっと多くの人がこれをデフォルトにしてほしい
コミュニティを作ること や何らかの責任を引き受けることは、例外的かつ意図的な行動であるべきだ
行動規範やLLMポリシーを見せかけだとした部分は少し的外れに見えるが、繊細な話題なのでそういうものだろう
ただし、ユーザーもコミュニティもなく、今後作るつもりもない1人用リポジトリに貼っておくなら見せかけになる
1人で使うリポジトリに、自分自身のための行動規範は必要ない
この議論が勢いを持ち、実際に機能する合意につながれば本当にいいと思う
ソフトウェアを作り、健全に貢献するやり方はたくさんある
ただしそれらは互いに両立しなかったり、オープンソースの高い基準に合わなかったり、可視性や人気のコストを払う必要があったり、ライセンス・セルフホスティング・コード貢献を受け付けないことのような異なる仕組みを使ったりもする
コミュニティソフトウェアで 楽しさと公平さ を前面に置く良い道を一緒に見つけられればと思う
この記事で示されている状態は、有名人ではない人が作ったばかりのすべての個人オープンソースプロジェクトの自然な状態だ
私たちは皆、そのように運営されているプロジェクトをかなりたくさん持っている
問題は、人々がプロジェクトから何を得たいのか分かっていなかったり、人気のあるプロジェクトを運営すると格好いいだろうと考えつつ、そのコストをきちんと見積もっていなかったりすることにある
そのため、意識的であれ無意識的であれ 注目集め が始まる
「GitHubがオープンソース全体をメンテナーにとっての無給の仕事にした」という言い方は、それを許した場合にだけ当てはまる
漠然とした名声の約束を除けば、ほとんどの状況でGitHubが本来自分のやりたくないことをやらせるためのテコはあまりない
その通りだ
以前、少し人気のあったプロジェクトがあり、望んでいない機能に関するバグ報告やプルリクエストが入ってきて対応するのにストレスを感じた
あのときこういう文章を読めていたらよかったと思う
付け加えると、https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9 も一読の価値がある
小さなプロジェクトについては、この記事に強く同意する
より大きなプロジェクトでも、最も成功したものは最初からオープンなコミュニティとして始まっていないことが多い
好きなプロジェクトの多くは大規模組織で開発が始まり、重要なのはそのソフトウェアを 社内で実際に積極的に使っていた ことだ
そのためメンテナーもすでに報酬を受け取っていた
個人プロジェクトであれ社内チームであれ、開発者自身の日常的な問題を解決するために作られたソフトウェアのほうが、名声や事業化のために作られたソフトウェアよりも成功しやすく、搾取的でもないように見える
Hacker Newsの意見
どれほど閉じたコミュニティでも、礼儀正しいメールを送れば貢献を受け入れてくれることが多い
あるオープンソース開発者が嫌がらせに疲れて、リポジトリのプルリクエストやいくつかの機能を無効にしていたことがあり、その時期にとても気難しい人だという評判まで立っていた
私はその事情を知らず、単にそのプロジェクトはもともとそういうやり方なのだと思って、メールアドレスを少し調べたうえで、気軽な丁寧なメールで非公式パッチを送った。使ってもよいし無視してもよいとはっきり伝えた
その開発者は感謝すると返事をくれ、事情を説明し、不便をかけて申し訳ないとまで言い、そのように閉じる以外に対処法が分からなかったと話したうえで、もちろん修正も取り込んでくれた
この記事は、自由ソフトウェアのプロジェクトが議論やバグ報告をDiscordに強制するという広く存在する問題を扱うのかと思った
1〜2週間ほどは別のツールへ移ろうという動きも見えたが、もう熱は冷めたようで、結局みんな諦めてDiscordに戻ったようだ
Discordが完全にひどいわけではないが、揮発的で、巨大で肥大化したWebアプリを要求する
年季の入った立場からすると、筆者の姿勢は気に入っている
ARPANETの古参たちの前に座っていた時代、1しかなくてその半分ほどを手作業で0に削り出さなければならなかった頃を覚えているくらい昔からいる
昔のソフトウェア開発では、プロジェクトはたいてい1人か2人によって書かれたり保守されたりしていて、インターネット中が彼らのメールアドレスを知っていて、直接バグ報告を送っていた
あるプロジェクトはIRCやメーリングリストで議論され、たいていはプロらしく振る舞っていたし、そうでなければメーリングリストから削除されるか、iircやpineのブロックファイルに入れられた
要点は、どの時点でもアクティブな開発者グループは非常に小さかったということだ
make、Sendmail、sed、awkのような小さなユーティリティを主に指していて、Perlでさえ1990年まではほとんどLarry Wallとtchristしかいないように見えた
gccは、何千人もの人がパッチを送り、それをアップストリームに入れようとするにはRMSともうまく調整しなければならなかったという、狂ったような反例だった
新しいツールは、より大きなチームが継続的に相互作用することを支えてくれるし、小さなチームが、インターネット上の誰かが腎臓でも賭けるくらい本気でない限りパッチなど気にしない、というやり方にも大きな利点がある
ただし、そういうやり方は人を成果物に引き込むうえでは利点ではないので、昔ながらのやり方で行くことはできても、チームは小さくなり、利用者を引きつけにくくなるかもしれない
それでも利用者のことなど知ったことではなく、私は自分のユースケースを支えるためにソフトウェアを使い、もしかすると他の人にも役立つかもしれないと思ってオープンソースとして公開している
もっと具体的に言えば、オープンソースは4つの基本的自由だけを約束する(https://en.wikipedia.org/wiki/The_Free_Software_Definition)
それ以外は文字どおり何も約束しておらず、無料であることも含まれない
自由・オープンソースソフトウェアはお金を取ることができるし、そうあるべきであり、ここでいう「free」はお金の話ではない
最近いくつかのコミュニティで起きたオープンソースの「サプライチェーン」攻撃をかなり前向きに見ている。楽観的に言えば、人々にオープンソースはサプライチェーンではないと気づかせてくれることを願っているからだ
詳細は https://lobste.rs/s/cxwidw/no_one_owes_you_supply_chain_secu... にある
ベンダーに金を払っているか、スケジュール保証を含む契約がない限り、サプライチェーンがあるとは言えない
ほぼすべてのFOSSライセンスには「このソフトウェアは無保証で提供される」という条項があり、サプライチェーンは保証を含意するので、FOSSはサプライチェーンではない
ここに来て「オープンソース」がまるで「道徳的価値」を持つかのように扱われ、自由ソフトウェアから盗んだ概念を両者が同じであるかのように混ぜるのを見るのにはうんざりしている
オープンソースとは、大手ソフトウェア企業が無数のボランティアから搾取するためのものにすぎない
行動規範界隈の人たちは、問題を起こすためだけにいる
赤いボタン／青いボタンの議論を見れば分かるが、あの激しい悪罵は、実際にボタンがあるか、人々が意地悪に振る舞うのを好む場合にしか成り立たない
善意の行動規範支持者は、結社の自由と表現の自由を語っている
プラットフォームが相手を嫌えば禁止してよいのか、それともメーリングリストの実務的な「親切にしよう」という慣習だけで扱うべきなのか、という問題だ
もちろん誰が決定権を持つか次第だが、それはどんなプロジェクトでも同じだ
プロジェクトリーダーシップの意向と矛盾する条件を持ち出しながら他人のプロジェクトに参加させろと要求し、同時に結社の自由も持てるなどということはない
推測するに、筆者が「誇示的なCode of Conductは不要だ」と言ったのは、小さなプロジェクトで世界に共有するだけにして、後から外部貢献を受け入れる選択肢だけ開いておきたいなら、実際にそうした状況に直面する前から行動規範を整えておく必要はない、という意味なのかもしれない
純粋に仮定の問題のために頭を悩ませる必要はない
行動規範がある理由は、代わりにあるのが恣意的な違反認定に対する恣意的な処罰か、完全なスパム無政府状態だからだ
以前ネチケットを説いていた人たちが、今になって明確さや健全なコミュニティにそこまで反対しているのが理解できない
考え直してみると、Goomba fallacyなのかもしれないし、行動規範を軽蔑する人たちは、1990年代のUsenetで延々とflame warとスパムを撒き散らしていた人たちなのかもしれない
オープンソースは単なるライセンス選択ではない
企業にとってより魅力的に見えるように自由ソフトウェアを再構成したものであり、オープンソースの核心は、企業が非公開で開発するよりも、大衆と協力してソフトウェアを開発するほうが効果的だという点にある
だからオープンソースは開かれたコミュニティを含意する
寛容なライセンスでコードを大衆に投げ出しつつ、協調開発はしたくないというのも、もちろん可能で、そのコードはオープンソースコードだ
コードを開くこと自体は良いことであり、それ以上をする義務はないが、オープンソースが設計された目的どおりではなく、その核心の一部を無視している
オープンソースコードを見て協調開発中だと想定する人たちは、不合理ではない
それがオープンソース運動の目的だからだ
あなたのソフトウェアにその想定が当てはまらなくても構わないが、社会的規範を破っているのは彼らではなくあなたのほうだ
私はStallman、プリンタドライバ、そして利用者が自分の作業を所有することを思い浮かべるので、オープンソースの目的についてそう断定されるとしっくりこない
https://en.wikipedia.org/wiki/The_Open_Source_Definition
そこには協調開発については何も書かれていない
人は感情的になり、新しい利用者が基本を学びたがらなかったり、利用者の世話をしようとしたりしがちだ
サポートフォーラムとは分離しつつ厳格で、適時に答えるがそっけない関係を保つのがよい
corebootやMrChromeboxが良い例で、彼は必要なときにだけ答える
同意するし、さらに付け加えるなら、人々にソフトウェアを使うよう説得するマーケティングページを作る必要もない
その代わりに、あるいはそれと一緒に、なぜこのソフトウェアを使うべきでないのか、その理由をすべて説明してみるのもよい
利用者が多いほど問題も増える
FOSSアプリケーションは必ずしも公に配布される必要はなく、それはよくある社会的期待にすぎない
FOSSだからといって、顧客でない人にコードが提供されなければならないという意味でもなく、誰が顧客かは開発者が決める
FOSSは有料で売ることが推奨されており、もともと無料だった他人のソフトウェアを売ることさえできる(https://www.gnu.org/philosophy/selling.en.html 参照)
非自由ライセンスを付けたオープンソースも依然としてオープンソースだが非FOSSであり、開発者はソフトウェアでもっと金を稼ぎたい、あるいは自分に有利な追加制限を置きたいなら、非自由オープンソースライセンスを選ぶことを恥じる必要はない
それがcopyleftであることもありうる
要するに、私たちはLICENSE.mdを作ってそこに大きく依存しているのに、SOCIAL.mdを作ろうとは誰も考えなかった
誰かが「オープンソース」と言うと、多くの人は「作者は人々や社会や周囲のためにこれを作っており、プロジェクト開発や新機能追加、特に私が必要とする機能、そしてすべての利用者の利益のための改善に関心がある。でなければ、なぜ公開するのか」と想定する
しかしこれはFOSSに対する最も一般的な社会的期待にすぎず、唯一のケースなどでは全くない
技術的オープンソースと社会的オープンソースの区別が欠けていることが、意見の食い違い、論争、そして最終的には食い違った社会的期待から来る燃え尽きの主因だ
以前は怒った大衆にこの問題と違いを説明しなければならなかったが、最近Jeffrey Paulの文章 https://sneak.berlin/20250720/the-agpl-is-nonfree/ で、オープンソースコードを贈り物にたとえているのを見た
私の説明は結局、「その贈り物が気に入らず自分に合わないなら、捨てて忘れろ」だった
OSIが承認しているが自由ソフトウェアとは見なしていないライセンスはほんのわずかしかない
https://www.gnu.org/licenses/license-list.html の、GPL互換ではない自由ソフトウェアライセンスの長い一覧を見ればよい
そのうえ「非FOSSオープンソース」という言い方自体が成り立たない。FOSSとは文字どおりFree and Open Source Softwareだからだ
今では怪しいWebサイトや奇妙なビルドパイプラインを経由する必要もなく、誰でも使える実行ファイルと一緒に、GitHubへほとんどそのまま上がっている
「コミュニティ」なし、政治なし、行動規範なし、プルリクエストもイシューもなし、Wikiなし、コアチームなし、なんて楽園のように聞こえる
最近はプロジェクト自体に害になるコミュニティが多すぎると感じる
さらに言えば、コミュニティがオープンソースプロジェクトに何らかの形で役立った場面を一度たりとも思い出せない
品質を犠牲にして統制権を最大化するのが目標なら、それでよい
ただ、その場合に本当にFLOSSを選ぶのが適切なのかは疑問だ