Carview!

CARVIEW

MOTORHOMES

Select Language

HTTP/2 200 date: Sun, 28 Dec 2025 06:41:11 GMT content-type: text/xml; charset=UTF-8 server: cloudflare cache-control: public, max-age=10800 content-language: en x-content-type-options: nosniff x-frame-options: SAMEORIGIN x-generator: Drupal 11 (https://www.drupal.org) strict-transport-security: max-age=31536000; includeSubDomains referrer-policy: strict-origin-when-cross-origin permissions-policy: accelerometer=(), camera=(), geolocation=(), gyroscope=(), microphone=(), payment=(), usb=() x-xss-protection: 1; mode=block x-permitted-cross-domain-policies: none cross-origin-resource-policy: cross-origin cross-origin-opener-policy: same-origin cross-origin-embedder-policy: unsafe-none content-security-policy: base-uri 'self'; upgrade-insecure-requests; default-src 'self' *.youtube-nocookie.com *.ytimg.com; style-src 'self' 'unsafe-inline'; x-drupal-cache: UNCACHEABLE (no cacheability) x-request-id: v-842f91e8-e3ab-11f0-8098-a3546d487c08 x-ah-environment: prod via: varnish x-cache: MISS last-modified: Sun, 28 Dec 2025 05:10:24 GMT cf-cache-status: HIT expires: Sun, 28 Dec 2025 09:41:10 GMT vary: accept-encoding content-encoding: gzip cf-ray: 9b4f1209db3f95be-BLR Dries Buytaert On digital experiences, Open Source, Open Web, Drupal, and our digital future. https://dri.es/ Christmas lights, powered by Drupal https://dri.es/christmas-lights-powered-by-drupal https://dri.es/christmas-lights-powered-by-drupal Wed, 24 Dec 2025 07:49:19 -0500 <figure><img src="https://dri.es/files/cache/drupal/drupal-blue-led-christmas-lights-1280w.jpg" alt="Blue LED string lights, glowing against a dark background" width="1280" height="720" /> <figcaption>Drupal-blue LEDs, controllable through a REST API and a Drupal website. Photo by Phil Norton.</figcaption> </figure> It's Christmas Eve, and Phil Norton is <a href="https://www.hashbangcode.com/article/drupal-11-controlling-led-lights-using-rest-service">controlling his Christmas lights with Drupal</a>. You can visit his site, pick a color, and across the room, a strip of LEDs changes to match. That feels extra magical on Christmas Eve. I like how straightforward his implementation is. A Drupal form stores the color value using the State API, a REST endpoint exposes that data as JSON, and MicroPython running on a Pimoroni Plasma board polls the endpoint and updates the LEDs. I've gone down the electronics rabbit hole myself with <a href="https://dri.es/my-solar-powered-and-self-hosted-website">my solar-powered website</a> and <a href="https://dri.es/building-my-own-temperature-and-humidity-monitor">basement temperature monitor</a>, both using <a href="https://www.drupal.org">Drupal</a> as the backend. I didn't do an <a href="/tag/electronics">electronics project</a> in 2025, but this makes me want to do another one in 2026. I also didn't realize you could buy light strips where each LED can be controlled individually. That alone makes me want to up my Christmas game next year. But addressable LEDs are useful for more than holiday decorations. You could show how many people are on your site, light up a build as it moves through your CI/CD pipeline, flash on failed logins, or visualize the number of warnings in your Drupal logs. This quickly stops being a holiday decoration and starts looking like a tax-deductible business expense. Beyond the fun factor, <a href="https://www.hashbangcode.com/article/drupal-11-controlling-led-lights-using-rest-service">Phil's tutorial</a> does real teaching. It uses Drupal features many of us barely think about anymore: the State API, REST resources, flood protection, even the built-in HTML color field. It's not just a clever demo, but also a solid tutorial. The Drupal community gets stronger when people share work this clearly and generously. If you've been curious about IoT, this is a great entry point. Merry Christmas to those celebrating. Go build something that blinks. May your deployments be smooth and your Drupal-powered Christmas lights shine bright. AI flattens interfaces and deepens foundations https://dri.es/ai-flattens-interfaces-and-deepens-foundations https://dri.es/ai-flattens-interfaces-and-deepens-foundations Tue, 23 Dec 2025 07:44:30 -0500 <a href="https://leerob.com/">Lee Robinson</a>, who works at Cursor, spent $260 in AI coding agent fees to <a href="https://leerob.com/agents">migrate Cursor's marketing site away from Sanity</a>, their headless CMS, to Markdown files. That number should unsettle anyone who sells or implements content management systems for a living. His reasoning: "With AI and coding agents, the cost of an abstraction has never been higher". He argued that a CMS gets in the way of AI coding agents. <a href="https://www.knut.fyi/">Knut Melvær</a>, who works at Sanity, the very CMS Lee abandoned, wrote a rebuttal worth reading. He pointed out that <a href="https://www.sanity.io/blog/you-should-never-build-a-cms">Lee hadn't actually escaped the complexity of a CMS</a>. Lee still ended up with content models, version control, and user permissions. He just moved them out of the CMS and distributed them across GitHub, Vercel, and custom scripts. That reframing is hard to unsee. Meanwhile, the broader momentum is undeniable. <a href="https://lovable.dev/">Lovable</a>, the AI-first website builder, went from zero to <a href="https://techcrunch.com/2025/12/18/vibe-coding-startup-lovable-raises-330m-at-a-6-6b-valuation/">$200 million in annual recurring revenue</a> in twelve months. Users prompt what they want and Lovable generates complete, functional applications. Historically, the visible layer of a CMS, the page builders and content creation workflows, is where most people spend their time. But the invisible layer is what makes organizations trust the system: structured content models, permission systems, audit trails, web service APIs, caching layers, translation workflows, design systems, component libraries, regulatory compliance and more. A useful way to think about a CMS is that roughly 30 percent is visible layer and 70 percent is invisible layer. For more than twenty years, the visible layer was where the work started. You started from a blank state – a page builder or a content form – then wrote the headline, picked an image, and arranged the layout. The visible layer was like the production floor. AI changes this dynamic fundamentally. You can now prompt a landing page into existence in under a minute, or generate ten variations and pick the best one. The heavy lifting of content creation is moving to AI. But AI gets you most of the way, not all the way. The headline is close but not quite right, or there is a claim buried in paragraph three that is technically wrong. Someone still needs to review, adjust, and approve the result. So the visible layer still matters, but it serves a different purpose. It's where humans set direction at the start and refine the result at the end. AI handles everything in between. You can try to prompt all the way to the finish line, but for "the last mile", many people will still prefer using a UI. So the traditional page builder becomes a refinement tool rather than a production tool. And you still need the full UI because it where you review, adjust, and approve what AI generates. What happens to the invisible layer? Its job shifts from "content management" to "context management". It provides what AI needs to do the job right: brand rules, compliance constraints, content relationships, approval workflows. The system becomes more powerful and complex, while requiring less manual work. So my base case for the future of CMS is simple: AI handles eighty percent of the work. Humans handle the remaining twenty by setting direction at the start, and refining, approving, and taking responsibility at the end. This is why Drupal is not standing still. We recently launched <a href="https://dri.es/drupal-canvas-1-0-released">Drupal Canvas 1.0</a> and one of its top priorities for 2026 is maturing <a href="https://dri.es/state-of-drupal-presentation-october-2025">AI-driven page generation</a>. As this work progresses, Drupal Canvas could become an AI-first experience for those who want it. Watching that come together has been one of the most exciting things I've worked on in years. We're far from done, but the direction feels right. Lee proved that a skilled developer with AI coding agents can rebuild a marketing site in a weekend for $260. That is genuinely remarkable. But it doesn't prove that every organization will abandon their CMS. CMSes have to evolve. They have to become a reliable foundation that both humans and AI agents can build on together. The visible layer shifts from where you create to where you refine. The invisible layer does more work but doesn't disappear. Someone still has to direct the system and answer for it when things go wrong. That is not a smaller role. It's a different one. Adaptable Drupal modules: code meant to be adapted, not installed https://dri.es/adaptable-drupal-modules-code-meant-to-be-adapted-not-installed https://dri.es/adaptable-drupal-modules-code-meant-to-be-adapted-not-installed Thu, 18 Dec 2025 04:31:31 -0500 Over the years, I've built dozens of small, site-specific Drupal modules. None of them live on Drupal.org. It makes me wonder: how many modules like that exist across the Drupal ecosystem? I'm guessing a lot. For example, I recently <a href="https://dri.es/i-open-sourced-my-blog-content">open-sourced the content of this blog</a> by exporting my posts as Markdown files and publishing them on GitHub. To do that, I built two custom Drupal modules with Claude Code: one that converts HTML to Markdown, and another that exports content as YAML with Markdown. Both modules embed architectural choices and algorithms I explicitly described to Claude Code. Both have unit tests and have been used in production. But both only work for my site. They're built around my specific content model and field names. For example, my export module expects fields like <code>field_summary</code> and <code>field_image</code> to exist. I'd love to contribute them to Drupal.org, but turning site-specific code into something reusable can be a lot of work. On Drupal.org, contributed modules are expected to work for everyone. That means abstracting away my content model, adding configuration options I'll never use, handling edge cases I'll never hit, and documenting setups I haven't tested. There is a "generalization tax": the cost of making code flexible enough for every possible site. Drupal has always had a strong culture of contribution, but this tax has kept a lot of useful code private. My blog alone has ten custom modules that will probably never make it to Drupal.org under the current model. Generalization work is extremely valuable, and the maintainers who do it deserve a lot of credit. But it can be a high bar, and a lot of useful code never clears it. That made me wonder: what if we had a different category of contributed code on Drupal.org? Let's call them "adaptable modules", though the name matters less than the idea. The concept is simple: tested, working code that solves a real problem for a real site, shared explicitly as a starting point. You don't install these modules. You certainly don't expect them to work out of the box. Instead, an AI adapts the code for you by reading it and understanding the design decisions embedded in it. Or a human can do the same. In practice, that might mean pointing Claude Code at my Markdown export module and prompting: "I need something like this, but my site uses Paragraphs instead of a regular Body field". Or: "I store images in a media field instead of an image field". The AI reads the code, understands the approach, and generates a version tailored to your setup. This workflow made less sense when humans had to do all the adaptation. But AI changes the economics. AI is good at reading code, understanding what it does, and reshaping it for a new context. The mechanical work of adaptation is becoming both cheap and reliable. What matters are the design decisions embedded in the code: the architecture, the algorithms, the trade-offs. Those came from me, a human. They are worth sharing, even if AI handles the mechanical adaptation. This aligns with where engineering is heading. As developers, we'll spend less time on syntax and boilerplate, and more time on understanding problems, making architectural choices, and weighing trade-offs. Our craft is shifting from writing code to shaping code. And orchestrating the AI agents that writes it. Adaptable modules fit that future. Modules that work for everyone are still important. Drupal's success will always depend on them. But maybe they're not the only kind worth sharing. The traditional contribution model, generalizing everything for everyone, makes less sense for smaller utility modules when AI can generate context-specific code on demand. Opinionated, site-specific modules have always lived in private repositories. What is new is that AI makes them worth sharing. Code that only works for my site becomes a useful starting point when AI can adapt it to yours. I created an <a href="https://www.drupal.org/project/drupalorg/issues/3563839">issue on Drupal.org to explore this further</a>. I'd love to hear what you think. (Thanks to <a href="https://www.drupal.org/u/phenaproxima">phenaproxima</a>, <a href="https://www.drupal.org/u/hestenet">Tim Lehnen</a>, <a href="https://www.drupal.org/u/g%C3%A1bor-hojtsy">Gábor Hojtsy</a> and <a href="https://www.drupal.org/u/wim-leers">Wim Leers</a> for reviewing my draft.) A RAID for web content https://dri.es/a-raid-for-web-content https://dri.es/a-raid-for-web-content Tue, 16 Dec 2025 07:22:03 -0500 If you've worked with storage systems, you know <a href="https://en.wikipedia.org/wiki/RAID">RAID</a>: redundant arrays of independent disks. RAID doesn't try to make individual disks more reliable. It accepts that disks fail and designs around it. I recently <a href="/blog/i-open-sourced-my-blog-content">open-sourced my blog content</a> by automatically exporting it as Markdown to GitHub. GitHub might outlive me, but it probably won't be around in 100 years either. No one really knows. That raises a simple question: where should content live if you want it to last decades, maybe centuries? I don't have the answer, but I know it matters well beyond my blog. We are the first generation to create digital content, and we are not very good at preserving what we create. Studies of link rot consistently show that large portions of the web disappear within just a few years. Every time you publish something online, you're trusting a stack: the file format, the storage medium, the content management system, the organization running the service, the economic model keeping them running. When any layer fails, your content is gone. So my plan is to slowly build a "digital preservation RAID" across several platforms: <a href="https://github.com">GitHub</a>, the <a href="https://archive.org">Internet Archive</a>, <a href="https://ipfs.tech/">IPFS</a>, and blockchain-based storage like <a href="https://filecoin.io/">Filecoin</a> or <a href="https://www.arweave.org/">Arweave</a>. If one disappears, the others might remain. Each option has different trade-offs and failure modes. GitHub has corporate risk because Microsoft owns it, and one day their priorities might change. The Internet Archive depends on non-profit funding and has faced <a href="https://www.rollingstone.com/music/music-features/internet-archive-major-label-music-lawsuit-1235105273/">costly legal battles</a>. IPFS requires someone to actively "pin" your content – if no one cares enough to host it, it disappears. Blockchain-based solutions let you pay once for permanent storage, but the economic models are unproven and I'm not a fan of their climate impact. If I had to bet on a single option, it would be the Internet Archive. They've been doing some pretty heroic work the past 25 years. GitHub feels durable but archiving old blog posts will never be Microsoft's priority. IPFS, Filecoin, and Arweave are fascinating technical experiments, but I wouldn't rely on them alone. But the point is not to pick a winner. It is to accept failure as inevitable and design around it, and to keep doing that as the world changes and better preservation tools emerge. The cost of loss isn't just data. It is the ability to learn from what came before. That feels like a responsibility worth exploring. I open-sourced my blog content https://dri.es/i-open-sourced-my-blog-content https://dri.es/i-open-sourced-my-blog-content Mon, 15 Dec 2025 05:15:17 -0500 Last week I wrote that <a href="/a-blog-is-a-biography">a blog is a biography</a>. But sometimes our most advanced technology is also our most fragile. With my blog turning twenty years old in fifteen days, I have been thinking a lot about digital preservation. The question I keep coming back to is simple: how do you preserve a website for hundreds of years? I don't have the answer yet, but it's something I plan to slowly work on over the next 10 years. What I'm describing here is a first step. Humans have been trying to preserve their words since we learned to write. Medieval monks hand-copied manuscripts that survived centuries. Clay tablets from ancient Mesopotamia still tell us about daily life from 5,000 years ago. They worked because they asked very little of the future. A clay tablet basically just sits there. In contrast, websites require continuous maintenance and recurring payments. Miss either, and they quietly disappear. That makes it hard for websites to survive for hundreds of years. Traditional backups may help content survive, but they only work if someone knows they exist and what to do with them. Not a safe bet over hundreds of years. So I am trying something different. I exported my blog as Markdown files and put them on GitHub. Nearly twenty years of posts are now in a public repository at <a href="https://github.com/dbuytaert/website-content">github.com/dbuytaert/website-content</a>. I'm essentially making two bets. First, GitHub does not need me to keep paying bills or renewing domains. Second, a public Git repository can be cloned. Each clone becomes an independent copy that does not depend on me. If you use a static site generator like Jekyll or Hugo, you are probably thinking: "Welcome to 2010!". Fair enough. You have been storing content as Markdown in Git since before my kids could walk. The difference is that most people keep their Git repositories private. I am making mine public. To be clear, my site still runs on <a href="/tag/drupal">Drupal</a>, and that is not changing. No need to panic. I just made my Drupal site export its content as Markdown. For the past two weeks, my site has been auto-committing to GitHub daily. Admittedly, it feels a bit strange to share everything like this. New blog posts show up automatically, but so does everything else: <a href="https://github.com/dbuytaert/website-content/commit/746700c29270d6e63489701c2fc6280b541fb3f5">tag maintenance</a>, even <a href="https://github.com/dbuytaert/website-content/commit/8f00e4b3f03817a8b97316d129a35338b9a1bcf1">deleted posts</a> I decided were not worth keeping. My blog has a publish button, an edit button, and a delete button. In my view, they are all equally legitimate. Now you can see me use all three. Git hides nothing. Exporting my content to GitHub is my first bet, not my last. My plan is to build toward something like a <a href="https://dri.es/a-raid-for-web-content">RAID for web content</a>, spreading copies across multiple systems. A blog is a biography https://dri.es/a-blog-is-a-biography https://dri.es/a-blog-is-a-biography Fri, 12 Dec 2025 03:17:43 -0500 <figure><img src="https://dri.es/files/cache/old-photos-without-date/greet-van-lerberghe-birth-1280w.jpg" alt="A mother in bed holds a newborn baby, surrounded by three formally dressed adults in a hospital room." width="1280" height="931" /> <figcaption>My mom as a newborn in her mother's arms, surrounded by my grandparents and great-grandparents.</figcaption> </figure> I never knew my great grandparents. They left no diary, no letters, only a handful of photographs. Sometimes I look at those photos and wonder what they cared about. What were their days like? What made them laugh? What problems were they working through? Then I realize it could be different for my descendants. A long-running blog like mine is effectively an autobiography. So far, it captures nearly twenty years of my life: my PhD work, the birth of my children, and the years of learning how to lead Drupal and build a community. It even captures the excitement of starting two companies, and the lessons I learned along the way. And in recent years, it captures the late night posts where I try to make sense of what AI might change. They are a snapshot of a world in transition. One day, it may be hard to remember AI was ever new. In a way, a blog is a digital time capsule. It is the kind of record I wish my great grandparents had left behind. I did not start blogging with this in mind. I wrote to share ideas, to think out loud, to guide the Drupal community, and to connect with others. The personal archive was a side effect. Now I see it differently. Somewhere in there is a version of me becoming a father. A version trying to figure out how to build something that lasts. A version wrestling, late at night, with technology changes happening in front of me. If my grandchildren ever want to know who I was, they will not have to guess. They will be able to hear my voice. If that idea feels compelling, this might be a good time to start a blog or a website. Not to build a large audience, but just to leave a trail. Future you may be grateful you began. Can AI clean up its own mess? https://dri.es/can-ai-clean-up-its-own-mess https://dri.es/can-ai-clean-up-its-own-mess Wed, 10 Dec 2025 04:44:54 -0500 In <a href="https://avc.xyz/the-big-blind">The Big Blind</a>, investor Fred Wilson highlights how AI is revolutionizing geothermal energy discovery. This sentence stood out for me: <blockquote> It is wonderfully ironic that the technology that is creating an energy crisis is also a potential solve for that energy crisis. </blockquote> AI consumes massive amounts of electricity, but also helps to discover new sources of clean energy. The source of demand might become the source of supply. I emphasized the word "might" because history is not on our side. But energy scarcity is a "discovery problem", and AI excels at discovery. The geothermal energy was always there. The bottleneck was our ability to find it. AI can analyze seismic data, geological surveys and satellite imagery at a scale no human can match. The quote stood out because technology rarely cleans up its own mess. More cars don't fix traffic and more coal doesn't fix pollution. Usually it takes a different technology to clean up the mess, if it can be cleaned up at all. For example, the internet created information overload, and search engines were invented to help manage it. But here, for AI and energy, the system using the resource might also be the one capable of discovering more of it. I see a similar pattern in open source. Most open source projects depend on a small group of maintainers who review code, maintain infrastructure and keep everything running. They shoulder a disproportionate share of the work. AI risks adding to that burden. It makes it easier for people to generate code and submit pull requests, but reviewing those code contributions still falls on the same few maintainers. When contributions scale up, review capacity has to keep pace. And just like with energy discovery, AI might also be the solution. There already exist AI-powered review tools that can scan pull requests, enforce project standards and surface issues before a human even looks at them. If you believe AI-generated code is here to stay (I do), AI-assisted review might not be optional. I'm no Fred Wilson, but as <a href="https://dri.es/angel-investments">an occasional angel investor</a>, such review tools look like a good way to go long on vibe coding. And as Drupal's Project Lead, I'd love to collaborate with the providers of these tools. If we can make open source maintenance more scalable and sustainable, everyone benefits. So yes, the technology making a situation worse might also be capable of helping to solve it. That is rare enough to pay attention to. 'Source available' is not open source (and that's okay) https://dri.es/source-available-is-not-open-source-and-that-is-okay https://dri.es/source-available-is-not-open-source-and-that-is-okay Tue, 09 Dec 2025 17:22:43 -0500 This week, Ruby on Rails creator David Heinemeier Hansson and WordPress founding developer Matt Mullenweg started fighting about what "open source" means. I've spent twenty years working on open source sustainability, and I have some thoughts. David Heinemeier Hansson (also known as DHH) released a new kanban tool, Fizzy, this week and <a href="https://world.hey.com/dhh/fizzy-is-our-fun-modern-take-on-kanban-and-we-made-it-open-source-54ac41b6">called it open source</a>. People quickly pointed out that the <a href="https://www.fizzy.do/license">O'Saasy license</a> that Fizzy is released under blocks others from offering a competing SaaS version, which violates the <a href="https://opensource.org/osd">Open Source Initiative's definition</a>. When challenged, he brushed it off on X and said, "You know this is just some shit people made up, right?". He followed with "Open source is when the source is open. Simple as that". This morning, <a href="https://ma.tt/2025/12/dhh-open-source/">Matt Mullenweg rightly pushed back</a>. He argued that you can't ignore the Open Source Initiative definition. He compared it to North Korea calling itself a democracy. A clumsy analogy, but the point stands. Look, the term "open source" has a specific, shared meaning. It is not a loose idea and not something you can repurpose for marketing. Thousands of people shaped that definition over decades. Ignoring that work means benefiting from the community while setting aside its rules. This whole debate becomes spicier knowing that <a href="https://www.youtube.com/watch?v=vagyIcmIGOQ">DHH was on Lex Fridman's podcast</a> only a few months ago, appealing to the spirit and ethics of open source to <a href="https://youtube.com/watch?v=vagyIcmIGOQ&t=20506">criticize Matt's handling of the WP Engine dispute</a>. If the definition is just "shit people made up", what spirit was Matt violating? The definition debate matters, but the bigger issue here is sustainability. DHH's choice of license reacts to a real pressure in open source: many companies make real money from open source software while leaving the hard work of building and maintaining it to others. This tension also played a role in <a href="https://dri.es/solving-the-maker-taker-problem">Matt's fight with WP Engine</a>, so he and DHH share some common ground, even if they handle it differently. We see the same thing in Drupal, where contributions from the biggest companies in our ecosystem is extremely uneven. DHH can experiment because Fizzy is new. He can choose a different license and see how it works. Matt can't as WordPress has been licensed under the GPL for more than twenty years. Changing that now is virtually impossible. Both conversations are important, but watching two of the most influential people in open source argue about definitions while we all wrestle with <a href="https://dri.es/scaling-open-source-communities">free riders</a> feels a bit like firefighters arguing about hose lengths during a fire. The definition debate matters because open source only works when we agree on what the term means. But sustainability decides whether projects like Drupal, WordPress, and Ruby on Rails keep thriving for decades to come. That is the conversation we need to have. In Drupal, we are experimenting with contribution credits and with guiding work toward companies that support the project. These ideas have helped, but also have not solved the imbalance. Six years ago I wrote in <a href="https://dri.es/balancing-makers-and-takers-to-scale-and-sustain-open-source">my Makers and Takers blog post</a> that I would love to see new licenses that "encourage software free riding", but "discourage customer free riding". O'Saasy is exactly that kind of experiment. A more accurate framing would be that Fizzy is <a href="https://en.wikipedia.org/wiki/Source-available_software">source available</a>. You can read it, run it, and modify it. But DHH's company is keeping the SaaS rights because they want to be able to build a sustainable business. That is defensible and generous, but it is not open source. I still do not have the full answer to the open source sustainability problem. I have been wrestling with it for more than twenty years. But I do know that reframing the term "open source" is not the solution. Some questions are worth asking, and answering: <ul> <li>How do we distinguish between companies that can't contribute and those that won't?</li> <li>What actually changes corporate behavior: shame, self-interest, punitive action, exclusive benefits, or regulation?</li> </ul> If this latest debate brings more attention to these questions, some good may come from it. The house and the town square https://dri.es/the-house-and-the-town-square https://dri.es/the-house-and-the-town-square Mon, 08 Dec 2025 03:16:31 -0500 Elizabeth Spiers recently wrote <a href="https://www.elizabethspiers.com/requiem-for-early-blogging/">a great retrospective on early blogging</a>. Spiers was the founding editor of <a href="https://en.wikipedia.org/wiki/Gawker">Gawker</a>, a provocative blog focused on celebrities and the media industry. She left in 2003, more than a decade before the site went bankrupt after a lawsuit by Hulk Hogan, funded by Peter Thiel. Today, she continues to blog on her own site, and she captured the difference between the early web and social media perfectly: <blockquote> I think of this now as the difference between living in a house you built that requires some effort to visit and going into a town square where there are not particularly rigorous laws about whether or not someone can punch you in the face. </blockquote> In the early days of blogging, responding to someone's post took real work. You had to write something on your own site and hope they noticed. As Spiers puts it, if someone wanted to engage with you, they had to come to your house and be civil before you'd let them in. If a troll wanted to attack you, they had to do it on their own site and hope you took the bait. Otherwise, no one would see it. It's a reminder that friction can be a feature, not a bug. Having to write on your own blog filtered out low-effort and low-quality responses. Social media removed that friction. That has real benefits: more voices, faster conversations, lower barriers to entry. But it also means the town square gets crowded fast, and some people come just to shout. It's the same in real life. When I think about the best conversations I've had, they happened in someone's living room or around a dinner table, not out in a busy public square, which often feels better suited for protests and parades. It works the same way on the web, which is <a href="https://dri.es/life-beyond-social-media-a-more-intentional-way-to-share-photos">why I'm barely active on social media anymore</a>. I experienced this tension on my own blog. For years I had anonymous comments enabled. I've always believed in the two-way nature of the web, and I still do. But eventually I turned comments off. Every month I wonder if I should bring them back. But as my blog gained traction, the quality of the comments had become uneven. There were more off-topic questions, sloppy writing, and the occasional troll. Of course, there were still great comments that led to real conversations, and those make me rethink turning comments back on. But between Drupal, Acquia, and family, I stopped having the time to moderate. These days the thoughtful responses come by email. It takes more effort than a comment, so the people who write usually have something substantive to say. The downside is that these exchanges stay private, which can be a shame. What I like the most about Spiers' blog post is that the early web didn't just enable better conversation. It required it. You had to say something interesting enough that someone would bookmark your URL and come back. Maybe that is the thing worth protecting: not the lack of a comments section, but the kind of friction that rewards effort. In that spirit, I'm going to make an effort to link to more blog posts worth visiting. Consider this me knocking on Spiers' door. Drupal Canvas 1.0 released https://dri.es/drupal-canvas-1-0-released https://dri.es/drupal-canvas-1-0-released Thu, 04 Dec 2025 17:42:46 -0500 <figure><img src="https://dri.es/files/cache/blog/drupal-canvas-1-released-1280w.png" alt="A futuristic illustration of bikers merged with a screenshot of the Drupal Canvas visual page builder interface." width="1280" height="720" /> </figure> When we launched <a href="https://dri.es/drupal-cms-1-released">Drupal CMS 1.0</a> eleven months ago, I posted the announcement on Reddit. Brave of me, I know. But I wanted non-Drupal people to actually try it. There were a lot of positive reactions, but there was also honest feedback. The most common? "Wake me up when your new experience builder is ready". The message was clear: make page building easier and editing more visual. I was not surprised. For years I have heard the same frustration. Drupal is powerful, but not always easy to use. That criticism has been fair. We have never lacked capability, but we have not always delivered the user experience people expect. Well, wake up. Today we released <a href="https://www.drupal.org/blog/drupal-canvas-is-now-available-inside-drupals-new-visual-page-builder">Drupal Canvas 1.0</a>, a new visual page builder for Drupal. You can create reusable components that match your design system, drag them on to a page, edit content in place, preview changes across multiple pages, and undo mistakes with ease. Watch the video below. Better yet, show it to someone who thinks they know what Drupal looks like. I bet their first reaction will be: "Wait, is that Drupal?". That reaction is exactly what we have been working toward. It makes Drupal feel more modern and less intimidating. <figure><div style="position: relative; padding-bottom: 56.25%; height: 0"><iframe src="https://www.youtube-nocookie.com/embed/g60glSkADlM" style="position: absolute; top: 0; left: 0; width: 100%; height: 100%" loading="lazy" title="YouTube video" allowfullscreen></iframe></div></figure> I also want to set expectations. Drupal Canvas 1.0 helps us catch up with other page builders more than it helps us leap ahead. We had to start there. But it helps us catch up in the right way, bringing the ease of modern tools while keeping Drupal's identity intact. This isn't Drupal becoming simpler by becoming less powerful. Drupal Canvas sits on top of everything that makes Drupal so powerful: structured content, fine-grained permissions, scalability, and much more. Most importantly, it opens new doors. Frontend developers can create components in React without having to learn Drupal first. And as shown in <a href="https://dri.es/state-of-drupal-presentation-october-2025">my DrupalCon Vienna keynote</a>, Drupal Canvas will have an AI assistant that can generate pages from natural language prompts. Drupal Canvas is <a href="https://www.drupal.org/project/canvas">a remarkable piece of engineering</a>. The team at Acquia and contributors across the community put serious craft into this. You can see it in the result. I'm thankful for the time, care, and skill everyone brought to it. So what is next? We keep building. Drupal Canvas 1.0 is step one, and this is a good moment for more of the <a href="https://www.drupal.org/">Drupal community</a> to get involved. Now is the time to build on it, test it, and improve it. Especially because Drupal CMS 2.0 ships in less than two months with Drupal Canvas included. Shipping Drupal Canvas 1.0 is a major milestone. It shows we are listening. And it shows what we can accomplish when we focus on the experience as much as the capability. I cannot wait to see what people build with it.

Original Source | Taken Source