PostgreSQL, a community project

September 29, 2020

PostgreSQL 13 was released last week. As a PostgreSQL developer, of course I monitor the news and social media on days like this to see what the public thinks about our release and maybe which features get discussed most. The latter is always surprising.

What I noticed particularly this year was that most of the discussion appeared to be not so much about the features and the technology direction, but praise about the PostgreSQL community, the PostgreSQL project, and its contributors, about how it is rare as a successful community-led project. This is nice to hear, we work hard on that. But then why, those discussions ask, are not more projects like this? Why are not more database projects like this?

One of the problems is that getting to this state is not easy.

Consider three open-source governance models:

  1. run by one individual (or maybe two, but not many)
  2. ruled by one company
  3. community-led

Now think about how an open-source project gets started. Clearly, most projects start out as #1 and stay there forever. Some projects start out directly as #2. Some actually start as #1 but first appear to the public as #2. Very few projects start as #3. Think about how that would have to happen in practice. You’d need a group of say four to ten people, remember, not all employed by the same firm, to start on something from scratch. That seems difficult. The situations where this happens most often is when a university starts a project and then abandons it, or similarly if a non-profit or research lab initiates the effort. Many projects of BSD and GNU origin started like that, as well as Postgres. (There are of course exceptions. For example, the KDE project, as far as I can tell, grew from nothing into a community-led project. I am in awe of that.)

Therefore: A community-led project must already start out as a community project.

Can you transition between these modes? Clearly a transition from #1 to #2 is plausible and common. Transitioning from #2 to #3 is possible but happens mostly when the company has failed commercially, and so it is rarely a path of success. A transition from #1 to #3 is possible, but it’s hard and usually requires an exceptional effort by the project founder (or, alternatively, the project founder leaves the project). If you’re in mode #1, going to mode #2 is often more appealing. Note, that it is very unlikely that a project transitions out of mode #3 into one of the other modes. One company would have to buy the entire community, which seems difficult. Or everybody but one contributor leaves the community, which would be a problem. Once you’re in #3, you tend to stay there, until perhaps the project fades away or collapses or splits because of disagreements in the community. So moving to mode #3 too early is also a problem if you’re really hoping to end up in mode #2 instead.

Therefore: Transitioning both to and away from a community-led project is difficult and often not successful.

So that’s why PostgreSQL is a community-led project and there aren’t many others, particularly among database systems.

There is of course the next question, which is how you then successfully maintain and grow a community once you have it. Maybe for another post.

Share this

Relevant Blogs

Random Data

This post continues from my report on Random Numbers. I have begun working on a random data generator so I want to run some tests to see whether different random...
December 03, 2020

More Blogs

Full-text search since PostgreSQL 8.3

Welcome to the third – and last – part of this blog series, exploring how the PostgreSQL performance evolved over the years. The first part looked at OLTP workloads, represented...
November 05, 2020

Números aleatorios

He estado trabajando gradualmente en el desarrollo desde cero de herramientas para probar el rendimiento de los sistemas de bases de datos de código abierto. Uno de los componentes de...
November 04, 2020