fidzu : Drupal

Lots of people working in technology have a choice between working for clients or working for consultants. We work on one side of the relationship thinking how nice it would be to have the advantages of being on the other; the preverbal grass is always seems greener.

I spent a little more than ten years as a client before I became a consultant. I spent just a bit longer as a consultant before becoming a client again. There are things I've learned in each role that help me do the other better. To ensure a mutually beneficial engagement it is helpful to understand the perspective of the other team.

Why is understand both sides useful?

The goals of a consultant and a client organization are misaligned. That doesn't mean you can't do great things together, but if you don't understand the goals of your partner you are likely to step on each other's toes.

The goals of clients

Client looks to consultants for one of two primary reasons:

• Add to team capacity
• Solve a problem

We either need to complete a project that our team does not have the time to tackle, or we need expertise it does not make sense for us to keep on staff. Sometimes we're looking to reduce costs by having a group of part time people fill the roles of a smaller number of fulltime team members.

I like to have my team's staffing level sufficient to complete all day-to-day tasks and to bring in outside help to take on special projects. Other people like to have consultants around consistently to provide the outside perspective and the diverse expertise that consultants bring. Both of those strategies are foundationally aimed at those two needs.

A smart client wants to spend the money needed to be successful, but not more. We want the most value for our money we can possibly get.

The goals of consultants

Consultants have a different pair of primary goals:

• Record billable hours and/or ensure profit margin
• Have a happy client who refers more business

Some consultants will protest that they have the goal to solves client's problems through good work. My perspective is those are way to achieve those two goals. Some clients are happy when you do good work (but not all). All clients are paying to have a problem solved (see above).

Profit motive isn't evil or wrong - even when supporting nonprofits and other socially beneficial institutions (having spent much of my career in nonprofits, we think about this a lot). Consultants need to make money to stay afloat. A consulting firm has people to pay, overhead to manage, and founders/investors to reward. Independent consultants need to eat, pay their mortgage, and so on. The larger the firm, the more pressure there is for larger profit margins.

To get new clients, consultants need "referable" clients. That means having clients who are so happy with the work done they will serve as a reference. I wish that always meant creating the best solution possible. What it means in practice is building the solution that makes the client happy. As a consultant I gave clients my best advice, and when they disagreed and insisted on a different solution, we build that instead. If they ran out of money along the way we still tried to keep them happy, even if we had the duct tape the last bits.

In the end, consultants build what clients pay for, and that's not always the best solution.

Finding the balance

With consultants trying to make the most money they can, and clients trying to get a successful solution for the least money, there is an inherent tension in the system. Still, there is a balance to be had, where everyone wins, and great things happen. The trick is to make it a healthy tension that forces everyone to be better. Finding that balance doesn't require that everyone involved has spent time on the other side the relationships, but it certainly helps.

When you understand the needs and goals of the other side of the relationship you can adjust your approach to make sure everyone is aligned to win.

Lessons to take from being a client

One of the things I learned along the way was that a lot of the advice given to new consultants contradicts what I knew from being a client. Spending time as a client gives you insights into how to best serve customers that many pure consultants don't understand.

Be the consultant you want to hire

When you work at an organization that hires consultants you see different approaches taken by different firms. You learn your preferences about what you like and don't like in a consulting partner. While no one style is the best fit for everyone it's unlikely that you are so unique that there aren't lots of other people who like that same style.

Default to the Golden Rule: treat clients the way you wanted to be treated by consultants.

You can't always do that 100% of the way - sure as a client I want everything free, but that's not reasonable. But by approaching the client the way I would have wanted to be treated consistently went a long way to helping smooth over challenges.

Start there, and over time you'll learn to adapt your approach when specific clients prefer a different style.

Be honest about your limitations

Do. Not. Lie. To. Me.

Do not guess without admitting it. If I wanted made up answers, I'd ask an AI.

Consultants always want to appear to be the expert in the room, and so they feel they have to answer every question. Too often that leads to consultants making up answers to show how smart they are; clients will catch you eventually.

One of the best ways to build trust with a client is admit when you don't know the answer to a question, and then come back later with the answer. Do not say "I don't know" and leave it there, go for some form of "I will need to go look that up/ask around/figure that out."

Great consultants find solutions, they don't always have the answer right away. We can wait for you to do some research when we stump you. That is a lot easier to explain than when you have to walk back having given us the wrong answer.

Focus on what the client needs to succeed

Clients should always have an outcome in mind that supports their work. Consultants are focused on the solution they are building. When everything is going well, that solution is what the client needs to support their work. If those stop being the same thing you have a very big problem.

Both clients and consultants can easily forget to consistently re-check that alignment. As a client and as a consultant I've been part of projects where the delivered solution didn't solve the actual problem - even when it fulfilled the spec and SOW. These moments frequently lead to energetic discussions that often become loud. No one wins when that happens.

Regularly check with the client, and with yourself, to see if the solution will solve the client's problem. When you see misalignment raise your hand early and often.

Lessons to take from being a consultant

Of course consultants know and learn stuff that isn't obvious to any given client. Consultants bring wider experiences, different perspectives, and a different energy to a project. That is part of what makes them valuable. Clients should hire a consultant they trust, and listen to their consultant. Think hard before deciding you know better.

Always learn new things, even if they aren't important today

As a client we tend to learn deeply about the tools we use and our work. Consultants work on a lot of projects with a lot of clients. Along the way they use a lot tools, and see at lot of ideas. That creates a culture and need for constantly learning. Often they are learning about things that don't seem useful right away.

The higher the role you have as a consultant, the more you are expected to be at least conversant about technology you haven't used yet. You also need to be conversant about the work of your clients. That's a lot of learning.

I had good learning habits going in to being a consultant. They served me extremely well as a consultant, and are serving me well again as a client.

The broad knowledge of a consultant is extremely useful and everyone benefits from more people knowing more stuff. Having that breadth of knowledge also helps when you do run into the places where you don't know something. It gives you the confidence that you can go learn the next thing you need to know quickly (see Be honest about your limitations above).

Know how to work to a deadline

Consultants are always working within time and budget constraints - usually tight ones. That forces them to learn to be efficient. Sometimes that means they cut corners (see next section) usually that just means they move fast. Good consultants have a high degree of dexterity with their tools, they learn to line up their work to knock out tasks, and they learn what's needed and what's just nice to have.

New consultants often feel like they are sprinting all the time, but experienced consultants learn to balance the sprints with jogging. The pace is nearly always high (at least if sales are going well), but it still ebbs and flows. Consultants learn to hit their deadlines, but rarely are ready to deliver early.

As a consultant if a deadline was far in the future it gave me time to do careful work, balance other clients, do research, or just time off. Far off deadlines gave me time to recover from sprints and make sure I had the energy for high intensity moment. That intensity is important to driving client success - but hitting the deadline is more important.

Hitting deadlines is also important for a client to do. Consultants need you to hit your deadlines so they can balance their workload to hit their deadlines. They may also have penalties embedded in the contract (see Read the Contract below) that could cost you time or money over the course of your project.

Perfect is the enemy of the good

Okay, this isn't something just consultants know, but it is something consultants often learn to deal with the hard way.

Consultants need a solution that meets the requirements, fits in the budget, and pleases the client. They are not there to create a solution that is perfect, or even elegant. In any project there is a balance to be had between carefully polished, and just barely good enough to be successful. Consultants learn to thread that needle. As long as the project is successful that's a good thing.

I have seen developers spend hours, days, even months, trying to build to the perfect level of abstraction, with the perfect naming conventions, and drive for the perfect code, only to have the project fail because it's overdue, over budget, and was outmoded by someone who worked twice as fast.

Yes, we all want good solutions to our technical problems. But no solution is going to be perfect. You should aim for perfection and know you are going to miss. When you learn to accept that, it'll be easier to move forward and be successful.

Things everyone should know regardless of role

For all there are things that each side brings something to the table, there are habits that everyone should have as part of their role. There are lessons I learned, or was taught, in both roles that are super important.

Read, and understand, the contract

Everyone on a project benefits from having working knowledge of the contract. In the end, when push comes to shove, all that matters is the words on the paper. You can usually avoid the pushing and shoving by understanding what everyone agreed to up front.

The biggest issues I've seen on consulting projects was when one side, or the other, didn't pay attention to the agreement.

Sometimes this happens because everyone is working in good faith, and no one remembers to amend the agreement when needs changed. In those cases you can often recover by continuing to work with each other in good faith.

Sometimes this happens when someone signed a contract they didn't read and understand. I once had a client yell at me because I added a paragraph to the contract outlining the resources they were responsible for providing and he didn't read it before we asked him for those resources (these clauses are really standard, and the one I wrote was extremely simple).

If everyone on the team takes the time to read and understand the contract it greatly reduces friction. Clients who understand the bounds and assumptions in a contract are able to get the most from their vendor without creating tension. Consultants who track the required deliverables of the contract don't frustrate clients by skipping required elements. It doesn't take long. The more you read them the faster we'll be at reading the next one.

Once you have read a bunch of contracts you'll know what's normal and what's not. At this point, if I don't understand the contract language I see that as a red flag even before I send it out for legal review.

Discuss problems and be solution oriented

Projects go best when everyone is open about what problems exist and then pivots to solving them.

Technology should be deployed to solve problems. That means starting by talking about problems. Being problem focused at the start makes it easy to be hung up talking only about those problems, or about new problems that come up while solving the first problem.

Having a good problem statement is critical to creating good solutions. But once you have the problem outlined you need to focus on solving it. Yes, raise problems, concerns, challenges, threats, weaknesses, etc. Talk openly about all those things. Then make the pivot into problem solving mode once the issue is well understood.

The best projects come together when when everyone collaborates on finding the best solutions to the problems at hand.

Quality matters

Everyone needs to focus on the quality of the outcome. Consultants, for all their fast moving creation of imperfect solutions, must still do good work. Clients should hold their vendors, and themselves, to high standards.

Every message that goes back and forth is a chance for misunderstand that gets in the way. Every input into discovery and every deliverable is a chance for gaps to form. If anyone takes their eye off the ball mistakes can happen and the solution no longer threads the quality needle correctly.

Mistakes will happen, and everyone will have to help course correct. But the higher the quality of the work done before the mistake, the faster it will be to recover and better and overall solution the client will get.

The Grass is Greener

One final note on the way out. If you are trying to decide between being a consultant or being a client, I recommend the switch - whichever you are today try being the other if you haven't yet. Not everyone loves both roles, and different roles have been right for me at different times.

As a client I loved what I did. We were helping make the world better. I was pushing things forward and helping the organizations succeed. But eventually the things they needed me to learn, and the pace I wanted to grow, weren't aligned to the organization's needs.

I'd been there a decade, I left on great terms, but it was time to go.

When I first became a consultant it was exciting. I got to work on a variety of projects, with more technologies than any one organization generally needs. The pace was higher and I was frequently pushing myself in new directions. Consulting gave me insights into how different organizations worked (for both better and worse). And I made more money.

Interesting work, exciting environment, more money, great!

As a consultant I spent less time in positions, the billable grind was exhausting, I missed being focused. When I returned to the client side, I got to focus again. I have one org to worry about, one set of organizational politics to understand, and so on. I get to learn the work of the organization deeply again and really understand the market we serve. In my case I, again, got more money - but that was at least partially luck as much as anything; consultants are often paid better than in-house team members.

Focused work, no billable hours target, calmer work environment, great!

Each really does have it's advantages. But so does understanding what it's like to be the person on the other side the relationship. Try them both, learn from both, decide what's the best fit for you.

31 Jan 2026 5:36pm GMT

My LocalGov Drupal contributions for January 2026

markconroy 30th Jan 2026

30 Jan 2026 3:44pm GMT

30 Jan 2026 2:09pm GMT

Held in Ghent during EU Open Source Week, Drupal Pivot brought together agencies and contributors for open conversations on resilience, AI, and digital sovereignty. Its timing, with the release of Drupal CMS 2.0, made it a point of reflection and transition.

30 Jan 2026 1:33pm GMT

AI document processing is transforming content management in Drupal. Through integration with AI Automators, Unstructured.io, and GPT models, editorial teams can automate tedious tasks like metadata extraction, taxonomy matching, and summary generation. This case study reveals how BetterRegulation implemented AI document processing in their Drupal 11 platform, achieving 95%+ accuracy and 50% editorial time savings.

30 Jan 2026 10:55am GMT

AI makes it cheaper to contribute to Open Source, but it's not making life easier for maintainers. More contributions are flowing in, but the burden of evaluating them still falls on the same small group of people. That asymmetric pressure risks breaking maintainers.

The curl story

Daniel Stenberg, who maintains curl, just ended the curl project's bug bounty program. The program had worked well for years. But in 2025, fewer than one in twenty submissions turned out to be real bugs.

In a post called "Death by a thousand slops", Stenberg described the toll on curl's seven-person security team: each report engaged three to four people, sometimes for hours, only to find nothing real. He wrote about the "emotional toll" of "mind-numbing stupidities".

Stenberg's response was pragmatic. He didn't ban AI. He ended the bug bounty. That alone removed most of the incentive to flood the project with low-quality reports.

Drupal doesn't have a bug bounty, but it still has incentives: contribution credit, reputation, and visibility all matter. Those incentives can attract low-quality contributions too, and the cost of sorting them out often lands on maintainers.

Caught between two truths

We've seen some AI slop in Drupal, though not at the scale curl experienced. But our maintainers are stretched thin, and they see what is happening to other projects.

Some have deep concerns about AI itself: its environmental cost, its impact on their craft, and the unresolved legal and ethical questions around how it was trained. Others worry about security vulnerabilities slipping through. And for some, it's simply demoralizing to watch something they built with care become a target for high-volume, low-quality contributions.

These concerns are legitimate, and they deserve to be heard. Some of them, like AI's environmental cost or its relationship to Open Web values, also deserve deeper discussion than I can give them here.

That tension shows up in conversations about AI in Drupal Core. People hesitate around AGENTS.md files and adaptable modules because they worry about inviting more contributions without adding more capacity to evaluate them.

This is the AI-induced asymmetric pressure showing up in our community. I understand the hesitation. Some feel they've already seen enough low-quality AI contributions to know where this leads. When we get this wrong, maintainers are the ones who pay. They've earned the right to be skeptical.

I feel caught between two truths.

On one side, maintainers hold everything together. If they burn out or leave, Drupal is in serious trouble. We can't ask them to absorb more work without first creating relief.

On the other side, the people who depend on Drupal are watching other platforms accelerate. If we move too slowly, they'll look elsewhere.

Both are true. Protecting maintainers and accelerating innovation shouldn't be opposites, but right now they feel that way. As Drupal's project lead, my job is to help us find a path that honors both.

I should be honest about where I stand. I've been writing software with AI tools for over a year now. I've had real successes. I've also watched some of the most experienced Drupal contributors become dramatically more productive with AI, doing things they could not have done without it. That perspective comes from direct experience, not hype.

But having a perspective is not the same as having all the answers. And leadership doesn't mean dragging people where they don't want to go. It means pointing a direction with care, staying open to evidence, and never abandoning the people who hold the project together.

We've sort of been here before

New technology has a way of lowering barriers, and lower barriers always come with tradeoffs. I saw this early in my career. I was writing low-level C for embedded systems by day, and after work I'd come home and work on websites with Drupal and PHP. It was thrilling, and a stark contrast to my day job. You could build in an evening what took days in C.

I remember that excitement. The early web coming alive. I hadn't felt the same excitement in 25 years, until AI.

PHP brought in hobbyists and self-taught developers, people learning as they went. Many of them built careers here. But it also meant that a lot of early PHP code had serious security problems. The language got blamed, and many experts dismissed it entirely. Some still do.

The answer wasn't rejecting PHP for enabling low-quality code. The answer was frameworks, better security practices, and shared standards.

AI is a different technology, but I see the same patterns. It lowers barriers and will bring in new contributors who aren't experts yet. And like scripting languages, AI is here to stay. The question isn't whether AI is coming to Open Source. It's how we make it work.

AI in the right hands

The curl story doesn't end there. In October 2025, a researcher named Joshua Rogers used AI-powered code analysis tools to submit hundreds of potential issues. Stenberg was "amazed by the quality and insights". He and a fellow maintainer merged about 50 fixes from the initial batch alone.

Earlier this week, a security startup called AISLE announced they had used AI to find 12 zero-days in the latest OpenSSL security release. OpenSSL is one of the most scrutinized codebases on the planet. It encrypts most of the internet. Some of the bugs AISLE found had been hiding for over 25 years. They also reported over 30 valid security issues to curl.

The difference between this and the slop flooding Stenberg's inbox wasn't the use of AI. It was expertise and intent. Rogers and AISLE used AI to amplify deep knowledge. The low-quality reports used AI to replace expertise that wasn't there, chasing volume instead of insight.

AI created new burden for maintainers. But used well, it may also be part of the relief.

Earn trust through results

I reached out to Daniel Stenberg this week to compare notes. He's navigating the same tensions inside the curl project, with maintainers who are skeptical, if not outright negative, toward AI.

His approach is simple. Rather than pushing tools on his team, he tests them on himself. He uses AI review tools on his own pull requests to understand their strengths and limits, and to show where they actually help. The goal is to find useful applications without forcing anyone else to adopt them.

The curl team does use AI-powered analyzers today because, as Stenberg puts it, "they have proven to find things no other analyzers do". The tools earned their place.

That is a model I'd like us to try in Drupal. Experiments should stay with willing contributors, and the burden of proof should remain with the experimenters. Nothing should become a new expectation for maintainers until it has demonstrated real, repeatable value.

That does not mean we should wait. If we want evidence instead of opinions, we have to create it. Contributors should experiment on their own work first. When something helps, show it. When something doesn't, share that too. We need honest results, not just positive ones. Maintainers don't have to adopt anything, but when someone shows up with real results, it's worth a look.

Not all low-quality contributions come from bad faith. Many contributors are learning, experimenting, and trying to help. They want what is best for Drupal. A welcoming environment means building the guidelines and culture to help them succeed, with or without AI, not making them afraid to try.

I believe AI tools are part of how we create relief. I also know that is a hard sell to someone already stretched thin, or dealing with AI slop, or wrestling with what AI means for their craft. The people we most want to help are often the most skeptical, and they have good reason to be.

I'm going to do my part. I'll seek out contributors who are experimenting with AI tools and share what they're learning, what works, what doesn't, and what surprises them. I'll try some of these tools myself before asking anyone else to. And I'll keep writing about what I find, including the failures.

If you're experimenting with AI tools, I'd love to hear about it. I've opened an issue on Drupal.org to collect real-world experiences from contributors. Share what you're learning in the issue, or write about it on your own blog and link it there. I'll report back on what we learn on my blog or at DrupalCon.

Protect your maintainers

This isn't just Drupal's challenge. Every large Open Source project is navigating the same tension between enthusiasm for AI and real concern about its impact.

But wherever this goes, one principle should guide us: protect your maintainers. They're a rare asset, hard to replace and easy to lose. Any path forward that burns them out isn't a path forward at all.

I believe Drupal will be stronger with AI tools, not weaker. I believe we can reduce maintainer burden rather than add to it. But getting there will take experimentation, honest results, and collaboration. That is the direction I want to point us in. Let's keep an open mind and let evidence and adoption speak for themselves.

Thanks to phenaproxima, Tim Lehnen, Gábor Hojtsy, Scott Falconer, Théodore Biadala, Jürgen Haas and Alex Bronstein for reviewing my draft.

30 Jan 2026 12:58am GMT

Lessons for building a digital repository of archival material, stories, or user-generated knowledge.

Digital archives play an increasingly important role in preserving cultural knowledge, personal histories, and community memory. But not all archives are created equal. Beyond simply storing information, the most effective digital archives are designed to be welcoming, respectful, and alive - spaces that invite exploration while honouring the people and knowledge they represent.

At Evolving Web, we recently collaborated with the University of Denver on the Our Stories, Our Medicine Archive (OSOMA), a community-owned digital archive that centres traditional Indigenous knowledge related to health, wellness, culture, and identity. Built in close collaboration with community partners, OSOMA offers a powerful example of how digital repositories can move beyond institutional models toward something more participatory and human.

If you're working on a digital archive - whether it's focused on cultural heritage, community storytelling, or user-generated knowledge - here are some key lessons from OSOMA that can help guide your approach.

Design for discoverability, not just storage

A strong digital archive doesn't assume users know exactly what they're looking for. Instead, it supports exploration and discovery.
On OSOMA, visitors can browse content by broad themes such as Plants, Food, Ceremony, Identity, and Land. From there, they can narrow their focus using more specific filters, for example, exploring knowledge connected to particular healing practices or types of medicine.

This structure allows users to move easily between big ideas and specific stories. Someone might begin by browsing "Plant Medicine" and then discover individual narratives, videos, or related knowledge shared by community members. The archive encourages curiosity rather than forcing users into rigid pathways.
By organizing content around themes that reflect Indigenous worldviews, rather than academic or institutional categories. OSOMA makes it easier for users to find meaning, not just information.

Use plain language to build trust

Plain language plays an important role in making digital archives accessible, but it also shapes how users feel when they engage with the content.

Across OSOMA, headlines, descriptions, and navigation labels are written in clear, approachable language. The content doesn't feel instructional or authoritative, and it avoids positioning itself as a definitive source of medical advice. Instead, it presents stories, experiences, and teachings in a way that feels open-ended and respectful.

This tone is especially important for an archive focused on health and wellness. By avoiding prescriptive language, OSOMA creates space for users to learn without pressure, and reinforces that the knowledge being shared belongs to the community, not the platform.

Make it easy to access knowledge quickly

OSOMA includes rich media such as videos and interviews, and the way users access that content is intentional.

For example, users can watch videos directly from search and results pages, without needing to click through multiple screens. This makes it easier to sample content, follow related threads, and continue exploring without losing context.

These small experience details matter. They reduce friction and make the archive feel responsive and intuitive, especially for users who may be less comfortable navigating complex digital interfaces.

Focus on personal stories over institutions

Many digital archives unintentionally feel institutional, even when they contain deeply personal material. OSOMA takes a different approach by placing individual voices front and centre.

Each community member has a dedicated profile page that brings together their stories, interviews, and related knowledge items. These profiles help users understand who is sharing the knowledge, where it comes from, and how it connects to lived experience.

Stories aren't treated as supplementary content, they are the foundation of the archive. This storytelling-first approach reflects Indigenous knowledge traditions, where stories are a primary way of sharing history, values, and healing practices. The result is an archive that feels human and relational, rather than abstract or academic.

Make participation visible and welcoming

OSOMA was designed as a living, community-owned archive, and that intention is visible throughout the site.

Links and prompts to contribute are displayed prominently, making it clear that community members are invited to share their own stories and knowledge. Even visitors who never log in or submit content can immediately sense that OSOMA is shaped by ongoing participation.

Behind the scenes, the platform supports this model by allowing Indigenous users to log in, contribute content, and access protected cultural knowledge. Using Drupal's Group functionality, the site ensures that sensitive information remains visible only to appropriate community members.

Participation isn't treated as an add-on but rather it's built into the structure of the archive itself.

Use design to support confidence and cohesion

Strong visual design helps establish trust, especially when an archive contains many voices and content types.
OSOMA uses photography and video of people, land, and cultural assets to ground the experience in real places and lived relationships. Circular image frames and a consistent colour palette draw from OSOMA's visual identity and help tie together diverse content.

These design choices do important work quietly. They lend confidence to the stories being shared and ensure the site feels cohesive, even as new contributions are added over time. Rather than competing with the content, the design supports it, creating space for stories to speak for themselves.

Accessibility is foundational, not optional

OSOMA was built to be welcoming to a wide range of users, including Elders, youth, and non-specialist visitors.

The site meets WCAG AA accessibility standards, with clear layouts, strong colour contrast, and plain-language content. Navigation and browsing tools were designed to be intuitive, so users can explore without needing technical expertise.

Accessibility here isn't treated as a compliance exercise. It's part of a broader commitment to inclusion, respect, and ease of use: values that align closely with OSOMA's community-led goals.

Building archives that honour living knowledge

OSOMA demonstrates that digital archives don't have to replicate colonial or extractive models of knowledge storage. With the right approach, they can become spaces of connection, care, and continuity.

By prioritizing discoverability, plain language, personal storytelling, participation, strong design, and accessibility, OSOMA offers a powerful example of what's possible when technology is shaped by community values.

If you're thinking about building a digital archive or knowledge platform, this project is a reminder to look beyond the technical requirements and ask deeper questions about ownership, voice, and experience.

Get in touch to talk about building digital platforms that are inclusive, future-friendly, and people-first.

Learn more about the OSOMA project by reading the case study.

+ more awesome articles by Evolving Web

29 Jan 2026 1:15pm GMT

Watch the Dries fireside chat from 2025, or catch up on all of the sessions from last year on Drupal.tv.

Theres even more Drupal goodness to be had in our archives or Drupal.tv's.

The Archives: 2024 2023 2022 2021 2020 2019 2018 2017 2016 2015 2014

29 Jan 2026 4:24am GMT

Today we released Drupal CMS 2.0. I've been looking forward to this release for a long time!

If Drupal is 25 years old, why only version 2.0? Because Drupal Core is the same powerful platform you've known for years, now at version 11. Drupal CMS is a product built on top of it, packaging best-practice solutions and extra features to help you get started faster. It was launched a year ago as part of Drupal Starshot.

Why build this layer at all? Because the criticism has been fair: Drupal is powerful but not easy. For years, features like easier content editing and better page building have topped the wishlist.

Drupal CMS is changing Drupal's story from powerful but hard to powerful and easy to use.

With Drupal CMS 2.0, we're taking another big step forward. You no longer begin with a blank slate. You can begin with site templates designed for common use cases, then shape them to fit your needs. You get a visual page builder, preconfigured content types, and a smoother editing experience out of the box. We also added more AI-powered features to help draft and refine content.

The biggest new feature in this release is Drupal Canvas, our new visual page builder that now ships by default with Drupal CMS 2.0. You can drag components onto a page, edit in place, and undo changes. No jumping between forms and preview screens.

WordPress and Webflow have shown how powerful visual editing can be. Drupal Canvas brings that same ease to Drupal with more power while keeping its strengths: custom content types, component-based layouts, granular permissions, and much more.

But Drupal Canvas is only part of the story. What matters more is how these pieces are starting to fit together, in line with the direction we set out more than a year ago: site templates to start from, a visual builder to shape pages, better defaults across the board, and AI features that help you get work done faster. It's the result of a lot of hard work by many people across the Drupal community.

If you tried Drupal years ago and found it too complex, I'd love for you to give it another look. Building a small site with a few landing pages, a campaign section, and a contact form used to take a lot of setup. With Drupal CMS 2.0, you can get something real up and running much faster than before.

For 25 years, Drupal traded ease for power and flexibility. That is finally starting to change, while keeping the power and flexibility that made Drupal what it is. Thank you to everyone who has been pushing this forward.

28 Jan 2026 9:05pm GMT

Zoocha has unveiled a new brand identity to reflect its transition from a Drupal development agency to a digital experience agency powered by Drupal. The rebrand responds to client demand for broader creative and strategic capabilities and positions the company for a market increasingly shaped by AI-driven digital experiences.

28 Jan 2026 2:10pm GMT

28 Jan 2026 3:13am GMT

28 Jan 2026 3:13am GMT

Setting up a local Drupal development environment requires tools that handle web servers, databases, and PHP configuration. DDEV provides a Docker-based solution that simplifies this process while maintaining flexibility for different project requirements.

In the video above, you'll learn how to install and configure DDEV, create a new Drupal project, use essential commands for daily development, import and export databases, set up debugging with Xdebug, and extend DDEV with add-ons and custom commands.

27 Jan 2026 8:20pm GMT

Are you building your business on rented land? We all have 'digital landlords' but are we conscious to the risks they pose?

27 Jan 2026 5:15pm GMT

Europe's push for digital sovereignty is gaining momentum, but much of the conversation remains superficial. Drawing on the recent analysis by Dries Buytaert, founder of Drupal, the real issue is not whether governments use European or non-European vendors-it's whether they retain meaningful control over the software that underpins public services. Dependency, not geography, is the risk. Several public institutions are beginning to act on this insight, but the structural implications remain largely unaddressed.

Dries' argument reframes open source from a technical preference into a governance imperative. Open source offers auditability, portability, and independence that proprietary systems cannot. Yet, while Europe's public sector heavily relies on open source, it consistently fails to invest in its foundations. Procurement practices continue to channel funding toward large integrators and resellers, leaving the maintainers who secure and evolve the software underfunded and overstretched.

The result is a stark mismatch between policy ambitions and spending realities. Governments pay for delivery and compliance but neglect the upstream work that ensures long-term security, resilience, and innovation. As Buytaert makes clear, digital sovereignty won't be achieved through strategy papers alone. It demands procurement policies that treat open-source contributions as a core public value-not an optional extra.

With that, let's move on to the important stories from the past week.

DRUPAL COMMUNITY

• Is MySQL Still Right for Drupal? Andrés Torres Russo Urges a Rethink

DISCOVER DRUPAL

• Drupal Migrate Plus 6.0.9 Requires PHP Attributes Over Annotations
• Drupal AI Adds mittwald Provider v1.0 to Support Hosted AI Models
• Display Builder Beta 1 Unifies Layout Interfaces for Drupal Site Builders
• Augusto Fagioli Releases Business Identity 1.0.0 to Streamline Company Data in Drupal
• Creodrop Promises One-Click Drupal Hosting Without the DevOps Headache

EVENT

• Upcoming Zoocha Webinar Showcases Global Touring's Drupal Success
• Drupal Powers EU Open Source Week 2026 With Policy, Innovation, and Community Events
• AmyJune Hineline Announced as Featured Speaker for Florida DrupalCamp 2026
• DrupalCamp Grenoble 2026 Opens Sponsorship Packages
• Dripyard and Lullabot to Deliver Future‑Proof Theming Training at DrupalCon Chicago 2026
• Drupal Iberia 2026 Set for 8-9 May in Braga, Tickets Now Available

FREE SOFTWARE

• Dries Buytaert Urges Europe to Fund Open Source Maintainers for Digital Sovereignty

TRAINING

• Architect Accelerator Course Challenges the Limits of Traditional Drupal Training

We acknowledge that there are more stories to share. However, due to selection constraints, we must pause further exploration for now. To get timely updates, follow us on LinkedIn , Twitter , Bluesky , and Facebook . You can also join us on Drupal Slack at #thedroptimes .

Thank you.

Alka Elizabeth
Sub-editor
The DropTimes

27 Jan 2026 3:36pm GMT

Planning to scale Drupal? Understand consulting costs, what great Drupal consulting covers, and how to pick a partner who improves speed, security, and maintainability.

27 Jan 2026 12:43pm GMT