- Lớp nhân sự thực sự bảo trì phần mã lõi của PostgreSQL, ra mắt năm 1986, đang già đi, làm dấy lên vấn đề về tính bền vững: 20 năm nữa ai sẽ tiếp tục công việc này
- Tính đến năm 2022, có 192 lập trình viên dẫn dắt ít nhất một commit; đây là cấu trúc tập trung vào số ít, khi 66% mã mới do 14 người viết và 90% do 40 người viết
- Độ tuổi trung bình của cộng đồng phát triển lõi vào khoảng 50, và Tom Lane, 68 tuổi, vẫn đóng vai trò trục chính của dự án
- Thay vì tuyển các nhân tài hàng đầu hiện có, Neon chủ ý đầu tư vào đào tạo thế hệ kế cận bằng cách tuyển junior và phát triển họ từ contributor thành committer, maintainer
- Để duy trì bảo trì dự án lâu dài, cần có chủ ý, nguồn vốn và lợi ích tự thân khai sáng (enlightened self interest)
Sự già hóa của PostgreSQL và vấn đề nhân sự bảo trì
- PostgreSQL, ra mắt năm 1986, đã trở thành lựa chọn mặc định trong một phần đáng kể của phát triển phần mềm hiện đại, nhưng sau một thời gian dài kể từ khi ra mắt, vấn đề về tính liên tục của đội ngũ thực sự xây dựng cơ sở dữ liệu này được đặt ra
- Câu hỏi là những người này sẽ còn tiếp tục gánh vác phần việc nặng nhọc (heavy lifting) trong việc duy trì một codebase nổi bật mà rất nhiều người phụ thuộc vào trong bao lâu
- Postgres là một dự án và cũng là một nhóm nhỏ gắn kết chặt chẽ
Thống kê contributor năm 2022
- Robert Haas, chief database scientist tại EnterpriseDB và là Postgres committer, đã công bố các con số trong bài viết định kỳ về tình hình đóng góp "Who Contributed to PostgreSQL Development in 2022?"
- Số người là tác giả chính (principal author) của ít nhất một commit PostgreSQL trong năm 2022 là 192
- 66% số dòng mã mới do một trong 14 người viết
- 90% số dòng mã mới do một trong 40 người viết
Cấu trúc tuổi của cộng đồng lõi
- Cộng đồng phát triển lõi đã hơi già hóa, với độ tuổi trung bình xấp xỉ 50
- Tom Lane thuộc Crunchy Data, ở tuổi 68, vẫn đóng vai trò trục chính (fulcrum) của dự án Postgres
Quản trị mở và câu hỏi sau 20 năm
- Open governance của Postgres là một nền tảng có thể dựa vào, và là một ví dụ mới mẻ trong thời điểm các thay đổi đơn phương đối với giấy phép open source thương mại (rugpull) diễn ra thường xuyên
- Nhìn từ góc độ tính bền vững của open source, nếu giả định Postgres vẫn vững mạnh sau 20 năm nữa, câu hỏi được đặt ra là ai sẽ làm công việc đó vào năm 2043
Thảo luận với Neon và Nikita Shamgunov
- Trong cuộc trò chuyện với CEO Nikita Shamgunov của Neon, chủ đề được bàn tới là sự già hóa của các dự án công nghệ và mối liên hệ của nó với tính bền vững của dự án
-
Giới thiệu Neon
- Neon là cơ sở dữ liệu Postgres được quản lý hoàn toàn, tối ưu cho ứng dụng serverless; tách biệt storage và compute, áp dụng nguyên tắc thiết kế "cơ sở dữ liệu chính là một URL"
- Hỗ trợ branching để có thể triển khai preview, qua đó hình thành quan hệ đối tác với Vercel
- Định hướng là làm cho nó "dễ dùng, hiện đại, bằng zero config API"
- Có 62 nhân viên, tổng vốn huy động 108 triệu USD ($108m), cạnh tranh với Supabase và các bên khác
-
Khác biệt giữa committer và contributor
- Shamgunov: "Tầng lớp Postgres committer ở độ tuổi 50, 60 và 40; người ở độ tuổi 30 chỉ là thiểu số"
- Để trở thành committer cần rất nhiều nỗ lực, nhưng để trở thành contributor thì chỉ cần viết mã tốt
Đầu tư đào tạo thế hệ committer kế cận
- Neon chủ ý đầu tư vào thế hệ tiếp theo của contributor, committer và maintainer
- Lựa chọn tự nhiên của nhiều công ty là tuyển các nhân tài hàng đầu hiện có thay vì bồi dưỡng nhân tài mới
- Shamgunov: "Chúng tôi đã thảo luận có nên tìm thêm Postgres committer để tuyển dụng hay không, nhưng không rõ đó có phải cách sử dụng vốn tốt nhất hay không"
- "Đào tạo mới thì tốt hơn, và bằng cách đó chúng tôi có thể tiếp tục mở rộng đội ngũ Postgres"
- Shamgunov nhấn mạnh rằng tuyển dụng và đào tạo junior để họ trở thành committer, xa hơn là maintainer, là điều quan trọng đối với sự tiến hóa liên tục của Postgres engine
Giấy phép và lợi ích tự thân khai sáng
- IP của Neon hiện dùng giấy phép permissive, nhưng Shamgunov không phải là người theo chủ nghĩa open source nguyên giáo
- Trong tương lai, Neon có quyền relicense và chuyển sang các điều khoản hạn chế hơn như Redis, MongoDB, Elastic
- Tuy nhiên, mã đã đóng góp cho Postgres sẽ không chịu ảnh hưởng bởi quyết định như vậy
- Việc có maintainer Postgres lõi trong nội bộ là một ví dụ về lợi ích tự thân khai sáng (enlightened self interest); đây là cơ chế giữ cho công ty trung thực, và dù công ty đưa ra quyết định nào thì cộng đồng cùng codebase lõi vẫn được hưởng lợi
Tính phổ biến của già hóa theo cohort
- Già hóa theo cohort không phải vấn đề chỉ riêng Postgres; như trường hợp Y2K (lỗi năm 2000) trong quá khứ, cộng đồng và hệ sinh thái đều già đi, và điều này có thể gây ra vấn đề về mặt công nghệ, nhân sự và chuyển giao thế hệ
- IBM là một ví dụ thành công trong việc thu hút lập trình viên trẻ vào lĩnh vực mainframe thông qua các chương trình đào tạo nghề ở đại học và những cách khác
- Cũng có nhiều dự án với hàng triệu người dùng nhưng chỉ do một hoặc hai người vận hành, không có sự tài trợ doanh nghiệp như Postgres hay Kubernetes
Kết luận — tính chủ ý trong bảo trì
- Postgres hoàn toàn không gặp khó khăn trong việc thu hút người dùng mới, và là một nền tảng cực kỳ phổ biến mà ngay cả các lập trình viên 22 tuổi ngày nay cũng chọn làm mặc định
- Tuy nhiên, để bảo đảm việc bảo trì dự án liên tục, cần có tính chủ ý (intentionality), nguồn vốn và lợi ích tự thân khai sáng
Công bố thông tin (Disclosure)
- Neon không phải khách hàng của RedMonk; Crunchy Data, IBM và Vercel đều là khách hàng của RedMonk, và bài viết này được đăng độc lập, không liên quan đến quan hệ khách hàng
1 bình luận
Các ý kiến trên Hacker News
Tôi 46 tuổi nhưng vẫn muốn thuộc về thế hệ tiếp theo, và chắc chắn cũng sẽ có những người trẻ hơn
Bài trình bày cuối cùng của tôi tại PGCon nói về những lỗ hổng cần biết để hack Postgres, đặc biệt là giai đoạn executor và nỗ lực lấp đầy TupleTableSlot
Tôi không phải là người phù hợp nhất, nhưng đôi khi người đang học lại hiểu rõ hơn người học cần gì
Cách đây không lâu tôi cũng đã thử viết mục lục cho một cuốn sách về cách đóng góp cho Postgres, và nghĩ rằng ít nhất cũng bán được 10 cuốn
Có lẽ đăng nhiều kỳ trực tuyến sẽ tốt hơn; dù theo cách nào thì tôi cũng tự hỏi liệu có ai quan tâm không
Hiện tại Postgres gần như là sở thích của tôi, nhưng nếu có nơi nào đang tìm người làm đóng góp mã nguồn mở cho Postgres toàn thời gian thì tôi sẵn sàng trao đổi
Khá nhiều người thuộc thế hệ tiếp theo hiện nay cũng đến với Postgres khá muộn
Tom cũng sẽ khiêm tốn nói về bản thân, nhưng ông ấy đã làm về mảng hình ảnh trong vài năm, tham gia dưới hình thức nào đó vào quá trình tạo ra tiff, jpg, png, rồi sau đó phát hiện Postgres và bắt đầu làm việc với nó
Anh ấy tạo rất nhiều nội dung về cách bắt đầu đóng góp cho Postgres, và cũng cởi mở khi trò chuyện với những người dùng PG nhiệt huyết khác
Có thể hợp tác hoặc xin lời khuyên: https://www.youtube.com/watch?v=rihfAnd_leM
Có thể liên hệ qua email x4mmm@.ru hoặc Twitter @x4mmmmmm
Khi rào cản tham gia đã thấp hơn, tôi kỳ vọng sẽ có nhiều người nghỉ hưu sớm hơn và tham gia mã nguồn mở hơn
Một số nhà xuất bản cho phép độc giả truy cập sớm báo lỗi: https://nostarch.com/early-access-program
Thú vị đến mức mục tiêu của tôi là có thể nghỉ hưu sớm và hack Postgres toàn thời gian
Trong đó có đủ cả mạng, lưu trữ, dữ liệu, thuật toán, v.v.
Thành thật mà nói, C không phải vấn đề lớn bằng; Postgres có code style tốt và khá nhất quán
Cái khó là độ phức tạp của cấu trúc nội bộ, và nếu cộng đồng nhỏ thì tốc độ nhận được trợ giúp cũng có thể bị ảnh hưởng
Tôi tự hỏi liệu các codebase C trong tương lai có gặp khó khăn trong việc tìm người bảo trì không
Postgres có hỗ trợ thương mại và quán tính, nhưng có vẻ thiếu kênh đưa các lập trình viên C lành nghề vào
C vẫn là một ngôn ngữ còn sống và không thiếu người dùng tích cực; với những người lập trình hệ thống bằng ngôn ngữ khác, đường cong học tập cũng không quá dốc
Với các nhà phát triển web/ứng dụng ngày nay, có một bức màn mờ đục giữa họ và kiến trúc hệ thống bên dưới nên C có thể gây cảm giác đáng sợ, nhưng các lập trình viên hệ thống dùng C++ hoặc Rust vốn đã làm việc phía sau bức màn đó với đôi găng tay dày hơn
Nhiều người trong số họ từng tiếp xúc với C, dù là trong đào tạo hay thử nghiệm trước đây, và nếu phải làm chuyên nghiệp thì họ có thể chủ động học để thích nghi với những cạm bẫy nguy hiểm
Có các lập luận phản đối việc chọn C cho dự án hệ thống mới, nhưng ngoài vấn đề thiếu lập trình viên hệ thống nói chung, hiện tại có vẻ chưa có mối lo lớn trong việc tìm người bảo trì code hiện có
Tôi không đo lường khoa học, nhưng có vẻ kỹ năng C trung bình của những người đóng góp mới đã thấp hơn trước, dĩ nhiên đây cũng có thể chỉ là lời của bộ râu bạc của tôi
Cho đến nay mọi người vẫn “vừa làm vừa học”, nhưng không rõ khoảng cách đó lớn đến mức nào
Có lẽ một ngày nào đó sẽ phải làm cho việc dùng ngôn ngữ khác trong một số phần của hệ thống, chẳng hạn như triển khai kiểu dữ liệu trong core, trở nên dễ dàng hơn; nhưng thực tế thì điều đó có vẻ vẫn còn hơi xa
Phần khó là có đúng kiến thức miền, và cần nhiều thời gian để quen với toàn bộ hệ thống
Tôi hầu như không biết lập trình viên Rust hay C++ lành nghề nào mà lại không thành thạo C
Tuy nhiên tôi tò mò khi nào nhiều codebase C hơn sẽ bắt đầu tách module ra và thay thế bằng Rust
Điều này đã diễn ra ở Linux, curl, các dự án C++ như Chrome, nhiều sản phẩm MS, Amazon S3, v.v.
Trường hợp chống lại rõ ràng nhất mà tôi biết là OpenBSD, vì họ muốn giữ bootstrap và toolchain cài đặt mặc định ở mức nhỏ
Ngay cả hệ thống kiểu của TypeScript cũng khá phức tạp hơn C
Hoặc có lẽ tôi chỉ đang bộc lộ sự thiếu hiểu biết của mình về mức độ phức tạp của C
Tôi có khá nhiều suy nghĩ về chủ đề này
Cộng đồng đã lên xuống trong một thời gian dài, và với ý định chia sẻ thêm một chút về cộng đồng PG, tôi xin nói vài điều
Trong vài năm đã không có committer mới nào, và gần đây nhóm đã cố gắng bổ sung committer mới một cách có chủ đích hơn, đồng thời dọn dẹp những người không còn tham gia nữa
Khoảng 15 năm trước từng có giai đoạn khá nhiều người trẻ nhận được quyền commit, và tôi nhớ có ba người khi đó chưa đến 25 tuổi, có lẽ tất cả đều chưa đến 22 tuổi
Trong số đó, một người không lâu sau đã rời khỏi cộng đồng Postgres, một người im ắng bận rộn với việc khác hơn 10 năm rồi quay lại, và một người vẫn tiếp tục tham gia tích cực
Có vẻ sự không thoải mái với những người nhận quyền commit rồi biến mất đã khiến việc thêm người mới chậm lại trong vài năm
Tóm lại, điều đó có nghĩa là rất khó để nhận quyền commit Postgres ngay sau khi tốt nghiệp đại học
Một dữ liệu thú vị nhưng khó thu thập là mọi người trở thành committer Postgres ở độ tuổi nào
Tôi sẽ không ngạc nhiên nếu trung bình độ tuổi nhận quyền commit gần 45
Nhiều contributor đến với Postgres sau khi đã làm việc trên các hệ thống khác, hoặc chỉ cân nhắc đóng góp khi đã tích lũy được một mức kinh nghiệm nhất định vì cách gửi patch lên mailing list có thể tạo cảm giác đáng sợ
Câu chuyện về commit đầu tiên của người đó rất hay
Khi kiểm thử hành vi SQL ở Materialize, người đó muốn kiểm tra xem hai hệ thống có xử lý hàm interval giống nhau không, và đã cẩn thận thử những thứ như
select interval '0.5 months 2147483647 days';Có thể tự thử trên dbfiddle: https://www.db-fiddle.com/f/ijT76fsmL99bHvXxhAtf7j/0
Thay vì báo lỗi, Postgres trả về giá trị sai
{"days":-2147483634}, và có thể đọc lý do ở đây: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...Vì vậy, điều đó tự nhiên được sửa trong Postgres, nhờ đó các phiên bản 15 trở lên xử lý đúng: https://www.db-fiddle.com/f/i3KikCb72AN1EZpywErZvr/1
Dù tôi thích Postgres đến mức còn xăm hình PG, cả hai con đường đóng góp đều không dễ
Nếu muốn đóng góp trong thời gian rảnh với tư cách một người dùng ngẫu nhiên, cũng không có nhiều ticket kiểu “issue tốt cho người mới bắt đầu”, và rất khó khởi đầu nếu không biết ít nhiều bối cảnh cùng lý do lịch sử của nhiều phần trong kiến trúc PG
Việc được những người như Tom hay Andres review patch cũng có thể tạo cảm giác đáng sợ
Con đường gia nhập các công ty PG có trả lương như EDB, PG Pros, Crunchy với vai trò developer cũng gần giống bài toán con gà và quả trứng
Rất khó được tuyển làm junior nếu chưa từng có kinh nghiệm hack PG trước đó, nhưng chính con đường để tích lũy kinh nghiệm ấy cũng không dễ
Nếu không phải công ty hiện tại, tôi muốn làm ở nơi làm công việc liên quan đến PG, nhưng thực tế không có nhiều lối vào khả thi
Với 10 người gần đây trở thành committer, tôi đã dùng vài lệnh git như dưới đây để so sánh thời điểm tên họ lần đầu xuất hiện trong commit message và thời điểm họ thực hiện commit đầu tiên với tư cách committer
Thời gian tham gia trung bình, nếu chỉ so sánh theo tháng/năm, là khoảng 8,9 năm, và trường hợp ngắn nhất cũng khoảng 6,5 năm
Có thể phân tích tốt hơn nữa, nhưng mục tiêu là có được cảm nhận sơ bộ
git log --grep 'Name' --format=%cs | sort | head -1git log --author 'Name' --format=%cs | sort | head -1Khi đó có thể một người 22 tuổi dễ tiếp cận hơn và nắm được nhiều phần hơn
Ngoài ra, khi đó C là ngôn ngữ tiêu chuẩn, còn các developer trẻ ngày nay có khả năng lập trình bằng Rust nhiều hơn là C
Tôi hoàn toàn không biết từng có một nhóm người nhận quyền commit khi chưa đến 22 tuổi
Tôi là một người đóng góp mới, bắt đầu đóng góp cho Postgres từ 5 tháng trước, và cuối tháng này sẽ tròn 27 tuổi
Dù chưa có nhiều đóng góp giá trị, tôi đã có vài commit và trong thời gian tới muốn làm cho việc build extension Postgres bằng Meson trở nên dễ dàng hơn, nếu có thể thì cũng muốn sớm loại bỏ build bằng autotools
Có thể sắp tới bạn sẽ thấy tôi trong các repository pgbouncer hoặc pgvector
Lý do tôi bắt đầu đóng góp là vì đã mệt mỏi với công ty tư vấn phần mềm nơi tôi làm việc trong 3 năm
Ban đầu tôi muốn sống như một người làm phần mềm hệ thống nguồn mở, và đã tìm được công việc về engine lưu trữ nguồn mở tại Micron
Thành thật mà nói tôi đã may mắn, nhưng tin tuyển dụng như được viết dành cho tôi nên tôi ứng tuyển, và đã làm việc vui vẻ trong dự án đó 2,5 năm
Đáng tiếc là cuối tháng 2 Micron đã sa thải toàn bộ đội ngũ, sau đó MongoDB từng đề nghị tôi làm về driver C/C++ rồi lại rút lại
Sau đó tôi bắt đầu dựa nhiều hơn vào mạng lưới quan hệ, và hỏi một người quen trong #mesonbuild trên Libera.Chat/Matrix đang làm về Postgres xem có vị trí nào liên quan đến Postgres phù hợp với nền tảng của tôi không
Anh ấy cho biết Neon đang tuyển dụng, tôi ứng tuyển vào đội storage engine, nhưng trong buổi phỏng vấn đầu tiên, người sau này sẽ trở thành quản lý của tôi nhận định rằng tôi phù hợp hơn với đội Postgres mới thành lập, tức đội đóng góp cho Postgres upstream
Tôi rất biết ơn Neon vì đã cho tôi cơ hội
Chủ đề của bài viết này khá thú vị vì đó là nội dung vừa được nhắc đến khi tôi trò chuyện với các contributor Postgres trẻ khác tại PGConf NYC
Ngay cả các patch nhỏ cũng khó được xem xét, và càng được cộng đồng biết tên thì dường như càng nhận được nhiều review hơn, tạo thành một vấn đề vòng lặp
Cấu trúc mailing list của Postgres cũng không tốt: phải uống nguyên vòi cứu hỏa pgsql-hackers, trong khi LKML được chia thành nhiều subsystem
Các code forge hiện đại có giá trị ở chỗ cho phép subscribe vào các tag cụ thể của PR/issue, nhưng hiện pgsql-hackers không có cách như vậy
Việc thêm mục vào commitfest cũng hơi phiền, và để chạy qua CI toàn bộ của Postgres thì phải đưa vào commitfest; sau đó vẫn phải tự kiểm tra hoặc hy vọng một committer báo cho bạn xem lỗi CI
Báo cáo lỗi cũng đi vào mailing list pgsql-bugs, và Postgres không có thứ tương ứng như Linux bugzilla
Patch được gửi dưới dạng file đính kèm email và không nhất thiết phải theo định dạng git-format-patch, trong khi nhìn bề ngoài LKML có vẻ dùng độc quyền git-send-email
Nhìn chung, công cụ của cộng đồng contributor Postgres có vẻ phù hợp nhất với những người đã cắm rễ sâu trong đó hơn 15 năm
Tôi không muốn biến điều này thành một bài “hãy dùng GitHub/GitLab”; ngược lại, tôi nghĩ email vượt trội hơn cho thảo luận patch, nhưng các công cụ xung quanh mailing list có thể được cải thiện
Mọi thứ quá tách rời, và tôi thấy SourceHut làm khá tốt trong việc khiến phát triển dựa trên mailing list dễ tiếp cận hơn với contributor thường xuyên
Issue, mailing list, CI/CD và repository đều được liên kết với nhau, chứ không bị chia ra thành các dịch vụ riêng như Postgres hiện nay
Bản thân bình luận này có thể một ngày nào đó trở thành một bài blog riêng, nhưng tôi dừng ở đây
Nếu bạn mới bắt đầu đóng góp cho Postgres, có lẽ chúng ta có thể chia sẻ kinh nghiệm; có thể gửi email tới tristan neon.tech hoặc tristan partin.io
Một contributor Postgres khác cho rằng có thể hữu ích nếu các contributor không phải committer gặp nhau hằng tháng để nói về các patch đang làm hoặc đã đăng và nhận peer review
Tristan có thể dẫn dắt một buổi gặp mặt trực tuyến
Melanie Plageman cũng từng quan tâm đến ý tưởng như vậy, và chúng tôi đã thảo luận ngắn về các hình thức office hour khác nhau
Nội dung này có vẻ có thể phát triển thành một bài viết hay, và xét về mặt tổ chức cũng như quy trình, đây dường như là những phần mà cộng đồng Postgres có thể cải thiện tương đối dễ dàng
Tuy nhiên tôi chưa chắc lắm về phần “độ nhận diện tên tuổi”, và dường như cũng có sự rơi rụng lớn ở phía đầu còn lại
Vấn đề pgsql-hackers giống như vòi cứu hỏa là đúng, và tôi nghĩ nó đã trở nên tệ hơn nhiều trong vài năm qua
Có thể bật CI trong repository mà không cần đưa vào commitfest: https://github.com/postgres/postgres/blob/master/src/tools/c...
Đây chính là CI chạy cho các mục commitfest
Tôi thật sự không thích việc báo cáo lỗi đi vào mailing list, và tôi cũng liên tục bỏ sót chúng
Tôi cũng cho rằng kernel bugzilla khá vô dụng, nhưng làm tốt hơn nó thì không khó
Tôi cũng không nghĩ cách xử lý patch kiểu LKML là tốt, đặc biệt là việc mỗi lần sửa đổi patchset lại tạo thread mới không khiến việc theo dõi trở nên thật dễ dàng
Dù đã tham gia phát triển khoảng 15 năm, tôi cũng sẽ không nói rằng bộ công cụ hiện tại hoạt động đặc biệt tốt
Quy trình phát triển trong thời gian đó đã tiến bộ ở một mức nào đó, nhưng vẫn chưa đến mức cần thiết
Thay đổi một cộng đồng có nhiều “râu bạc” như cộng đồng PG tốn rất nhiều công sức; không phải là không thể, nhưng không dễ
Cá nhân tôi cực kỳ không thích dùng GitHub hay GitLab cho các công việc phức tạp, nhưng tôi nghĩ nên chấp nhận PR/MR qua một trong hai nền tảng đó để giúp contributor mới dễ tham gia hơn
Tuy nhiên đó không phải việc chỉ mình tôi quyết định được
Có lẽ sẽ không có nhiều hơn 2–3 người phản đối ý tưởng rằng email vượt trội cho thảo luận patch nhưng các công cụ xung quanh cần được cải thiện
Vấn đề là nhiều người muốn dành thời gian hack Postgres hơn là làm công cụ hay tích hợp cho quy trình phát triển
Tôi đã thử làm một chút với Postgres nhờ pgrx, và có thể khuyến nghị nó như một nền tảng xây dựng giải pháp dữ liệu
Kênh CMU cũng là tài liệu tốt: https://www.youtube.com/@CMUDatabaseGroup
Ví dụ, nếu muốn viết một handler Table Access Method mới, core pg-sys SDK có binding liên quan đến TableAM, nhưng không có tài liệu hay ví dụ nào về cách dùng chúng trong Rust
Gần đây tôi nhận thấy hầu hết những người bước vào ngành IT chỉ quan tâm đến tiền, còn những người thật sự nhiệt huyết thì không còn nhiều nữa
Điều đó rất buồn, và có vẻ nhiều dự án mã nguồn mở đang chết dần vì lý do đó
Kiểu chỉ “copy-paste từ Stack Overflow rồi nhận lương” mà không đóng góp hay giúp đỡ lại
Không có nghĩa là ai cũng vậy, nhưng qua việc làm ở nhiều công ty, quan sát và trò chuyện gần gũi thì tỷ lệ tôi thấy khoảng 19:1
Nhân tiện, tôi thường hoàn thành công việc quá nhanh so với tiêu chuẩn nên hay lãng phí thời gian chờ họp, vì vậy mỗi ngày tôi làm việc cho hai công ty
Tôi cũng làm nhiều việc phụ để được làm những việc thú vị, và nhiều lần làm miễn phí chỉ để thử phần cứng mới hoặc thử nghiệm
Các điều khoản chuyển nhượng phát minh và điều khoản về hoạt động bên ngoài trong hợp đồng làm tăng rào cản đóng góp
Tôi đồng ý rằng Postgres không hẳn đang gặp khó trong việc thu hút người dùng mới
Tôi cũng đang dùng Postgres cho nhiều ứng dụng self-hosting
Tuy nhiên, với các ứng dụng PHP thì tôi vẫn tiếp tục dùng MariaDB, vốn là mặc định hoặc là cơ sở dữ liệu duy nhất được hỗ trợ
Tóm lại, nội dung có vẻ là cộng đồng contributor của PostgreSQL đang già đi, còn Neon đang mở rộng nền tảng developer bằng cách tuyển dụng và đào tạo junior thay vì dựa vào các committer hiện có
Là một lập trình viên không có kinh nghiệm C/C++ nhưng có hứng thú, tôi nghĩ nếu có một series video giải thích chi tiết mã nguồn thì sẽ thực sự giúp ích để bắt đầu đóng góp