オープンソースは公開コミュニティを意味しない
(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 してもよく、技術インキュベーターと保育施設が混ざったようなオペレーティングシステムへ引きずり込まれる必要はない
1件のコメント
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 も一読の価値がある
小さなプロジェクトについては、この記事に強く同意する
より大きなプロジェクトでも、最も成功したものは最初からオープンなコミュニティとして始まっていないことが多い
好きなプロジェクトの多くは大規模組織で開発が始まり、重要なのはそのソフトウェアを 社内で実際に積極的に使っていた ことだ
そのためメンテナーもすでに報酬を受け取っていた
個人プロジェクトであれ社内チームであれ、開発者自身の日常的な問題を解決するために作られたソフトウェアのほうが、名声や事業化のために作られたソフトウェアよりも成功しやすく、搾取的でもないように見える