Apr 11, 2024
Posted by
Ryan Booz
The State of PostgreSQL survey was recently closed with overwhelming community response and excitement. One observation that stands out in the results, particularly with the solid growth of PostgreSQL adoption, is how few users contribute to the project and community—only 12 % of users with 15 or fewer years of experience have contributed at least once. Add to that the multiple comments each year about how difficult and (seemingly) underappreciated some contributions are, and it feels like this topic should be at the top of our discussion list.
To be clear, it's evident that the community is engaged, excited, and supportive. But at both ends of the "how long have you been using PostgreSQL" spectrum, there seems to be agreement that more involvement would be good and that making it easier for users to get involved should be a priority.
Let's take a closer look.
This year's survey had nearly 1,000 respondents, more than twice as many as last year. While there was an increase in users that have contributed to PostgreSQL in some way (17 % vs. 15 % in 2021), it strikes me that this nearly mirrors the 80/20 rule, otherwise known as the Pareto Principle. Taken at face value, it appears that approximately 17 % of the community is responsible for creating most of the value that the community receives.
But that's only part of the story.
As we said above, it's evident that code contribution and figuring out ways to increase community involvement in the project is something many people think about. What surprised me even more is how years of PostgreSQL experience and level of project contribution influenced user comments in this area.
When a user has between 0-5 years of experience using PostgreSQL, the focus around community contribution is primarily on better tooling and examples for helping to build the community, things that are often non-code in nature:
Once users have 6-15 years of experience, the focus begins to change. It appears that this group of users, having invested a significant amount of time using PostgreSQL, wants a better view of the project roadmap with a common theme around making contributions more straightforward and accessible.
And finally, once a user has invested at least 15 years into learning and using PostgreSQL, it becomes more evident that the project can only be sustained through more people getting involved. There's a genuine sense that growing the base of contributors is better for everyone.
The arc of this journey isn't surprising. The newer someone is to the project, the more they're looking for non-technical improvements that would help them succeed. Users with solid experience begin to look for ways to contribute but still find it challenging to do that. By the time someone has been involved with PostgreSQL for 15 years, they know that the project's success is dependent on bringing in new contributors and that there are still some significant barriers for most users.
Do any of these comments resonate with you? When you look at the comments from your peer group (based on your years of experience with PostgreSQL), do you have similar thoughts about supporting the project and community? Does it feel like now might be the right time to start finding ways that you could contribute to the project or community?
Me too! So let's talk about some ways we could all take the next step.
As it turns out, we had a similar discussion last year based on the survey feedback. Aleksander Alekseev (Timescaler and PostgreSQL contributor) wrote a 💯 article on how to contribute to PostgreSQL (or any open-source project). I'd encourage you to read the article in full, but Aleksander made a few key points last year, which I think are worth repeating in light of the 2022 survey responses.
Regardless of the total PostgreSQL experience someone has, it seems clear that community members want to contribute more and see the overall community experience continue to improve. By taking the next step in one of the areas mentioned in the survey, you need to know your end goal because it will influence both the experience you need and the benefit you and others will gain.
Aleksander identified a few principal reasons people often contribute to a project like PostgreSQL:
When I look at the list of comments that users left, I see many areas that almost anyone could contribute to, both coding and non-coding. Knowing how you can effectively contribute and why you're motivated to do so will go a long way in helping you identify just the right place to start.
What I noticed most in the comments users provided about improving the community is that most of the need seems to be in the non-code area. While some comments are directly related to code contributions, many more deal with educational content, improving the documentation with better examples, and providing more options for getting community help.
Stated plainly, PostgreSQL and every other open-source project succeed when there are technical contributions and a host of supporters.
Improving the documentation is mentioned often. Providing better examples around mid-level features shows up a few times. Advanced topics like replication and partitioning are common areas for people to seek help.
These helpful resources could happen within the official documentation (especially improved query examples!) or through personal blogs, conference talks (check out the upcoming events for call for papers and submit your talk proposal), or videos.
Speaking of conferences and meetups, we can all acknowledge that the last two years have transformed our expectations around events and community. There are so many more opportunities for everyone that wants to contribute, whether locally or across the globe. For instance, although PGConf NYC is in New York City and coordinated by the North American PostgreSQL group, there is some help and collaboration from organizers and volunteers in Europe.
There are always user groups that you can attend or offer to present at, most of which still have a virtual option available! You could get involved by offering to translate documentation or the Code of Conduct. And finally, you can join the PostgreSQL Slack, Discord, or novice email list to offer your support and expertise to other users within the community. There are so many great opportunities to help build PostgreSQL at many levels!
To modify the official documentation, you'll have to check out the main repository and learn about writing in DocBook (XML) format. The one caveat for contributing to the official documentation is that it is part of the main Git repository and subject to the same process (discussed below) as regular source contributions.
While this is a little more effort than a typical pull request workflow, submitting documentation contributions can be an excellent way to start with small patches so you can become familiar with the workflow.
Speaking of workflow and patches in the main repository (both code and documentation), let's briefly discuss how you can get started.
Maybe you look at the comments above, particularly if you've had 6-10 years of PostgreSQL experience, and you're beginning to feel like now is the time to start contributing to the core code project.
Despite clear attempts to clarify the process by the team of users contributing to core PostgreSQL development, I see from these comments that many users still don't understand how code contribution works and what a Commitfest entails. (Hint, hint: I'm guessing that a clear, organized blog, conference talk, or YouTube video on the process would be an instant hit!)
A Commitfest is a month-long iteration during which new patches are accepted. When a Commitfest is in progress, contributors won’t accept new patches, instead adding them to the following event. There are five Commitfests every year: January, March, July, September, and November.
At a high level, to contribute a patch to the PostgreSQL project, you'll need to join the pgsql-hackers@ mailing list and get familiar with the Commitfest tracking website. Additionally, the Commitfest Wiki page provides a checklist of how the process works from beginning to end and what the Commitfest manager is responsible for doing.
Once you're engaged on the mailing list and understand when the next Commitfest will start, you can work through the pgsql-hackers list to submit the patch for inclusion in the next Commitfest. After the patch is accepted and added to a Commitfest, the real work begins—and all feedback happens within the mailing list.
At the start of a Commitfest, proposed patches typically have the following lifecycle:
Knowing the potential flow of a patch through the Commitfest can help you understand a particular focus for a pending update or upcoming major release. Over the last few major releases, there might be many smaller changes (some of which have a huge impact), but there tend to be larger themes of functionality that define a specific release of PostgreSQL. I point this out because even helping to clarify or blog about upcoming topics in PostgreSQL releases can be tremendously helpful to the overall community.
In short, whether you can contribute patches or not, learning to follow the Commitfest process and proposed patches is a great way to get more connected to the project.
The State of PostgreSQL 2022 survey results once again provided valuable insights into how the community uses PostgreSQL, community strengths, and some areas that many think could improve. One of those areas continues to be around community support and contributions.
Hopefully, just seeing some of the comments that community members provided regarding community and growth will encourage more of us to jump in with contributions. PostgreSQL will get better, and the community will get stronger.
Now that we’ve given you a taste of our survey results, are you curious to learn more about the PostgreSQL community? If you’d like to know more insights about the State of PostgreSQL 2022, including why respondents chose PostgreSQL, their opinion on industry events, and what information sources they would recommend to friends and colleagues, don’t miss our complete report. Click here to read the report and learn firsthand what the State of PostgreSQL is in 2022.