Code, community, and DDEV: Randy Fay's journey
In Episode 6 of The Change Mode Podcast, host Chad Carlson sits down with Randy Fay, the lead maintainer of DDEV, to dive into the world of development environments, TRS-80 nostalgia, and the evolution of open-source communities. Randy takes us on a journey from his early days in programming to his pivotal role in creating DDEV—a tool that’s changing the game for web developers using Docker. With a dash of humor, Randy breaks down how DDEV offers a consistent, isolated workspace across operating systems and why this is a game-changer for devs juggling multiple projects.
Whether you're a seasoned dev or just tech-curious, Randy’s insights on community-driven development and DDEV’s roadmap for 2024 will keep you hooked. Plus, he shares the importance of financial support from sponsors like Platform.sh, which helps the project thrive. Don't miss out on learning how DDEV is empowering developers worldwide and what exciting new features are coming soon—trust us, it’s a conversation you won’t want to miss.
Podcast transcript
We utilized ChatGPT to enhance the grammar and syntax of the transcript.
Chad Carlson: Hello everyone, welcome to a very special episode of the podcast. My name is Chad Carlson, I manage the Developer Relations team here at Platform.sh and Upson, and today I have the pleasure of talking with Randy Fay. Hi Randy.
Randy Fay: How are you doing today? Great to see you.
Chad Carlson: Yeah, you too. I'm doing well. Would you mind just taking a second to introduce yourself to our audience?
Randy Fay: You bet. My name is Randy. I'm R. Fay in most places, R-F-A-Y, and I am the maintainer of DDEV, or the lead maintainer of the DDEV project, and have been doing that for the last seven or eight years. It's loads of fun. I've been doing software for a gazillion years, but DDEV, for the last bit, is really fun. I've been an active, or at least for a long time, I was active in the Drupal community and contributed a lot there. I got involved in core contribution at some point and maintained a bunch of modules. So there's my quick introduction. I live in Palisade, Colorado, the far western side of Colorado, right next to the Utah border, where it's been really hot for the last month.
Chad Carlson: Thanks. If we could go back, what got you interested in programming and technology and working with computers?
Randy Fay: Oh, it's just so much fun. It's like an infinite video game. Video games predate me, or they post-date me, so I never really got into them. But the ability to have an infinite challenge with infinite building blocks, like an infinite set of LEGO or Tinker Toys or an erector set that you never had to buy, was always fascinating to me. When I finally finished college, my goal was to be a history and social studies teacher. I did that for a while, but I failed pretty badly, mostly because I looked like I was 17 and was teaching 17-year-olds. It might have also had something to do with the fact that I bought a TRS-80 Model 1 Level 2 and started staying up all night writing BASIC programs and saving them onto cassette tapes. That was the beginning. It was just so fascinating to build something that you could think of with no limitations.
Chad Carlson: Were there any projects you had in mind when you were working in history and social studies, or was it just purely driven by the desire to build things?
Randy Fay: No, it was just amazing to be able to tinker with stuff. I don't remember what I was trying to write or anything like that. I just remember going at it, trying to make things work, and realizing that you could make them work. I had taken two courses in college, which was all they offered at the place I went. If I had any sense back then, I would have changed schools and gone somewhere to get a CS degree. But I thought it was important to become a teacher, so I did.
Chad Carlson: And what was the transition after that, from teaching to the next chapter?
Randy Fay: I gave up teaching and started looking for a job to support my wife and our newborn daughter. I ended up landing a job where I was supposed to write documentation for a home automation system in 1982, I think. It was a tiny company called CompuHome Systems—basically a guy's living room—and we made a home automation system that was initially written in BASIC on the Apple II. Since there were only three of us, I quickly moved from writing documentation to writing code. We ended up writing a lot of stuff in 6502 Assembler, and I did that for about seven years. It was an amazing opportunity to try new things, but home automation wasn’t really a thing back then. It wasn’t successful, but it was still a great experience.
Chad Carlson: That’s interesting! Documentation was your entry point into coding?
Randy Fay: Yes, exactly. That was my selling point. Writing is something that comes pretty naturally to me, especially in terms of descriptive writing.
Chad Carlson: How do you make, and it might be quite the job, the transition between this initial work into more open source-oriented work and into that world?
Randy Fay: Well, there are a few decades in between. In the early nineties, I got into the Linux world, which was great. Before that, I worked on Unix, specifically AIX, the IBM flavor of Unix. We ended up working on the original generation of mobile data, which was called CDPD, Cellular Digital Packet Data. So, you know, we have 5G today, but that was 1G—the very first generation.
I was doing actual kernel programming because we were writing kernel modules that ran in the Solaris kernel, handling this traffic from CDPD. It was amazing fun, very challenging debugging, and a highlight of my career because I got to work with amazing collaborators. Debugging that kind of code is incredibly difficult, but we developed techniques to handle it and worked together. We worked way too hard, but we had a lot of fun and some great memories.
Later on, I started getting into PHP development and websites. This was around 2005-2006, when websites were becoming the cool thing, and everyone wanted to make them. I started making a few personal websites and eventually landed in the Drupal world. Around that time, my wife Nancy and I were doing a lot of bike touring. We were preparing for an epic bike ride from the top of Canada to Argentina, a two-and-a-half-year journey. We wanted to create a website for it, so we built it with Drupal.
After we got back, I wanted to learn more about open source, and Drupal was the obvious place to start. I dived into that community, and they welcomed me. I had many years of fun and contribution there. While I'm no longer technically up-to-date, I’m still connected to the community, especially since they’ve adopted DDEV.
Chad Carlson: What is DDEV exactly? What problem does it seek to solve for Drupal or otherwise?
Randy Fay: Every website developer needs a place to work on their site. When you’re working with a team, each person needs their own environment. It’s like how artists need their own canvas; they can’t all work on the same one. There was a time when people tried to develop on shared computers, which was a complete disaster.
DDEV allows each developer to work on their own isolated environment. Whether you're working on TYPO3, Drupal, Laravel, or any other project, you can do it in your own space. You can even work on multiple projects at the same time. DDEV makes this possible by using Docker, so all the important pieces run inside containers. This ensures consistency across different operating systems—whether you’re using macOS, Linux, Windows, or WSL2. The idea is that your team members can work on different environments but have the same experience. That’s what DDEV does, and it's a lot of fun.
Chad Carlson: Was its origin from the Drupal community specifically, or was there a broader source?
Randy Fay: The project came from a company called Drud. They were originally trying to build a hosting product and wanted to compete with Platform.sh. A local development component was part of that product, and they had a command-line tool that could do a lot of things, similar to the Platform CLI tool. Early on, it became clear that the local dev component was really useful, so they split it off, and that became DDEV.
DDEV was the part I was most interested in, and for five years, they let me work on it. It was very generous. Eventually, Drud lost its funding, like many companies do. But they let me continue working on DDEV, even though I wasn't much of a fan of their hosting product. It seemed like too big a challenge for a company of five or ten people to try to do what Platform.sh does with hundreds of people. But they were kind enough to let me focus on DDEV, and I’m very grateful for that.
Chad Carlson: That's pretty huge.
Randy Fay: Yeah, it was an amazing gift. I had always been the guy who didn’t have trouble setting up a local environment. I knew how to do the Nginx configuration, the PHP configuration, and the MySQL or MariaDB configuration. So, initially, I was pretty skeptical of DDEV. I thought, "Why would you want to do this when you can just run Apache or Nginx and FPM locally? They run fine on Mac, and you can even run them on traditional Windows." But I soon realized that while I could manage one or two projects with different PHP versions or MySQL versions, handling multiple projects with different environments simultaneously was beyond my abilities. That’s when I was sold on DDEV.
Another key realization was that when people have complex local development setups, the lead dev on the team usually spends all their time maintaining everyone else’s environment. DDEV eliminates that problem. You can check in the configuration, and when a new developer joins, they just run ddev start, and their environment is identical to everyone else’s. That way, people like me—who are comfortable with complex configuration—don’t have to spend all their time helping others who find it mysterious and challenging.
Chad Carlson: Would you say that making development easier for people was the problem you were most attracted to? Or was it more about managing different PHP versions and the complexity of juggling various configurations?
Randy Fay: I think it was both, but mostly I just enjoy making developers happy. DDEV's goal is to make development easier, and from the early days, it was clear that it made some developers really happy. I found that rewarding. When you understand why you’re doing something, who it matters to, and you get positive feedback, it makes the work a lot more fun. That’s what I enjoy about it. And Drud was generous enough to let me continue working on DDEV, which was great for their name as well—they even changed their name to DDEV because people liked it so much.
Chad Carlson: How did Docker change the local development space, and what impact did it have on DDEV?
Randy Fay: Docker came in like a storm, maybe about 10 years ago. Before that, people were using VirtualBox or configuring things directly on their local machines, which worked on Mac and Linux, but wasn’t as flexible. Docker made it so that the setup could be the same everywhere without needing an additional product. It allowed different configurations for multiple projects, which simplified things a lot. Before Docker, there was a lot of painful setup time, especially with VirtualBox, where you’d have to do a build as it started up. Docker made all of that faster and more reliable, which is why it took over the space.
Chad Carlson: That makes sense. And DDEV is a project that’s written in Go, correct?
Randy Fay: That’s right. Well, it’s written in Go and about 15 other languages. The main code is in Go, which acts as the orchestrator. It’s a wrapper around Docker Compose, which is a wrapper around Docker, which runs Linux images with scripts in them. So, it’s a hodgepodge of different things. One of the great things about Go is that it compiles into a native binary that doesn’t need any dependencies—no DLLs or external libraries. You could call it a "fat binary," though that’s not exactly the right term. Essentially, everything it needs is bundled into the binary itself.
In one build, we can create the Mac AMD64 version, the ARM64 version, and the Windows version. We typically build them on Linux, but we could build them anywhere, and they would come out the same. That’s one of the great features of Go. It’s amazing. There are a few disadvantages, though. Our community is mostly PHP users, and for them, Go feels strange and unfamiliar. The learning curve makes it harder for people to contribute to DDEV, which is a challenge for an open-source project.
Chad Carlson: Do you see Go becoming more common in PHP-adjacent projects? I’ve seen some web servers written in Go that are gaining popularity in the PHP space.
Randy Fay: Yes, there’s some crossover. For example, PHP FPM is written in Go, and Docker itself—the client and server—are also written in Go. So, while Go is more commonly used on the operations side, there is definitely some use of it in PHP-adjacent projects. It’s becoming more popular, but it’s still a learning curve for most PHP developers.
Chad Carlson: Aside from the DDEV codebase, are there other places where you like to dedicate your time contributing to open-source? I know training is important to you.
Randy Fay: Yes, I enjoy teaching people how to use DDEV and how to contribute to it. Over the past year or so, we’ve been doing contributor training and other types of training to help people understand how to use DDEV. We’ve had a lot of fun with it, but I also spend time mentoring contributors because we want to grow more maintainers for the project. We don’t want it to be dependent on just me. We have another fantastic maintainer, Stas Zouk, who often handles our releases. He’s an exceptional maintainer, but we want to get him fully funded and grow other contributors and maintainers. I also participate in mentored contributions at events like DrupalCon, helping people learn how to contribute to Drupal or solve technical problems.
Chad Carlson: You brought up something I meant to touch on—you're trying to expand the life of DDEV by supporting additional contributors. How does financially supporting DDEV work these days?
Randy Fay: DDEV is supported by the community. Right now, both Stas and I work on it—I'm full-time, and Stas is about one-third of the time. An amazing thing happened a couple of years ago. After Drud went away, I continued working on the project, but people were understandably suspicious about whether it was still a "going concern" and whether I would carry on with it. Despite that, I just kept going.
After a couple of years, Platform.sh decided to step in and solve some problems. They bought the intellectual property from the original Drud company, including the DDEV name and trademark. That was a huge relief because it solved the issue of using the DDEV name. Even more generously, they started paying me a salary to continue working on it. It was an incredible gesture and really built confidence in the project again. It’s been more than two years now that Platform.sh has been supporting DDEV financially, and we're very grateful for that.
However, we’re trying to get more sponsors. While we have some very generous sponsors, we’d like to get more so we can fully fund Stas and create more space for future maintainers. I won’t last forever—I'm an old guy with an expiration date—so we need the project to be community-maintained and sustainable beyond any one individual.
Chad Carlson: How did Stas become involved, and how did he take on the lead role that he has today?
Randy Fay: It was a classic open-source story. Stas started by taking on important and difficult bugs and features, and he did that consistently over a few years, demonstrating that he was really good at it. He’s a PHP developer, primarily working in Laravel, and he also contributes to Arch Linux—he’s one of those hardcore Linux folks. He kept growing in his contributions, and at some point, I spoke with him about becoming a paid contributor. Last October or November, we introduced him to the community as a full maintainer.
Chad Carlson: So, getting more funding is a priority. What about features? What’s directly ahead for the DDEV project that you’re investing energy into and excited about?
Randy Fay: We have a plan for 2024. DDEV has always evolved based on community input and involvement. Our community is very active, and because we’re attentive to their feedback, DDEV has become what people have asked for. One of our key goals is ongoing support. We have a Discord channel, and we’re active in other places like Stack Overflow. Listening to people’s experiences and learning from them is critical, and we take that seriously. When people have trouble with a feature or hit an error, we work to improve that feature or error output to make things clearer and easier to use.
In addition to support, we have two big goals for 2024. First, we’re working on a web-based add-on registry. We have an add-on ecosystem where people can create add-ons for things like Redis, Elasticsearch, Solr, and more. This system has exploded over the last few years—there are now over a hundred add-ons. While you can get a list of these add-ons with ddev get --list or ddev get --list --all, it’s difficult to navigate a hundred of them. So, we’re building a web-based registry to make it easier for people to browse and understand what’s available.
The second goal is to have a Node.js backend. We already have solid Node.js support integrated into DDEV, but we want to have a direct Nginx and Node backend option, in addition to the current Nginx and PHP setup. Those are our two big focus areas for this year.
Chad Carlson: You mentioned that the community has a significant influence on what DDEV becomes. How has the add-on system impacted people's sense of involvement and the feedback you receive?
Randy Fay: The add-on system has been a huge win in terms of community involvement. Before that, we had a project on GitHub called DDEV Contrib, where people could submit pull requests to share how they solved different problems. The problem with that was things would quickly become obsolete. You know how fast technology moves—something that works today could be broken by tomorrow’s updates.
With the add-on system, each add-on has its own repository and maintainer. If someone has an issue with an add-on, they can open an issue or submit a PR directly to that maintainer. This spreads the responsibility across the community instead of us trying to maintain everything. It’s much more sustainable and allows people to contribute in meaningful ways. From a maintenance and community contribution standpoint, it’s been a huge success.
Chad Carlson: I like that. It sounds like a great system. Thank you, Randy, for taking us through the DDEV project. I think we’ve covered most of the main questions. Now, if you're okay with it, we can move into the lightning round with some lighter, more fun questions.
Randy Fay: Yeah, you bet.
Chad Carlson: Alright, cool. If you weren’t working in software, what do you think you’d be doing now?
Randy Fay: Are you asking what I’d do for work, or how I’d spend my time?
Chad Carlson: Whichever you'd prefer, but let's focus on work.
Randy Fay: I love software and support, so it’s hard to imagine doing anything else. Outside of work, I spend most of my time mountain biking or cycling in some way. Nancy and I have spent many years and thousands of miles bike touring. It’s a huge part of our lives. So, if I weren’t in software, I’d probably be doing more of that.
Chad Carlson: Throughout your career, what’s the most important thing you’ve learned about documentation?
Randy Fay: One of the fundamental things I’ve learned is that people don’t read it. Everybody says that, but it’s true. The key is figuring out how to communicate effectively through docs or other means. Communication has to be two-way—you learn from the people using your project, and you respond to their needs. Good documentation is part of that overall communication process.
Chad Carlson: How do you think your writing has changed over the years?
Randy Fay: I’ve always been a pretty dry, descriptive writer. I’m excellent at being specific and clear, but my writing is very prosaic. I don’t typically write anything particularly engaging or exciting, but I believe in being clear and specific when explaining or describing things. I try hard to be precise, but I wouldn’t claim to know how to write a novel or anything of that nature.
Chad Carlson: What do you think is your greatest strength?
Randy Fay: I would say it's probably that I love doing support. I really enjoy reacting to people and trying to help them solve their problems. That goes back to my Drupal contribution days—feeling like you have something valuable to offer and being able to help people solve problems. One of the most amazing things about open source is that, in some communities, you actually have the opportunity to participate in solving problems. In a community like Drupal or DDEV, if you see a problem, you can contribute to fixing it, and that’s incredibly rewarding.
Chad Carlson: What project are you most proud of working on?
Randy Fay: DDEV is definitely the thing I’m most proud of, but the project where we worked on CDPD, the first generation of cellular data, is also something I’m very proud of. That was fun and amazing, and it paved the way for the cellular data we have now. But DDEV is definitely the highlight—it's been around for several years now, and people love it. It’s exciting to work on something that’s both useful and well-loved.
Chad Carlson: Which project stands out as the most difficult?
Randy Fay: The CDPD project was probably the most technically difficult because we were working at the kernel level and had to develop our own debugging techniques. I’ve worked on many projects that were difficult for other reasons, like the people or the organization, but from a technical standpoint, CDPD was challenging and successful. Many software projects never get rolled out or adopted, but that one did. It was great to see it come to fruition. That said, DDEV has also been challenging in its own ways, but it’s going strong, and it’s been a joy to work on.
Chad Carlson: It’s really impressive to see the community you’ve built and how you’ve cultivated it. We have one more question, and I may need to share my screen briefly. This is just a fun one to close out—how do you pronounce this command?
Randy Fay: I think I’ve always said "chmod." When you brought this up, I looked it up, and there’s a Reddit thread that took years to sort out because everyone has a different opinion. I say "chmod" and "chown," but probably not "chooser"—I think I say "chuser." But yeah, "chmod" is how I pronounce it. What about you?
Chad Carlson: I think in my head, I say "chmod" as well, but this is the “chmodcast” this week! Randy, thank you so much for joining us on the “chmodcast.” Is there anything else you’d like to say to our listeners before we go?
Randy Fay: Just that it’s great to talk with everyone, and I look forward to seeing you wherever we may cross paths.
Chad Carlson: Thank you, Randy, and thank you to everyone listening. See you next time.