Lessons on attracting new contributors from 30 years of PostgreSQL

The PostgreSQL project has been chugging along for decades; in that time, it has become a thriving open-source project, and its participants have learned a thing or two about what works in attracting new contributors. At FOSDEM 2026, PostgreSQL contributor Claire Giordano shared some of the lessons learned and where the project is still struggling. The lessons might be of interest to others who are thinking about how their own projects can evolve.

Giordano said that her first open-source project was while working at Sun Microsystems; she worked on the effort to release Solaris as open-source software, "which was quite a wild ride". From there, she joined Citus Data, which provided an extension for PostgreSQL to add distributed-database features; that company was acquired by Microsoft in 2019. She said she now heads Microsoft's open-source community initiatives around PostgreSQL and that the talk is based on her upstream work with that project; as one might expect, though, she noted that the talk would represent her views and not those of her employer.

PostgreSQL: the next generation

The challenge that she wanted to talk about, "which might keep some of you awake at night", is how to attract the next generation of open-source developers. If a project is successful enough to stick around, how does it ensure there are people to keep it afloat when the older crop of contributors starts to retire? When Giordano refers to contributors, she means all of them—not only those who contribute code. Even though she started off her career as a developer many years ago, "I have never committed or contributed a single lick of code to this project", but she works on PostgreSQL in other ways.

PostgreSQL is one of the projects that has, indeed, been successful and long-lived enough that some of its contributors may be pondering retirement soon. Giordano noted that PostgreSQL, as a technology, had been around for about 40 years. It has been an open-source project for nearly 30 years: its first open-source release was on July 8, 1996. Since that release, the number of PostgreSQL committers has grown from five to 31 people. The project has many more contributors, but the committers are those who can actually push code directly to the project's Git repository.

There is a new major version of PostgreSQL released each year. Version 18 was released in September 2025; it contained more than 3,000 commits, nearly 4,000 files changed, and more than 410,000 lines of code changed by 279 people. During that cycle, 83 of the people were first-time contributors. Those statistics only consider code and documentation, however: Giordano estimated that there were more than 360 people who contributed "in some way, code or beyond code" in 2025.

Contributor funnel

PostgreSQL's contributor community is global. Giordano observed that two of the project's 31 committers were based in New Zealand, which meant that the country had more PostgreSQL committers per capita than any other country. But what types of contributors does the project have, and how do they become involved? She noted that the project does not formally track contributors, but she had created a "funnel", shown below, that visualized how a person might progress from casual contributor to major contributor or even committer.

Every contributor has their own motivations, and they may not be altruistic. She hearkened back to a FOSDEM 2020 talk by James Bottomley, "The Selfish Contributor Explained", which posited that many people contribute for selfish reasons. But, she said with a reference to the classic novel Anna Karenina, every contributor is selfish in their own way.

In addition to her day job, Giordano is also the host of a monthly podcast called "Talking Postgres", where she talks to developers who work on or with PostgreSQL. Through that she has learned that each contributor has a different "origin story"; some start out working on PostgreSQL simply because it interests them, others begin contributing because they need the database for other projects, and of course some contributors are hired to do the work. She said that it is especially interesting to talk to people who are new to PostgreSQL and to think about whether the project is growing in the right way.

The soul

To frame the next section of the talk, she had taken inspiration from a book by Tracy Kidder, The Soul of a New Machine. The book, published in 1981, is a nonfiction account of the development of the Data General Eclipse MV/8000 minicomputer. In reference to the book, Giordano said she had structured the next section of the talk into three buckets: the soul, the machine, and the fuel:

For the soul, we'll be looking at the human ecosystem, the people, the community, and the culture. For the machine it's more about developer workflows, the processes, the tooling that we use, and the governance. Then for the fuel, it's about the economics and how people get paid. [...]

Let's start with the soul, with the human bits, because at the end of the day, without people on these projects, none of it would exist.

She said she heard the phrase once, "come for the code, stay for the community". (The actual phrase, "came for the language, stayed for the community" was originally coined by Brett Cannon about Python.) She said that her first European PostgreSQL conference was notable because people made her feel like she really belonged, "which just, like, boggled my mind". The community has many meetups and conferences to build in-person, trust-based relationships that are important to the project.

Another thing that works for the community, Giordano said, is "just the joy of working with Postgres". She displayed a slide from Bruce Momjian's FOSDEM 2023 talk, "Building Open Source Teams", that described the fun of programming. Not only is programming fun, she said, but PostgreSQL in particular is fun to work on "because this database is so big and has so many different subsystems" that developers have choices about what kind of problems they work on. If a developer doesn't want to work on database backup, for example, they can work on other parts of the system. That's true for companies funding developers too; organizations can choose to fund the work that is important to their business.

The annual PGConf.dev developer's conference is also working well to feed the "soul" of the project, she said. It is now in its third year, and its organizers have been doing "a lot of experimentation with different formats and how to make it easier for new contributors to get involved with the project".

Another thing that is working well is PostgreSQL's recognized contributors policy, which is managed by the project's contributor's committee. It's the committee's job to figure out who to recognize on the contributor profiles page, which lists the project's core team, major contributors, and significant contributors. "Most people like being recognized for good work. And it feels good. And you're more likely to do more of the work that feels good."

But the project struggles in other areas, such as its committer pipeline. Fast-forward five to seven years, Giordano said, and it would not be surprising if some of the project's current maintainers stepped back or retired. Someone had recently joked that the new rule is "you cannot retire until you have nominated and fully trained your successor". That just might work.

One question that comes up regularly is: "do we accidentally overlook people for promotion?" Is it really a lack of people in the pipeline, or is the project failing to recognize and advocate for people to be "promoted"? She suggested there may be a "desert" in the middle of the path from new contributors to committer. Major contributors who have been working on the project for a long time may not be getting the mentoring they need to move up to committer level.

Welcome to the machine

With the soul covered, Giordano wanted to move on to the machine; "I'll start again with the positives because, you know, it's always good to start with the positives". One of the nice things about PostgreSQL is the predictable lifecycle that is easy to understand: "annual major releases, quarterly patch releases, and there's a CommitFest five times a year in July, September, November, January, and March". LWN covered the PostgreSQL CommitFest process in June 2024.

The CommitFest emphasizes regular review of patches that have been submitted to the project. Giordano cited PostgreSQL committer Tom Lane, who had said to her that patch review encourages people to read the code and not only the patch. That, in turn, helps contributors increase their knowledge of the entire system. "So it's not only improving the quality of the patches, but it's helping to skill up reviewers within the community." PostgreSQL's continuous-integration (CI) system has also seen "pretty dramatic improvements" in the past few years. She said she imagined it is much much nicer now to get automated testing on patches rather than worrying about breaking the build farm—especially for drive-by contributors.

The skill and dedication of the maintainers, she said, is also working in favor of the project:

In fact, as I talk to more junior developers, they tell me that one of the big magnets of joining the project and working on Postgres is the chance to get to work with some of these pretty amazing, brilliant, talented luminaries. Now I know. Every project has brilliant people, and we don't corner the market on that. But if you're a database person and you care about Postgres, it's pretty cool.

But it's not all positive. While the patch-review process may be useful, the project struggles due to lack of bandwidth to review patches. She used an air-traffic-control analogy, describing patches as planes circling an airport. "There's a lot of planes up there, and not that many are landing". That was a bit of hyperbole, since there were more than 3,000 commits that made it into the last release, but she said that it can feel that way when an author of a patch is waiting on patch-review feedback. "If you've submitted it and you haven't heard anything, I can imagine that can be very frustrating". Likewise, people who have a lot of reviews to do may feel pressured. "So this is definitely, I think, an area where we're struggling".

One possible answer to the review problem is having component committers. Currently the project's committers have commit access to the entire project; it may be that the project should consider trusting some contributors with commit access to specific subsystems. It has been discussed, Giordano said, and no one has felt comfortable enough to do it—yet. "There's pros and cons, but it's going to keep coming up. And who knows? Maybe someday there will be an attempt to experiment with it".

Intimidation

Like a number of older open-source projects, PostgreSQL has a strong mailing-list culture. That has its positives, such as the project's invaluable mail archive and the fact that people tend to be more thoughtful in email replies, but it has its drawbacks as well. In particular, it is "a little bit intimidating" for new contributors to ask a simple question when they know it's going to be archived forever. Newer contributors are more familiar, and comfortable with, tools like Slack, Discord, and other text-messaging applications.

To solve this, she said that Robert Haas started a program in 2024 for mentoring new developers in a Discord channel (link to invite). "If you want to be mentored in Postgres, you should definitely reach out to Robert and apply for one of the next cohorts". There are monthly hacking workshops as well.

PostgreSQL is written in C, which has come up as another possible barrier to entry for new developers. She said that she didn't know if C was still a requirement for computer-science degrees, though it was required when she got her degree. In fact, PostgreSQL has its own flavor of C, which "I have heard from some newer developers is a bit intimidating". Add that to the fact that the project's getting-started information is fragmented and out of date, she said, and it can be a problem for new people.

The topic of AI slop overwhelming maintainers was almost omnipresent at FOSDEM. This presentation was no exception; Giordano said that PostgreSQL has been seeing an increase in slop contributions over the last year, and it is creating a burden for its maintainers. In turn, it makes them reluctant to look at contributions from new people "because they don't know if it's real or if it's just AI slop". The prevalence of AI slop may well burn out maintainers and clog the machine that keeps PostgreSQL running.

The fuel

PostgreSQL is hot right now, which helps to fuel the fire for PostgreSQL development. It is in use by plenty of organizations, developers love it, students are learning it, and there are many jobs related to it. "So this commercial gravity, if you will, is attracting people to learn the technology and work on the project." It also inspires corporate funding for contributors to work on the project, which means that not only are the committers paid to work on PostgreSQL full time, but many other people are paid to work on the project part-time.

Where the project is struggling, however, is in the realm of "committer paranoia". This is a topic that Haas spoke about at PGConf.dev (slides) in 2025. Essentially, there is a lot of stress around submitting patches and accepting them. Committers are responsible for the patches they commit, whether they authored them or not. This responsibility extends beyond the immediate need to make sure that the patch works, etc., but fixing bugs and so forth years down the road. "If there is a problem, you're on the hook to get it fixed and get it fixed right away. Get it fixed yesterday."

She returned again to the theme of committers retiring; the project is talking about that problem, but it doesn't have it figured out yet.

tl;dr

So, Giordano asked as time had nearly elapsed, what are the takeaways from the talk? The good news is that "Postgres has already proven that we can evolve". The key thing is that the project has to keep evolving, and to embrace the needs of its future developers without compromising the needs of the present. That includes fixing the project's patch-review throughput, running experiments to ensure that the project is not discouraging as many people and is instead getting them more engaged with the project. "And hopefully then we can also avoid burnout amongst our own people".

She followed up by inviting people, if they had the skills (or were willing to build them) described during her talk, to consider becoming a PostgreSQL hacker. She closed with a slide thanking a number of individuals and all the hackers at the FOSDEM 2026 PostgreSQL developer meeting for their inspiration and reviews of her talk.

[Thanks to the Linux Foundation, LWN's travel sponsor, for funding my travel to Brussels to attend FOSDEM.]