Helge Notø Makes Open-Source Stewardship a Focus of Board Candidacy

Longtime Drupal contributor Helge Notø says his candidacy for the Drupal Association Board is shaped by a practical concern: how Drupal can protect maintainers and remain open while turning institutional use into sustained contribution.

In written answers to The DropTimes’ Allen Jason, Notø connects AI contribution policy, public-sector procurement, digital sovereignty, enterprise positioning, and junior career paths through a common argument: Drupal’s long-term independence depends on organisations that use it helping to sustain it.

Notø has worked with Drupal for more than two decades as a user, developer, and project manager. His community involvement includes organising in Bergen and serving on the Drupal Norway board. In a candidate statement published on 7 July 2026, he identified clearer advocacy for Drupal, a balanced approach to AI, and stronger pathways for junior contributors as priorities.

Drawing on that experience, he calls for clear norms for AI-generated code, contribution clauses in public-sector procurement, stronger messaging on distributed stewardship, and deeper cooperation with the PHP Foundation. He asks to be judged on whether the Association builds those partnerships and helps move major institutions from users to contributors.

This interview is part of The DropTimes’ (TDT) series with candidates for the at-large seat on the Drupal Association Board. TDT sent each candidate five common questions and two candidate-specific questions to help readers compare their priorities, experience, and approach to the Association’s role.

Interviews in this series are being published as candidates return their completed responses.

AI, Contribution, and Access

TDT [1]: As AI-assisted and agentic site-building grows, what role should the Drupal Association play in protecting Drupal’s open-source values, data privacy, maintainer well-being, and freedom from vendor lock-in?

Helge Notø: AI is a fantastic and extremely powerful tool and I enjoy using it both professionally and even more so in my private projects. But precisely because it's so powerful, we need a balanced approach. The most immediate risk I see is on the contribution side: maintainers being overwhelmed by huge, AI-generated pull requests that are too large to review properly and arrive faster than any volunteer can keep up with. The Association's role, as I see it, is to help establish the rules and norms for handling AI-generated code; clear expectations around contribution size, disclosure of AI assistance, and review standards so that we get the benefit of these tools without burning out the people who keep the project running.

Get the norms right, and AI becomes what it should be: a way to lower barriers and multiply what our contributors can do. Get them wrong, and we exhaust our maintainers.

Alongside that, the fundamentals still apply: AI features in Drupal shouldn't lock us into any single vendor's models, and openness and data privacy must extend to how AI tooling is built and integrated.

TDT [2]: Drupal benefits from enterprise users, agencies, and public institutions, but contributions are still uneven. What should the Drupal Association do to turn more of that use into visible support through developer time, code, documentation, infrastructure, or funding?

Helge Notø: The gap between who uses Drupal and who contributes to it is one of the oldest problems in open source, and I see it clearly here in Norway. Large organizations and public institutions run substantial parts of their digital presence on Drupal; a few municipalities, several universities, and government services, but the contributions flowing back rarely match the value they take out. It's usually the agencies serving them that contribute, while the organizations themselves treat Drupal as something that simply exists, like infrastructure nobody has to maintain.

I don't think this is bad will, it's that contribution has never been made part of the deal. That's where the Association can act. First, help make contribution part of procurement: when a public institution buys Drupal work, contributing fixes and improvements upstream should be a natural clause in the contract, some European institutions are already moving this way, and the Association can provide the templates and the arguments. Second, make the case directly to large organizations that funding the commons they depend on is responsible stewardship, and for public money especially, this argument is gaining real traction in Europe. Third, make the path short: many large organizations fix things internally that never make it upstream simply because nobody owns that last step. If the Association can make contributing the easy, visible and expected choice for large users, the imbalance starts to correct itself.

TDT [3]: How should the Drupal Association balance investment in enterprise tooling with simpler entry points for junior developers, hobbyists, and new site builders?

Helge Notø: Honestly, I don't think the dichotomy is real. The best tooling investments we've made serve everyone at once. DDEV is the perfect example; it's a boon to enterprise teams and hobbyists alike. Having worked with Drupal since the LAMP stack days, I genuinely enjoy not having to guess at server setup anymore. And that same improvement helps a junior developer get their first site running just as much as it helps a large agency standardize its workflow. Composer is similar; it takes some work to learn, but once you understand it, the benefits far outweigh the cost.

That last point matters, because I think we should avoid the trap of "this is too difficult." The answer to a learning curve isn't to dumb Drupal down; developers can tell when they're being condescended to, and a simplified Drupal that hides its own power serves nobody. The answer is training. Where the Association should invest is in making the adoption of Drupal easier: better learning resources, better documentation, better guided paths from first install to first contribution. Good tools plus good training lifts everyone: The junior developer, the hobbyist, and the enterprise team are climbing the same ladder. Our job is to make the ladder solid, not to saw off the top rungs.

Sovereignty, Trust, and Market Position

TDT [4]: If digital sovereignty is increasingly defined through national ownership, where does that leave a global open-source project like Drupal? How should the Drupal Association argue that distributed international stewardship can offer a credible form of sovereignty?

Helge Notø: If sovereignty is defined purely as national ownership, no global project qualifies but I think that definition misses what sovereignty is actually about. Here in Norway, we feel this directly: we are heavily dependent on American suppliers for our digital infrastructure, and recent years have made it clear how uncomfortable that dependence can become. A small country will never have a domestic vendor for everything. So for us, the real question isn't "who owns it?" but "who controls it?" Can you inspect the code, run it where you choose, modify it without permission, and exit without penalty? By that standard, Drupal offers more sovereignty than any proprietary vendor, foreign or domestic.

There's also the security argument, which is inherent to open source itself: the code is open to inspection by anyone, which means vulnerabilities can be found and fixed by thousands of eyes rather than hidden behind a vendor's closed doors. You don't have to trust a company's promises about their software - you can verify. For public institutions, that transparency is a form of sovereignty in itself.

The argument the Association should make is that distributed international stewardship is a feature, not a bug: no single government or company can capture, pressure, or shut down Drupal.

What institutions need from us is credibility on governance, security processes, and long-term continuity, and we can deliver on it.

TDT [5]: Many organisations evaluate Drupal alongside proprietary SaaS platforms rather than other open-source CMSs. What should the Drupal Association do differently to improve Drupal’s position in those evaluations?

Helge Notø: There are two fronts here. The first is the evaluation experience itself. When a decision-maker compares Drupal to a SaaS platform, the SaaS product wins the first impression: polished, fast to demo, easy to try. Projects like Drupal Canvas are, in my opinion, exactly the way to breach into that sphere: Giving Drupal a modern site-building experience that can stand next to any SaaS offering in a demo, without giving up what makes Drupal, Drupal. The Association should put real weight behind making that first-touch experience competitive.

The second front is the opposite of flashy, and it's where Drupal genuinely wins: longevity. Government sites and large institutional platforms are meant to run for 5-10 years or more. That timescale changes everything. A SaaS vendor can pivot, raise prices, or sunset a product — and the AI-based solutions appearing everywhere right now are not even proven over a few years. Drupal's codebase has demonstrated solidity over 25 years, with a clear upgrade path and a security team with a long track record. Promoting how solid Drupal actually is, boring as that may sound next to the latest AI pitch, is just as important as modernizing the first impression.

When an IT director or CTO is signing up for a ten-year commitment, still here, still maintained, still yours is a powerful message. Do not underestimate how strong a statement that is.

TDT [6]: How should the Drupal Association translate Drupal’s open-source values into practical messages about security, maintenance, trust, and long-term responsibility?

Helge Notø: Much of this connects to what I said in the previous answer: Drupal's values are our strongest sales argument, but only if we translate them into the language of the people making decisions. "Open code" means your security team can audit everything and thousands of eyes already have. "Community stewardship" means no vendor can raise your prices or shut down your platform. "Twenty-five years of history" means a proven track record of security handling and long-term maintenance. Simple, concrete messages that answer the questions an IT director or CTO is actually asking.

But there's another angle we should use more: look at what's happening with companies that are open source in theory but not in reality. WordPress has shown how a project can be held hostage by the interests of a single company. Sanity and similar platforms wear the open source label while keeping the parts that matter closed or controlled. Every one of those stories is an argument for Drupal because our openness isn't marketing, it's structural. Nobody owns Drupal. Nobody can pull what happened elsewhere.

And at the same time, we shouldn't be too proud to learn from our competitors. Their onboarding, their polish, their way of explaining themselves simply — where it works, take it and use it to our advantage. Being genuinely open doesn't mean we have to be genuinely harder to understand. The winning combination is their accessibility with our substance and trustworthiness underneath.

Accountability and Outcomes

TDT [7]: If elected to represent the community on the board, what is the single most important, measurable outcome you intend to deliver by the end of your term, and what specific metrics do you want the community to use to evaluate your success?

Helge Notø: The outcome I ultimately want is a wave of new and junior contributors, but I have to be honest: that's a hard goal to reach directly, and it's the result of other things going right, not something a board member can will into existence. So let me point at the lever behind it instead.

What I want to have achieved by the end of my term is deeper cooperation with organizations tackling the same root problem we face, especially the PHP Foundation, since our fates are linked through the underlying language. The inherent problem of open source is the same at every level: lots of companies benefit enormously from our work, but many are just takers who never contribute back. Concretely, I want more large organizations, in my own country, that means the universities and government institutions running on Drupal, contributing back with developer time, funding, and upstream work.

Why does that matter for juniors? Because it's the whole chain.

When large institutions visibly invest in Drupal, there are jobs. When there are jobs, Drupal becomes a credible career path.

And if we can't show juniors that the jobs are out there, we can't reasonably expect them to choose Drupal over other platforms, no matter how good our onboarding is.

So this is what I ask to be measured on: By the end of my term, has the Association built concrete cooperation with the PHP Foundation and comparable organizations? Can we point to large institutions (universities, public sector, and others) that have moved from takers to contributors? If those pieces are in place, the juniors will have a real reason to come.