To my delight the PgDay Paris 2024 organizers decided to pick my lighting talk despite the ominous title. I got 5 minutes to share with the audience how whether a project thrives or fails depends entirely on the time friends and strangers on the internet are willing to invest in it - as is the case with Open Source Software - and that I thing the Postgres project might not be ultimately set up for this.
Below is the script (somewhat).
The State of Open Source Software
- 90% of companies use open source (from an OpenUK report, but honestly I think this number is higher)
- FOSS constitutes 70-90% of any given piece of modern software solutions (Linux Foundation)
- 89% of codebases contain open source more than 4 years out of date (2024 Open Source Security and Risk Analysis Report, Synopsys)
- 84% of code bases contain at least one known vulnerability
- 44% of maintainers are solo maintainers (2023 Tidelift State of the Open Source Maintainer report)
- 58% have at least considered quitting the project
- 22% have actually quit maintaining a project
In his PGConf EU keynote “The next 20 years of PostgreSQL” Simon Riggs had us all celebrate Postgres’ recent milestone of being the Most Popular Database. But just because something is popular, doesn't mean it's not at risk. (I illustrated this point on stage with pictures of bands breaking up).
Money makes the world go around
2023 was a reminder that corporate budgets and priorities are fickle.
About 12 Million Dollar passed from companies directly to FOSS projects in 2023. While (substantially) beneficial for maintainers, it's not proving to be a sustainable single model for the ecosystem. Divide 12M over the entire dependency graph and all the nested libraries we rely upon, and compare that to the salaries you all - we all - want to earn, and you’ll realize the math is off.
Open source is still being funded for only a small portion of its value. While all companies rely on open source, little funding is trickling down, and even less of that is making it to maintainers. Most maintainers are unable to financially support their work unless companies choose to hire them for it.
Countering the regularly cited theory that most maintainers prefer to work on open source as an unpaid hobby because that makes them more hardcore or whatever, the aforementioned Tidelift survey found that 77% of the maintainers who are not paid would prefer to get paid.
People make the world go around too
Any open source project is reliant on people’s continuing work, and people joining the project so that all the work can get done to keep the project relevant and growing in step with industry’s changing demands.
The Postgres project is set up so that it works for a very homogenous group, and does not seem motivated to change it because it works for them and for the right now - and being proclaimed the most popular database certainly provides no incentive for change. But not investing in growing your group will end up hurting the project
Of course I don’t know how folks self-identify so I’m sorry for assuming, and also this list is based on state at the beginning of March, but:
- Postgres Core: 7/7 white dudes, no APAC representation, 7/3 work at EDB)
- Major Contributors: 41/39 dudes
- Contributors: 94/91 dudes
Core team members are appointed by existing core team members, and people tend to "hire" people who look like them...
With 5 emeritus hackers, and now I don’t know when this role was introduced, but it reads to me as if you’re a hacker for life somewhat and so if we don’t add to that group of Core and Major, nothing’s going to change much in terms of diversity.
Maintainer burnout is a real thing, and lack of succession planning but also lack of defined roles someone new can fill is a concern. What that list of Core; Major and Contributor sadly doesn’t take into account contributions other than code.
Hell, that existing list doesn’t even have a definition beyond a few bullet points. And for a project that values openness as much as the Postgres project, it’s pretty darn unclear how one can turn their aspirations into reality and climb the contributors ladder.
Preparing for this talk I rabbit-holed into a post by Robert Haas (courtesy of Peter Geoghegan), who served of the Contributor team for a while - the group of people who make decisions on who is considered a Major Contributor for example.
People who make a particularly large number of the kinds of contributions that get credited in commit messages tend to (eventually) get listed as a "Contributor" or "Major Contributor," but it's not very clear what amount of such code contributions ought to entitle someone to such a listing. There is no standard agreed even among the four people on the Contributors team as to what should qualify.
Out loud, Robert questions whether work on ecosystem projects (extensions like PostGIS) should be considered in deciding contributor status. And regarding the not-code contributions:
It is not clear to what extent these ought to be acknowledged as contributions to PostgreSQL and to what extent they ought to be regarded as contributions to something else.
But what can I do you ask??
Employing contributors to contribute does seem like a good model. Let’s diversify that pool to not be reliant on a handful of companies.
Definitely watch "Cracking the Code to Executive Support", Addie Girouard’s FOSDEM talk, to learn how you can get your employer to care about supporting Open Source Software, so that you can contribute to making Postgres a healthier project.
Also, by seriously reconsidering how you define "Mailing List Culture". From the wiki:
- our community is known for its aggressive and technical discussion style.
- Please keep in mind that as a new contributor, you are encountering a new culture.
- you must take some time to get acquainted
Reads to me like we're putting all the emotional labor with the newcomer. Way to temper their enthusiasm.
What's next?
I really care about the Postgres project, and would like it to be better (equipped to stand the test of time / priorities). One initiative that seems promising is the PostgreSQL Europe Diversity Task Force that Karen Jex started as her first action after being selected member of the PostgreSQL Europe Board. I look forward to contributing to that.
Top comments (3)
This is a very interesting analysis, especially the fact that reaching the top of popularity could make us blind to real risks. In fact, if we look at the "awards", the popularity is covered in several categories: most desired, most admired, most popular and most loved. By looking at those categories, my understanding is that a software can't get there only with good code. There is a lot about the work of the entire community to get there. So there is some work to do in order to recognize contributions and keep a healthy community.
Some of this risk analysis has been done before, but in a more aggressive way not getting anywhere, on the contrary. Now, you are doing it in a constructive way, and I know that some code contributors are also worried about this. I hope this time the call will be received in a better way.
Very good article Floor and great delivery during the Lightning Talks at PgDay Paris. I really enjoyed it.
Floor raises a crucial question about the sustainability of the Postgres project. While celebrating its popularity, we must address the homogenous core team and unclear contribution process. Encouraging a more diverse and inclusive contributor pool is essential for Postgres's future.
Cheers !
Intresting post
Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more