The first commit to the CloudNativePG project was made in February 2020. Just two years later, EDB began the process of donating the project to the Cloud Native Computing Foundation. This move wasn’t just symbolic, it was a deliberate strategy to ensure CloudNativePG could continue to thrive under the guidance of a broader, more diverse community of contributors.
My colleague Gabriele Bartolini and I talked about the challenges and lessons learned transferring stewardship of an open source project to a foundation. Gabriele is the VP of Cloud Native at EDB, an active PostgreSQL Contributor, maintainer of CloudNativePG, and a Data on Kubernetes community Ambassador. Relevant to the topic of the presentation, I’ve been a CloudNativePG Code Owner since spring this year.
Why transfer stewardship?
We’ve seen what happened in the past with company owned open source projects, it all starts with good intentions but: companies get acquired, and objectives change - we wanted to make sure CloudNativePG lives beyond EDB and be free forever.
You’ll remember the story of MySQL. MySQL was created by a Swedish company, MySQL AB. MySQL AB was bought by Sun Microsystems in 2008 . And then Oracle acquired Sun Microsystems in 2010.
Concerns about Sun's position as a competitor to Oracle were raised by antitrust regulators, open source advocates, customers, and employees. The European Commission delayed the acquisition for several months over questions about Oracle's plans for MySQL, Sun's competitor to Oracle Database. But it went through in the end as we know.
The day Oracle acquired Sun, one of the original maintainers forked MySQL, launching MariaDB, and taking a swath of MySQL developers with him. He also started a petition asking that MySQL either be divested to a third party, or have its licensing changed to be less restrictive.
There's the MariaDB Foundation, and there's MariaDB the company which makes its profits from developing proprietary products related to MariaDB. If MySQL had been managed under a neutral, non-profit foundation, it likely couldn’t have been acquired in the same way. The separation of governance (the Foundation) from commercial activity (the Company) protects a project’s community and technical direction, regardless of corporate mergers or business pressures.
Bringing it back to CloudNativePG, donation to the CNCF prevents it from ever being a topic of discussion.
About a year ago I was exploring the possibility of a foundation to centralize support for PostgreSQL ecosystem projects (extensions and auxiliary tooling), together with David Wheeler, when we were both still at Tembo. Of course then David and I looked at CloudNativePG as a project that could probably benefit from a vendor-neutral hub-thing invested in the future development of the project.
Now, I don’t work at Tembo anymore (and neither does David), and the foundation was never launched, but the problems we were seeing in open source - single-vendor projects, and critical software maintained by a single, fallible human, or a very small number of maintainers in their free time - didn’t go away.
I watched CloudNativePG go the foundation route from the sidelines and it made total sense. Since joining EDB I have had plenty of conversations with the maintainers and learned what it means to be a CNCF project and proposed to Gabriele that we share this story.
Why the Cloud Native Computing Foundation?
People in the Postgres community might not be familiar with the CNCF/Linux Foundation. So first let’s look at these organizations a bit closer and I think you’ll too conclude that other foundations like the Eclipse Foundation; Apache Software Foundation, Free Software Foundation, etc wouldn’t fit, CNCF was the defacto choice.
The Linux Foundation is a nonprofit technology consortium founded in 2000. Its mission is to support the growth of Linux and open-source software by fostering collaboration between developers, companies, and organizations.
The foundation provides a neutral, trusted hub for projects that are critical to modern computing, ranging from the Linux kernel itself to emerging technologies in cloud computing, networking, and security.
Over time, the Linux Foundation has expanded beyond just Linux to host and incubate a wide range of open-source projects. It provides governance, funding, infrastructure, legal support, and events to ensure projects can grow sustainably.
Some of the most well-known initiatives under its umbrella include LF Edge (for edge computing), and OpenJS Foundation (for JavaScript technologies).
The Cloud Native Computing Foundation (CNCF) was founded in 2015 as a project under the Linux Foundation. Its creation was driven by the rapid rise of cloud-native technologies—especially containerization and microservices—that required open governance and community-driven standards.
CNCF serves as a vendor-neutral home for projects that enable organizations to build and run scalable, resilient applications in modern cloud environments.
CNCF is best known for hosting Kubernetes, along with dozens of other important projects such as Prometheus (monitoring), and Envoy (service proxy). By bringing these under one umbrella, CNCF ensures interoperability, community collaboration, and long-term sustainability.
Timeline / not-so ancient history
CloudNativePG was originally conceived in August 2019, when Gabriele was asked by Simon Riggs, then CEO at 2ndQuadrant now EDB, to lead the Cloud Native/Kubernetes initiatives for the company. His team had a long running history of DevOps practices, and had been following Kubernetes for some time.
The game-changer was the introduction of local persistent volumes in Kubernetes 1.14 (April 2019), together with a more consistent and standard adoption of the operator pattern in the industry. They began an exploratory phase: they wanted to build an operator that would rely on light images (immutable application containers), to be entirely declarative and to be tightly integrated with the Kubernetes API server.
By December 2019, they had achieved results well beyond our expectations in all areas—most notably that Kubernetes on bare metal was performing almost identically to Linux on bare metal.
Next, they started the productization phase of a BDR (Bi-Directional Replication) operator for multi-master replication, released in January 2020.
In February 2020, they began refactoring that code into a new product: Cloud Native Postgres. They published some results of how the technology was working for 2ndQuadrant and that caused the Data on Kubernetes community founder to reach out to ask Gabriele to present the project.
After 2ndQuadrant was acquired by EDB in September 2020, Cloud Native Postgres was further developed, with a first stable release announced in February 2021. Gabriele believes that at 2ndquadrant the project wouldn’t have grown to the same size, we did so many different things. At EDB there was an intentional investment.
December 2020, Gabriele wrote a proposal titled "Open Core for Cloud Native PostgreSQL", to begin an evaluation process for the release of the Kubernetes Operator for PostgreSQL under an OSI compatible open source license.
The project and the team kept growing throughout 2021. Then, Gabriele changed role to a more strategic one at EDB and in January 2022 he gave a presentation to the board about open sourcing Cloud Native Postgres, proposing to adopt the Apache License 2.0, required for entering the CNCF graduation process.
His arguments:
- There was no PostgreSQL project in the CNCF landscape yet
- It’d increase adoption of PostgreSQL (“Postgres everywhere” was EDB's credo at the time)
- The operator become the de facto standard for Postgres management in the Kubernetes community
- And enhance visibility of EDB as a technological leader in databases on Kubernetes as the original creators
He explained how Open Source IP would be transferred to CNCF upon approval, while the Closed Source IP would be retained by EDB. With support from his then manager, Jozef de Vries, and EDB general counselor at time Paul Lucchese he got the approval of the board.
On April 21, 2022, Cloud Native Postgres got renamed to CloudNativePG, and the repository open sourced under the Apache license with a history of over 1400 commits, and released version 1.15.0.
EDB formed the initial community of contributors around a vendor neutral and transparent governance model inspired by the CNCF’s values and principles - centered on making cloud native computing ubiquitous, fostering a vendor-neutral, open-source ecosystem, and democratizing innovation. Key principles include openness, transparency, inclusion, respect, and creating an accessible and welcoming community for all contributors and users.
A starry-eyed Gabriele wrote: “Today is the culmination of years of hard work at EDB, and, hopefully, the beginning of a new phase in the multi-decade evolution of Postgres and its community.”
Quoting AC/DC “It’s a long way to the top” in that if accepted into the CNCF program, that would mean the start of a journey, certainly not the end. That was a bit of foreshadowing too, since we didn’t get in immediately.
In July 2022 the CloudNativePG maintainers submitted the first CNCF Sandbox application, which did not get accepted. But we’ll get to that! In January 2025 CloudNativePG became a CNCF project entering the Sandbox stage.
June 2025 the team started the first cohort in the LFX mentorship program, with a mentee contributing the declarative management of Foreign Data Wrappers. Currently wrapping up the second cohort / LFX round, with 2 different proposed projects, the program is a way to grow the contributor base.
What does donating a project look like?
CNCF projects have a maturity level of Sandbox, Incubating, or Graduated, which corresponds to the Innovators, Early Adopters, and Early Majority tiers of the Crossing the Chasm diagram.
The maturity level is a signal by CNCF as to what sorts of enterprises should be adopting different projects. Projects increase their maturity by demonstrating their sustainability to CNCF’s Technical Oversight Committee: that they have adoption, a healthy rate of changes, and committers from multiple organizations; have adopted the CNCF Code of Conduct; and have achieved and maintained the Core Infrastructure Initiative Best Practices Badge.
Incubation means Visibility, with progressing to incubation we go from early adopters to early majority, convincing more companies to dedicate engineering time to the project.
To put in your application today, you open an issue on GitHub where you answer questions about fit, integrations, existing users, etc. The previous application got rejected, they were still using a spreadsheet back then. The reason for the rejection was that “There are already other operators, CNCF can’t be a kingmaker”.
The team disagreed - they felt the committee failed to look at the licenses for the other operators - but didn’t give up, and instead critically analyzed the feedback. They engaged with the community, and invested in adoption. Mostly in people’s extra time because of badly timed reorganization.
Gabriele liaised with the CNCF, talks got accepted for CloudNativeCon + KubeCon, Leonardo Cecchi started working with TAG (Technical Advisory Group) Storage (Volume Snapshots work). CloudNativePG won peer-respect over time, got to learn the ecosystem, and the project was in a better place, more mature, to apply again.
CloudNativePG is now under CNCF trademark, which meant EDB needed to change the name for the managed product. The maintainers governance model / best practices the CNCF evangelizes were already adopted before the first application.
Bonus of applying: people say really nice things about your baby!
Lessons learned
Here we can switch to "we", since this is when I joined EDB and got to spend some of my working hours on the project.
It's not all been smooth sailing since we entered the sandbox.
With more visibility you get more people submitting PRs, and the existing maintainers don’t have enough time to review or even triage everything.
We feel this quote by Chris Aniszczyk, CNCF’s CTO. We have a real need for maintainers that are people that review and maintain, not just add more shiny stuff. Or contributors that when they’re adding new stuff, make sure they add documentation and tests or they’re just again flooding the backlog. There’s a responsibility on us as well to make sure people know docs and tests better the odds of getting stuff into the project.
There are sometimes big feelings, and people forget that behind GitHub accounts are volunteers. Sure, some are on the payroll of a company, still largely EDB, but these folks work on the project in their spare time too.
We know that we can lose our cool too sometimes.
An entertaining and all too true talk about this is "Kubernetes Maintainers Read Mean Comments". Tim Hockin from Google & Davanum Srinivas from AWS do just as the talk title suggests: read the mean comments on GitHub issues and PRs.
We’re not the first people in open source to figure this out. This talk by Tim Hockin, again, on setting expectations and saying no, really hits home. He said “We’ve got to say no to things today, so we can afford to do interesting things tomorrow”. And quoting Solomon Hykes, Founder of Docker: The first rule of open source is that no is temporary, yes is forever.
What's next?
We’re going for Incubation status, and we’re focused on the graduation requirement to increase vendors involved through the maintainers. We’ve worked with mentees through the LFX mentorship program which is a great opportunity for us, but also for people new in the community to build up their skills, and we’re definitely looking to continue this.
We’re very involved in the conversation what stuff needs to be done in upstream PostgreSQL versus upstream Kubernetes to make the data on Kubernetes better for everyone. Then there’s the work on version 1.28, and we’re already presenting new integrations and feature capabilities at KubeCon North America this November!
If you’re using CloudNativePG (like: IBM, Google Cloud, Azure, Xata,
ParadeDB, and Wien IT already do), or implementing it for a customer? I’d love you ask you to add your (company’s) name to the ADOPTERS file, and I will likely reach out regarding a testimonial, or an end user interview.
If you’re interested in joining in the development of the project, join the CNCF Slack and find the channels with “cloudnativepg” in the name, and join our Office Hours for questions, and our Developers / Community Calls to talk CloudNativePG development and community building.
Top comments (0)