Good afternoon everyone, hello, welcome to this talk by Clare Jordanna, who leads the Postgres
open source efforts at Microsoft.
Thank you.
Can everybody hear me okay in the back?
Show of hands?
Okay, if for some reason I start talking like this and you can't hear me anymore, somebody
wave to me and get my attention okay?
Because I flew all the way here and I want to make sure I get a good recording.
Thank you for joining me for lunch and to be part of this talk about building the next
generation of open source contributors.
My name obviously is Clare Jordanna and just so you know where I'm coming from, what
my background is, my very first open source project was actually at Sun Microsystems
where I worked in the kernel group and I led the effort to open source the Solaris operating
system which was quite a wild ride, maybe, maybe thank you.
And I had no idea what open source will how much fun and how rewarding it would be and
how it would change the course of my career.
A few years later, more than a few years later, more than 10 years later, I ended up joining
a small San Francisco based startup called site is data that had an open source extension
to postgres.
So that's when I first got involved in Postgres and then a few years after that, Microsoft
acquired site is data.
And so over the last seven years since I joined Microsoft, we've been building a team of
open source contributors to the Postgres upstream project and that's where I spend the
bulk of my time right now, leading our community efforts.
And this talk represents my views, not my employers, but based on my work on the upstream
open source project.
So that's some context.
And the talk is about a challenge that I suspect, some of you, maybe even many of you also
share and it might also keep you awake at night, which is how do you build that next
generation of open source contributors if you're successful enough to be around long enough
that people are going to start to move on or step back or retire, like, how do you make
sure you've got people ready to take the baton on that project?
Now, why are we talking about Postgres?
So first of all, show of hands, how many of you have worked with Postgres as a user or
a developer?
Okay, I love it.
That's awesome.
How many of you love Postgres?
Another show of hands?
Okay, that's also equally awesome.
For the camera, for the recording, please know there are a lot of people with our hands
raised in the audience.
So Postgres is on the present in the world and we're talking about it because for those
who are unfamiliar, it's a relational database, it's open source, it's reliable, it's robust,
used by millions of people.
We just heard a talk a little a few minutes ago about QGIS, well, Postgres is the day-to-base
that sits underneath PostGIS and so there's a lot of geospatial applications that run
on top of it and some of the cloud database services out there that are based on Postgres
or some of the fastest growing, managed services in the world and it's just got an amazing
community and I think that's the part.
I heard the phrase once, come for the code and stay for the community.
So it's not special, though, in terms of needing to make sure that the next generation
is there to take the baton.
So the reason we're talking about Postgres today is because our successes and our failures
and our experiments might be useful to people in other open source projects.
And so what we're going to do is talk about what's working as well as where we're still
struggling as a project.
So this isn't going to be a raw, raw cheerleader.
Here's everything that's wonderful.
We're going to look at both sides of the coins.
I also want to clarify that when I talk about contributors to Postgres, there are definitely
parts of this talk where I'm talking about hackers.
I'm talking about people who contribute to the code.
But there are other parts of the talk that are about people who contribute to the project
in other ways.
And I'm a good example of that.
I have never committed or contributed a single lick of code to this project, even though
I started off my life as a developer many, many, many years ago.
But I do contribute to the project in other ways.
And so we'll talk about both types of people because the project has a lot of different
aspects to it.
Okay, so why am I giving this talk?
I host this monthly podcast called Talking Postgres and curious how many of you have
heard of it by any chance.
Okay, so not as many hands this time, but I'm hoping to see more the next time I'm up here.
In the podcast, I talk to people who work with Postgres about why they do what they do
and sometimes how they got there, what are their origin stories.
And so the guests have been a mix of committars.
Committars is the Postgres term for maintainers on other open source projects.
Also had a lot of major contributors on the show, users of Postgres, some of the cloud
operators who manage those managed services.
Anyway, it's been a big mix and in those conversations, I started wondering about the
next generation and how do we build it?
So before we dive in to looking at the future, just a couple of quick things about the
past and the present.
First of all, this year is the 30th birthday for the Postgres open source project.
So I'm not going to ask you all to start singing the happy birthday song because that would
be a little bit awkward, especially because I can't hold a tune.
But it's a pretty big milestone.
The technology itself has been around for 40 years now, but the open source project began
30 years ago.
But over that 30-year time period, as you can see in this chart, the number of maintainers,
what we call committars on the project, has grown from 5 to 31 today.
Now these are just the maintainers, obviously there's a lot more people who contribute
to the project beyond that, which we'll look at in just a minute.
If we look at present day, the most recent release of Postgres came out last September,
and we ship an annual major release every year in that same timeframe, it's very predictable.
And in this release, there were over 3,000 commits.
There were almost 4,000 files changed, over 400,000 lines of code changed,
and 279 individual code or doc authors, who contributed at least one commit to the release.
So that gives you a feel for the scope of the project.
And of those 279 code authors, 83 of them contributed their first time change, which is kind of cool.
I mean, that's what 30 percent.
Now some of those are probably dried by contributors who just did this once,
and then they're going to go back to wherever they came from.
But still, gives you a sense of scope.
Now, when I tried to calculate how many people worked on the project and contributed in some way,
code or beyond code in 2025, the entire calendar year, the conclusion was more than 367.
But probably a lot more than 367.
So that's kind of the floor.
We had the 279 who contributed code, and then I looked at the people who were recognized as
significant contributors and major contributors.
And those people who were recognized are recognized for multiple years of work for sustained contribution to the project.
But beyond that, there are people who were, you could think of them as rising significant contributors.
They haven't yet been recognized, but they are doing a lot, and they probably did a lot last year.
So more than 367.
All right, and I just also want to let you know that this project is very global.
Now, this map is only a map of the 31 maintainers to the project, and it lets you know the countries that they live in.
But it actually mirrors what we see with the rest of the project.
There are people that contribute from so many countries, so many different places.
It really is a global project, and if you look in the bottom right hand corner,
you'll see that two of the maintainers are actually live in New Zealand.
So I sometimes joke that New Zealand has more postgres commuters per capita than any other country in the world.
And yeah, it's global.
And when I think about who the contributors are, obviously we have drive-by contributors.
I said that already.
I believe there are a hobbyists.
I don't know any.
I have never met any, but I'm sure they exist.
And in fact, when I was talking the other day to a room full of commuters,
many of them told me that they started off as hobbyists.
That's kind of how they got their start.
And there are people to who maybe work as consultants, but they spend 10% of their time,
or 20% of their time contributing to the project,
and then other people get paid to work on postgres full time.
And then quick view of a funnel.
We don't actually track a funnel for our contributors.
It doesn't exist.
I had to kind of create this and put it together.
And maybe we should measure it to figure out where the holes in our contributor funnel.
But obviously people first get interested.
They're drawn to the success of the project.
Maybe they want to scratch an inch.
They have a specific problem that needs to be fixed.
Or maybe they're just curious to learn more or bored for some reason.
And then they get activated.
They start lurking on the mailing list.
Maybe they start mailing and contributing.
Start doing a couple of patch reviews.
There are sometimes just last week in Prague.
There was an intro to Postgres hacking workshop.
I can see one of the instructors in the room holding a camera right now.
And it's pretty awesome that people teach these workshops.
And that's one way that people start to get engaged.
Maybe they go and attend office hours with some of the commuters and maintainers as well.
And then they started advancing through the system.
And eventually if they're in it for the long game,
they'll probably end up getting promoted to be a major contributor or a committer.
They'll start mentoring other people, giving lots of conference talks,
advocating, and more.
So that's just a quick feel for the funnel that we need to care about,
as we start to think about building the next generation of contributors.
How many of you have read the book Anna Karenina?
Okay, a few hands.
I love this book.
I took a Russian literature class in college.
And this was one of the required reading.
And it starts off with the line.
Happy families are all alike.
Every unhappy family is unhappy in its own way.
And for some reason that made me think actually about James Bottomley's talk
about the selfish contributor explained that he's given at Fossdom in the past.
And I don't think this is one of the takeaways I was supposed to take away from that talk.
But it did make me realize that you know,
people contribute to open source projects for all sorts of different reasons.
And the reasons are not the same, and they're not even altruistic.
They might be selfish.
I mean at the end of the day, those of us who get paid to work on Postgres,
we need to eat.
We need to put our kids through college, right?
It's good to get paid to work on an open source project.
So every contributor might be selfish in their own way.
And one of the things on that awesome podcast that I mentioned earlier
that I've learned is that all the origin stories are different.
So this is a picture in the top left of a contributor committed
to Postgres named Thomas Monroe.
And he was telling the story about how he first started with Postgres,
investigating locking mechanisms in Postgres.
And it was because his application got a lot of press,
and it was mentioned on some TV or radio show,
and they got so many hits on the app,
and it just completely melted down.
So he's like, okay, we got to make a change.
I've got to go investigate other databases,
and that's how he ended up becoming involved in Postgres.
Then when I was talking to a man named Hakey Lina Kangas,
I hope I pronounced it right.
He was on paternity leave, and with his second child,
and the little girl was a really good sleeper.
I don't know how people have babies that are really good sleepers,
but his was, and so he needed something to do during the day,
and he was looking for a new open source project
to dig his teeth into, and that's how he got involved in Postgres.
And he's now a committer who's one of the co-founders of neon
that got acquired last year by Databricks,
and absolutely brilliant man.
And then there's Tom Lane, who some of you may have heard of,
he's a very prolific Postgres contributor,
and his original career goal was to become a pinball designer.
But when he was in college, he was going to study mechanical engineering,
but the professors in the EE department were more interesting.
So we switched to electrical engineering.
He was required to take an intro to CS class,
and then a professor kind of came up to him and said,
you know, you should apply to be a research assistants
in the CS department.
You're really good at this.
And so he's like, well, I need a part-time job,
and I don't want to flip burgers, so, okay, I'll give that a try.
And so that ended up being the path that he took
that led to Postgres.
So people have different paths to bring them here.
I was talking the other day to a man named Greg Bird.
He works at AWS, and he's been in a database
and system space for over 30 years,
but he's brand new to Postgres.
So he's kind of like an interesting, not case study,
but person to talk to to find out like, well,
what are your impressions of working on this project?
I think he's been working on Postgres now for about seven months,
so very, very new.
And he thought it was great
that there's this fantastic database,
a challenging work that he could work on,
and that someone was going to pay him to do it.
But he found it both fun and frustrating,
both challenging and anxiety written.
And he said that the learnings have been as much
about the code and the technology as they've been
about how the commuters make decisions
and what the personalities are like,
amongst the group of maintainers on the project.
So it's kind of interesting to hear about people's perceptions
when they're new.
When you're trying to think about, you know,
are we growing in the right way?
All right.
So now we're going to dive into the future,
building the next generation,
and I had to figure out how to frame
what we were going to talk about.
So shout out to Tracy Kitter, who wrote this amazing book,
the soul of the new machine.
I've structured everything that we're going to talk about
into these three buckets.
The soul, the machine, and the fuel.
And so for the soul, we'll be looking at the human ecosystem,
the people, the community, the culture.
For the machine, it's more about the developer workflows,
and the processes, the tooling that we use,
the governance.
And then for the fuel, it's about the economics
and how people get paid.
So those are the groupings.
But I did a ton of research in coming up with this talk.
It is not just based on my observations,
and my opinions.
You'll see a long list of people at the end
in the credit section.
And I see some of the people who consulted with me,
and I think them for all their work.
But there was so much input I couldn't cover it all.
So I had a cherry pick amongst the topics,
but what we will do is look at what's working
and where we're still struggling.
All right.
So are you still with me?
Are you still awake?
Have I board you yet?
No?
Okay.
Good.
Let's start with a soul, with the human bits,
because at the end of the day,
without people on these projects,
none of it would exist.
So one thing that's working is the welcoming community.
That phrase come for the code,
stay for the community.
I'll never forget my very first PGConf EU,
which was in Lisbon.
That's an annual European Postgres conference.
It changes cities,
or changes countries, even every single year.
And so there I wasn't Lisbon.
It was brand new to the Postgres community,
and people really made me feel like I belonged,
which just like boggled my mind.
There are a lot of conferences and meetups
in the Postgres world where you can kind of build those
in-person trust relationships that are so important.
This particular sketch that you see
is from an annual conference that's fairly new,
called PG Day Lowlands,
happens in the Netherlands every year,
and Bodys Mejias, who is pictured on stage there.
He often jokes that it's the second most popular
European Postgres conference,
and that always leads to a debate of,
what's the first, and what's the third,
and who are you to claim the second?
But anyway,
another thing that's working for us is just
the joy of working on Postgres.
I stole this slide from Bruce Momshin,
who is part of the Postgres court team,
and he is a very prolific conference speaker,
just a really good educator in the Postgres space.
And it's been around in the project
since the very beginning 30 years ago, too.
And he has a slide about why is programming fun
that he gave here at Boston, actually,
and a talk about community building.
But in addition to programming being fun,
Postgres is fun to work on.
And I was talking to an engineer,
the other day, who has been working on Postgres,
probably for about four or five years,
and what he said is that because this database is so big,
and there's so many different subsystems,
that there's a lot of choice about what kind of
challenges that you can tackle,
what you can work on, and he says that,
that's pretty wonderful.
Because even if you don't want to work on
backup, for example,
you can go work on other parts of the system.
Another thing that's working for us,
and this is true across the companies
that are funding Postgres contributors
on the upstream project is just high touch,
one on one mentoring.
And that shouldn't come as a surprise.
I mean, I think that works across projects,
and probably many of you have benefited
from that over the years, or at least,
I hope you have.
So it's tried and true, but it works.
And by the way, you're probably noticing
I have a lot of sketches and graphics in this talk,
and that's just because I'm a visual storyteller,
and I'm allergic to bullets.
But I put a lot of thought into what these graphics are.
So I hope you don't conclude that this is a child
a story or anything.
I think the topic is still pretty important.
In this case, it's a diagram of chemistry,
and we have an experimentation with a photo
above the lab of the six organizers
from last year's PGConf.dev.
We have an annual development conference in Postgres
and about three years ago, a group of people
decided to reboot it.
Historically, it was called PGCon.
It always happened in Ottawa, maybe you've heard of it.
But more recently, it's been happening in Vancouver
in Montreal, and they've really been doing
a lot of experimentation with different formats
and different types of sessions,
and how to make it easier for new contributors
to get involved in the project.
And these are both code contributors,
as well as contributors like me.
So I think this is definitely something
that is working well for the project,
and props to Melanie Plagueman and Steve Singer,
Jonathan Katz, Robert Haas,
Katting Chen, and Paul Ramsey for doing that.
And then another thing that I think is working
is just the recognition of sustained contributors.
And in recent years, there's been an effort
to really work hard and make sure people don't get overlooked,
because at the end of the day,
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.
So there's a whole policy that this is a screenshot of on the screen,
and that's part of one of the many governance things in the project,
and there's a contributors committee,
and it's their job to figure out who to recognize
in these different categories,
like significant contributors and major contributors.
And a lot of those people are code contributors,
and then some of them are people like me,
who are contributing to other aspects of the project.
And then where we're struggling in the area of the soul.
One area is just the belief that we probably don't have enough
commuters in the pipeline.
And if we fast forward five to seven years,
I wouldn't be surprised if the people whose names are on that main
tainer map, I showed a few minutes ago,
if a few of those people choose to step back or retire.
And so, you know, what we need to solve this,
it's important.
And people are definitely talking about it and doing things
to contribute to it.
And someone joked the other day,
I went to the developer meeting,
the Postgres developer meeting that happens a couple days
before fondsdom here in Brussels,
and I popped in for a little bit to talk about this talk.
And somebody joked that,
okay, the rule is going to have to be that you cannot retire
until you have nominated and fully trained your successor.
So, you know, that might just work.
And it's no different than people who own businesses, right?
They have to figure out how to train their successors.
Another area where we're struggling is this question,
are we accidentally overlooking people for promotion?
When we say we don't have enough commuters in the pipeline,
are we right about that?
You know, one of the things in an open source project
is you don't have managers out there advocating for their people,
making sure that the potential and the accomplishments of people
aren't getting overlooked.
So, this is a question that one of the maintainers mentioned to me,
and I thought it was a good question to chew on.
And then another question that came up is,
is there a desert in the middle?
If you look at the mailing lists,
we're a lot of postgres conversations take place,
and you see somebody new chime in with questions
or a potential patch proposal or something like that,
a lot of times you'll see commuters jump on it
to make that person first answer their question,
but also to make them feel validated and to be responsive to them.
But for major contributors who've been doing that job
a couple years and don't need special handholding anymore,
are they getting the attention and the mentoring that they need
in order to move up to the committer level?
And so, this was another thing that came up
and that maybe is something that we could do better in.
So, that's the summary of things that are working
and that we're struggling with in the area of the soul.
And now we're going to move on to the machine.
We'll look at some more aspects of the project.
And I'll start off again with the positives,
because you know, it's always good to start with the positives.
So, one of the things that's working is just the very
predictable rhythm of our development life cycle.
It's easy to understand, you know, annual major releases,
quarterly patch releases.
There's a commit fest where happens five times a year,
so July, September, November, January, just finished one.
And another one coming up in March.
And this is a screenshot of the commit fest app
where you can see all the patches that are out there
waiting for review what the status is, all of that.
And so, this is definitely a positive.
And then another area that's working is patch review.
And the fact that it has some interesting benefits
beyond just ensuring the quality of the patches
that get committed to postgres.
I was talking to Tom Lane, and one of the things he said is,
you know, the reason we emphasize patch reviews so much,
it encourages people doing the review to read the code.
Not just to read the patch, but to read the surrounding code,
and that's the best way to increase knowledge of the system.
So, it's not only improving the quality of the patches,
but it's helping skill up the reviewers within the community.
So, I thought that an iceberg was good for that.
Just to show that there are these invisible benefits
under the surface.
Another thing that's working really well
is the dedication and skill of the maintainers.
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.
No, 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.
This is a sketch based on a photo that Tomosh Fondra took earlier.
I guess last spring in Montreal,
we have these twice a year,
invitation only postgres developer meetings,
and so this is what this was a sketch of that I tried to use as a way
of depicting it.
So, a lot of people in that are
commuters and maintainers on the project.
Another thing that's working are,
I mentioned those intro to postgres hacking workshops
that happen more and more commuters
are experimenting with having office hours
as a way to talk to them and get questions answered
in a way that's off the mailing list
and maybe a little bit less intimidating.
And so, those things seem to be working well
in helping new people kind of get their feet wet
and step into the project.
Another thing that's working
is there have been a bunch of pretty dramatic improvements
to CI infrastructure for postgres in the last couple of years.
The way Tomosh Fondra describes that is that
it's brought light to the darkness.
And, obviously, especially if you're a drive-by contributor,
I've got to imagine it's a lot nicer now
to be able to get some automated testing
done on your proposed patch.
In this way, versus to break the build farm,
which is probably what would have happened five years ago.
So, that's working.
But now let's talk about where we're struggling
in the area of the machine.
And one area is patch review bandwidth.
So, the analogy I came up with for this is
you see the planes circling overhead
waiting to hear from air traffic control
about the ability to land
and there's a lot of planes up there
and not that many are landing,
which is a bit of hyperbole.
Obviously, you saw that 3000 commits
made it into postgres 18.
So, it's not this bad,
but it can feel this bad at times
if you're waiting for patch review feedback.
If you've submitted it and you haven't heard anything,
imagine that can be very frustrating.
Or if you're the person who's got
umpteen reviews to do
and you're feeling tremendous pressure
to have been supportive of others in the community,
but there's only 24 hours in the day.
So, this is definitely
I think an area where we're struggling.
Another question that people brought up
to me of all the people I interviewed
quite a number of them brought up this question
that keeps coming up of should we have component
committers?
Or people with restricted commit bits
for just parts of the postgres subsystems,
not for the whole thing.
Right now, the maintainers,
the commit bits that they have apply to all of the code
and all of the docs.
So, even if they're specialist in particular subsystems,
they still are trusted with the entire source base.
And so, people have discussed this over time
and no one's felt comfortable enough to do it yet.
There's pros and there's cons
to having component committers,
but it's going to keep coming up
and who knows,
maybe someday they'll be in attempt to experiment with it
and just give it a try and see
if it helps with the bandwidth issues.
The other thing that has come up
is this question of is mailing list culture
a barrier to entry for new developers.
Particularly for developers who are just more comfortable
with DMs on discord or slack or text message
or all the various channels that people have these days.
What I hear is that for some people
to ask what's a simple question on an email
that's going to be archive forever
can feel a little bit intimidating.
And so, it just came up as an area
that we're struggling.
Now, there are a lot of positives
to the mailing list culture that postgres uses.
That archive is invaluable.
The fact that people do have to be thoughtful
with what they write probably means that those emails
are more carefully written and they're more clear.
So, there's a lot of positives
but it still is uncomfortable for some new people
and that's something that's going to continue to be discussed.
On the bright side, about a year and a half ago,
yeah, year and a half ago,
after PDConf Dev,
in 2024, Robert Hoss,
who works at EDB and he's one of the maintainers of the project,
he started a new mentoring program for new people.
And if you want to be mentored in postgres,
you should definitely reach out to Robert
and apply for one of the next cohorts.
But he ended up creating a discord server
for people to use as part of that mentoring program.
And they have these monthly hacking workshops as well
in addition to the mentoring cohorts
and the discord server ended up more thing
to become a postgres hacking discord server
and there's a lot of conversations happening on there
and I put a screenshot here from someone named Phil Eaton
who I don't know,
but I thought it was interesting what he had to say
that it's like a game changer for him
in terms of accessibility
that for people who want to learn more about postgres,
it's just less intimidating than the mailing list.
So, there you go.
The question also comes up
is the C programming language barrier to entry.
I don't know, and you're getting your computer science degree these days,
is it required to learn to program and see?
I don't know.
It was required when I got my degree years ago.
So, now you know I'm a little bit older
and I'm not a new grad.
But in the postgres world,
some of the engineers are telling me,
we actually have a flavor of C,
it's not a separate language,
it's just a way in which we program and see.
So they call it postgres C.
But I have heard from some newer developers
that it is a bit intimidating
if they're not expert in this
to have to learn about it.
So that's an area that we're struggling.
And then the other thing that came up
is just that are getting started
information for contributors is a bit fragmented,
a bit out of date,
it can be incomplete,
and this is, oh my gosh,
this is a solvable problem,
but everybody's busy
and so and doing other important things.
So we haven't solved this problem yet
and it will help to get there.
And then another area that we're struggling
is with AI SLAP submissions.
Now this is a new problem.
I, if I were giving this talk a year ago,
I don't know that I would have brought this up.
But it is definitely creating a burden
for our maintainers to sift through
to figure out what's real and what's not.
It has the potential to create burnout
amongst the maintainers.
And it can also cause them to stop looking at
email and submissions from new people
because they don't know if that's real
or if that's just AI SLAP.
And so that can be bad
and that new people on the mailing list
might not get the attention they deserve
even when they deserve it.
Perhaps more pernicious question is
will this use the AI cause
some of the more junior developers to not learn
as much as they could or they should?
Because it does give you a great shortcut
in some ways.
But is it blocking learning?
That's a question that people are talking about.
And speaking of AI SLAP,
there is a talk in this room,
later today,
being given by Daniel Stemberg on the curl project
and it's on this very topic.
So if it's something that you're interested in,
you might want to swing back here at 17 o'clock.
All right.
So the other thing I found myself wondering
and this didn't come as feedback from anybody else,
but as I put this talk together,
I wondered if we're measuring enough.
Got it.
I didn't put it in the struggling bucket per se,
but I do think there's an opportunity here
for us to look at the contributor funnel
and try to figure out where the holes are
because maybe they're not where we think.
And not all commits are equal.
And right now,
we tend to look at how many commits
an individual had authored in a particular release.
But if half of them are typos,
it's not quite the same thing.
And so should we be looking at impact
and not just at numbers of commits?
And so I think there might be an opportunity here.
If there's a data scientist in the room
who loves data bases and who loves Postgres,
maybe there's a project here for you.
All right.
So that's the machine looking at what's working
and where we're struggling.
And now I want to talk about the fuel
for just a minute.
The economics behind this project.
And the first thing that's really working
in our favor is that Postgres is hot.
Like a lot of people are using it.
A lot of businesses, a lot of companies.
It's used in mission critical workflows.
It's used in small startups.
Developers love it.
Students learn it.
And there's a lot of Postgres jobs out there.
So this commercial gravity,
if you will,
is attracting people to learn the technology
and work on the project.
And so that's pretty awesome.
Another thing that's working
is the corporate funding of contributors
to work full-time on the project.
Now this screenshot is only
of the maintainers, only of the commissioners.
So, but when I talk about the corporate funding
of contributors, I'm talking about way more
than just this list of 31 people.
But this list of 31 people is correct
in terms of who the maintainers are
as of a couple days ago in January.
And what companies are funding them
to work full-time on the project.
And then, like I said,
there's people who are part-time contributors,
and their companies are funding them to do that.
And other types of, you know,
major contributors,
significant contributors,
also getting paid to work on it.
So that's pretty awesome.
Where we're struggling in the area of fuel.
Robert Hoss, a VDB, gave a talk
at PGConf Dev last spring.
And it was called Committer paranoia.
And as I was doing my research for this talk,
I watched it only at 1.5x speed, so not too fast.
And I found myself laughing when I got to this section,
not laughing at him, laughing with him
and with the situation.
But he had this picture in his talk.
And he said, it's easy to imagine
that if you're a contributor who's
waiting on the committer's to commit
your patch request, it's easy to imagine that this picture
depicts how the committer feels when they type get push.
But in fact, it's a lot more like this.
And he says, when he talks to the other maintainers,
they say it's stressful.
They do a lot of painstaking,
exhaustive verification of a patch,
whether it belongs to someone else or belongs to them,
before they push it.
Because, and he said that often,
there was a phrase to push their own patches
as they are somebody else's.
And that it's hard.
Because obviously, if there is a problem,
you're on the hook to go get it fixed,
and to go get it fixed right away,
and go get it fixed yesterday.
And so it can actually be stressful.
Another area that we're struggling
is the whole premise.
The whole reason I decided to give this talk.
So this image is my image of what a beautiful
retirement party would be.
I'd like to go sailing in the Greek Islands in the summer.
And so this is on a Greek island,
looking out at other Greek islands across the agency.
I just think this would be a really nice place
to celebrate a retirement.
But people are going to move on or step back
or do something different or retire.
And so figuring out those succession plans,
making sure that people are trained and ready
to take on the batons.
You know, is something that the organization and the team
and people are all working on and talking about,
which is good, right?
It's better than sticking your head in the sand
and ignoring it.
So it is getting attention,
but it is an area that I would say
we probably don't have completely figured out yet.
And so that's it for fuel,
summary of what's working and where we're struggling.
So now what?
Why?
What's the TLDR?
What are the takeaways from this talk?
The good news is that I feel like in the last 30 years
of this open source project,
Postgres is already proven that we can evolve
and we can scale.
There are so many aspects to the project
and the governance and the people,
and there's more people than there were
in the very beginning.
So I think I have a lot of confidence
in our ability to evolve.
But the key thing is that we have to keep evolving.
There's a famous quote about sustainability
and it's from this report called
the Brentland report.
Anybody familiar with it?
On sustainability?
Okay.
I didn't know about it either.
So there you go.
But the quote is that you have to meet
the needs of the present
without compromising the ability of future generations
to meet their own needs.
And so Daniel Gustas and I,
who's the Postgres Committee
sitting in the third row right there,
we're talking about this the other day
and we both wanted to kind of flip it around.
So, you know,
our thinking was that we need to embrace
the needs of future developers
without compromising
how the people who are today's maintainers
today's contributors do their job.
And so that's kind of the challenge.
How do you balance those competing trade-offs?
The fact that the future developers don't like
mailing lists or are uncomfortable or intimidated by
see with, you know,
the way things are working quite well today
and how do we find that balance?
So my analogy for this was a bridge
that has traffic going across,
has to continue to have traffic going across
because, you know, otherwise you can't cross that
but there's obviously some constructions going on there too.
And then, oh, I need to go over here.
Is it going to work now?
No.
Okay, that's what I got there.
I would love to see us find a way,
find ways to run experiments,
try things to improve our patch review through
but because if we can improve that,
then we're not discouraging as many people
in that next generation.
And hopefully getting them more engaged versus less engaged
and hopefully then we can also avoid burnout amongst
our own people.
So this is my dream that we keep experimenting
and find a way to address this puppy.
So that's the TLDR right there
in terms of the three things
that I wanted to bring up at the end.
Now, for any of you in the audience
who may be, you know,
have a baby at home who sleeps a lot
and are looking for a new project,
the way that Hakey Lida Kangas was
or who were just interested in doing something new
with databases in the open source space
and if I haven't scared you away
with all of this discussion about areas that we're struggling,
these are the kind of things that it
I believe takes to become a postgres hacker.
This is my perspective
but also based on conversations
with lots of current postgres hackers.
And obviously it takes programming skills.
Obviously it takes knowledge
that you build over time
of the different subsystems in the database.
Communication is super important.
Especially on a global project
where people, you know,
English is the second or third language
for some of the contributors.
You've got to be a good communicator
and particularly a written communicator as well.
You've got to build that track record of delivery
and good decision-making.
If something goes wrong,
you've got to be there to follow through
and fix it, not like off sailing
in the Greek Islands or something like that.
And one of the things Tom Lane talked about
in the podcast discussion that I did with him
on Talking Postgres is he talked about that kind of thick skin
you need to have to work in public
which is probably familiar to many of you
because you're here at an open source conference.
And this is common across all open source projects.
But when you fail in open source,
you can't hide from it.
You can't shirk from it.
It's there.
It's in the source tree.
People can all see it.
It's obvious.
So you need to have that skill
of being able to work in public.
And then the part that people don't always get
and I put that in the collaboration skills bucket
is just that.
You have to also care about how other people perceive you.
And do they think you listen?
And do they think you would be willing to reconsider
if you made a mistake or might have made a mistake?
And do they trust you?
So it's really that self-awareness
that is important to you.
All right.
So if any of you want to become a Postgres hacker
and you have some of these skills
because we can always build new skills, right?
The whole growth mindset thing.
Then you should check out the project.
And the last thing I want to mention,
and this is just because I have you as a captive audience,
how many of you have heard of a Postgres
virtual conference called Pozette
and event for Postgres?
Okay.
So just a small number of hands.
All right.
Well, let me tell you this.
First of all, the name Pozette
was actually inspired by the name Faustum.
Because, okay, how many of you know
what all the letters in Faustum stand for?
Raise your hand.
See?
Not that many.
I mean quite a few, but not even half the room.
So that was kind of where the name Pozette came from.
I was like, you know, let's come up with an acronym
that has some meaning,
but people don't need to know it.
So it's a virtual event.
My team runs it.
It happens once a year.
And the CFP, the call for talk proposals,
actually closes tonight at 1159 PNPST.
So I just thought I would mention that in case any of you
who have used Postgres and have learnings to share
customer stories, user stories about Postgres.
Maybe you want to try your hand at giving a virtual talk.
So that's my personal plug.
And I also want to say thank you to all these people
who helped me put this talk together,
including all the folks that the developer meeting a couple days ago
here in Brussels who advised on it.
So with that, if there are any questions,
I think we have like two minutes.