From Drupal Core to Static Site Innovation: Samuel Mortenson on Tome, SFC, and Open Source Legacy

Not every departure is a clean break. In open source communities, especially ones as enduring as Drupal, contributors often find that stepping away doesn’t mean letting go. The connection remains—quietly persistent, built from years of engagement, and occasionally reignited with a simple check of an issue queue.

Samuel Mortenson knows that kind of connection well.

For nearly a decade, Samuel has been a consistent and influential presence in the Drupal ecosystem. His contributions span core development, tooling, architecture, and community leadership. With experience at organisations like ThinkShout and Acquia, and nearly ten years of activity on Drupal.org, he has helped shape not only the platform’s technical evolution but also how others build with it.

Although he’s no longer contributing full-time to Drupal core, Samuel hasn’t drifted far. He continues to monitor issue queues, revisit ideas, and remain engaged with the project’s direction. His involvement today may be quieter, but it’s no less thoughtful—and no less impactful.

In this conversation, Samuel reflects on that ongoing relationship and the work that continues to carry his signature. We discuss Tome, the static site generator he created to decouple Drupal’s internals—treating configuration, content, and HTML as discrete, version-controlled artefacts. More than a module, Tome represented a shift in thinking: toward portability, reproducibility, and developer autonomy. We also explore TabCMS, an inventive CMS that runs entirely in the browser, and examine his broader contributions to theming systems, developer tools, content APIs, and Single File Components (SFCs)—a modern approach to templating and architecture within Drupal.

Samuel speaks with clarity and commitment, not as someone looking back, but as someone still engaged—still watching, still thinking, still contributing in ways that matter. His story is not one of departure, but of a lasting connection that continues to shape the system he helped build.

So if you're wondering what it looks like to move on without really moving away, to hold onto the core of something even when you’ve walked past its edges, read on.

TDT [1]: You’ve described yourself as “semi-retired” from Drupal.org. For many contributors, that would be a hard transition. What led you to that decision, and how did it feel stepping away from something you helped shape so deeply?

Samuel Mortenson: I guess, professionally, the simplest answer is that I wanted to get into cybersecurity as a career, and that happened to mean stepping away from Drupal. I had volunteered with the Drupal Security Team for a few years at that point and really enjoyed that work—security is one of those “bottomless pit” fields where there’s always more to learn and do.

The weird part about transitioning was how little employers cared about my open-source work. I can’t tell you how many interviews I was in where I heard, “So you worked at Drupal?” I think you build such strong connections with open-source and get so competent in a niche technology that it makes it hard to leave that behind.

TDT [2]: You mentioned that when Drupal was your full-time work, it stayed with you, into evenings, weekends, and your personal site. How did that dual focus, as both a job and a hobby, shape the way you contributed? And what changed when Drupal wasn’t part of your day-to-day anymore?

Samuel Mortenson: It was kind of an insane amount of work. People used to ask how many hours of my free time I would use to contribute, and I was too embarrassed to answer—but I loved it! The way I maintained some amount of work-life balance was that professionally (at Acquia), I was a full-time Drupal core contributor, and in my free time, I worked almost exclusively on my own modules. I’m sure a lot of professional Drupal developers can relate. Contributing can be a fun break from the real world, even if, from the outside, it appears you’re just doing “more Drupal” after hours.

When I stopped doing Drupal at my day job, it was hard to be inspired after hours. Most of my contrib modules solved real problems, but now I don’t really know what problems Drupalers have!

TDT [3]: Tome offers a radical proposition: Drupal, but static. What was the original spark that led you to build it—and did you always envision it being more than just a personal tool?

Samuel Mortenson: Tome was created around the same time as Gatsby was becoming popular, and I think after using Gatsby a bit, I kept wondering, “Wait, what’s the point of a static site if I have to pay for Drupal hosting?”. I was also redesigning my personal site and wanted to use Drupal (or at least, use some CMS), so everything kind of came together at once.

TDT [4]: One of the most striking things about Tome is how it separates concerns: configuration, content, and HTML all become portable, version-controlled, and reproducible. What core problem were you trying to solve with that architecture, and did you look to other systems like Jekyll or Hugo for inspiration, or were you more interested in what only Drupal could offer?

Samuel Mortenson: I really wanted the editorial process for Tome to feel like any other static site generator—check out the repo, edit content, build the static site, and walk away. Since Drupal uses a database, it’s inherently stateful; without Tome, you would need to commit a database backup to Git, which would mostly defeat the usefulness of version control diffs. Tome Sync, which is the submodule that handles this, exports entities to JSON every time they’re edited. On a fresh database, it attempts to import them in the correct order and restore your site to the state it was in at the last commit. There are a lot of tricky problems, but for the most part, it seems to work!

TDT [5]: You’ve mentioned in talks that you were frustrated with the experience of rebuilding your site in Jekyll, then thought, “Why can’t I just use Drupal?” What were the specific features or behaviours in Drupal that you missed most when using traditional static generators?

Samuel Mortenson: I’m tempted to say “all of them”, but when I was migrating my personal site, I really enjoyed using Content Types to create pages beyond blog posts, and WYSIWYG felt amazing coming from editing markdown files. While there’s some custom code in my site, contrib modules like Pathauto and Simple XML sitemap gave me features out of the box that would have been hard to replicate in Jekyll. There’s a reason why static site generators like Gatsby focused on CMS integrations early on: maintaining “serious” editorial sites with markdown files is not fun.

TDT [6]: You’ve spoken about using Drupal like a static site generator, where everything lives in one repo, and the CMS is only used locally. That turns the traditional model on its head. What do you think people still misunderstand about what static really means—or can mean?

Samuel Mortenson: I think Tome Sync (static content) is a legitimately new idea in Drupal, but since Tome packages itself as a static site generator, people only think of static HTML. For example, I used to build sales demos for Acquia, and a major pain point was making demos installable. Essentially, we were using a home-grown version of Default Content and install profiles to give sales reps a starting place for running demos. With Tome Sync, we could have just built otherwise normal Drupal sites and exported them to Git.

So, kind of long-winded, but people miss that 

Tome is basically a way to export and import vanilla Drupal sites. Build a Drupal site the way you normally would, install Tome, export content and/or HTML, and you’re 80% of the way there!

TDT [7]: Your work always seems to start with a real itch—your personal site, your dislike of global styles, or the pain of writing controllers. How do you know when something is worth turning into a full module vs. just a hack for your own site?

Samuel Mortenson: Well, for the most part, I turn almost all of my “hacks” into full contrib modules, but I guess when I was working professionally, I maintained a lot of custom code long term. Contributing to, or all of open-source, is inherently about generalising problems. When you work on something long enough, you start to see patterns in your own code, or frustrations that go long unsolved, and I think that’s when great open source is born.

TDT [8]: You’ve often said you're “done”—but also continue checking your issue queues every few months. If Tome or SFC suddenly got a flood of new users, would that change how you see your role? Is there any part of you that still wants to keep building in this space?

Samuel Mortenson: Mostly, I just want things to keep working. However, if Tome and SFC receive a lot of attention and the issue queue is full of reasonable feature requests, I would probably add new co-maintainers. I’m not really interested in making anything new, although I did make a new install profile for Tome called Bookish (link) just three years ago. One thing that doesn’t help is that my projects are mostly feature-complete, but if I work on my personal site and notice something annoying, maybe I’ll jump back in.

TDT [9]: TabCMS is like Tome’s chaotic younger cousin—no backend at all, just raw files in the browser. What itch did that scratch, and does it come from the same impulse that made you want to strip Drupal down to a static renderer?

Samuel Mortenson: That’s a fun project. I don’t remember exactly what got me started on it, but at the time, there really wasn’t any other CMS that ran in the browser without a backend. The annoying thing with Tome is that you have to run it locally—with Drupal’s ever-shifting platform requirements, it can be really hard to get it working on a new machine (without Docker). TabCMS is pretty bare-bones, but you could probably maintain a blog or personal site with it.

A project in a similar vein is probably https://neocities.org, which, as the name implies, is a spiritual successor to GeoCities and lets you build sites entirely in your browser. Ideally, TabCMS would work offline but have a “one-click” sort of hosting option, or just be integrated into platforms like this.

Recently, I’ve been working with Y.js (link), which lets you build real-time, offline-first web apps using CRDTs. If I had unlimited time, I’d probably create a new version of TabCMS that utilised this feature to enable multiple editors to edit content simultaneously.

TDT [10]: You’ve built APIs, themes, content storage systems, and dev tools—all in service of faster, cleaner, smaller sites. Do you think there's a philosophy that connects all of your work? Something unspoken, but always present?

Samuel Mortenson: I don’t view my projects as being strongly related, but I really enjoy releasing open source that works out of the box or otherwise requires no configuration. I remember my old coworker and Drupal contributor Wim Leers talking about this as a virtue in projects, he worked on REST, Big Pipe, JSON API, and many other things that “just work”.

I recently released ripoff (link), which is a good example of this—it’s a fake data generator that tries to be as straightforward as possible, and should work on any PostgreSQL app without framework-specific configuration. An ambitious long-term goal for it is to be usable as a replacement for Tome Sync, but don’t hold your breath for that.

TDT [11]: A common thread in your projects is minimalism—removing infrastructure, reducing files, keeping things tightly scoped. Is that about performance, portability, or something deeper—like wanting full control over your own tools?

Samuel Mortenson: Drupal is just so complex, and I think a lot of contrib modules try to be everything for everyone. This is practically really great for site builders, but I think it implicitly leads to UX/DX problems down the line. You can mimic my “module style” by looking at an existing part of core or contrib and asking, “What is the simplest form of this thing?” If you look at the code in my modules, it’d be hard to argue I’m a minimalistic, but the user experience always tries to be as straightforward as possible, even if it limits power users.

TDT [12]: SFC turned component theming into a single-file workflow—Twig, styles, JS, and even route definitions in one place. What pain were you feeling that pushed you to throw out the traditional Drupal theming model and just start over?

Samuel Mortenson: I made Single File Components (SFC) around the same time as Pattern Lab adoption was at its peak in Drupal, and while the core ideas behind atomic design were solid, the technical implementation felt really complex to me. I had been using Vue.js a bit, which SFC is largely inspired by. If the “cool kids” building Progressive Web Apps (PWAs) are co-locating everything, why can’t we?

As you mentioned, SFC also allows you to define “actions” (example link), which are server-side callbacks that can be called from components but live in the same file. This probably makes Drupal people shudder, but we’re seeing the same thing adopted in the frontend! React Server Components and Next.js Server Actions exist for the same reason: it is extremely ergonomic to edit everything in one file.

Also, like many of my projects we’ve discussed, SFC powered the rebuild of my personal site (link), so I got to 'dog food' it and improve it significantly early on.

TDT [13]: If you could redesign how we build and deliver websites from scratch—no legacy, no technical debt—what would that system look like, and how close did Tome, SFC, or TabCMS get to that ideal?

Samuel Mortenson: This is kind of a cop-out, but I think it really depends on the client and the engineers you’re working with. If you have a bunch of React developers, they’re going to prefer a headless CMS to Drupal. If you’re building a one-off landing page, plain HTML is often better than a CMS.

I think Next.js is really interesting to look at as an “old school” PHP developer—people are re-discovering that server-side rendering (SSR) and co-locating server and client code feels pretty good!

I can’t tell you what the perfect CMS looks like for everyone, but for me it’s something free, secure, usable, “batteries included”, collaborative, and most importantly, fun. Drupal is something like 70% of the way there.

TDT [14]: Let’s say someone wanted to build the next big static-first CMS. You’ve built one. You’ve lived that reality. What advice would you give them that goes beyond “just write good docs”?

Samuel Mortenson: Have I built one? Haha. I guess my biggest advice is don’t view static sites as a market sector, view it as one possible way to render content from your CMS. When I was building Tome and Gatsby was all the rage, people really thought static sites were the future, but we haven’t seen that come to fruition. It turns out, people like using a CMS, editing content “live”, and they need their websites to actually do something!

TDT [15]: When you think about your legacy in the Drupal world—Tome, SFC, Media, moderation workflows—what do you hope people take away from your work? Not just technically but also in how you approach problems.

Samuel Mortenson: I haven’t thought about this in a while since I don’t contribute much anymore, but when I was in the thick of it, I mostly just wanted people to try my work and find it useful. The best compliment you can get as a contrib developer is “This should be in core”, and I think that’s the sort of scope and level of quality you should strive for as a Drupal developer.

TDT [16]: What project, tool, or idea are you quietly obsessed with right now—something you’re working on in the background, or even just thinking about a lot?

Samuel Mortenson: I’m working on a communications project in my free time called AwaySync (link), and while development has been extremely slow and unfruitful so far, I’ve really been into Y.js (link). I’m interested in how more web apps could be multiplayer, or what experiences get unlocked by collaborating on complex documents.

TDT [17]: With AI making waves across web development, some are asking what an “AI-powered CMS” would even look like. Can you imagine a role for AI within Drupal—from intelligent content suggestions to automatic theming or even smarter config management?

Samuel Mortenson: Good timing—I just started using AI at work, and wrote my first few PRs with it last week. You know, people have high hopes for AI, specifically autonomous AI agents that work without supervision, but I would suggest considering what it’s good at now. Tagging your content, improving search, and making suggestions for your writing—these are all things LLMs seem qualified to do today.

Long-term, it’s interesting to consider what “content” will look like in a post-AI world. If users start to get fatigued by AI-generated “slop”, I wonder if the way we interact with websites will change. Should content editors cater SEO to AI crawlers? Will every website need an MCP API?

I guess there are two ideal futures for me—one is where people hate AI, and flock to platforms that focus on “human-generated” content. Another is where our only interface to the web is through AI, but that interface pushes websites to have useful metadata and not just pump out LLM-generated text. The worst reality is one where nothing has changed besides who (or what) is writing the blog posts.

TDT[18]: You’ve stepped back from active Drupal contribution, but clearly you’re still building projects like TabCMS and AwaySync, suggesting your focus has shifted, not stopped. Can you share what you’re working on now? What’s been capturing your interest lately, and how is it different from—or connected to—the work you did in Drupal?

Samuel Mortenson: I’m still primarily focused on solving problems I encounter at my day job using open source, so that hasn’t changed. Ripoff (link) was created after dealing with some pains around fake data generation, where the framework we use at work felt more awkward than just writing SQL. AwaySync (while private) is a response to communication problems with platforms like Slack.

The main shift for me is that instead of hyper-specialising on a framework like Drupal, I’m trying to make things that are useful for developers using any language or framework. The goal is the same, though—solve real problems for as many people as possible.