Colan Schwartz on Open Source and the Realities of Scaling with Drupal

Colan Schwartz is a technical co-founder, fractional CTO, and enterprise cloud architect with deep roots in the open source world. Over nearly two decades, he has contributed to more than 40 Drupal modules, helped maintain the Aegir Hosting System, and mentored encryption-focused projects through Google Summer of Code. He is also the founder of BackUpScale, a secure backup platform, and a founding partner of Consensus Enterprises, a firm focused on DevOps and cloud automation. Earlier in his career, he played key roles at The Authenticity Institute and contributed to major government platforms like Canada’s Buy & Sell portal.

In this conversation with Alka Elizabeth, sub-editor at The DropTimes, Colan talks about how he got involved with Drupal, what led him to projects like Drubernetes, and why he has always gravitated toward tools that are practical, secure, and built for scale. He shares his experience navigating open source communities, building SaaS products, and helping organizations adopt the right technologies for the right problems.

The discussion moves through both the technical and personal sides of his journey, offering insight into how his work has evolved and what continues to motivate him. It is a candid look at a career shaped by curiosity, independence, and a strong belief in open, well-structured systems.

TDT [1]: You’ve been part of the Drupal world for nearly 20 years. What originally pulled you in, and when did it shift from something you were exploring to something you decided to help shape?

Colan Schwartz: I started my career by building content management systems (CMSs) with Slash, the code used to build Slashdot. At one point, when catching up with one of my friends who I started out with, he told me that they’re no longer using Slash; they’re using some other CMSs now, and Drupal was one of them.

I discovered that there were Drupal meet-ups happening in Toronto, so I started going. There were always people looking for help with Drupal, and not enough developers. So I just started getting work that way. I never really decided to help shape it; that just came with territory in an open-source community. A client would need something done so I’d contribute it back. That’s just how we all worked.

TDT [2]: With over 15 years of Drupal experience and more than 40 contributed modules under your name, which ones are you still actively maintaining today, and how has your approach to module maintenance changed over time?

Colan Schwartz: Truth be told, I never actively maintained any of them over the long term. If I needed a module for a project, and it wasn’t being maintained, I’d take it over to add new features and fix bugs that I needed, and then cut a release that I could use without having to deal with lots of patches. If I couldn’t find a module I needed, I’d just create it. When I finished working on a project, I’d stop actively maintaining it.

What’s changed over the years is that I used to merge code that was reviewed and tested by the community (RTBC) in my spare time, not anything more than that. When I got busier, I stopped.

TDT [3]: You’ve stayed committed to the Aegir Hosting System for years. What is it about Aegir that continues to matter to you, and what do you think people often miss when considering its role in the Drupal ecosystem?

Colan Schwartz: I got into it because I had an idea for a software-as-a-service (SaaS) product that required each customer to have her own Drupal instance. Aegir was the best way to manage such a system; it provided automation before automation was even a thing. I then realized that there was a demand for Aegir consulting so that’s what I started doing for money when I wasn’t working on the SaaS project.

The problem with Aegir was always that we were more interested in using it than doing community outreach. When I was around, we never really sold it, en masse, as a way to manage lots of Drupal sites internally for security, autonomy or sovereignty. It was like Fight Club; we just didn’t talk about it. By the time we started talking about it (I used to say that if you wanted to upgrade 200 Drupal sites with the push of a button, you needed Aegir), the Drupal community had mostly lost interest.

To be honest though, I haven’t thought about it much in over a year. When I left Consensus Enterprises, the firm I started, I was happy to leave it with them. They’ve been working on a reboot, Aegir 5. That SaaS project that I originally worked on is now backburnered, but if anyone else is interested in working on a single-tenant Drupal SaaS application, they’re free to pick up and run with Aegir Site Subscriptions.

TDT [4]: Your consulting career spans a wide range of industries and organizational sizes. What have you noticed as the most common points of friction when teams try to adopt or scale with Drupal?

Colan Schwartz: It’s always the same problem, using the wrong tool for the job. Drupal’s great for some things, but not for others. It was either:

• Using Drupal for a brochure site (no user interaction / logins) when a static site generator (e.g. Hugo) will do. If you don’t need a database, why add all of the Drupal maintenance overhead and security vulnerabilities, when there’s virtually no attack surface with static HTML?
• Using Drupal as a front-end site (with other back-end systems handling data storage). I see Drupal more as a data management framework (DMF) than a CMS: You can point & click your data model together really easily, the framework is solid and there’s a JSON API. While there’s some really interesting work happening with External Entities for front-end sites, if you’re going to go decoupled, my recommendation is to use Drupal for the back end, not the front end.

TDT [5]: With your launch of BackUpScale, you're stepping into the infrastructure and backup space. Do you see this kind of product work as a natural evolution of your Drupal consulting practice, or is it a separate direction?

Colan Schwartz: I always saw it as a separate direction because I hadn't been focusing on Drupal at all, just Cloud Architecture and Infrastructure Automation. But now that I think about it, DevOps came out of the work I did with Drupal, which evolved into these other things.

Drupal had absolutely nothing to do with the BackUpscale prototype. For the Production system, however, we obviously needed a dashboard site so that users can manage their subscription preferences and pay for plans. It seemed like a good fit, and that's what we're planning to launch with, sometime in the next year.

TDT [6]: According to your Drupal.org profile, you were regularly involved in DrupalCons from 2008 through 2015, including Boston, San Francisco, Chicago, Portland, Austin, and Los Angeles. After that, your presence at Drupal events appears to have diminished. What changed for you, and how do you see your connection to the Drupal community today?

Colan Schwartz: At the time, I was doing a lot of traveling from here in Canada so I applied for a Nexus pass, which allows for easier travel to and from the United States (US). It involved an interview with Canadian and US border officers, which shouldn't have been a big deal, but the US border officer was blatantly disrespectful and accusatory. He then cancelled my application with the official reason of "Other", and no explanation. I tried to raise the issue through official channels, but there was simply no accountability. I tried going to the US one more time after that, to represent Drupal for Google's Summer of Code (GSOC) conference, but they gave me hard time then too, leading to me missing my scheduled flight. I eventually made it over, but haven't traveled to the US since, and have no future plans to do so. Why would I spend my money in a country that treats people like that?

For a time, some of us were pushing the Drupal Association to hold DrupalCon events in Canada or Mexico. It made perfect sense because the official name at the time was "DrupalCon North America", which includes all three countries, but they weren't receptive to the idea.

TDT [7]: You’ve been credited on over 400 Drupal issues. At this stage in your career, what guides your decision to contribute, and how do you define impact when it comes to open source?

Colan Schwartz: Again, Drupal is a great tool, but it's not one that I use every day. When I am using it, it's the same as before. If I need something done, and it's not getting done, I'll do it. Whenever possible, I build systems with open-source components because I know that I can make whatever changes I need. It's purely just a way to get things done. I never understood how folks work with proprietary components because it's simply not possible to make changes.

TDT [8]: You recently released Drubernetes, a Terraform module that deploys Drupal inside Kubernetes clusters. What gap were you trying to close with this project, and how does it reflect your broader approach to automation, infrastructure, and Drupal’s role in modern DevOps environments?

Colan Schwartz: Automation is great because you only have set it up once, and it's self-documenting. Additionally, my memory isn't amazing so I don't have to remember how I did something earlier, I just re-run the code. That's why I really like working with infratructure-as-code (IaC) tools like Terraform and Ansible in my Cloud Architecture work. Given the maturity of both Drupal and this other set of tools, I assumed that I'd find a supported automation mechanism for deploying Drupal into Kubernetes. I didn't, so that's how Drubernetes was born. (For the full story, see the article Want to Run Drupal in Kubernetes? Try Our New Terraform Module.)

TDT [9]: You’ve shared research and articles raising serious concerns about the use of AI in software development and beyond. From your perspective as a developer and architect, what do you see as the most pressing risk, and where should the line be drawn between helpful automation and harmful dependency?

Colan Schwartz: I'm not sure what the most pressing risk is, but we need to talk about all of them. Everything in technology is a tool. Drupal is a tool. AI is a tool. I've never subscribed to the philosophy that technology will solve all of our problems, but it can certainly help by providing tools. But tools must be used safely. We don't spend enough time thinking about their social implications; most technologists hold a hammer, and all they can see are nails. What are the safe contexts for which a particular tool is appropriate?

The problem is that most folks working in technology aren't asking the right questions. Why? Because they were never trained to do so. 

To get a Computer Science or Engineering degree, how many ethics or other social science courses are required? The answer is basically zero, literally a round number. 

I took a Social Implications of Computing course in my fourth year, but it certainly wasn't mandatory, and there were only 10 of us. It should have been mandatory. For any students reading this: Take these courses, or at the very least, watch some TV shows that discuss these issues, like Star Trek, Law & Order, and Black Mirror.

TDT [10]: Of all the work you’ve done in the Drupal ecosystem, what is one thing that had a real impact but never got the recognition it deserved?

Colan Schwartz: I was always interested in security and privacy so I mentored a few students for GSOC who were interested in working on encrypting data at rest, which is something that wasn't easy to set up in Drupal back then. The first year I did this, we produced Pubkey Encrypt, which provides server-side encryption. For the second year, we produced Client Side File Cryptography and Client-side content encryption. These were a nice evolution because with client-side, or end-to-end encryption (E2EE) , you don't even have to trust the server that's hosting your data; there's nothing they, or anyone else, can do to access it.

I was never looking for recognition here, but I certainly expected some more uptake. Someone worked on a Drupal 10 release for Pubkey Encrypt, but I've seen no other evidence that anyone's actually used any of these modules. The project pages don't show the number of sites that use them, but it's possible that the security crowd disabled the phoning home that generates this data. In any case, given all of the Internet surveillance that's been going around, I'm really surprised that this functionality hasn't take off. If services like Proton (basically the E2EE version of Google's services, e.g. mail & calendars) are popular, then why aren't folks interested in building other sites and services that can do this? Maybe the time hasn't come for it yet.

TDT [11]: For over a decade, you've worked independently and built multiple ventures, from Consensus Enterprises to BackUpScale. You've navigated client work, product development, and infrastructure design all on your own terms. As someone who’s clearly comfortable operating outside traditional structures, what kind of future are you building for yourself now? Are there new directions you're drawn to, or are you doubling down on the path you've carved so far?

Colan Schwartz: What I'm really passionate about now is building SaaS startups, which I work on whenever I can. But I still enjoy consulting work around DevOps, Cloud Architecture and Infrastructure Automation. For example, if you need help getting Drupal running smoothly in Kubernetes, I'd be happy to help. And don't hesitate to reach out if you're looking for a startup partner, co-founder, or just need some guidance and coaching.