- 1986’da yayımlanan PostgreSQL’in çekirdek kodunu fiilen bakımda tutan kadro yaşlanıyor; 20 yıl sonra bu işi kimin sürdüreceğine dair sürdürülebilirlik sorunu öne çıkıyor
- 2022 itibarıyla en az bir commit’te başlıca rol alan geliştirici sayısı 192; yeni kodun %66’sını 14 kişi, %90’ını ise 40 kişi yazıyor; bu da az sayıda kişide yoğunlaşan bir yapıya işaret ediyor
- Çekirdek geliştirme topluluğunun ortalama yaşı yaklaşık 50 ve Tom Lane 68 yaşında olmasına rağmen hâlâ projenin ana ekseni olmayı sürdürüyor
- Neon, mevcut yıldız isimleri transfer etmek yerine junior geliştiriciler alıp onları contributor’dan committer’a, oradan maintainer’a yetiştiren yeni nesil yetiştirme yaklaşımına bilinçli biçimde yatırım yapıyor
- Projenin sürekli bakımını sürdürebilmek için niyetlilik, finansman ve aydınlanmış öz çıkar (enlightened self interest) gerekiyor
PostgreSQL’in yaşlanan kadrosu ve bakım ekibi sorunu
- 1986’da yayımlanan PostgreSQL, modern yazılım geliştirmenin büyük bölümünde varsayılan seçenek haline geldi; ancak aradan geçen uzun yıllar, veritabanını fiilen inşa eden insanların sürekliliği sorununu gündeme getiriyor
- Pek çok kişinin bağımlı olduğu yüksek profilli bir kod tabanının ağır yükünü (heavy lifting) bu insanların daha ne kadar taşıyabileceği sorusu ortaya çıkıyor
- Postgres, birbirine sıkı bağlı küçük bir grup tarafından yürütülen bir proje
2022 katkıcı istatistikleri
- EnterpriseDB’nin chief database scientist’i ve Postgres committer’ı Robert Haas, düzenli katkı durumunu ele aldığı "Who Contributed to PostgreSQL Development in 2022?" yazısında şu verileri paylaştı
- 2022’de en az bir PostgreSQL commit’inde başlıca yazar (principal author) olan kişi sayısı 192
- Yeni kod satırlarının %66’sı 14 kişiden biri tarafından yazıldı
- Yeni kod satırlarının %90’ı 40 kişiden biri tarafından yazıldı
Çekirdek topluluğun yaş yapısı
- Çekirdek geliştirme topluluğu bir miktar yaşlanmış durumda; ortalama yaş yaklaşık 50
- Crunchy Data bünyesindeki Tom Lane, 68 yaşında ve hâlâ Postgres projesinin merkezî dayanak noktası (fulcrum) rolünü üstleniyor
Açık yönetişim ve 20 yıl sonrası sorusu
- Postgres’in Open governance yapısı, güvenilebilecek bir temel sunuyor ve ticari açık kaynak lisanslarında tek taraflı değişikliklerin sıklaştığı bugünlerde ferahlatıcı bir örnek oluşturuyor
- Açık kaynak sürdürülebilirliği açısından, Postgres’in 20 yıl sonra da güçlü biçimde varlığını sürdürdüğü varsayılırsa, 2043’te bu işi kim yapacak sorusu ortaya çıkıyor
Neon ve Nikita Shamgunov ile tartışma
- Neon CEO’su Nikita Shamgunov ile yapılan sohbette, teknik projelerde kadronun yaşlanması ve bunun proje sürdürülebilirliğiyle ilişkisi ele alınıyor
-
Neon tanıtımı
- Neon, sunucusuz uygulamalar için optimize edilmiş tam yönetimli bir Postgres veritabanı; depolama ile compute’u ayırarak "veritabanı aslında bir URL’dir" tasarım ilkesini benimsiyor
- Önizleme dağıtımlarını mümkün kılan branching desteği sunuyor ve bu sayede Vercel ile ortaklık kurdu
- Hedefi, "kolay, modern ve zero config API ile" oluşturmak
- 62 çalışanı var, bugüne kadar 108 milyon dolar ($108m) yatırım aldı ve Supabase gibi şirketlerle rekabet ediyor
-
committer ve contributor arasındaki fark
- Shamgunov: "Postgres committer katmanı 50’li, 60’lı ve 40’lı yaşlarda; 30’lu yaşlardakiler azınlıkta."
- committer olmak çok emek gerektiriyor, ancak contributor olmak için yalnızca iyi kod yazmak yeterli
Yeni nesil committer yetiştirmeye yatırım
- Neon, contributor, committer ve maintainer’ların bir sonraki nesline bilinçli olarak yatırım yapıyor
- Birçok şirket için doğal tercih, yeni yetenek yetiştirmek yerine mevcut yıldız isimleri transfer etmek
- Shamgunov: "Daha fazla Postgres committer bulup işe alalım mı diye konuştuk, ancak bunun sermayenin en iyi kullanımı olup olmadığı belirsizdi."
- "Yeni insanları yetiştirmek daha iyi ve bu sayede Postgres ekibini büyütmeye devam edebiliriz."
- Shamgunov, junior geliştiricileri işe alıp eğiterek onları committer’a, ardından maintainer’a dönüştürmenin Postgres motorunun sürekli evrimi açısından önemli olduğunu vurguluyor
Lisans ve aydınlanmış öz çıkar
- Neon’un IP’si şu anda izin verici (permissive) lisans altında, ancak Shamgunov açık kaynak konusunda katı bir ideolog değil
- Gelecekte Neon’un, Redis, MongoDB ve Elastic örneklerinde olduğu gibi yeniden lisanslama (relicense) yoluyla daha kısıtlayıcı koşullara geçme hakkı bulunuyor
- Ancak Postgres’e daha önce katkı olarak verilmiş kod bu tür bir karardan etkilenmeyecek
- Şirket içinde çekirdek bir Postgres maintainer’ı bulundurmak, aydınlanmış öz çıkarın (enlightened self interest) bir örneği; bu, şirketi dürüst tutan bir mekanizma ve hangi karar alınırsa alınsın topluluk ile çekirdek kod tabanı bundan fayda görüyor
Kuşak yaşlanmasının yaygınlığı
- Bir kuşağın topluca yaşlanması yalnızca Postgres’e özgü değil; geçmişteki Y2K (2000 yılı hatası) örneğinde olduğu gibi topluluklar ve ekosistemler yaşlanıyor, bu da teknoloji, insan kaynağı ve kuşak değişimi açısından sorunlara yol açabiliyor
- IBM, üniversite meslek eğitim programları gibi girişimlerle genç geliştiricileri mainframe alanına çekmede başarılı bir örnek sundu
- Kurumsal sponsorluğu olmayan, yalnızca bir veya iki kişi tarafından yürütülen ve milyonlarca kullanıcıya sahip Postgres ya da Kubernetes benzeri çok sayıda proje de bulunuyor
Sonuç — bakımın niyetliliği
- Postgres, yeni kullanıcı kazanmakta hiçbir zorluk yaşamıyor; bugün 22 yaşındaki geliştiriciler bile onu varsayılan seçenek olarak tercih eden son derece popüler bir platform
- Ancak projenin sürekli bakımını garanti altına almak için niyetlilik (intentionality), finansman ve aydınlanmış öz çıkar gerekiyor
Açıklama (Disclosure)
- Neon, RedMonk müşterisi değil; Crunchy Data, IBM ve Vercel ise RedMonk müşterileri ve bu yazı müşteri ilişkilerinden bağımsız olarak yayımlandı
1 yorum
Hacker News yorumları
46 yaşındayım ama sonraki nesil içinde yer almak istiyorum; benden daha genç insanların da mutlaka olduğunu düşünüyorum
PGCon'da yaptığım son sunum, Postgres'i hack'lemek için bilinmesi gereken boşluklar, özellikle executor aşaması ve TupleTableSlot'u doldurma denemem hakkındaydı
En uygun kişi ben olmayabilirim ama bazen öğrenen biri, öğrenenlerin neye ihtiyaç duyduğunu daha iyi bilir
Bir süre önce Postgres'e katkıda bulunma yöntemlerini ele alan bir kitabın içindekiler taslağını da yazmıştım; en az 10 kopya satacağını düşünüyorum
Çevrimiçi bir seri daha iyi olabilir; hangisi olursa olsun, ilgilenen biri olur mu merak ediyorum
Şu anda Postgres benim için daha çok bir hobiye yakın ama açık kaynak Postgres katkısı üzerinde tam zamanlı çalışacak birini arayan bir yer varsa konuşmaya açığım
Bugünkü sonraki neslin önemli bir kısmı da Postgres'e epey geç katılmış sayılır
Tom da kendini küçümseyerek anlatacaktır ama birkaç yıl görüntü alanında çalıştı; tiff, jpg, png'nin her birinin üretim sürecine bir şekilde dahil olduktan sonra Postgres'i keşfedip üzerinde çalışmaya başladı
Postgres'e katkıya nasıl başlanacağı konusunda çok içerik üretiyor ve diğer PG meraklılarıyla konuşmaya da sıcak bakıyor
İş birliği ya da tavsiye de mümkün olabilir: https://www.youtube.com/watch?v=rihfAnd_leM
Kendisine x4mmm@.ru e-postasından veya Twitter'da @x4mmmmmm üzerinden ulaşılabilir
Katılım eşiği düştükçe, daha fazla insanın erken emekli olup açık kaynağa katılmasını umuyorum
Bazı yayınevleri erken erişim okurlarının hataları bildirmesine izin veriyor: https://nostarch.com/early-access-program
Erken emekliliğin mümkün hale gelip Postgres'i tam zamanlı hack'lemenin hedefim olması heyecan verici
Ağ, depolama, veri, algoritmalar gibi her şey içinde var
Dürüst olmak gerekirse C daha küçük bir sorun; Postgres'in kod stili iyi ve oldukça tutarlı
Zor olan, iç yapının karmaşıklığı; topluluk küçükse yardım alma hızını da etkileyebilir
İleride C kod tabanlarının bakımcı bulmakta zorlanıp zorlanmayacağını merak ediyorum
Postgres'in ticari desteği ve ataleti var ama deneyimli C geliştiricilerinin yetiştiği kanallar eksik görünüyor
C hâlâ yaşayan bir dil ve aktif kullanıcı sıkıntısı yok; başka dillerde sistem programlama yapan biri için öğrenme eğrisi de o kadar dik değil
Günümüzde web/uygulama geliştiricileri için alt sistem mimarisi ile kendileri arasında opak bir perde olduğundan C ürkütücü gelebilir; ama C++ ya da Rust kullanan sistem programcıları zaten o perdenin arkasında, daha kalın eldivenlerle çalışıyor
Bu kişiler geçmişte eğitim ya da deneme amaçlı da olsa C ile çoğu zaman karşılaşmış oluyor; profesyonel olarak üstlendiklerinde bilinçli şekilde çalışıp tehlikeli tuzaklara uyum sağlayabilirler
Yeni sistem projelerinde C'yi seçmeye karşı argümanlar var, ama sistem programcısı eksikliği dışında, mevcut kodun bakımcılarını bulma konusunda şu an büyük bir endişe görünmüyor
Bilimsel olarak ölçmedim ama yeni katkıcıların ortalama C becerisi eskisine göre düşmüş gibi; elbette bunu söyleyen benim gri sakalım da olabilir
Şimdiye kadar insanlar “iş başında öğreniyor”, ama aradaki farkın ne kadar büyük olduğundan emin değilim
Bir gün sistemin bazı kısımlarında, örneğin core içindeki veri tipi implementasyonları gibi yerlerde başka dilleri daha kolay kullanmamız gerekecek gibi; ama gerçekçi bakınca bu hâlâ biraz uzak görünüyor
Zor olan doğru alan bilgisini edinmek; sistemin geneline alışmak uzun zaman alıyor
Deneyimli Rust ya da C++ geliştiricileri arasında C'de de yetkin olmayan neredeyse kimse tanımıyorum
Yine de daha fazla C kod tabanının modülleri ayırıp Rust ile değiştirmeye ne zaman başlayacağını merak ediyorum
Bu zaten Linux, curl, Chrome gibi C++ projeleri, çeşitli MS ürünleri, Amazon S3 vb. yerlerde oluyor
Bildiğim en belirgin direniş OpenBSD; bunun nedeni de bootstrap ve varsayılan kurulum toolchain'ini küçük tutmak istemeleri
TypeScript'in tip sistemi bile C'den oldukça karmaşık
Ya da belki de C'nin ne kadar karmaşık olduğuna dair cehaletimi ortaya koymuşumdur
Bu konu üzerine epey düşündüm
Topluluk uzun süre büyüyüp küçülme döngüleri yaşadı; PG topluluğunu biraz daha paylaşmak amacıyla birkaç şey söyleyeyim
Birkaç yıl boyunca hiç yeni committer yoktu; son dönemde ekip yeni committer’ları daha bilinçli biçimde eklemeye ve artık katılmayan kişileri listeden çıkarmaya çalışıyor
Yaklaşık 15 yıl önce oldukça fazla genç insanın commit yetkisi aldığı bir dönem vardı; 25 yaşından önce, hatta belki hepsi 22 yaşından önce bu yetkiyi almış üç kişiyi hatırlıyorum
Bunlardan biri kısa süre sonra Postgres topluluğunun dışına geçti, biri 10 yıldan uzun süre başka işlerle sessizce meşgul olduktan sonra geri döndü, biri ise aktif katılımını sürdürdü
Commit yetkisi aldıktan sonra ortadan kaybolan kişilerle ilgili bir rahatsızlık vardı; sanırım bu yüzden birkaç yıl boyunca yeni kişi ekleme yavaşladı
Özetle, üniversiteden mezun olur olmaz Postgres commit yetkisi almak zor demek istiyorum
İlginç ama toplaması zor bir veri, insanların kaç yaşında Postgres committer’ı olduğu
Ortalama olarak commit yetkisi alınan yaşın 45’e yakın olduğunu duysam şaşırmam
Pek çok katkıcı başka sistemlerde çalıştıktan sonra Postgres’e geliyor ya da e-posta listesine patch göndermek göz korkutucu geldiği için ancak belli bir kariyer birikiminden sonra katkıda bulunmayı düşünüyor
İlk commit’inin hikâyesi harika
Materialize’da SQL davranışını test ederken iki sistemin interval fonksiyonlarını aynı şekilde işleyip işlemediğini doğrulamak istemiş ve titizlikle
select interval '0.5 months 2147483647 days';gibi şeyler denemişdbfiddle’da kendiniz deneyebilirsiniz: https://www.db-fiddle.com/f/ijT76fsmL99bHvXxhAtf7j/0
Postgres hata vermek yerine
{"days":-2147483634}gibi yanlış bir değer döndürmüş; nedenini buradan okuyabilirsiniz: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...Bu yüzden doğal olarak bunu Postgres’te düzeltmiş ve bu sayede 15 ve üzeri sürümlerde doğru işleniyor: https://www.db-fiddle.com/f/i3KikCb72AN1EZpywErZvr/1
Postgres’i o kadar seviyorum ki PG dövmem bile var; ama katkı yollarının ikisi de kolay değil
Boş zamanında sıradan bir kullanıcı olarak katkı yapmak istesen de “ilk kez yapmak için iyi issue” türü çok fazla ticket yok ve PG mimarisinin çeşitli bölümlerindeki bağlamı ve tarihsel gerekçeleri az da olsa bilmeden başlamak zor
Tom veya Andres gibi kişilerden patch review almak da göz korkutucu olabilir
EDB, PG Pros, Crunchy gibi ücretli PG şirketlerinde geliştirici olarak işe girme yolu da tavuk-yumurta sorununa yakın
Önceden PG hacking deneyimi olmadan junior olarak işe alınmak zor; ama o deneyimi edinmenin yolu da kolay değil
Şu anki şirketim olmasa PG işi yapan bir yerde çalışmak isterdim, fakat gerçekçi giriş yolları çok fazla değil
Son dönemde committer olan 10 kişi için, adlarının commit mesajlarında ilk göründüğü zaman ile committer olarak ilk commit yaptıkları zamanı karşılaştırmak üzere aşağıdakiler gibi birkaç git komutu kullandım
Yalnızca ay/yıl karşılaştırıldığında ortalama katılım süresi yaklaşık 8,9 yıldı; en kısa süre de yaklaşık 6,5 yıldı
Daha iyi analizler de yapılabilir, ama amaç kabaca bir fikir edinmekti
git log --grep 'Name' --format=%cs | sort | head -1git log --author 'Name' --format=%cs | sort | head -1O dönemde 22 yaşındaki biri için yaklaşmak daha kolaydı ve daha fazla bölümü kavramak mümkün olmuş olabilir
Ayrıca o zamanlar C standart dildi; günümüzde genç geliştiricilerin C’den çok Rust ile programlama yapma olasılığı daha yüksek
22 yaşın altında commit yetkisi alan kişilerden oluşan bir yoğunlaşma olduğunu hiç bilmiyordum
5 ay önce Postgres’e katkıda bulunmaya başlamış yeni bir katkıcıyım ve bu ayın sonunda 27 yaşıma gireceğim
Henüz çok değerli katkılar yapmış sayılmam ama birkaç commit’im var; ileride Postgres eklentilerini Meson ile derlemeyi kolaylaştırmak ve mümkünse autotools derlemesini hızla ortadan kaldırmak istiyorum
Yakında pgbouncer veya pgvector depolarında da beni görebilirsiniz
Katkıda bulunmaya başlamamın nedeni, 3 yıl çalıştığım yazılım danışmanlığı şirketinden yorulmuş olmamdı
Aslında açık kaynak sistem yazılımları tarafında çalışan biri olmak istiyordum ve Micron’da açık kaynak bir depolama motoru işi buldum
Dürüst olmak gerekirse şanslıydım ama iş ilanı sanki benim için yazılmış gibiydi, başvurdum ve o projede 2,5 yıl boyunca keyifle çalıştım
Ne yazık ki Şubat sonunda Micron tüm ekibi işten çıkardı; sonrasında MongoDB’den C/C++ sürücüleri üzerinde çalışma teklifi aldım, sonra bu teklif geri çekildi
Ardından daha çok bağlantılarıma yaslanmaya başladım ve Libera.Chat/Matrix’teki #mesonbuild kanalından tanıdığım, Postgres işleri yapan birine, geçmişime uygun Postgres’le ilgili bir pozisyon olup olmadığını sordum
Bana Neon’un işe alım yaptığını söyledi; depolama motoru ekibine başvurdum ama ilk görüşmede, ileride yöneticim olacak kişi, yeni kurduğu Postgres ekibine, yani upstream Postgres’e katkı veren ekibe daha uygun olduğuma karar verdi
Bana bu fırsatı verdiği için Neon’a çok minnettarım
Bu yazının konusu, PGConf NYC’de diğer genç Postgres katkıcılarıyla konuşurken tam da yeni gündeme gelmişti; o yüzden ilginç
Küçük bir yamaya bile baktırmak zor ve toplulukta adınız duyuldukça daha fazla inceleme alıyor gibisiniz; bu da döngüsel bir sorun haline geliyor
Postgres posta listesi yapısı da iyi değil; pgsql-hackers adlı yangın hortumundan doğrudan içmek zorundasınız, oysa LKML birçok alt sisteme ayrılmış durumda
Modern kod forge’larında PR/issue’ların belirli etiketlerine abone olabilmenin değeri var, ancak şu an pgsql-hackers’ta böyle bir yöntem yok
commitfest’e öğe eklemek de biraz zahmetli; tüm Postgres CI’dan geçmek için commitfest’e koymanız gerekiyor, sonrasında da ya kendiniz kontrol etmeli ya da bir committer’ın CI hatasına bakmanızı söylemesini ummalısınız
Hata raporları da pgsql-bugs posta listesine gidiyor; Postgres’te Linux bugzilla benzeri bir karşılık yok
Yamalar e-posta eki olarak gönderiliyor ve mutlaka git-format-patch biçiminde de olmuyor; LKML ise görünüşe göre neredeyse sadece git-send-email kullanıyor
Genel olarak Postgres katkıcı topluluğunun araçları, 15 yıldan uzun süredir o dünyanın içinde derinlemesine yer alan insanlara en çok uyuyor gibi
Bunu “GitHub/GitLab kullanalım” yazısına çevirmek istemiyorum; aksine yama tartışmaları için e-postanın daha üstün olduğunu düşünüyorum, ama posta listelerinin etrafındaki araçlar iyileştirilebilir
Her şey fazla ayrışmış durumda; SourceHut’un posta listesi tabanlı geliştirmeyi sıradan katkıcılar için daha erişilebilir kılma konusunda iyi iş çıkardığını düşünüyorum
Issue’lar, posta listeleri, CI/CD ve depoların hepsi birbirine bağlı; şu an Postgres’te olduğu gibi ayrı hizmetlere bölünmüş değiller
Bu yorumun kendisi bir gün ayrı bir blog yazısı olabilir ama burada bitiriyorum
Postgres’e katkıya yeni başlamış biriyseniz deneyimlerimi paylaşabilirim; tristan neon.tech veya tristan partin.io adresinden e-posta atabilirsiniz
Bir başka Postgres katkıcısı, committer olmayan katkıcıların her ay buluşup üzerinde çalıştıkları ya da yayımladıkları yamaları konuştuğu ve akran incelemesi aldığı bir toplantının faydalı olabileceğini düşündü
Tristan çevrimiçi toplantıya öncülük edebilir gibi görünüyor
Melanie Plageman da böyle bir fikre ilgi duymuştu; farklı ofis saati biçimlerini kısaca tartışmıştık
Bu iyi bir yazıya dönüşebilir; organizasyon ve süreç açısından Postgres topluluğunun görece kolay iyileştirebileceği bir alan gibi görünüyor
Ancak “isim bilinirliği” kısmından o kadar emin değilim; diğer uçta da büyük bir kopuş var gibi
pgsql-hackers’ın yangın hortumu gibi hissettirmesi doğru ve son birkaç yılda bunun çok daha kötüleştiğini düşünüyorum
commitfest’e koymadan da depoda CI’ı açabilirsiniz: https://github.com/postgres/postgres/blob/master/src/tools/c...
Bu, commitfest öğeleri için çalışan CI ile aynı
Hata raporlarının posta listesine gitmesinden gerçekten nefret ediyorum; ben de sürekli kaçırıyorum
Kernel bugzilla’nın da epey işe yaramaz olduğunu düşünüyorum ama ondan daha iyisini yapmak zor değil
LKML tarzı yama işlemenin de iyi olduğunu düşünmüyorum; özellikle her yama seti revizyonunda yeni bir thread oluşması, takibi pek de kolaylaştırmıyor
Yaklaşık 15 yıldır geliştirmeye katılıyor olsam da mevcut araçların özellikle iyi çalıştığını söyleyemem
Geliştirme süreci bu süre içinde bir ölçüde gelişti ama gereken seviyeye gelmedi
PG topluluğu gibi gri sakallıların çok olduğu bir topluluğu değiştirmek çok emek ister; imkânsız değil ama kolay da değil
Kişisel olarak GitHub veya GitLab’ı karmaşık işler için kullanmaktan kesinlikle hoşlanmıyorum, ama yeni katkıcılar için kolaylaştırmak adına ikisinden biri üzerinden PR/MR kabul etmemiz gerektiğini düşünüyorum
Tabii bu yalnızca benim karar verebileceğim bir şey değil
Yama tartışmalarında e-postanın üstün olduğu ama etrafındaki araçların iyileştirilmesi gerektiği fikrine karşı çıkacak kişi sayısının 2-3’ten fazla olacağını sanmıyorum
Sorun şu ki birçok kişi zamanını geliştirme süreci araçları veya entegrasyon yerine Postgres hack’lemeye harcamak istiyor
pgrx’in yardımıyla Postgres üzerinde biraz çalıştım ve veri çözümleri kurma platformu olarak tavsiye edebilirim
CMU kanalı da iyi bir kaynaktı: https://www.youtube.com/@CMUDatabaseGroup
Örneğin yeni bir Table Access Method handler’ı yazmak isteseniz bile, çekirdek pg-sys SDK’sında TableAM ile ilgili binding’ler olsa da bunların Rust’ta nasıl kullanılacağına dair dokümantasyon veya örnek yok
Son zamanlarda IT’ye giren çoğu kişinin sadece parayı düşündüğünü, tutkulu insanların ise artık pek kalmadığını gözlemliyorum
Bu çok üzücü; birçok açık kaynak projesinin de bu yüzden ölmekte olduğunu düşünüyorum
Geriye katkı ya da yardım sunmadan sadece “Stack Overflow’dan kopyala-yapıştır yapıp maaş almak” şeklinde ilerliyor
Herkes böyle demek istemiyorum ama çeşitli şirketlerde çalışıp yakından gözlemlediğim ve konuştuğum oran yaklaşık 19:1 gibiydi
Bu arada ben, standartlara göre işleri fazla hızlı bitirdiğim ve toplantıları beklerken çok zaman harcadığım için her gün iki şirkette çalışıyorum
İlginç işler yapmak için çok sayıda yan iş de yaptım; yeni donanımları denemek ya da deney yapmak için ücretsiz çalıştığım da çok oldu
Sözleşmelerdeki buluş devir maddeleri ve dış faaliyet maddeleri katkı yapmanın önündeki engeli yükseltiyor
Postgres’in yeni kullanıcı çekmekte zorlanmadığına katılıyorum
Ben de birkaç self-hosting uygulamasında Postgres kullanıyorum
Ancak PHP uygulamalarında, varsayılan ya da tek veritabanı olan MariaDB’yi kullanmaya devam ediyorum
Özetle, PostgreSQL’e katkıda bulunan kitlenin yaşlandığı; Neon’un ise mevcut committer’lar yerine junior geliştiricileri işe alıp eğiterek geliştirici tabanını genişlettiği anlatılıyor gibi görünüyor
C/C++ deneyimim yok ama konuya ilgi duyan bir programcı olarak, kodu ayrıntılı biçimde açıklayan bir video serisi olursa katkıda bulunmaya başlamak için gerçekten çok yardımcı olurdu