If you are an application developer and you build on PostgreSQL, then maybe you have looked into where PostgreSQL comes from, who develops it, and where you can get professional help if needed.

Now, if you are a PostgreSQL developer (hi!), do you know what you are building on, where those things come from, who develops them, and where you get get professional help if needed?

Consider the dependency diagram of the internet:

PostgreSQL is perhaps one of the bigger boxes in the middle. But what are the shapes of the boxes below it?

Some are okay: Well-known projects with robust communities and ecosystems, such as Perl, Python, ICU, LLVM, systemd; those are big boxes. There is also OpenSSL, which in a well-publicized case was at one point one of those thin boxes, but that’s been rectified. There are lz4 and zstd, somewhat new arrivals in the dependencies of PostgreSQL, which appear to have active communities in their respective GitHub projects. There is also zlib, which is in maintaince mode but still putting out regular releases. This is all fine.

There is some stuff in the murky middle that I’m too lazy to look into. Who maintains libkrb5 and libldap and libpam these days? I guess these libraries are probably used widely enough that someone will care, and maybe at the end of the day with a support contract someone like Red Hat will be on the hook.

But there are also the rather thin sticks propping up PostgreSQL (and many other things):

  • The entire documentation toolchain (docbook-xml, docbook-xsl, libxml, libxslt, xsltproc) is in low to no maintenance mode. I discussed this in more detail in my presentation at FOSDEM 2021.

  • GNU Gettext is being maintained, but just barely. I would love some action there. Here is a feature request, for example. How can we help? I will talk about this in my presentation at FOSDEM 2023.

  • The TAP tests in PostgreSQL rely on the Perl module IPC::Run, which by the way is explicitly looking for a new maintainer!

  • Autoconf is without consistent maintenance now. Here is a great writeup. Of course, we are in the process of replacing this by Meson. Meson maintenance is very active. For now.

  • The ossp-uuid library has been unmaintained for over ten years. We support a variety of uuid libraries now, so it’s gotten a bit complicated.

The two possible points are:

Projects like PostgreSQL have money and professional contributors. Some projects that PostgreSQL relies on do not. Just as we sometimes ask users of PostgreSQL to contribute money or developer time, projects like PostgreSQL should, arguably, also contribute money or developer time to what it uses. It’s not straightforward to just pass through donations (for legal reasons), but it’s something to think about in principle.

The second point is a bit harder, because you can’t contribute if there is no maintainer, that is, someone to receive the contributions. Becoming a new maintainer is a larger commitment. Would it make sense for, say, a PostgreSQL company to hire or sponsor someone to become the new IPC::Run maintainer or the new DocBook XSL maintainer (or previously the new Autoconf maintainer)? How would you organize that and what would the economic model be? Not clear.