Influence Is Not Ownership: Anna Widenius and Kaj Arnö on Governance, Open Source, and the Future of MariaDB
“The purpose of governance is to make clear where authority comes from, how decisions are made, and how other people can acquire responsibility and challenge decisions… Influence is not the same thing as personal ownership of the project.”
— Anna Widenius, CEO, MariaDB Foundation
Q1. Anna, you recently published what you called a “love letter” to the people who made it possible to document the governance processes that MariaDB Server has relied on in practice for years — making explicit what was already working but largely invisible. Why does making governance visible and inspectable matter so much for an open source project, and what specifically was at risk of being lost if these processes had remained undocumented and understood only by a small group of long-standing contributors?
Anna Widenius: For me, the central issue is that open source should not require insider knowledge.
MariaDB Server has had a mature and disciplined development process for a long time. There are experienced maintainers, established areas of technical responsibility, rigorous review practices, and well-understood ways of resolving technical questions. MariaDB plc in particular has invested enormously in building and sustaining that engineering capability.
What was less visible was the project-level map of that system.
If you were already deeply involved in MariaDB development, you understood who carried which responsibilities and how somebody gradually earned greater technical authority. For somebody approaching the project from outside, that pathway was much harder to see.
That is where transparency becomes important. A healthy open source project should make it possible for a capable contributor to understand what responsibilities exist, what standards are expected, how decisions are made, and what it takes to progress from contributor to committer, reviewer and eventually maintainer.
So the risk was not that MariaDB lacked professional engineering processes. Quite the opposite. The risk was that an effective system could remain more legible to the organisations and individuals already deeply involved in it than to the next generation of contributors we want to attract.
Documenting governance makes that system inspectable and transferable. It builds trust, makes succession easier, and gives external contributors a clearer basis for deciding whether they want to invest seriously in the project.
I sometimes think that open source code without inspectable governance is only half open. The source tells you what the software does. Governance tells you how you can become someone trusted to help shape what it does next.
So I see this as a sign of maturity: taking a development culture and governance practice that has evolved over many years and making it explicit enough that people outside today’s core group can understand it, participate in it and eventually help carry it forward.
Q2. The new governance framework makes one principle explicit: authority comes from the responsibility a person carries within the project, not from their employer. That is an important and deliberately stated principle — but it is also a genuinely difficult one to uphold when, as you acknowledge, most of the current maintainer responsibilities are carried by people working for MariaDB plc. How do you ensure that principle is not merely aspirational — that it actually shapes decisions when the interests of the Foundation, the commercial company, and independent contributors diverge?
Anna Widenius: I think the first thing is not to pretend that employer relationships are irrelevant. They are not.
MariaDB plc employs a large number of people who spend their working lives developing MariaDB Server. It would be very strange if those people did not have significant influence over the project. They have accumulated enormous technical knowledge, and many of them carry substantial ongoing responsibility.
The important distinction is between influence that comes from doing the work and authority that comes automatically from being employed by a particular company. An engineer’s technical authority within the project comes from what they contribute, what they maintain, what they review and what responsibilities they are prepared to carry over time.
To me, the real test of employer neutrality is not whether MariaDB plc engineers have a lot of influence. Given the amount of work they do, of course they should. The test is whether someone outside MariaDB plc who makes comparable contributions and takes comparable responsibility can earn comparable authority.
That is precisely why documenting the pathway from contributor to committer, reviewer and maintainer matters.
Different participants will naturally sometimes have different priorities or technical views. MariaDB plc may have a strong preference based on its customers and product strategy. The Foundation may be seeing a different need across the wider ecosystem. An independent contributor may propose something neither organisation originally considered. Technical questions still have to be resolved through the technical governance of the project, based on the merits of the proposal and the responsibilities of the people involved.
A strong commercial company investing heavily in upstream development is an enormous asset to an open source project. It means having engineers whose full-time work is to develop the product, maintain complex areas of the codebase, review other people’s contributions, test changes, resolve regressions, respond to production requirements and carry technical responsibility over many years. That kind of sustained professional engineering capacity is extremely difficult for any open source project to build and retain.
MariaDB plc provides a great deal of that capacity to MariaDB Server, and the project is substantially stronger because of it.
The Foundation’s role is to make sure that this strength exists within an open project structure: that participation remains open, that the path into greater technical responsibility is visible, and that contributors outside MariaDB plc who are prepared to make comparable contributions and carry comparable responsibility have a genuine path to earning comparable authority.
That, to me, is the point of employer neutrality. It does not require diminishing the influence of the people doing most of the work. It means making clear that influence ultimately follows contribution, expertise and responsibility, and that the same principles apply to everyone.
Q3. Kaj, you have observed that most open source governance frameworks are discussed only when something goes wrong — and that MariaDB’s step was to make what already worked visible and open to inspection rather than inventing a new structure. From your years of experience at MySQL AB, Sun, and now MariaDB Foundation, what are the most common ways that open source database governance fails silently — not in a visible crisis, but in a slow erosion of contributor trust, decision quality, or technical direction — and what early warning signs should a foundation board be watching for?
Kaj Arnö: Silent failure of open source database governance may happen in several ways. Through neglect, active and passive. Through ignorance, lack of attention. Through missing expectation setting, too little communication. Through allocation of only junior resources to community contributions. Through too slow response times by senior resources. All of these come as grey zones and all of them are areas where we have learned a trick or two over the years, moving into ever lighter shades of grey.
A foundation board who makes such mistakes is not likely to be listening for early warning signs. They are most likely to not even understand what they are missing out on, and sit there with only a handful of contributors and a backlog of pull requests that are slowly decaying, sometimes withering, other times festering and becoming increasingly hard to merge. So for a Foundation board, PRs languishing in the queue are probably the best early warning to look out for.
And to be honest, that’s exactly what happened in our case. The remedy in our case was the agreement with MariaDB plc, in yet another example of plc strategically committing to the health of the open source project, to ring fence time for reviewing community contributions in all developer sprints. As a result, we’re now in much better shape than before.
Q4. The relationship between the MariaDB Foundation and MariaDB plc is one that the open source community watches carefully — because it represents a model that many projects are trying to navigate: a foundation that stewards a technology in the public interest, alongside a commercial entity that depends on that same technology for its business. Can you describe concretely how the roadmap development process works between the two organizations — who proposes what, how priorities are set, where the Foundation has genuine influence over technical direction, and where it does not?
Anna Widenius: I think it is important to separate several things that are sometimes bundled together under the word “roadmap.”
MariaDB plc has its commercial and product priorities and decides where it wants to invest its engineering resources. Those priorities are informed by customers, by production experience, by product strategy and by the very substantial engineering organisation it has working on MariaDB Server.
The Foundation has a different but complementary field of view. We hear from community users, hosting companies, cloud providers, distributions, application ecosystems, universities, tool vendors, independent developers and other organisations building around MariaDB. We also look at the long-term health of the Server, ecosystem gaps, contributor experience and areas where important work may not yet have an obvious commercial owner.
Other contributors and companies may have priorities of their own. All of those streams can feed into the same upstream project.
So I do not think of the MariaDB Server roadmap as a single document produced by one organisation and handed down to everybody else. It emerges from several sources of requirements, investment and technical initiative. MariaDB plc is by far the most important of those sources because of the scale and continuity of its engineering investment, but it is not the only source.
The Foundation’s influence comes primarily through participation and enablement. We can influence the roadmap where the community demands for a feature, identify ecosystem gaps, bring together people who should be working on the same problem, improve infrastructure and testing, sponsor or incubate work that strengthens the wider ecosystem, and help external contributors navigate their way into the project.
One area I am particularly interested in is extensibility. MariaDB already has a remarkably rich architecture for plugins, storage engines and other ways of extending the Server, and some of the most interesting opportunities now come from people and companies outside the traditional core development group.
That is exactly where open governance and technical architecture meet. If we want other people to build on MariaDB, they need both technical surfaces that allow them to innovate and confidence that there is a transparent path for engaging with the project.
To me, that is one of the strengths of the model: commercial product investment, community priorities and external innovation can all feed the same upstream project. These requirements don’t need to be conflicting and, above all, do not need competing roadmaps.
Q5. Customer and user feedback is one of the most important inputs to any software project’s roadmap — but in open source, the channels through which that feedback reaches the development team are often opaque. How does MariaDB Foundation ensure that the needs of organizations running MariaDB in production — particularly smaller users who are not Gold Sponsors and do not have direct access to MariaDB plc’s engineering team — actually influence the project’s direction rather than being systematically filtered out by the priorities of those with the loudest voices and the largest contracts?
Anna Widenius: This is one of the reasons an independent Foundation is useful.
MariaDB plc has direct access to the requirements of its customers. Those are extremely valuable signals, particularly because many of those customers operate MariaDB in demanding production environments and at significant scale. Customer requirements often reveal problems, performance needs and operational realities that are difficult to discover in any other way.
The Foundation adds another layer of visibility.
We are increasingly connected to hosting companies, cloud providers, e-commerce platforms, developer-tool vendors, observability companies, universities, independent developers, technology partners and users who may never become customers of MariaDB plc. We also try to create deliberate channels for listening beyond the organisations we already know: our annual MariaDB user survey, conversations at open source and database events, community meetups, contributor discussions and the many individual conversations that happen around those activities.
That gives us a different kind of signal. You could say that MariaDB plc often sees extraordinary depth, while the Foundation can sometimes see breadth across an ecosystem.
One user asking for something is useful information. Twenty hosting companies independently running into the same operational problem is a pattern. If developers, platform providers and application vendors are all telling us that the same piece of interoperability is missing, that becomes a very strong signal. The annual survey gives us another way of testing whether something we are hearing repeatedly in individual conversations is actually visible across a much broader population.
A major part of the Foundation’s role is therefore aggregation. We can see needs that might otherwise remain scattered across hundreds or thousands of individual users and bring those patterns into conversations with maintainers, contributors and MariaDB plc.
Aggregation also means going beyond counting requests. To make a signal actionable, we need to understand the workload, scale, operational requirements, economic impact and whether organisations are prepared to test or adopt a proposed solution. That allows us to bring maintainers, service providers and cloud platforms evidence they can use for real investment decisions.
Sponsorship gives organisations a more structured relationship with the Foundation, and I think that is entirely legitimate. Sponsors support our work, and naturally we invest time in understanding what matters to them. Their requirements become another source of information about how MariaDB is being used in the real world. Technical decisions, however, still go through the project’s normal governance and review processes.
The wider principle is that a healthy project needs multiple feedback channels. Commercial customers are one. Community users are another. Contributors are another. Surveys, open source events and the ecosystem around MariaDB give us still more.
The real value comes from putting those signals together. A large enterprise customer can reveal a very deep production requirement. A group of hosting providers can reveal a horizontal ecosystem problem. An independent developer can identify an innovation nobody else was looking for. A survey can tell us whether something that looks important from a handful of conversations is actually widespread. The broader and more transparent those channels become, the better the project can understand the world it is actually serving.
Q6. Kaj, you mentioned that the MariaDB Foundation Board meeting covered topics ranging from the Oracle MySQL Contributor Summit and ecosystem interoperability to AI skills, sponsorship strategy, and AI-assisted security analysis. That is a striking range for a single board meeting — and you publish fairly detailed minutes precisely because you believe open source deserves open governance. What is the most important and least-discussed topic from the perspective of the broader open source database community that is not yet getting the attention it deserves at the board level — and what would it take to put it on the agenda?
Kaj Arnö: We do try to cover “all” topics, at least to touch upon matters in order to set expectations for later deep dives, when we have more time. Lately, we have been indeed been able to cover a fairly wide range of topics. Our plugins, i.e. our extensibility strategy is a highly technical issue where ecosystem perceptions still sees us behind PostgreSQL, for no particularly good reason. This needs board level attention, and I’m sure it will bubble up fairly soon by itself, as other issues get resolved. Developer mindshare issues also deserve more attention, as do issues related to communicating our roadmap and functionality to the right channels. We keep hearing about users surprised at our feature set,”I thought you were just a fork of MySQL”, not understanding the results of years of work on top of MySQL. It breaks my heart to see us having a great Vector offering, when it comes to both versatility, performance and ease of use – yet we haven’t found our way to the right developer minds and forums in order for us to be a default choice. Those are key matters to be put on the board agenda.
Q7. The database market has never been more fragmented — or more dynamic. We have relational databases, document stores, graph databases, vector databases, time-series databases, NewSQL systems, lakehouse formats, and now AI-native data stores, all competing for developer attention and enterprise budget simultaneously. From the perspective of two people who have spent decades in the database industry: is this proliferation of database types and systems genuinely serving users and organizations well, or is it creating a fragmentation problem that makes it harder to build and maintain reliable data architectures — and where do you see the market consolidating, and around what?
Anna Widenius: I think we have probably overcorrected toward specialization in databases.
There are good reasons why specialized systems appeared. Different workloads have genuinely different requirements, and specialization has driven a tremendous amount of innovation. But every additional database also creates architectural cost: another operational system, another security model, another data pipeline, another consistency boundary, another skill set the organisation has to maintain.
So I expect some consolidation, but not necessarily consolidation into one giant database that tries to implement every possible workload itself.
The more interesting model is a strong, extensible core that can absorb new capabilities when they belong in the core, while also supporting best-of-breed engines and extensions for specialised workloads. That gives users a much broader range of capabilities without requiring a completely separate database platform, operational model and skill set for every new use case.
Vector search is a good example of the first path. A few years ago, it was easy to assume that vector workloads necessarily required an entirely separate category of database. MariaDB now provides native Vector capabilities as part of the Server itself. That is a case where an important new workload can become a natural capability of an established relational database.
Other workloads may be better served by specialised technologies connected to the same core. Analytics is an interesting example, where work connecting MariaDB with DuckDB shows the potential of combining MariaDB with a best-of-breed analytical engine instead of trying to recreate every specialised capability inside the Server.
This also matters when analytical requirements emerge inside an established transactional application. Organisations should be able to address many of those requirements without moving the operational workload to another database or creating an entirely separate data platform. MariaDB with DuckDB points toward a model in which transactional and analytical capabilities can coexist behind the same familiar database interface, while dedicated analytical systems remain available for workloads that genuinely require them.
This is particularly interesting for MariaDB because extensibility is not something we have to invent from scratch. It is deeply embedded in the architecture. MariaDB has had pluggable storage engines for decades, alongside many other plugin interfaces.
So the opportunity is not simply to keep adding more and more functionality to one monolithic database. It is to give users one strong and familiar core that can evolve itself where that makes sense, while also allowing specialised engines and extensions to serve very different use cases efficiently.
And that has an important open-source dimension. The most interesting innovation is not necessarily the innovation the core project itself predicted.
A healthy extensible platform combines a professionally maintained core with an ecosystem that can innovate around it. Maintaining a database Server over decades requires sustained engineering work: compatibility, reliability, testing, regressions, performance, security and all the less glamorous work that makes new capabilities usable in production. MariaDB plc contributes enormous capacity to that part of MariaDB.
Extensibility then allows the circle of innovation to become much wider. The core project does not need to predict every future workload or build every possible capability itself. It needs an architecture and interfaces that allow other people and companies to build useful things around it, while benefiting from the strength of the underlying platform.
I think that combination of a strong professionally maintained core and an open ecosystem capable of extending it is going to become increasingly important.
Q8. The MariaDB governance framework describes how contributors can grow into committers, reviewers, and maintainers — a pathway that exists in theory in many open source projects but in practice is navigated successfully by relatively few people. What are the real barriers that prevent technically capable contributors from moving along that pathway, and what has MariaDB Foundation learned from cases where the seven-day response clock you mention has failed to produce the momentum that was hoped for?
Anna Widenius: There are several barriers to becoming a contributor to a mature database project. The codebase is large, ownership can be difficult to understand, testing can be intimidating, and even technically excellent contributors can lose momentum simply because nobody responds quickly enough.
That is why we have been working on very practical things: making responsibility clearer, improving contributor documentation and testing, and setting expectations around response times. A seven-day clock can prevent silence. It cannot manufacture mentorship, but it can at least make sure that somebody who has made the effort to contribute is not left wondering whether anyone noticed.
But I think we also need to broaden what we mean by participation.
Historically, open-source projects have tended to think about the path from user → contributor → committer → maintainer. That path remains extremely important. We want more people eventually carrying real responsibility for MariaDB Server.
At the same time, a mature database needs people with very deep specialist knowledge who are willing to carry responsibility over many years. MariaDB plc employs many such engineers, and that continuity is enormously valuable. It is neither realistic nor necessary to imagine that every person or company contributing value to MariaDB should ultimately become a core Server maintainer.
Someone may build a storage engine, an extension, an integration or an entirely new capability on top of MariaDB. A company may want to build a product around the database, provide independent support and consulting, integrate MariaDB into a cloud platform, or operate it as a managed service while contributing improvements to the interfaces and capabilities it depends on. Those organisations are also part of the technical and commercial ecosystem around the project.
So one of the things I want us to become much better at is making MariaDB easy not only to contribute to, but to build on.
That requires good documentation, stable interfaces, testing, discoverability and clear ways for extension authors to interact with the core project. Governance matters here as well, because people invest much more confidently when they understand how decisions are made and can see a realistic pathway for deeper engagement with the project.
For me, that is a broader definition of openness. The source code is open. The path into responsibility is open. And increasingly the architecture itself should invite people to build things around MariaDB that none of us could have designed centrally.
That gives us a much larger ambition than simply increasing the number of people committing patches to the Server. It means creating an ecosystem in which professional core engineering and innovation around the core reinforce each other.
One measure of a genuinely open project is whether several independent companies can confidently build support, services, tooling and managed offerings around the same upstream technology. Transparent governance and stable technical interfaces make that investment possible and help the project reach users through many different commercial channels.
Q9. Looking at the challenges ahead for MariaDB as a project and as an ecosystem — AI workloads requiring new database capabilities, the rise of vector databases, increasing competition from cloud-native managed database services, and the ongoing challenge of sustaining open source contribution at scale — what is the challenge you are most concerned about that you believe the broader open source database community is not yet taking seriously enough?
Anna Widenius: MariaDB is a tool that at the same time is served by AI and itself serves AI. Integration of a tool into AI usually means making it easy for the harnesses to develop code for that tool. Making vibe coding efficient. In our case, we are also an infrastructure component of AI, based on our Vector offering. The RAG applications enabled by MariaDB make it possible for users to create AI applications that scale, and that save tokens by delegating work to “normal” MariaDB indexes, instead of consuming oodles of AI tokens. I say “normal” as we’re talking vector algorithms, such as HNSW (which stands for “hierarchical navigable small world”), where a smart design of the app avoids the costs related to large contexts.
The challenge is the complexity of the AI world and the speed at which tools change. New harnesses and new LLM models are hard enough for many of us to navigate, and the best usage of skill files and MSP servers is changing rapidly. Architecting a scalable app in such a situation is of course a challenge to be concerned about, particularly as new innovations may quickly obsolete best practices. The trick is to balance the ambition between quick wins and the sustainability of a long-term app.
Q10. Anna, you share the surname Widenius with Michael “Monty” Widenius, the creator of both MySQL and MariaDB — one of the most significant figures in open source database history. Kaj, you co-founded MariaDB plc with Monty and spent years as CEO of the Foundation he created. The question neither of you may want to answer publicly: how much of MariaDB’s identity, direction, and community culture is genuinely shaped by the governance framework, the Foundation board, and the community — and how much is still, honestly, shaped by the vision, preferences, and personality of one person? And is that a strength, a risk, or both?
Anna Widenius: Oh, no Roberto – this is a question I absolutely want to answer. In fact I am extremely grateful for the opportunity to do it!
Of course Monty has enormous influence.
Pretending otherwise would be both inaccurate and rather silly.
He created MySQL. He created MariaDB. He has spent decades thinking about relational databases, and a great deal of the architecture, technical philosophy and culture of both projects carries his fingerprints.
But there is an important distinction between enormous influence and MariaDB being driven by one person.
MariaDB today is developed by a substantial engineering organisation at MariaDB plc, together with maintainers and contributors across the wider project. Product direction, engineering priorities and technical decisions emerge from the work of many people: plc leadership and product teams, engineers responsible for different parts of the Server, maintainers, customers, the Foundation, and contributors bringing ideas and requirements from elsewhere in the ecosystem.
Monty is a particularly influential participant in that system, and he is also a member of MariaDB plc’s leadership team. He challenges technical assumptions, proposes ideas, argues about architecture and sets an extraordinarily high bar for what he believes MariaDB Server should be capable of. His influence sits within a much broader product and engineering organisation, alongside other executives, technical leaders and engineers with substantial responsibilities and expertise of their own.
His ideas are reviewed, challenged, implemented, tested and very often argued about by people with deep technical expertise and strong opinions of their own.
That distinction is important to me because governance is not a mechanism for averaging away exceptional people.
The purpose of governance is to make clear where authority comes from, how decisions are made, and how other people can acquire responsibility and challenge decisions. Someone with Monty’s knowledge, history and continuing contribution should have enormous influence. But influence is not the same thing as personal ownership of the project, and it does not mean that one person determines MariaDB’s product direction.
Opinionated, passionate discussion has always been part of the culture around Monty. He wants people who care enough about the technology to argue with him.
You see that in MariaDB today as well. The engineering organisation at MariaDB plc contains very strong technical personalities, as does the Maintainers Council and the wider contributor community. Governance gives that culture structure: responsibilities are explicit, decisions can be challenged, and authority can be earned by others.
So where is the risk?
The risk would be confusing the enormous influence of a particularly capable individual with a system that depends upon his consent.
Those are two very different things.
I very much want Monty to remain a major intellectual and technical force in MariaDB for as long as he wants to be. At the same time, the measure of a mature project is that it becomes stronger through many consequential people and institutions: strong engineering leadership, strong maintainers, new contributors, more organisations carrying technical responsibility, and clear ways of making and challenging decisions.
To me, that is the ideal outcome. We do not make MariaDB Server “less Monty” in order to make it more open. We make sure that the extraordinary contribution of its founder exists within a project and engineering organisation capable of producing many other people whose ideas can be equally consequential.
Kaj Arnö: My answer is at the same time different from Anna’s, as it is identical to it. From the outside, it may seem that the quirks of the founders of a project direct most aspects of an Open Source project. To the extent it’s true, it shows on a cultural level. The importance of technical merit is there, and the sheer joy of winning an intellectual argument has always played a role in the MySQL and MariaDB universe. With MariaDB, arguing from a community ethics perspective became even more important than during MySQL AB times. In between during Sun Microsystems Inc. times, there was a detour into a preaching mode, where exporting “our” model to Sun was high on the mental agenda. But the really interesting thing is to see how Monty evolves. Old dogs don’t learn to sit, proverb has it. Yet Monty has learned quite a few tricks in the last, say, ten years: In communication, in expectation setting, in listening to other opinions. They say you don’t change much after you turn 35; Monty has changed his opinions on core engineering topics. To name just one, he has moved from begrudgingly accepting that others use AI, into vibe coding himself (not core Server code, but test cases and peripheral scripts). He was even happy to review and improve upon a vibe coded contribution to a fundamental new piece of functionality (JSON and BLOB support in in-memory tables). Monty remained Monty and found lots of things that absolutely needed optimisation, improvement and partly rewriting. But even if Monty’s vision remains intact, his personality and preferences adapt and evolve with the times we live in.
……………………………………….
Anna Widenius, CEO MariaDB Foundation
Anna Widenius is CEO of the MariaDB Foundation, where she champions open-source database technology and works to strengthen the MariaDB ecosystem. She brings extensive experience in open-source advocacy, marketing, operations, and strategic planning. Previously serving as Chief of Staff at the Foundation, Anna played a key role in driving strategic initiatives and community engagement. She is passionate about open source, innovation, and building vibrant communities around technology.
Kaj Arnö, Executive Chairman MariaDB Foundation
Kaj is a software industry generalist, having served as VP Professional Services, VP Engineering, CIO and VP Community Relations of MySQL AB prior to the acquisition by Sun Microsystems. At Sun, Kaj served as MySQL Ambassador to Sun and Sun VP of Database Community. Board member at Footbalance Systems Oy (Helsinki, Finland). Past founder, CEO and 14 year main entrepreneur of Polycon Ab (Finland).
Kaj is a co-founder of MariaDB Corporation Ab, and served on its Executive Team in several positions, most recently Chief Evangelist.
………………….
Comments are closed.