- 1986年にリリースされた PostgreSQL の中核コードを実際に保守している層が高齢化しており、20年後に誰がこの作業を引き継ぐのかという 持続可能性 の問題が浮上
- 2022年時点で1件以上のコミットを主導した開発者は192人で、新規コードの66%を14人、90%を40人が書く 少数集中構造
- 中核開発コミュニティの平均年齢は約50歳で、Tom Lane は68歳ながら今なおプロジェクトの中心的役割を担っている
- Neon は既存のトップ人材を採用するのではなく、ジュニアを採用して contributor から committer、maintainer へと育てる 次世代育成 に意図的に投資
- プロジェクトの継続的な保守には 意図性・資金・啓発された自己利益(enlightened self interest) が必要
PostgreSQLの高齢化と保守人材の問題
- 1986年にリリースされた PostgreSQL は、現代のソフトウェア開発のかなりの部分でデフォルトの選択肢として定着しているが、長い年月を経て、このデータベースを実際に作っている人材の継続性が問題視されている
- 多くの人が依存する注目度の高いコードベースを維持する 重労働(heavy lifting) を、彼らがいつまで続けられるのかという問い
- Postgres は緊密に結びついた小規模な集団であり、そうしたプロジェクトでもある
2022年のコントリビューター統計
- EnterpriseDB の chief database scientist であり Postgres committer でもある Robert Haas が、定期的な寄稿状況の記事 "Who Contributed to PostgreSQL Development in 2022?" で数値を公開
- 2022年に1件以上の PostgreSQL コミットで 主著者(principal author) だった人は192人
- 新規コード行の 66% を14人のうちの誰かが作成
- 新規コード行の 90% を40人のうちの誰かが作成
中核コミュニティの年齢構成
- 中核開発コミュニティはやや高齢化しており、平均年齢はおよそ 50歳
- Crunchy Data に所属する Tom Lane は68歳で、今なお Postgres プロジェクトの支点(fulcrum)の役割を果たしている
オープンガバナンスと20年後の問い
- Postgres の Open governance は頼れる基盤であり、商用オープンソースライセンスの一方的な変更(rugpull)が相次ぐ現在において新鮮な事例
- オープンソースの持続可能性という観点から、20年後も Postgres が健在だと仮定した場合、2043年に誰がその仕事をするのか という問いが生じる
Neon と Nikita Shamgunov の議論
- Neon CEO Nikita Shamgunov との会話では、技術プロジェクトの高齢化と、それがプロジェクトの持続可能性とどう結びつくかが議論された
-
Neon の紹介
- Neon はサーバーレスアプリ向けに最適化されたフルマネージド Postgres データベースで、ストレージとコンピュートを分離し、「データベースはひとつのURLである」という設計原則を採用
- プレビュー環境をデプロイできる ブランチング(branching) をサポートし、これによって Vercel とパートナーシップを構築
- 「簡単に、モダンに、ゼロ設定(zero config) API で」作ることを目指している
- 従業員62人、累計調達額1億800万ドル($108m)、Supabase などと競合
-
committer と contributor の違い
- Shamgunov 「Postgres の committer 層は50代・60代・40代で、30代は少数だ」
- committer になるには多大な努力が必要だが、contributor になるには 良いコードを書けばよいだけ
次世代コミッター育成への投資
- Neon は contributor・committer・maintainer の 次世代 に意図的に投資している
- 多くの企業にとって自然な選択は、新しい人材を育てるより既存のトップ人材を採用すること
- Shamgunov 「Postgres committer をさらに探して採用するか議論したが、それが資金の最善の使い道かは不明だった」
- 「新たに育成するほうがよく、そのやり方で Postgres チームを継続的に拡大できる」
- Shamgunov は、ジュニアを採用・訓練して committer、さらに maintainer へ育てることが Postgres エンジンの継続的進化 に重要だと強調
ライセンスと啓発された自己利益
- Neon の IP は現在 寛容(permissive)ライセンス だが、Shamgunov はオープンソース原理主義者ではない
- 将来的に Neon が Redis、MongoDB、Elastic のように 再ライセンス(relicense) して、より制限的な条件へ移行する権利はある
- ただし、すでに Postgres に貢献したコードはそのような決定の影響を受けない
- 中核的な Postgres maintainer を社内に抱えることは 啓発された自己利益(enlightened self interest) の一例であり、会社を誠実に保つ装置でもあり、どのような決定を下してもコミュニティと中核コードベースに利益をもたらす
コホート高齢化の普遍性
- コホートの高齢化は Postgres に限った問題ではなく、過去の Y2K(2000年問題) のように、コミュニティやエコシステムも年を取り、技術・人材・世代交代の面で問題が生じうる
- IBM は大学の職業教育プログラムなどを通じて、若い開発者をメインフレーム分野へ呼び込むことに成功した例
- Postgres や Kubernetes のような企業支援もなく、たった1〜2人で運営されながら数百万人のユーザーを抱えるプロジェクトも多数存在する
結論 — 保守の意図性
- Postgres は新規ユーザー獲得にまったく苦労しておらず、今日では22歳の開発者たちもデフォルトで選ぶ 非常に人気の高いプラットフォーム
- しかし、プロジェクトの継続的な保守を保証するには 意図性(intentionality)・資金・啓発された自己利益 が必要
公開(Disclosure)
- Neon は RedMonk の顧客ではなく、Crunchy Data・IBM・Vercel はいずれも RedMonk の顧客だが、本稿は顧客関係とは無関係に独立して掲載された
1件のコメント
Hacker News の意見
46歳だけれど、次の世代に入りたいし、もっと若い人たちもきっといると思う
PGConで行った最後の発表は、Postgresをハックするために知っておくべき隙間、特にエグゼキュータ段階とTupleTableSlotを埋めようとする試みについてだった
自分が最適任者ではないが、学んでいる人のほうが学習者に必要なものをよく分かっていることもある
少し前にはPostgresへの貢献方法を扱う本の目次も書いてみたし、少なくとも10冊は売れそうだと思う
オンライン連載のほうがよいかもしれないが、どちらにせよ興味のある人がいるのか気になっている
今のところPostgresは趣味に近いが、オープンソースPostgresへの貢献をフルタイムでやる人を探しているところがあれば、話してみる気はある
今の次の世代のかなりの人数も、Postgresに入ってきたのは比較的遅いほうだ
Tomも自分を低く言うだろうが、数年間画像関連の仕事をして、tiff、jpg、pngそれぞれの生成過程に何らかの形で関わった後、Postgresを見つけて作業を始めた
Postgresへの貢献を始める方法に関するコンテンツを多く作っており、他のPG熱心なユーザーと話すことにも前向き
協業や助言も可能かもしれない: https://www.youtube.com/watch?v=rihfAnd_leM
メール x4mmm@.ru または Twitter @x4mmmmmm で連絡可能
参加のハードルが下がった分、より多くの人が早期退職してオープンソースに参加するようになるのか楽しみだ
一部の出版社は、早期アクセスの読者が誤りを報告できるようにしている: https://nostarch.com/early-access-program
早期退職が可能になって、Postgresをフルタイムでハックすることが目標になるくらい面白い
ネットワーキング、ストレージ、データ、アルゴリズムなどがすべて入っている
正直、Cはそれほど大きな問題ではなく、Postgresはコードスタイルがよく、かなり一貫している
難しいのは内部構造の複雑さであり、コミュニティが小さいと支援を受ける速度にも影響する可能性がある
今後、Cコードベースがメンテナー探しに苦労するようになるのか気になる
Postgresには商用サポートと慣性があるが、熟練したC開発者の流入経路が不足しているように見える
Cは今も生きている言語で、アクティブユーザーに不足はなく、他の言語でシステムプログラミングをしている人にとって学習曲線もそれほど急ではない
今日のWeb・アプリケーション開発者には、下層のシステムアーキテクチャと自分との間に不透明な幕があるためCが威圧的に感じられるかもしれないが、C++やRustを使うシステムプログラマーは、すでにその幕の向こうでより厚い手袋をはめて作業している
彼らは過去に教育や実験の一環としてでもCに触れたことが多く、専門的に担当することになれば、意図的に学んで危険な落とし穴に適応できる
新しいシステムプロジェクトにCを選ぶことに反対する論拠はあるが、システムプログラマー自体が不足している問題を除けば、既存コードのメンテナーを探すことに今すぐ大きな懸念はなさそうだ
科学的に測定したわけではないが、新しい貢献者たちの平均的なCの実力は以前より下がっているように思えるし、もちろんこれは私の白髪交じりのあごひげがそう言っているだけかもしれない
これまでは人々が「仕事をしながら学ぶ」形だったが、そのギャップがどれほど大きいのかは確かではない
いつかはシステムの一部、たとえばコア内のデータ型実装のようなところで、他の言語をより簡単に使えるようにすべきだと思うが、現実的にはまだ少し先の話に見える
難しい部分は正しいドメイン知識を身につけることで、システム全体に慣れるには時間がかかる
熟練したRustやC++開発者の中で、Cにも熟達していない人をほとんど知らない
ただ、より多くのCコードベースでモジュールを切り出してRustで置き換えるようになり始める時期は気になる
すでにLinux、curl、ChromeのようなC++プロジェクト、複数のMS製品、Amazon S3などで起きている
私が知る最も明示的な抵抗例はOpenBSDで、ブートストラップと基本インストールのツールチェーンを小さく保とうとしているためだ
TypeScriptの型システムでさえ、Cよりかなり複雑だ
あるいは、Cがどれほど複雑かについての私の無知をさらしているだけかもしれない
このテーマについては考えるところが多い
コミュニティは長いあいだ拡大と縮小を繰り返してきたので、PostgreSQL コミュニティのことをもう少し共有する意図でいくつか話してみる
何年ものあいだ新しいコミッターがまったくおらず、最近はチームが新しいコミッターをより意図的に追加し、もう参加していない人を整理しようとしてきた
約15年前には、かなり多くの若い人がコミット権限を得ていた時期があり、25歳前、おそらく全員22歳前だった3人を覚えている
そのうち1人はほどなく Postgres コミュニティの外へ移り、1人は10年以上別の仕事で静かに忙しくしたあと戻ってきて、1人はずっと積極的に参加し続けた
コミット権限を得たあとにいなくなる人たちへの居心地の悪さがあり、そのため数年間、新しい人の追加が遅くなっていたのだと思う
まとめると、大学卒業直後にすぐ Postgres のコミット権限を得るのは難しいということ
興味深いが集めにくいデータは、人々が何歳で Postgres コミッターになるのかというもの
平均的にコミット権限を得る年齢が45歳に近いとしても驚かないと思う
多くのコントリビューターは他のシステムでの仕事を経てから Postgres に来るか、メーリングリストにパッチを送るという方式が威圧的に感じられ、ある程度キャリアを積んでからようやく貢献を考える
その人の最初のコミットの話は素晴らしい
Materialize で SQL の動作をテストしていたとき、2つのシステムが interval 関数を同じように処理するか確認しようとして、丁寧に
select interval '0.5 months 2147483647 days';のようなものを試したdbfiddle で直接試せる: https://www.db-fiddle.com/f/ijT76fsmL99bHvXxhAtf7j/0
Postgres はエラーではなく
{"days":-2147483634}という誤った値を返し、理由はここで読める: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...そこで自然に Postgres 側で修正し、そのおかげでバージョン15以降では正しく処理される: https://www.db-fiddle.com/f/i3KikCb72AN1EZpywErZvr/1
Postgres が大好きで PostgreSQL のタトゥーまで入れているが、貢献への道はどちらも簡単ではない
自由時間に一ユーザーとして貢献しようとしても、「初めて取り組むのに良い issue」のようなチケットは多くなく、PostgreSQL アーキテクチャの複数の部分についての文脈や歴史的理由を少しでも知らないと始めにくい
Tom や Andres のような人にパッチレビューを受けるのも威圧的に感じられることがある
EDB、PG Pros、Crunchy のような有償 PostgreSQL 企業の開発者になる道も、鶏と卵の問題に近い
以前の PostgreSQL ハッキング経験なしにジュニアとして採用されるのは難しいが、その経験を積むための道自体も簡単ではない
今の会社でなければ PostgreSQL の仕事をしているところで働きたいが、現実的な入口は多くない
最近コミッターになった10人について、コミットメッセージに初めて名前が登場した時点と、コミッターとして最初のコミットをした時点を比較しようと、以下のような git コマンドをいくつか使ってみた
平均参加期間は月/年だけで比較した場合、約8.9年で、最短の場合でも約6.5年だった
より良い分析も可能だろうが、目的は大まかな感覚をつかむことだった
git log --grep 'Name' --format=%cs | sort | head -1git log --author 'Name' --format=%cs | sort | head -1当時は22歳でも取り組みやすく、より多くの部分を把握できたのかもしれない
また当時は C が標準的な言語だったが、今の若い開発者は C より Rust でプログラミングする可能性が高い
22歳未満でコミット権限を得た人たちが集中していたことはまったく知らなかった
5か月前からPostgresに貢献し始めた新しいコントリビューターで、今月末に27歳になります
まだ価値ある貢献を多くしたわけではありませんが、いくつかコミットがあり、今後はMesonでPostgres拡張をビルドしやすくすること、できればautotoolsビルドを早くなくすことにも取り組みたいです
近いうちにpgbouncerやpgvectorのリポジトリでも見かけるかもしれません
貢献するようになったきっかけは、3年間働いたソフトウェアコンサルティング会社に疲れたことでした
もともとオープンソースのシステムソフトウェア側の人間として生きたいと思っており、Micronでオープンソースのストレージエンジンの仕事を見つけました
正直運がよかったのですが、求人票が自分のために書かれたように感じて応募し、そのプロジェクトで2.5年間楽しく働きました
残念ながら2月末にMicronがチーム全体を解雇し、その後MongoDBからC/C++ドライバーの仕事を打診されたものの取り消されました
その後は人脈により頼るようになり、Libera.Chat/Matrixの#mesonbuildで知っていた人がPostgresの仕事をしていたので、自分の経歴に合うPostgres関連のポジションがあるか尋ねました
彼はNeonが採用中だと教えてくれ、ストレージエンジンチームに応募しましたが、最初の面接で、後にマネージャーになる人が、新たに作るPostgresチーム、つまりアップストリームPostgresに貢献するチームのほうがより合っていると判断しました
機会をくれたNeonにはとても感謝しています
この文章のテーマは、PGConf NYCで他の若いPostgresコントリビューターたちと話している中でちょうど出てきた内容なので興味深いです
小さなパッチでさえ見てもらうのが難しく、コミュニティで名前が知られるほどレビューを受けやすくなるようで、循環的な問題になります
Postgresのメーリングリスト構造もよくなく、pgsql-hackersという消防ホースをそのまま飲まなければならない一方で、LKMLはいくつものサブシステムに分かれています
現代的なコードフォージにはPR/Issueの特定のタグを購読できる価値がありますが、現在のpgsql-hackersにはそうした仕組みがありません
commitfestに項目を追加するのもやや面倒で、Postgres全体のCIを通すにはcommitfestに入れる必要があり、その後も自分で確認するか、コミッターがCI失敗を見るよう知らせてくれることを期待しなければなりません
バグ報告もpgsql-bugsメーリングリストに送られ、PostgresにはLinux bugzillaのような対応物がありません
パッチはメール添付で送り、必ずしもgit-format-patch形式でもありませんが、LKMLは見たところgit-send-emailをほぼ専用で使っているようです
全体として、Postgresコントリビューターコミュニティのツールは、15年以上その中に深く入り込んでいた人たちに最も合っているように見えます
「GitHub/GitLabを使おう」という文章にしたいわけではなく、むしろパッチ議論にはメールのほうが優れていると思っていますが、メーリングリスト周辺のツールは改善できるはずです
すべてが分離しすぎていて、SourceHutはメーリングリストベースの開発を日常的なコントリビューターにとってより近づきやすくする点でうまくやっていると思います
Issue、メーリングリスト、CI/CD、リポジトリがすべてつながっており、現在のPostgresのように別々のサービスに分かれていません
このコメント自体、いつか別のブログ記事にできそうですが、ここで終わります
Postgresへの貢献を始めたばかりの人なら経験を共有できると思いますし、tristan neon.techまたはtristan partin.ioにメールしてください
また別のPostgresコントリビューターは、非コミッターのコントリビューター同士が毎月集まり、作業中または投稿済みのパッチについて話し、ピアレビューを受ける会が役立つかもしれないと考えていました
Tristanがオンラインミートアップを主導できそうです
Melanie Plagemanもそうしたアイデアに関心を持っており、異なる形のオフィスアワーについて少し議論したことがあります
これは良い記事に発展しそうで、組織とプロセスの面でPostgresコミュニティが比較的容易に改善できる部分のように見えます
ただし「名前の認知度」の部分にはあまり確信がなく、反対側の端でも大きな離脱があるように思います
pgsql-hackersが消防ホースのように感じられる問題はその通りで、ここ数年でかなり悪化したと思います
commitfestに入れなくてもリポジトリでCIを有効にできます: https://github.com/postgres/postgres/blob/master/src/tools/c...
これはcommitfest項目に対して走るものと同じCIです
バグ報告がメーリングリストに行くのは本当に嫌で、私もずっと見逃しています
カーネルbugzillaもかなり役に立たないと思いますが、それよりうまくやるのは難しくありません
LKML式のパッチ処理も良くないと思っており、特にパッチセットの改訂ごとに新しいスレッドができるため、追跡がとても簡単になるわけではありません
約15年間開発に参加していても、現在のツールが特にうまく機能しているとは言いません
開発プロセスはその間にある程度進歩しましたが、必要な水準には達していません
PGコミュニティのように灰色のひげが多い共同体を変えるには多くの労力が必要で、不可能ではありませんが簡単ではありません
個人的にはGitHubやGitLabを複雑な作業に使うのは強く嫌いですが、新しいコントリビューターにとってより簡単にするために、どちらかを通じたPR/MRは受け入れるべきだと思います
ただし、それは私の判断だけでできることではありません
パッチ議論にはメールが優れているが周辺ツールを改善すべきだ、という考えに反対する人は2〜3人より多くはないと思います
問題は、多くの人が開発プロセスのツールや統合よりもPostgresのハッキングに時間を使いたいと思っていることにあります
pgrxのおかげでPostgresで少し作業してみましたが、データソリューション構築プラットフォームとしておすすめできます
CMUのチャンネルも良い資料でした: https://www.youtube.com/@CMUDatabaseGroup
たとえば新しいTable Access Methodハンドラーを書きたい場合でも、コアのpg-sys SDKにはTableAM関連のバインディングがありますが、Rustでどう使うかについてのドキュメントや例がありません
最近IT業界に入ってくる人の大半はお金にしか関心がなく、情熱的な人はもうあまりいない、という印象を持つようになった
とても悲しいし、そのせいで多くのオープンソースプロジェクトが死にかけているように思う
恩返しとなる貢献や手助けもなく、「Stack Overflowからコピペして給料をもらう」だけ、という感じだ
全員がそうだという意味ではないが、いくつかの会社で働き、近くで観察して話してみた割合は19:1くらいだった
ちなみに私は標準に比べて仕事を終えるのが早すぎて、会議待ちで時間を無駄にすることが多いため、毎日2社で働いている
面白い仕事をするために副業もたくさんしてきたし、新しいハードウェアを試したり実験したりするために無償でやったことも多かった
契約書の発明譲渡条項と社外活動条項が、貢献のハードルを高くしている
Postgresが新規ユーザーを引きつけるのに苦労しているわけではない、という点には同意する
私もいくつかのセルフホスティングアプリでPostgresを使っている
ただしPHPアプリケーションでは、デフォルトまたは唯一のデータベースであるMariaDBを使い続けることになる
要するに、PostgreSQLの貢献者層は高齢化しており、Neonは既存のコミッターの代わりにジュニアを採用・育成して開発者基盤を広げている、という内容に見える
C/C++の経験はないが興味はあるプログラマーとしては、コードを詳しく説明してくれる動画シリーズがあれば、貢献を始めるうえで本当に役立ちそうだ