オープンソースプロジェクトの維持管理において、最も難しいのは「いいアイデアでも『ノー』と言うこと」だ。ユーザーが魅力的で技術的にも問題のない機能提案をしても、それがプロジェクトのビジョンに合致しなければ、断らざるを得ない。この判断は、ユーザーには理解しがたいが、維持者にとっては「責任ある管理」として不可欠な行為である。 著者は、PrefectやFastMCPといった成功したプロジェクトの開発・維持を経験し、さらにApache Airflowの立ち上げにも携わった。彼が学んだのは、プロジェクトの成功は機能の数ではなく、ビジョンの整合性とユーザーとの共鳴にあるということだ。ソフトウェアの抽象化がユーザーの「メンタルモデル」と一致するとき、人々はそのソフトウェアを選ぶ。維持者の役割は、まずそのモデルを確立し、その後それに忠実な開発を続けることだ。表面的には有用でも、精神的に不一致な機能は、プロジェクトの本質を損なうリスクをはらんでいる。 この「魂」を守るためには、技術的な仕様だけでなく「なぜこのプロジェクトがあるのか」を明確に文書化することが鍵となる。開発ガイドや目的声明は、貢献者に期待を示し、共通の価値観を形成する。これにより、意図が一致する貢献者が集まり、プロジェクトの方向性が強化される。結果として、プロセスは bureaucratism（官僚主義）ではなく、方向性を統一するツールとなる。 しかし、近年のAIの進化により、このバランスが大きく崩れている。従来はコード作成に時間がかかるため、貢献者は議論を経て作業していた。だが、LLMの登場でコードは安価になり、議論を経ずに完成形のPRが送られてくるようになった。それらは「動く」が、プロジェクトの哲学に根ざしていない。目的は「ユーザーの要望に応える」ではなく、「プロジェクトのビジョンを守る」ことにある。 そのため、FastMCPではPRの前にissueの作成を義務化したが、結果として一文のissueがPR直前に作成されるという逆効果が生じた。より効果的なのは、「この機能はプロジェクトが担うべき責任ではない」と明言することだ。貢献者がその主張を裏付ける努力をすれば、それはすべての利害関係者にとってプラスになる。つまり、主張の責任は貢献者にあり、リポジトリにない。 また、機能の維持が長期的に困難な場合も考慮すべきだ。PRがマージされれば、バグや不整合の責任は維持者に移る。FastMCPでは「contribモジュール」として、公式コアに含めないが有用な機能を別途提供する仕組みを導入。開発者は自らの責任で維持し、将来の互換性も保証しない。多くの場合、こうした機能は独立したプロジェクトとして生きるほうが適している。 著者は自身の対応姿勢の変化にも気づいている。かつては15分以内の返信を心がけていたが、低品質な問い合わせが増え、自分も対応の質を下げがちになっている。LLM生成の大量テキストより、明確な質問と再現可能な例（MRE）を好むようになった。 これは「手作り」の開発スタイルだが、AI時代でも価値あるものだ。著者はAIを活用しつつも、慎重な管理こそが「優れたソフトウェア」を生むと信じている。最近、MCP委員会の会議に参加した際、若いプロトコルが過剰な要望にさらされながらも、「これはプロトコルがすべきことか？」という問いを常に持ち続ける姿勢に感銘を受けた。彼らの「すべきでないことを明確にすること」こそが、技術の成熟と哲学的根拠の証だ。 このように、開発の「手間」は、プロジェクトの価値を高める原動力である。維持者の役割は、単なるコードの管理ではなく、ビジョンの守護者である。