オープンソースは必ずしも活発なコミュニティを意味しない
オープンソースソフトウェアは、かつてはシンプルなウェブページやFTPサーバーで公開され、メールやメーリングリストによるコミュニケーションが主流でした。
しかし、GitHubの登場により、プロジェクトの維持管理が企業的な業務に変わり果て、プロジェクト管理者は多くの負担を感じています。
大規模なプロジェクトにはチームが必要な場合もありますが、本来のオープンソースの精神を取り戻し、シンプルな方法で開発を再開することが重要です。
オープンソースであることと、コミュニティを形成することは必ずしも一致せず、開発者は自身のペースで開発を進めるべきです。
オープンソースソフトウェア（OSS）は、技術的な「オープンさ」と、コミュニティの「オープンさ」が必ずしも一致しないという問題提起です。本記事は、GitやGitHubの普及によって変化したOSSのあり方を批判的に分析し、開発者が本来の自由を取り戻すための視点を提供しています。
初期OSSのシンプルな開発形態
DVCS（分散型バージョン管理システム）が登場する以前のOSSは、非常にシンプルな形態で運用されていました。プロジェクトの紹介はHTMLページやテキストファイルが中心で、コードはFTPサーバーを通じて提供されるのが一般的でした。
コミュニケーション手段は、メールや、稀に作られるIRC（インターネットチャット）チャンネルが主でした。現代のような「コミュニティ」や「政治」といった要素はなく、プルリクエストやIssueトラッカーといった複雑な仕組みも存在しなかったとのことです。これは、技術的にはオープンでありながら、現代的な意味での「コミュニティ」は存在しない状態でした。
GitHubによる開発の変質
2000年代後半に登場したGitHubなどのプラットフォームは、OSS開発のあり方を大きく変えました。これにより、多くの開発者が「無給の仕事」を強いられる状況が生まれたと指摘されています。
Issueやプルリクエスト、ロードマップ作成、ステークホルダーとの会議など、OSSの維持管理がまるで企業の「仕事」のように複雑化しました。開発者は、本来の楽しみであるはずのOSS活動が、通知や要求、コミュニティの「世話」といった雑務に追われ、燃え尽き症候群（バーンアウト）に陥りやすい状況にあると説明されています。
開発者が取り戻すべき自由
OSS開発が必ずしも大規模なコミュニティを必要とするわけではない、というのが本記事の主張です。巨大なプロジェクトを除き、開発者は古いシンプルな手法に戻る選択肢があるとしています。
Issueトラッカーやプルリクエストを停止し、信頼できる少数のメンバーと協業するか、完全に一人で開発を進めることも可能です。OSSを「オープン」にするために、必ずしも公開的な場や、形式的な行動規範（Code of Conduct）が必要なわけではないと提言しています。コードを書くこと自体が、最も重要な「オープンさ」であると結論付けています。
まとめ
本記事は、OSSの「オープンさ」を、単なるコードの公開だけでなく、開発者自身の自由とコントロール権の維持という視点から再定義しています。開発者が過剰なコミュニティの要求に疲弊しないための、開発スタイルへの回帰を促す内容だそうです。
原文の冒頭を表示（英語・3段落のみ）
Open source software has existed long before the invention of the (D)VCS.
The author likely hosted a
barebones HTML webpage or a txt file describing the project. There definitely was an FTP
※ 著作権に配慮し、引用は冒頭3段落までです。続きは元記事をご覧ください。