- Basis pengembang yang benar-benar memelihara kode inti PostgreSQL, yang dirilis pada 1986, semakin menua, sehingga muncul isu keberlanjutan tentang siapa yang akan melanjutkan pekerjaan ini 20 tahun dari sekarang
- Per 2022, ada 192 pengembang yang menjadi penulis utama untuk setidaknya satu commit, dengan struktur yang terkonsentrasi pada segelintir orang: 66% kode baru ditulis oleh 14 orang, dan 90% oleh 40 orang
- Usia rata-rata komunitas pengembang inti sekitar 50 tahun, dan Tom Lane yang berusia 68 tahun masih berperan sebagai poros utama proyek
- Neon secara sengaja berinvestasi dalam membina generasi berikutnya dengan merekrut junior, alih-alih hanya merekrut talenta papan atas yang sudah ada, lalu membina mereka dari contributor menjadi committer dan maintainer
- Untuk pemeliharaan proyek yang berkelanjutan, dibutuhkan kesengajaan, pendanaan, dan kepentingan pribadi yang tercerahkan (enlightened self interest)
Penuaan PostgreSQL dan masalah tenaga pemelihara
- PostgreSQL, yang dirilis pada 1986, telah menjadi pilihan bawaan di sebagian besar pengembangan perangkat lunak modern, tetapi seiring berlalunya waktu sejak peluncurannya, muncul pertanyaan tentang keberlanjutan orang-orang yang benar-benar membangun database ini
- Muncul pertanyaan sampai kapan mereka dapat terus melakukan pekerjaan berat (heavy lifting) untuk memelihara codebase penting yang diandalkan banyak orang
- Postgres adalah proyek sekaligus kelompok kecil yang sangat erat
Statistik kontributor tahun 2022
- Robert Haas, chief database scientist di EnterpriseDB sekaligus Postgres committer, memaparkan angka-angka ini dalam tulisan pembaruan kontribusi rutin berjudul "Who Contributed to PostgreSQL Development in 2022?"
- Pada 2022, ada 192 orang yang menjadi penulis utama (principal author) untuk setidaknya satu commit PostgreSQL
- 66% baris kode baru ditulis oleh salah satu dari 14 orang
- 90% baris kode baru ditulis oleh salah satu dari 40 orang
Struktur usia komunitas inti
- Komunitas pengembang inti cenderung sudah cukup menua, dengan rata-rata usia sekitar 50 tahun
- Tom Lane dari Crunchy Data, yang berusia 68 tahun, masih memainkan peran sebagai poros utama (fulcrum) dalam proyek Postgres
Tata kelola terbuka dan pertanyaan 20 tahun ke depan
- Open governance Postgres adalah fondasi yang bisa diandalkan, dan menjadi contoh yang menyegarkan di masa ketika perubahan sepihak lisensi open source komersial (rugpull) semakin sering terjadi
- Dari sudut pandang keberlanjutan open source, jika diasumsikan Postgres tetap kuat 20 tahun lagi, muncul pertanyaan: siapa yang akan melakukan pekerjaan itu pada 2043?
Neon dan diskusi dengan Nikita Shamgunov
- Dalam percakapan dengan CEO Neon Nikita Shamgunov, dibahas penuaan proyek teknis dan hubungannya dengan keberlanjutan proyek
-
Tentang Neon
- Neon adalah database Postgres fully managed yang dioptimalkan untuk aplikasi serverless, memisahkan storage dan compute, serta mengadopsi prinsip desain bahwa "database adalah sebuah URL"
- Neon mendukung branching yang memungkinkan deployment pratinjau, dan melalui hal ini menjalin kemitraan dengan Vercel
- Arahnya adalah membangun sesuatu yang "mudah, modern, dan berupa API zero config"
- Perusahaan ini memiliki 62 karyawan, telah menghimpun pendanaan sebesar $108m, dan bersaing dengan Supabase serta lainnya
-
Perbedaan antara committer dan contributor
- Shamgunov: "Lapisan committer Postgres terdiri dari orang-orang berusia 50-an, 60-an, dan 40-an; yang berusia 30-an hanya sedikit"
- Menjadi committer membutuhkan banyak usaha, tetapi untuk menjadi contributor, yang diperlukan hanyalah menulis kode yang bagus
Investasi pada generasi committer berikutnya
- Neon secara sengaja berinvestasi pada generasi berikutnya dari contributor, committer, dan maintainer
- Pilihan alami banyak perusahaan adalah merekrut talenta papan atas yang sudah ada, alih-alih membina talenta baru
- Shamgunov: "Kami memang membahas apakah harus mencari dan merekrut lebih banyak Postgres committer, tetapi tidak jelas apakah itu penggunaan dana yang terbaik"
- "Lebih baik membina yang baru, dan dengan cara itu kami bisa terus membesarkan tim Postgres"
- Shamgunov menekankan bahwa merekrut dan melatih junior agar tumbuh menjadi committer, lalu maintainer, penting bagi evolusi berkelanjutan mesin Postgres
Lisensi dan kepentingan pribadi yang tercerahkan
- IP Neon saat ini berada di bawah lisensi permisif, tetapi Shamgunov bukan seorang fundamentalis open source
- Ke depan, Neon tetap memiliki hak untuk melisensikan ulang (relicense) seperti Redis, MongoDB, atau Elastic, lalu beralih ke syarat yang lebih ketat
- Namun, kode yang sudah disumbangkan ke Postgres tidak akan terdampak oleh keputusan semacam itu
- Memiliki maintainer inti Postgres di dalam perusahaan adalah contoh kepentingan pribadi yang tercerahkan (enlightened self interest): mekanisme yang menjaga perusahaan tetap jujur, dan apa pun keputusan yang diambil, komunitas serta codebase inti tetap diuntungkan
Universalitas penuaan kohor
- Penuaan kohor bukan masalah yang terbatas pada Postgres; seperti kasus Y2K di masa lalu, komunitas dan ekosistem ikut menua, yang dapat memunculkan masalah dari sisi teknologi, tenaga kerja, dan regenerasi
- IBM adalah contoh perusahaan yang berhasil menarik pengembang muda ke ranah mainframe melalui program pelatihan karier di universitas dan lainnya
- Ada juga banyak proyek dengan jutaan pengguna yang dijalankan hanya oleh satu atau dua orang tanpa dukungan sponsor perusahaan, seperti Postgres atau Kubernetes
Kesimpulan — kesengajaan dalam pemeliharaan
- Postgres sama sekali tidak kesulitan mendapatkan pengguna baru, dan bahkan pengembang berusia 22 tahun saat ini memilihnya sebagai default; ini adalah platform yang sangat populer
- Namun, untuk menjamin pemeliharaan proyek yang berkelanjutan, dibutuhkan kesengajaan (intentionality), pendanaan, dan kepentingan pribadi yang tercerahkan
Pengungkapan (Disclosure)
- Neon bukan pelanggan RedMonk, sementara Crunchy Data, IBM, dan Vercel semuanya adalah pelanggan RedMonk; artikel ini diterbitkan secara independen terlepas dari hubungan pelanggan tersebut
1 komentar
Opini Hacker News
Saya berusia 46 tahun, tetapi ingin masuk ke generasi berikutnya, dan saya yakin ada juga orang-orang yang lebih muda
Presentasi terakhir saya di PGCon membahas celah-celah yang perlu diketahui untuk mengutak-atik Postgres, terutama tahap executor dan upaya mengisi TupleTableSlot
Saya bukan orang yang paling tepat, tetapi kadang orang yang sedang belajar lebih tahu apa yang dibutuhkan sesama pembelajar
Beberapa waktu lalu saya juga sempat menulis daftar isi buku tentang cara berkontribusi ke Postgres, dan rasanya setidaknya 10 eksemplar akan terjual
Serial online mungkin lebih baik, tetapi apa pun bentuknya, saya penasaran apakah ada yang tertarik
Saat ini Postgres lebih mendekati hobi bagi saya, tetapi jika ada tempat yang mencari orang untuk mengerjakan kontribusi open source Postgres secara penuh waktu, saya bersedia berdiskusi
Banyak dari generasi berikutnya saat ini juga masuk ke Postgres cukup terlambat
Tom mungkin akan merendah, tetapi ia bekerja di bidang citra selama beberapa tahun dan terlibat dalam proses pembuatan tiff, jpg, dan png dalam suatu bentuk, lalu menemukan Postgres dan mulai mengerjakannya
Ia membuat banyak konten tentang cara mulai berkontribusi ke Postgres, dan juga ramah untuk diajak bicara oleh sesama penggemar PG
Kolaborasi atau saran mungkin juga memungkinkan: https://www.youtube.com/watch?v=rihfAnd_leM
Bisa dihubungi lewat email x4mmm@.ru atau Twitter @x4mmmmmm
Karena hambatan untuk berpartisipasi sudah lebih rendah, saya berharap lebih banyak orang akan pensiun dini dan ikut serta dalam open source
Beberapa penerbit mengizinkan pembaca early access melaporkan kesalahan: https://nostarch.com/early-access-program
Menarik sekali sampai-sampai target saya adalah bisa pensiun dini dan mengutak-atik Postgres secara penuh waktu
Di dalamnya ada networking, storage, data, algoritma, dan sebagainya
Sejujurnya C bukan masalah yang terlalu besar, dan Postgres punya gaya kode yang bagus serta cukup konsisten
Yang sulit adalah kompleksitas struktur internalnya, dan jika komunitasnya kecil, itu juga bisa memengaruhi kecepatan mendapatkan bantuan
Saya penasaran apakah ke depan codebase C akan kesulitan mencari maintainer
Postgres punya dukungan komersial dan inersia, tetapi jalur masuk developer C yang terampil tampaknya kurang
C masih merupakan bahasa yang hidup, tidak kekurangan pengguna aktif, dan bagi orang yang melakukan pemrograman sistem dalam bahasa lain, kurva belajarnya juga tidak terlalu curam
Bagi developer web/aplikasi saat ini, ada tirai buram antara mereka dan arsitektur sistem lapisan bawah sehingga C bisa terasa mengintimidasi, tetapi programmer sistem yang memakai C++ atau Rust sudah bekerja di balik tirai itu dengan sarung tangan yang lebih tebal
Banyak dari mereka pernah bersentuhan dengan C, setidaknya untuk pendidikan atau eksperimen, dan jika harus menanganinya secara profesional, mereka bisa sengaja mempelajarinya dan beradaptasi dengan jebakan-jebakan berbahaya
Ada argumen untuk menentang memilih C bagi proyek sistem baru, tetapi selain masalah kurangnya programmer sistem itu sendiri, tampaknya belum ada kekhawatiran besar dalam mencari maintainer untuk kode yang sudah ada
Saya tidak mengukurnya secara ilmiah, tetapi rata-rata kemampuan C kontributor baru rasanya lebih rendah daripada dulu, meski tentu saja ini mungkin hanya kata-kata si janggut abu-abu dalam diri saya
Sejauh ini orang-orang “belajar sambil bekerja”, tetapi saya tidak yakin seberapa besar kesenjangannya
Suatu saat kita mungkin perlu membuat bahasa lain lebih mudah dipakai di sebagian sistem, misalnya pada implementasi tipe data di core, tetapi secara realistis itu masih tampak agak jauh
Bagian yang sulit adalah memiliki pengetahuan domain yang tepat, dan butuh waktu lama untuk akrab dengan keseluruhan sistem
Saya hampir tidak mengenal developer Rust atau C++ yang berpengalaman tetapi tidak mahir juga dalam C
Namun saya penasaran kapan lebih banyak codebase C mulai memisahkan modul dan menggantinya dengan Rust
Ini sudah terjadi di Linux, curl, proyek C++ seperti Chrome, berbagai produk MS, Amazon S3, dan lainnya
Penolakan paling eksplisit yang saya tahu adalah OpenBSD, karena mereka ingin menjaga bootstrap dan toolchain instalasi dasar tetap kecil
Bahkan sistem tipe TypeScript pun cukup lebih kompleks daripada C
Atau mungkin ini hanya menunjukkan ketidaktahuan saya tentang seberapa kompleks C sebenarnya
Saya punya banyak pemikiran tentang topik ini
Komunitas sudah lama mengalami pasang surut, jadi saya ingin menyampaikan beberapa hal dengan niat sedikit lebih berbagi tentang komunitas PG
Selama beberapa tahun tidak ada committer baru sama sekali, dan belakangan tim berupaya lebih sengaja menambah committer baru serta merapikan orang-orang yang sudah tidak lagi berpartisipasi
Sekitar 15 tahun lalu ada masa ketika cukup banyak orang muda mendapatkan hak commit, dan saya ingat tiga orang yang saat itu belum berusia 25 tahun, mungkin semuanya bahkan belum 22 tahun
Salah satunya tidak lama kemudian pindah ke luar komunitas Postgres, satu orang diam-diam sibuk dengan hal lain selama lebih dari 10 tahun lalu kembali, dan satu orang terus berpartisipasi secara aktif
Sepertinya ada ketidaknyamanan terhadap orang-orang yang menghilang setelah mendapat hak commit, sehingga penambahan orang baru melambat selama beberapa tahun
Singkatnya, ini berarti sulit untuk mendapatkan hak commit Postgres segera setelah lulus kuliah
Data yang menarik tetapi sulit dikumpulkan adalah pada usia berapa orang menjadi committer Postgres
Saya tidak akan heran jika rata-rata usia saat mendapatkan hak commit mendekati 45 tahun
Banyak kontributor datang ke Postgres setelah lebih dulu mengerjakan sistem lain, atau baru mempertimbangkan untuk berkontribusi setelah punya pengalaman tertentu karena cara mengirim patch ke mailing list terasa mengintimidasi
Kisah commit pertamanya sangat bagus
Saat menguji perilaku SQL di Materialize, ia mencoba memastikan apakah dua sistem menangani fungsi interval dengan cara yang sama, dan dengan teliti mencoba hal seperti
select interval '0.5 months 2147483647 days';Anda bisa mencobanya sendiri di dbfiddle: https://www.db-fiddle.com/f/ijT76fsmL99bHvXxhAtf7j/0
Alih-alih error, Postgres mengembalikan nilai keliru
{"days":-2147483634}, dan alasannya bisa dibaca di sini: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...Jadi wajar saja ia memperbaikinya di Postgres, dan berkat itu versi 15 ke atas menanganinya dengan benar: https://www.db-fiddle.com/f/i3KikCb72AN1EZpywErZvr/1
Saya sangat menyukai Postgres sampai bahkan punya tato PG, tetapi kedua jalur kontribusinya sama-sama tidak mudah
Jika mencoba berkontribusi sebagai pengguna biasa di waktu luang, tidak banyak tiket seperti “isu yang bagus untuk pemula”, dan sulit memulai tanpa setidaknya sedikit memahami konteks serta alasan historis dari berbagai bagian arsitektur PG
Mendapat review patch dari orang seperti Tom atau Andres juga bisa terasa mengintimidasi
Jalur masuk sebagai developer di perusahaan PG berbayar seperti EDB, PG Pros, atau Crunchy juga hampir seperti masalah ayam dan telur
Sulit direkrut sebagai junior tanpa pengalaman hacking PG sebelumnya, tetapi jalur untuk membangun pengalaman itu sendiri juga tidak mudah
Jika bukan di perusahaan saya sekarang, saya ingin bekerja di tempat yang mengerjakan PG, tetapi tidak banyak pintu masuk yang realistis
Untuk 10 orang yang baru-baru ini menjadi committer, saya mencoba memakai beberapa perintah git seperti di bawah untuk membandingkan kapan nama mereka pertama kali muncul di pesan commit dan kapan mereka membuat commit pertama sebagai committer
Rata-rata masa keterlibatan, jika hanya membandingkan bulan/tahun, sekitar 8,9 tahun, dan yang paling singkat pun sekitar 6,5 tahun
Analisis yang lebih baik tentu bisa dilakukan, tetapi tujuannya hanya mendapatkan gambaran kasar
git log --grep 'Name' --format=%cs | sort | head -1git log --author 'Name' --format=%cs | sort | head -1Saat itu mungkin lebih mudah diakses oleh orang berusia 22 tahun, dan mungkin lebih banyak bagian yang bisa dipahami
Selain itu, saat itu C adalah bahasa standar, tetapi developer muda sekarang lebih mungkin memprogram dengan Rust daripada C
Saya sama sekali tidak tahu bahwa pernah ada kelompok orang yang mendapat hak commit sebelum berusia 22 tahun
Saya adalah kontributor baru yang mulai berkontribusi ke Postgres sejak 5 bulan lalu, dan akan berusia 27 tahun pada akhir bulan ini
Saya belum banyak memberikan kontribusi yang bernilai, tetapi sudah ada beberapa commit, dan ke depannya saya ingin membuat build ekstensi Postgres dengan Meson menjadi mudah, serta kalau memungkinkan segera menyingkirkan build autotools
Mungkin Anda juga akan segera melihat saya di repositori pgbouncer atau pgvector
Pemicu saya berkontribusi adalah karena saya sudah jenuh dengan perusahaan konsultasi software tempat saya bekerja selama 3 tahun
Sejak awal saya ingin hidup sebagai orang yang bergerak di software sistem open source, dan saya menemukan pekerjaan di Micron untuk mengerjakan storage engine open source
Terus terang saya beruntung, tetapi lowongan itu terasa seperti ditulis untuk saya, jadi saya melamar, dan saya bekerja dengan senang di proyek itu selama 2,5 tahun
Sayangnya pada akhir Februari Micron memberhentikan seluruh tim, dan setelah itu saya sempat mendapat tawaran dari MongoDB untuk mengerjakan driver C/C++, tetapi kemudian tawaran itu ditarik
Setelah itu saya mulai lebih mengandalkan jaringan kenalan, dan karena ada orang yang saya kenal dari #mesonbuild di Libera.Chat/Matrix yang bekerja di Postgres, saya bertanya apakah ada posisi terkait Postgres yang cocok dengan latar belakang saya
Ia memberi tahu bahwa Neon sedang merekrut, dan saya melamar ke tim storage engine, tetapi pada wawancara pertama orang yang kelak menjadi manajer saya menilai bahwa saya lebih cocok untuk tim Postgres yang baru dibentuk, yaitu tim yang berkontribusi ke upstream Postgres
Saya sangat berterima kasih kepada Neon karena telah memberi saya kesempatan
Topik tulisan ini menarik karena baru saja muncul saat saya berbicara dengan kontributor Postgres muda lainnya di PGConf NYC
Bahkan patch kecil pun sulit mendapat perhatian, dan tampaknya semakin dikenal nama seseorang di komunitas, semakin banyak review yang ia dapat, sehingga menjadi masalah yang berputar
Struktur mailing list Postgres juga kurang baik; kita harus langsung meminum aliran deras bernama pgsql-hackers, sementara LKML terbagi ke berbagai subsistem
Code forge modern punya nilai karena kita bisa berlangganan tag tertentu pada PR/issue, tetapi saat ini pgsql-hackers tidak punya cara seperti itu
Menambahkan item ke commitfest juga agak merepotkan, dan agar bisa melewati CI Postgres secara penuh, patch harus dimasukkan ke commitfest; setelah itu pun kita harus mengeceknya sendiri atau berharap committer memberi tahu untuk melihat kegagalan CI
Laporan bug juga masuk ke mailing list pgsql-bugs, dan Postgres tidak punya padanan seperti Linux bugzilla
Patch dikirim sebagai lampiran email dan bahkan tidak harus dalam format git-format-patch, sedangkan LKML tampaknya hampir secara eksklusif memakai git-send-email
Secara keseluruhan, tooling komunitas kontributor Postgres tampaknya paling cocok untuk orang-orang yang sudah tertanam jauh di dalamnya selama lebih dari 15 tahun
Saya tidak ingin menjadikannya tulisan “ayo pakai GitHub/GitLab”; justru saya pikir email lebih unggul untuk diskusi patch, tetapi tooling di sekitar mailing list bisa diperbaiki
Semuanya terlalu terpisah, dan menurut saya SourceHut cukup berhasil membuat pengembangan berbasis mailing list lebih mudah diakses oleh kontributor sehari-hari
Issue, mailing list, CI/CD, dan repositori semuanya terhubung, tidak terpecah menjadi layanan terpisah seperti Postgres saat ini
Komentar ini sendiri suatu saat layak menjadi tulisan blog terpisah, tetapi saya akhiri di sini
Jika Anda baru mulai berkontribusi ke Postgres, saya rasa kita bisa saling berbagi pengalaman; silakan email ke tristan neon.tech atau tristan partin.io
Kontributor Postgres lain juga berpendapat bahwa akan berguna jika para kontributor non-committer bertemu setiap bulan untuk membicarakan patch yang sedang dikerjakan atau sudah dipublikasikan, serta mendapatkan peer review
Tristan tampaknya bisa memimpin pertemuan online
Melanie Plageman juga tertarik pada ide semacam itu, dan kami pernah sempat membahas berbagai bentuk office hours
Cerita ini sepertinya bisa berkembang menjadi tulisan yang bagus, dan dari sisi organisasi serta proses, terlihat seperti bagian yang relatif mudah diperbaiki oleh komunitas Postgres
Namun saya kurang yakin soal bagian “pengenalan nama”, dan tampaknya ada churn besar juga di ujung yang lain
Masalah pgsql-hackers yang terasa seperti selang pemadam memang benar, dan menurut saya dalam beberapa tahun terakhir jauh lebih buruk
CI bisa diaktifkan di repositori tanpa memasukkannya ke commitfest: https://github.com/postgres/postgres/blob/master/src/tools/c...
Itu adalah CI yang sama dengan yang berjalan untuk item commitfest
Saya benar-benar tidak suka laporan bug masuk ke mailing list, dan saya juga terus-menerus melewatkannya
Saya juga menganggap kernel bugzilla cukup tidak berguna, tetapi tidak sulit untuk melakukan lebih baik daripada itu
Saya juga tidak menganggap pemrosesan patch ala LKML itu bagus, terutama karena setiap revisi patchset membuat thread baru sehingga tidak menjadi sangat mudah dilacak
Meski sudah sekitar 15 tahun terlibat dalam pengembangan, saya tidak akan mengatakan tooling saat ini bekerja dengan sangat baik
Proses pengembangan memang sudah sedikit berkembang selama ini, tetapi belum sampai tingkat yang dibutuhkan
Mengubah komunitas dengan banyak “janggut abu-abu” seperti komunitas PG membutuhkan banyak usaha; bukan mustahil, tetapi tidak mudah
Secara pribadi saya sangat tidak suka memakai GitHub atau GitLab untuk pekerjaan yang kompleks, tetapi menurut saya kita harus menerima PR/MR melalui salah satu dari keduanya agar lebih mudah bagi kontributor baru
Namun itu bukan sesuatu yang bisa diputuskan hanya oleh saya
Saya rasa tidak akan ada lebih dari 2–3 orang yang menentang gagasan bahwa email unggul untuk diskusi patch, tetapi tooling di sekitarnya perlu diperbaiki
Masalahnya, banyak orang lebih ingin menghabiskan waktu untuk meng-hack Postgres daripada mengerjakan tooling atau integrasi proses pengembangan
Saya pernah sedikit mengerjakan Postgres dengan bantuan pgrx, dan bisa merekomendasikannya sebagai platform untuk membangun solusi data
Kanal CMU juga merupakan materi yang bagus: https://www.youtube.com/@CMUDatabaseGroup
Misalnya, meskipun kita ingin menulis handler Table Access Method baru, SDK inti pg-sys punya binding terkait TableAM, tetapi tidak ada dokumentasi atau contoh tentang cara menggunakannya dari Rust
Saya jadi mengamati bahwa kebanyakan orang yang masuk ke IT belakangan ini hanya mengejar uang, dan orang yang benar-benar antusias sudah tidak banyak lagi
Ini sangat menyedihkan, dan rasanya banyak proyek open source sekarat karenanya
Polanya hanya “copy-paste dari Stack Overflow lalu menerima gaji”, tanpa kontribusi atau bantuan balik
Bukan berarti semua orang begitu, tetapi dari rasio yang saya amati dan bicarakan dari dekat saat bekerja di beberapa perusahaan, kira-kira 19:1
Sebagai catatan, saya bekerja di dua perusahaan setiap hari karena saya sering menyelesaikan pekerjaan terlalu cepat dibanding standar, lalu membuang waktu menunggu rapat
Saya juga banyak mengambil pekerjaan sampingan demi mengerjakan hal-hal menarik, dan sering melakukannya gratis untuk mencoba hardware baru atau bereksperimen
Klausul pengalihan invensi dan klausul aktivitas eksternal dalam kontrak meningkatkan hambatan untuk berkontribusi
Saya setuju bahwa Postgres tidak kesulitan menarik pengguna baru
Saya sendiri memakai Postgres untuk beberapa aplikasi self-hosted
Namun untuk aplikasi PHP, saya tetap memakai MariaDB, yang menjadi default atau satu-satunya database
Singkatnya, ini tampaknya mengatakan bahwa basis kontributor PostgreSQL makin menua, dan Neon memperluas basis developer dengan merekrut dan melatih junior alih-alih mengandalkan committer yang sudah ada
Sebagai programmer yang tertarik meski tidak punya pengalaman C/C++, saya rasa seri video yang menjelaskan kode secara rinci akan sangat membantu untuk mulai berkontribusi