- Die Personengruppe, die den Kerncode von PostgreSQL seit seiner Veröffentlichung 1986 tatsächlich wartet, altert, wodurch die Frage der Nachhaltigkeit aufkommt: Wer wird diese Arbeit in 20 Jahren fortführen?
- Stand 2022 gab es 192 Entwickler, die bei mindestens einem Commit die Federführung hatten; eine stark konzentrierte Struktur, in der 66 % des neuen Codes von 14 Personen und 90 % von 40 Personen geschrieben wurden
- Das Durchschnittsalter der Kernentwickler-Community liegt bei etwa 50 Jahren, und Tom Lane spielt mit 68 weiterhin eine zentrale Rolle im Projekt
- Neon investiert bewusst in die Förderung der nächsten Generation, indem das Unternehmen statt bereits etablierter Top-Talente Junioren einstellt und sie vom Contributor zum Committer und Maintainer entwickelt
- Für die kontinuierliche Wartung des Projekts braucht es Zielgerichtetheit, Finanzierung und enlightened self interest
Die Alterung von PostgreSQL und das Problem bei den Wartungskapazitäten
- PostgreSQL, 1986 veröffentlicht, ist in weiten Teilen der modernen Softwareentwicklung zur Standardwahl geworden. Mit dem langen Bestehen der Datenbank stellt sich jedoch die Frage nach der langfristigen Kontinuität der Menschen, die sie tatsächlich bauen
- Es stellt sich die Frage, wie lange diese Personen die schwere Arbeit (heavy lifting) bei der Pflege einer viel genutzten, prominenten Codebasis noch leisten können
- Postgres ist ein eng verbundener kleiner Kreis und zugleich ein Projekt
Beitragsstatistiken für 2022
- Robert Haas, Chief Database Scientist bei EnterpriseDB und Postgres-Committer, veröffentlichte Zahlen in seinem regelmäßigen Beitrag "Who Contributed to PostgreSQL Development in 2022?"
- 192 Personen waren 2022 bei mindestens einem PostgreSQL-Commit Hauptautor (principal author)
- 66 % der neuen Codezeilen wurden von einer von 14 Personen geschrieben
- 90 % der neuen Codezeilen wurden von einer von 40 Personen geschrieben
Altersstruktur der Kern-Community
- Die Kernentwickler-Community ist etwas in die Jahre gekommen; das Durchschnittsalter liegt ungefähr bei 50 Jahren
- Tom Lane von Crunchy Data ist 68 Jahre alt und fungiert weiterhin als Dreh- und Angelpunkt (fulcrum) des Postgres-Projekts
Offene Governance und die Frage nach 20 Jahren
- Die offene Governance von Postgres ist ein verlässliches Fundament und in einer Zeit, in der einseitige Änderungen kommerzieller Open-Source-Lizenzen häufig vorkommen, ein erfrischendes Beispiel
- Aus Sicht der Nachhaltigkeit von Open Source stellt sich, wenn man annimmt, dass Postgres auch in 20 Jahren noch stark dasteht, die Frage: Wer wird diese Arbeit 2043 machen?
Neon und die Diskussion mit Nikita Shamgunov
- In einem Gespräch mit Neon-CEO Nikita Shamgunov ging es um die Alterung technischer Projekte und deren Zusammenhang mit der Nachhaltigkeit solcher Projekte
-
Einführung in Neon
- Neon ist eine vollständig gemanagte Postgres-Datenbank, optimiert für serverlose Apps, die Storage und Compute trennt und dem Designprinzip folgt: "Eine Datenbank ist letztlich eine URL"
- Unterstützt wird Branching, das Preview-Deployments ermöglicht; darauf aufbauend entstand eine Partnerschaft mit Vercel
- Das Ziel ist, etwas zu schaffen, das "einfach, modern, als zero-config API" funktioniert
- 62 Mitarbeiter, insgesamt 108 Millionen US-Dollar Finanzierung ($108m), im Wettbewerb mit Supabase und anderen
-
Unterschied zwischen Committer und Contributor
- Shamgunov: "Die Gruppe der Postgres-Committer ist in den 50ern, 60ern und 40ern; Menschen in ihren 30ern sind selten."
- Committer zu werden erfordert viel Aufwand, während man für Contributor-Status einfach nur guten Code schreiben muss
Investitionen in die nächste Generation von Committern
- Neon investiert bewusst in die nächste Generation von Contributoren, Committern und Maintainern
- Für viele Unternehmen wäre die naheliegende Entscheidung, bestehende Top-Talente einzustellen statt neue zu entwickeln
- Shamgunov: "Wir haben darüber gesprochen, ob wir weitere Postgres-Committer finden und einstellen sollten, aber es war unklar, ob das der beste Einsatz unseres Geldes ist."
- "Es ist besser, neue Leute aufzubauen, und auf diese Weise können wir das Postgres-Team weiter vergrößern."
- Shamgunov betont, dass es für die kontinuierliche Weiterentwicklung der Postgres-Engine wichtig ist, Junioren einzustellen und auszubilden, damit sie zu Committern und später zu Maintainern werden
Lizenzen und enlightened self interest
- Das IP von Neon steht derzeit unter einer permissiven Lizenz, aber Shamgunov ist kein Open-Source-Fundamentalist
- Künftig könnte Neon wie Redis, MongoDB oder Elastic das Recht ausüben, neu zu lizenzieren (relicense) und zu restriktiveren Bedingungen zu wechseln
- Der bereits zu Postgres beigetragene Code wäre von einer solchen Entscheidung allerdings nicht betroffen
- Zentrale Postgres-Maintainer im eigenen Unternehmen zu haben, ist ein Beispiel für enlightened self interest: ein Mechanismus, der das Unternehmen ehrlich hält, und unabhängig von den getroffenen Entscheidungen profitieren Community und Kern-Codebasis davon
Die Allgemeingültigkeit alternder Kohorten
- Die Alterung von Kohorten ist kein auf Postgres beschränktes Problem; wie schon beim Y2K-Problem altern Communities und Ökosysteme, was im Hinblick auf Technologie, Fachkräfte und Generationswechsel Probleme verursachen kann
- IBM ist ein Beispiel dafür, mit Hochschul- und Berufsbildungsprogrammen junge Entwickler erfolgreich in den Mainframe-Bereich geholt zu haben
- Es gibt auch viele Projekte mit Millionen Nutzern, die nicht von Unternehmen wie bei Postgres oder Kubernetes unterstützt werden, sondern nur von ein oder zwei Personen betrieben werden
Fazit — Zielgerichtetheit bei der Wartung
- Postgres hat keinerlei Schwierigkeiten, neue Nutzer zu gewinnen, und ist heute eine äußerst beliebte Plattform, die selbst 22-jährige Entwickler standardmäßig wählen
- Um die kontinuierliche Wartung des Projekts sicherzustellen, braucht es jedoch Zielgerichtetheit, Finanzierung und enlightened self interest
Offenlegung
- Neon ist kein Kunde von RedMonk; Crunchy Data, IBM und Vercel sind allesamt Kunden von RedMonk, und dieser Beitrag wurde unabhängig von den Kundenbeziehungen veröffentlicht
1 Kommentare
Meinungen auf Hacker News
Ich bin zwar 46, würde aber gern zur nächsten Generation gehören, und es gibt sicher auch jüngere Leute
Mein letzter Vortrag auf der PGCon handelte von den Lücken, die man kennen muss, wenn man an Postgres hacken will, insbesondere von der Executor-Phase und dem Versuch,
TupleTableSlotzu füllenIch bin nicht die am besten geeignete Person, aber manchmal weiß jemand, der selbst lernt, besser, was Lernende brauchen
Vor einiger Zeit habe ich auch ein Inhaltsverzeichnis für ein Buch darüber geschrieben, wie man zu Postgres beiträgt, und ich glaube, mindestens 10 Exemplare würden sich verkaufen
Eine Online-Serie wäre vielleicht besser; so oder so frage ich mich, ob es Interessierte gäbe
Im Moment ist Postgres für mich eher ein Hobby, aber wenn es irgendwo jemanden sucht, der sich Vollzeit mit Open-Source-Beiträgen zu Postgres beschäftigt, wäre ich gesprächsbereit
Ein beträchtlicher Teil der heutigen nächsten Generation ist ebenfalls erst ziemlich spät zu Postgres gestoßen
Auch Tom würde das herunterspielen, aber er hatte einige Jahre im Image-Bereich gearbeitet und war in irgendeiner Form an der Entstehung von tiff, jpg und png beteiligt, bevor er Postgres entdeckte und daran zu arbeiten begann
Er erstellt viele Inhalte dazu, wie man mit Beiträgen zu Postgres anfängt, und ist auch offen dafür, mit anderen PG-Enthusiasten zu sprechen
Zusammenarbeit oder Rat könnten ebenfalls möglich sein: https://www.youtube.com/watch?v=rihfAnd_leM
Er ist per E-Mail unter x4mmm@.ru oder auf Twitter unter @x4mmmmmm erreichbar
Da die Einstiegshürden niedriger geworden sind, bin ich gespannt, ob mehr Menschen früh in den Ruhestand gehen und sich an Open Source beteiligen werden
Einige Verlage erlauben Early-Access-Lesern, Fehler zu melden: https://nostarch.com/early-access-program
Es ist so interessant, dass mein Ziel darin besteht, früh in den Ruhestand gehen zu können und Vollzeit an Postgres zu hacken
Netzwerk, Storage, Daten, Algorithmen usw. steckt alles darin
Ehrlich gesagt ist C das kleinere Problem; Postgres hat einen guten und ziemlich konsistenten Code-Stil
Schwierig ist die Komplexität der internen Struktur, und wenn die Community klein ist, kann sich das auch darauf auswirken, wie schnell man Hilfe bekommt
Ich frage mich, ob C-Codebasen künftig Schwierigkeiten haben werden, Maintainer zu finden
Postgres hat kommerziellen Support und Trägheit auf seiner Seite, aber es scheint an Wegen zu mangeln, über die erfahrene C-Entwickler nachwachsen
C ist weiterhin eine lebendige Sprache, es mangelt nicht an aktiven Nutzern, und für Leute, die in anderen Sprachen Systemprogrammierung betreiben, ist die Lernkurve nicht besonders steil
Für heutige Web- und Anwendungsentwickler kann C einschüchternd wirken, weil zwischen ihnen und der darunterliegenden Systemarchitektur ein undurchsichtiger Vorhang liegt; Systemprogrammierer, die C++ oder Rust verwenden, arbeiten aber bereits hinter diesem Vorhang, nur mit dickeren Handschuhen
Viele von ihnen sind C in der Vergangenheit zumindest in Ausbildung oder Experimenten begegnet, und wenn sie sich beruflich damit befassen, können sie es gezielt lernen und sich an die gefährlichen Fallstricke gewöhnen
Es gibt Argumente dagegen, C für neue Systemprojekte zu wählen, aber abgesehen vom Problem eines Mangels an Systemprogrammierern selbst sehe ich derzeit keine großen unmittelbaren Sorgen, Maintainer für bestehenden Code zu finden
Ich habe es nicht wissenschaftlich gemessen, aber die durchschnittlichen C-Kenntnisse neuer Contributors scheinen niedriger zu sein als früher; natürlich könnte das auch nur mein grauer Bart sagen
Bisher lernen die Leute „on the job“, aber wie groß diese Lücke ist, weiß ich nicht sicher
Irgendwann wird man wohl Teile des Systems, etwa die Implementierung von Datentypen im Core, leichter in anderen Sprachen schreiben können müssen; realistisch gesehen scheint das aber noch etwas weiter weg zu sein
Der schwierige Teil ist, das richtige Domänenwissen zu haben, und es dauert lange, mit dem gesamten System vertraut zu werden
Ich kenne kaum erfahrene Rust- oder C++-Entwickler, die nicht auch gut in C wären
Allerdings frage ich mich, wann mehr C-Codebasen anfangen werden, Module herauszulösen und durch Rust zu ersetzen
Das passiert bereits bei Linux, curl, C++-Projekten wie Chrome, diversen MS-Produkten, Amazon S3 und anderen
Die ausdrücklichste Gegenwehr, die ich kenne, kommt von OpenBSD, weil sie Bootstrap und die Toolchain der Basisinstallation klein halten wollen
Sogar das Typsystem von TypeScript ist deutlich komplexer als C
Oder ich offenbare damit nur meine Unwissenheit darüber, wie komplex C ist
Ich habe mir zu diesem Thema viele Gedanken gemacht
Die Community ist seit Langem mal gewachsen und mal geschrumpft, und ich möchte ein paar Punkte nennen, um etwas mehr über die PG-Community zu teilen
Über mehrere Jahre hinweg gab es überhaupt keine neuen Committer, und in letzter Zeit hat das Team versucht, bewusster neue Committer hinzuzunehmen und Personen auszusortieren, die nicht mehr beteiligt sind
Vor etwa 15 Jahren gab es eine Phase, in der ziemlich viele junge Leute Commit-Rechte erhielten; ich erinnere mich an drei Personen, die damals unter 25 waren, vielleicht sogar alle unter 22
Eine davon wechselte kurz darauf aus der Postgres-Community heraus, eine war über zehn Jahre still mit anderer Arbeit beschäftigt und kam dann zurück, und eine blieb durchgehend aktiv beteiligt
Ich glaube, wegen eines Unbehagens gegenüber Leuten, die nach Erhalt von Commit-Rechten verschwinden, verlangsamte sich das Hinzufügen neuer Personen über einige Jahre
Kurz gesagt bedeutet das: Direkt nach dem Uni-Abschluss Postgres-Commit-Rechte zu bekommen, ist schwierig
Interessant, aber schwer zu erhebende Daten wären, in welchem Alter Menschen Postgres-Committer werden
Es würde mich nicht überraschen, wenn das durchschnittliche Alter beim Erhalt von Commit-Rechten eher bei 45 läge
Viele Beitragende kommen erst nach Arbeit an anderen Systemen zu Postgres, oder die Art, Patches an Mailinglisten zu schicken, wirkt einschüchternd, sodass sie Beiträge erst in Betracht ziehen, nachdem sie bereits eine gewisse Berufserfahrung gesammelt haben
Die Geschichte seines ersten Commits ist großartig
Beim Testen des SQL-Verhaltens in Materialize wollte er prüfen, ob die beiden Systeme interval-Funktionen gleich behandeln, und probierte gewissenhaft Dinge wie
select interval '0.5 months 2147483647 days';ausMan kann es selbst auf dbfiddle ausprobieren: https://www.db-fiddle.com/f/ijT76fsmL99bHvXxhAtf7j/0
Postgres gab statt eines Fehlers den falschen Wert
{"days":-2147483634}zurück; warum, kann man hier nachlesen: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...Also wurde es naheliegenderweise in Postgres behoben, und dadurch wird es ab Version 15 korrekt behandelt: https://www.db-fiddle.com/f/i3KikCb72AN1EZpywErZvr/1
Ich mag Postgres so sehr, dass ich sogar ein PG-Tattoo habe, aber beide Wege zum Beitragen sind nicht leicht
Selbst wenn man in der Freizeit als beliebiger Nutzer beitragen möchte, gibt es nicht viele Tickets im Stil von „good first issue“, und ohne zumindest ein wenig Kontext und historische Gründe zu mehreren Teilen der PG-Architektur zu kennen, ist der Einstieg schwierig
Auch ein Patch-Review von Leuten wie Tom oder Andres kann einschüchternd sein
Der Weg, als Entwickler bei einem kostenpflichtigen PG-Unternehmen wie EDB, PG Pros oder Crunchy einzusteigen, ist ebenfalls eher ein Henne-Ei-Problem
Ohne frühere PG-Hacking-Erfahrung ist es schwierig, als Junior eingestellt zu werden, aber der Weg, genau diese Erfahrung zu sammeln, ist ebenfalls nicht einfach
Wenn nicht bei meinem jetzigen Unternehmen, würde ich gern irgendwo arbeiten, wo an PG gearbeitet wird, aber es gibt nicht viele realistische Einstiegswege
Für die 10 zuletzt ernannten Committer habe ich ein paar git-Befehle wie die folgenden verwendet, um den Zeitpunkt zu vergleichen, an dem ihr Name erstmals in einer Commit-Message auftauchte, und den Zeitpunkt ihres ersten Commits als Committer
Die durchschnittliche Beteiligungsdauer lag, wenn man nur Monat/Jahr vergleicht, bei etwa 8,9 Jahren, und selbst der kürzeste Fall lag bei etwa 6,5 Jahren
Eine bessere Analyse wäre möglich, aber das Ziel war, ein grobes Gefühl dafür zu bekommen
git log --grep 'Name' --format=%cs | sort | head -1git log --author 'Name' --format=%cs | sort | head -1Damals war es für 22-Jährige vielleicht zugänglicher, und man konnte womöglich größere Teile überblicken
Außerdem war C damals die Standardsprache, während junge Entwickler heute wahrscheinlich eher in Rust programmieren als in C
Ich wusste überhaupt nicht, dass es eine Häufung von Leuten gab, die unter 22 Commit-Rechte erhielten
Ich bin ein neuer Contributor, der vor fünf Monaten angefangen hat, zu Postgres beizutragen, und werde Ende dieses Monats 27.
Ich habe noch nicht viele wertvolle Beiträge geleistet, aber es gibt ein paar Commits, und künftig möchte ich das Bauen von Postgres-Erweiterungen mit Meson einfacher machen und, wenn möglich, auch die autotools-Builds schnell loswerden.
Man könnte mich bald auch in den Repositories von pgbouncer oder pgvector sehen.
Der Anlass, überhaupt beizutragen, war, dass ich von der Software-Consulting-Firma, bei der ich drei Jahre gearbeitet hatte, genug hatte.
Eigentlich wollte ich immer jemand aus dem Bereich Open-Source-Systemsoftware sein und fand bei Micron eine Stelle für Arbeit an einer Open-Source-Storage-Engine.
Ehrlich gesagt hatte ich Glück, aber die Stellenausschreibung wirkte, als sei sie für mich geschrieben worden, also bewarb ich mich und arbeitete 2,5 Jahre mit Freude an diesem Projekt.
Leider entließ Micron Ende Februar das gesamte Team; danach wurde mir Arbeit an C/C++-Treibern bei MongoDB angeboten, das Angebot aber wieder zurückgezogen.
Danach begann ich, mich stärker auf mein Netzwerk zu stützen, und fragte jemanden aus #mesonbuild auf Libera.Chat/Matrix, der an Postgres arbeitete, ob es Postgres-bezogene Stellen gebe, die zu meinem Hintergrund passten.
Er sagte mir, dass Neon einstelle, und ich bewarb mich beim Storage-Engine-Team; im ersten Interview kam die Person, die später mein Manager werden sollte, jedoch zu dem Schluss, dass ich besser in das neu aufgebaute Postgres-Team passen würde, also in das Team, das zu Upstream-Postgres beiträgt.
Ich bin Neon sehr dankbar, dass sie mir diese Chance gegeben haben.
Das Thema dieses Artikels ist interessant, weil es gerade erst in Gesprächen mit anderen jungen Postgres-Contributoren auf der PGConf NYC aufgekommen war.
Selbst kleine Patches lassen sich nur schwer begutachten, und je bekannter ein Name in der Community ist, desto eher scheint man Reviews zu bekommen – ein zirkuläres Problem.
Auch die Struktur der Postgres-Mailinglisten ist nicht gut: Man muss den Feuerwehrschlauch namens pgsql-hackers direkt trinken, während die LKML in mehrere Subsysteme aufgeteilt ist.
Moderne Code-Forges bieten den Wert, bestimmte Tags von PRs/Issues abonnieren zu können; in pgsql-hackers gibt es derzeit aber keine solche Möglichkeit.
Auch das Hinzufügen eines Eintrags zum commitfest ist etwas umständlich; um die komplette Postgres-CI zu durchlaufen, muss man ihn ins commitfest aufnehmen, und selbst danach muss man entweder selbst nachsehen oder hoffen, dass ein Committer einen auf CI-Fehler hinweist.
Bugreports gehen ebenfalls an die Mailingliste pgsql-bugs, und Postgres hat kein Gegenstück wie Linux bugzilla.
Patches werden als E-Mail-Anhänge verschickt und sind nicht einmal zwingend im git-format-patch-Format, während die LKML dem Anschein nach ausschließlich git-send-email verwendet.
Insgesamt scheinen die Werkzeuge der Postgres-Contributor-Community am besten zu Leuten zu passen, die seit über 15 Jahren tief darin verwurzelt sind.
Ich möchte daraus keinen „Lasst uns GitHub/GitLab benutzen“-Beitrag machen; im Gegenteil, ich halte E-Mail für Patch-Diskussionen für überlegen, aber die Werkzeuge rund um die Mailinglisten könnten verbessert werden.
Alles ist viel zu stark getrennt, und SourceHut hat meiner Meinung nach ziemlich gute Arbeit dabei geleistet, mailinglistenbasierte Entwicklung für alltägliche Contributor zugänglicher zu machen.
Issues, Mailinglisten, CI/CD und Repository sind dort alle miteinander verbunden und nicht wie derzeit bei Postgres auf separate Dienste verteilt.
Dieser Kommentar könnte irgendwann selbst ein eigener Blogbeitrag werden, aber ich höre hier auf.
Wenn jemand neu mit Postgres-Beiträgen angefangen hat, könnte ich meine Erfahrungen teilen; man kann mir unter tristan neon.tech oder tristan partin.io eine E-Mail schreiben.
Ein anderer Postgres-Contributor meinte außerdem, dass ein monatliches Treffen von Nicht-Committer-Contributoren nützlich sein könnte, bei dem man über Patches spricht, an denen man gerade arbeitet oder die man veröffentlicht hat, und Peer-Reviews bekommt.
Tristan könnte wohl ein Online-Treffen leiten.
Melanie Plageman hatte ebenfalls Interesse an so einer Idee, und wir hatten kurz über verschiedene Formen von Office Hours gesprochen.
Daraus könnte ein guter Beitrag werden, und es wirkt wie ein Bereich, in dem die Postgres-Community organisatorisch und prozessual vergleichsweise leicht Verbesserungen erzielen könnte.
Beim Punkt „Namensbekanntheit“ bin ich allerdings weniger sicher, und am anderen Ende scheint es ebenfalls eine starke Abwanderung zu geben.
Dass sich pgsql-hackers wie ein Feuerwehrschlauch anfühlt, stimmt, und ich denke, das ist in den letzten Jahren deutlich schlimmer geworden.
Man kann CI im Repository aktivieren, ohne etwas ins commitfest aufzunehmen: https://github.com/postgres/postgres/blob/master/src/tools/c...
Das ist dieselbe CI, die auch für commitfest-Einträge läuft.
Dass Bugreports an eine Mailingliste gehen, hasse ich wirklich, und ich übersehe sie auch ständig.
Ich halte das Kernel-bugzilla zwar ebenfalls für ziemlich nutzlos, aber es wäre nicht schwer, es besser zu machen.
Auch die Patch-Verarbeitung im LKML-Stil halte ich nicht für gut; insbesondere entsteht bei jeder Überarbeitung eines Patchsets ein neuer Thread, was die Nachverfolgung nicht gerade sehr einfach macht.
Selbst nach etwa 15 Jahren Mitarbeit an der Entwicklung würde ich nicht sagen, dass die aktuellen Werkzeuge besonders gut funktionieren.
Der Entwicklungsprozess hat sich im Laufe der Zeit zwar bis zu einem gewissen Grad weiterentwickelt, aber nicht bis zu dem nötigen Niveau.
Eine Community mit so vielen Graubärten wie die PG-Community zu verändern, erfordert viel Aufwand und ist nicht unmöglich, aber auch nicht leicht.
Persönlich verabscheue ich es stark, GitHub oder GitLab für komplexe Arbeiten zu nutzen, aber ich denke, wir sollten PRs/MRs über eines von beiden akzeptieren, um es neuen Contributoren leichter zu machen.
Das ist allerdings keine Entscheidung, die nur bei mir liegt.
Ich glaube, es gäbe kaum mehr als zwei oder drei Leute, die der Ansicht widersprechen würden, dass E-Mail für Patch-Diskussionen überlegen ist, die umgebenden Werkzeuge aber verbessert werden sollten.
Das Problem ist, dass viele ihre Zeit lieber ins Hacken an Postgres stecken als in Werkzeuge oder Integrationen für den Entwicklungsprozess.
Ich habe mit Hilfe von pgrx ein wenig mit Postgres gearbeitet und kann es als Plattform zum Aufbau von Datenlösungen empfehlen.
Der CMU-Kanal war ebenfalls eine gute Ressource: https://www.youtube.com/@CMUDatabaseGroup
Wenn man zum Beispiel einen neuen Table Access Method-Handler schreiben möchte, gibt es im Kern-pg-sys-SDK zwar Bindings zu TableAM, aber keine Dokumentation oder Beispiele dazu, wie man sie in Rust verwendet.
Ich beobachte, dass die meisten Leute, die heutzutage in die IT kommen, nur aufs Geld aus sind und es kaum noch wirklich leidenschaftliche Menschen gibt.
Das ist sehr traurig, und ich habe das Gefühl, dass viele Open-Source-Projekte deshalb zugrunde gehen.
Es läuft auf „von Stack Overflow kopieren und einfügen und dafür Gehalt bekommen“ hinaus, ohne etwas zurückzugeben oder zu helfen.
Ich will nicht sagen, dass alle so sind, aber nach meiner nahen Beobachtung und Gesprächen in mehreren Unternehmen lag das Verhältnis ungefähr bei 19:1.
Nebenbei: Ich arbeite täglich für zwei Unternehmen, weil ich Arbeit im Vergleich zum üblichen Maßstab viel zu schnell erledige und dann oft Zeit verschwende, während ich auf Meetings warte.
Ich habe auch viele Nebenjobs gemacht, um an interessanten Dingen zu arbeiten, und oft sogar unbezahlt, nur um neue Hardware auszuprobieren oder zu experimentieren.
Erfindungsabtretungsklauseln und Regelungen zu externen Tätigkeiten in Verträgen erhöhen die Hürde für Beiträge.
Ich stimme zu, dass Postgres keine Schwierigkeiten hat, neue Nutzer anzuziehen.
Auch ich nutze Postgres für mehrere Self-Hosting-Apps.
Bei PHP-Anwendungen bleibe ich allerdings bei MariaDB, wenn es die Standarddatenbank oder die einzige unterstützte Datenbank ist.
Zusammengefasst scheint es darum zu gehen, dass die Beitragendenbasis von PostgreSQL altert und Neon statt bestehender Committer Junioren einstellt und ausbildet, um die Entwicklerbasis zu verbreitern.
Als Programmierer ohne C/C++-Erfahrung, aber mit Interesse daran, fände ich eine Videoserie, die den Code ausführlich erklärt, wirklich hilfreich, um mit Beiträgen anzufangen.