The Drupal (news, site) open source web content management system is developed by thousands and used by millions of people around the world, powering a diverse range of websites. In this interview, I visit with Drupal's creator, Dries Buytaert, who explains how Drupal evolved over the past ten years, out of a simple message board written in a college dormitory in Belgium. He discusses how his company, Acquia (news, site), has impacted his ability to focus on Drupal, weighs in on some of the new features in Drupal 7 and looks toward the next decade of progress.
When we began this interview, Dries was on a Drupal tour in Australia, calling from a hotel room in Sidney. For Dries, trips like this are becoming more and more common, allowing him to meet an increasing number of the people all over the globe using and developing Drupal.
He listens to success stories and challenges faced in adopting or migrating to Drupal. “It helps me as the project lead to talk to as many Drupal people as I can”, he explained. Later this year he's planning an around-the-world tour, literally flying around the world visiting as many countries as he can to talk about Drupal.
Jeremy Andrews: What were you doing before you started the Drupal project?
Dries Buytaert: As a high school student my first job was making hamburgers at “Quick”, a European fast food chain. In college I studied Computer Science at the University of Antwerp. I spent my time studying, but like any student I also enjoyed having a good time. I was fortunate that my parents paid for the basics like tuition and books, but I got a job at an ISP so I could buy gadgets and pay for other fun things. I was one of their first hires, and running the service desk and doing outside sales was good training for my work today at Acquia.
In the few years I worked at the ISP I saw it grow from 5 to 60 people. It was very educational to see an organization grow so rapidly. In the early days, I had to sell Internet subscriptions when there weren't enough support calls coming in. Unlimited Internet access was very expensive back then, especially for a student, and one of the perks of the job was a fast, 10Mbit connection. This is where I begin to learn about the Internet.
JA: I'd like to talk all about Drupal, but first let's jump to the present and learn more about who you are outside of Drupal. Before Drupal you were flipping burgers; what do you do these days when you're not focused on Drupal?
DB: I have two wonderful kids and an amazing and very supporting wife. I greatly enjoy the time I spend with them. We get outside as much as possible, taking day trips to the park or zoo, or going hiking. I usually bring my camera as I also enjoy photography.
JA: You have an extremely busy schedule; do you feel you get enough personal time to spend with your family?
DB: I make as much time for them as I can on the weekends. I do work some on Saturday and Sunday, but I make sure I'm there doing fun things with them when the kids are awake. For example, Sunday morning we make croissants together. This past weekend we put skis on my son Axl and started teaching him to ski.
JA: What do your parents think of Drupal?
DB: At first they'd get upset because when I was home from school on the weekends I was always online. They were not happy with my huge telephone bills, so there was some tension there. They're very proud of Drupal now.
JA: There are plenty of reasons to be proud of what you've accomplished with Drupal. It's already been a decade since you started the project. What inspired you to start writing Drupal in the first place?
DB: I'd already built websites with Perl and CGI, but PHP and MySQL were new technologies back then and I wanted to learn about them. I was interested in working with a database instead of writing data to flat files.
I also had a need for a private message board, so I worked on it for a year or so before it actually evolved into a Content Management System, or CMS. During that time it didn't even have a name, but that was the foundation that evolved into Drupal. I was hooked on all things Internet, and the message board was an experimental platform for me. For example, RSS or RDF feeds had just been created, and I was one of the early implementers of the specification. Same thing with “public diaries”, which later became “blogs”.
I was always looking for early signs of cool new things to try and include in my message board. It had no module architecture in the beginning, so I had to rewrite the software several times. I learned about modular design in my computer science studies, as well as from experience; I modeled later versions of the message board somewhat after the Linux kernel.
As I looked around at other systems like PHP-Nuke, I felt what I'd written had a better architecture, both in design and performance. When I eventually moved the message board from our private intranet onto the Internet I also started writing more about the future of the web. I wrote about things I was doing, and it attracted an audience. Some people would write to ask for the source code. Other people would write to suggest I might change an algorithm to work differently.
It finally got to the point that I was proud enough of what it did My message board had become a modular CMS and I felt it was actually something that would be useful to other people, so I released it as open source.
JA: How did you first become aware of open source software?
DB: I picked up a copy of the Slackware Linux distribution my first year in college. It took me a day to install, and then another week trying to get X-Windows working. I fully switched to Linux in '97 or '98. I was an open source user for a year before I got involved in development to get a wireless network driver working.
Wireless cards were still very expensive in those days, and the software drivers were relatively immature on all operating systems, even Windows. I ended up writing a FAQ for the Linux WLAN project, which I maintained until 2000. I still have a copy of the final version on my website at http://buytaert.net/files/wlan-faq.html.
This is all related to Drupal. At the time I lived in a really tiny room with just a desk, a bed, a sink, and a microwave. One of my best friends lived across the street and signed up for a beta testing program for high speed Internet that a company in Antwerp started. He was one of the first to get ADSL in Antwerp. All of a sudden he had super fast Internet access, but had to sign an agreement not to share it, the connection was only to be used by one person.
Being college students, we decided to build a wireless bridge to share the connection. We looked for wireless network cards, and back then we found them for $20,000! We kept looking, and finally found a small outlet in the UK selling more affordable wireless cards. They were still expensive for us students, probably around $1,000. I was using Linux, and it was hard to get the drivers working. I documented the process and finally got them to work. That was great!
Now that we had a wireless bridge, I decided to connect other people too. We drilled holes in the floor to connect people below and at night we'd run wires to the people next door. All of a sudden there were a bunch of people connected to my friend's ADSL connection, all over the wireless bridge. So we needed a private message board. If the beta ADSL connection dropped, or if I turned on the microwave and the wireless disconnected, I'd post a message on our intranet letting people know. We also used it to share stories or interesting things we found online, like our own little Slashdot, and to coordinate things like dinner plans.
JA: When you released the message board as open source, you named it “Drupal”. Where did this name come from and what does it mean?
DB: When I moved the message board from our private intranet to the public Internet, I needed a domain name. I had intended to register “dorp.org”, as dorp is the Dutch word for village and seemed a fitting name for our small online community. I accidentally typed 'drop.org'; it was available so I bought it instead. Drupal was then word play based on the Dutch word “druppel”, which means drop.
I honestly didn't spend a lot of time thinking about it. I never had a master plan; actually I hardly had any plans for Drupal in those early days. I just wanted to share the code because people were interested. I expected maybe a dozen people would download and use it. At that time Drupal didn't even have its own website, I just uploaded the code to a subsection on drop.org.
JA: Is there any code still in Drupal that was in that first release?
DB: I don’t think so. Maybe there are still some helper functions left, but I don't know for sure. It had a social focus, and a philosophy of modularity and flexibility including the hook system, so you could say the DNA is still there but not the actual code.
JA: When did you first realize that Drupal could be bigger than your own contributions?
There were contributions to Drupal from other people very early on. Initially people would just email me patches. Then I set up a mailing list where we would exchange patches. When that stopped scaling we moved to CVS. We created a special “to_review” directory where people would commit patches. I'd review the latest version of the patches on the mailing list. That also stopped scaling at some point, and eventually the project module was born.
JA: You released Drupal under the GPL License. How important is this to the project?
DB: I think it's a very important license. It’s one of the reasons we have such a strong community of contributors. The GPL gives everyone the ability to use Drupal, to look at the source code, to make changes to Drupal, and to re-distribute their changes. The GPL fundamentally encourages people to share. Sharing leads to collaboration, which turns into community. There are many other open source licenses, but they don't necessarily all encourage the same kind of sharing. I think the GPL has been critical to Drupal’s success.
JA: When did you first start meeting other Drupal developers in person?
DB: I gave my first presentation about Drupal in Vancouver, in 2004. By then Drupal was already 3 years old. That was the first time I met other Drupal developers in person. The event was set up by the Bryght people, a company in Vancouver. It was a lot of fun, and made me decide to organize the first DrupalCon in Antwerp.
JA: With Drupal’s success, you're often the center of attention. Do you enjoy being in the limelight all the time?
DB: When I started Drupal I didn't expect to be in the limelight at all. In a way, I'm in this position by accident as I don’t naturally seek attention. It's a role I’ve been growing into for ten years. I want to help lead Drupal to success, and believe that I can help in my role, which is why I do it. I do enjoy talking about Drupal, and getting to meet so many interesting people.
JA: You now have a decade of experience releasing Drupal. Which version was the most challenging to release?
DB: I think Drupal 4.7 will go down in history. It was really tough on me personally to push that release out. That's when the Form API was born, and I committed it late in the game. It took ages to flush out the bugs, convert modules, and get documentation written. That was a really hard release.
JA: Is Drupal a content management system or a framework?
DB: That's an interesting topic, which frequently comes up for debate. In my first Drupal presentation in Vancouver I referred to Drupal as both a content management system and a framework. I’ve consistently said it’s both, and I still think it’s both. It's also a third thing, Drupal is a community of passionate people.
JA: What is Drupal not?
DB: One of the great things about Drupal is that it can be many different things. It offers scalability in terms of size, meaning it's useful for both small and large websites. And it offers a richness of feature scalability, meaning it can be used for many, many different things. It can be used for anything from blogs, to forums, to intranets, to extranets, to corporate websites, and much more.
At the same time, Drupal isn’t the solution for everything. Drupal can be many things, but you should always use the best tool for the job -- don’t try and force it into something it isn't the best solution for.
JA: How much time do you spend these days reviewing and writing code?
DB: It depends on the development phase we're currently in. On average I spend about two hours a day reviewing code, seven days a week. I calculated that during the Drupal 7 release cycle, I committed about 3.6 patches a day, including weekends and holidays. Right now I have a little break because we just released Drupal 7, and I've not yet opened the Drupal 8 development branch. Some days I may put in six or eight hours, and sometimes I may not review any code for as long as a week.
I don’t write much code anymore. I only wrote a handful of patches in Drupal 7 core. I wrote much of the Mollom module, and also work on the Mollom backend once in a while. I actually love writing code, but I feel the best way I can serve the community is not by writing code, but by reviewing it. This is a conscious decision of how I can give the most with my time.
JA: You've managed the Drupal source code in CVS for years. What do you think of the effort to switch from CVS to Git?
DB: I think it will be great. It's important because it will change the way we work. It will allow us to scale and get to the next level. Compared to Git, CVS makes it relatively hard to work together and share code. CVS also only credits the people who commit the code to the repository, and not the people who actually write the code. That's annoying because we want to properly recognize contributors. We work around this by giving credit in the commit messages, but Git embeds this in the protocol itself.
I also spend a lot of my time on airplanes, and it's hard to work with CVS in offline mode. You can't do a diff when you're working offline with CVS, while Git gives you a complete local repository and facilitates working offline. Git solves these limitations, and more. CVS was a good tool when we started, but it's time to move on.
I’m also excited about how it could potentially change our entire development model. Instead of having to pull in lots of smaller patches, I’ll be able to work with individuals or groups of people to bring in much bigger changes. I think this will enable people to work on bigger changes that can then be more easily merged.
JA: You've picked a Drupal co-maintainer to help with recent releases. How do you pick them?
DB: It’s a very difficult and strategic decision for me. For Drupal 5 I chose Neil Drum partially because he'd worked on early installer prototypes, and Drupal needed an installer. I knew it was something he cared about, and he was a good architect who understood the importance of clean code and usability. The installer became one of the biggest features in Drupal 5.
With Drupal 6 I chose Gábor Hojtsy as a co-maintainer as I liked working with him, and I wanted more localization and internationalization as a way to reach out to people in more countries. He was working on a master’s thesis on internationalization and had previously shown a lot of interest in the issue, so again it was a strategic decision.
For Drupal 7, I picked Angie Byron because I knew she was very passionate about usability, and I wanted to make usability improvements a big part of Drupal 7.
I chose co-maintainers not only for their passions, but also for their ability to work with other people. It’s not always easy to say no, or to guide a group of developers through a decision and consensus building process. Leadership and social skills are also important.
JA: Have you picked a Drupal 8 co-maintainer?
DB: Not yet. I have people in mind, but it's going to be difficult. I pick my co-maintainers based on the strategic goals I like to see us accomplish in the next release. Before I pick one or more co-maintainers, I want to get a better sense of what features the community feels should be included in Drupal 8, and the changes we want to make to our development process. I've received input from hundreds of people over the past year alone, and I have my own ideas, but I’m still in listening mode. We’re in between two release cycles, and this is an important time for me to listen before making some decisions.
It's increasingly difficult to select a co-maintainer because as the project grows they need to dedicate increasingly more time to the role. Whereas it used to take a couple hours a week, now it takes at least several hours a day or more. It could easily be a full-time job. I'm sure there are people that would turn down the offer to be a co-maintainer because it's a huge commitment for potentially five to six years. It's a lot to ask someone, and a lot to balance.
This all influences my decision. Their passion, their technical skills, their people skills, and whether or not they can dedicate enough time to the job.
Interestingly, the move to Git allows for a much more distributed development process. It may turn out that I'll be able to work with lots of mini-co-maintainers. That is one of the things I’m thinking about now.
JA: Drupal 7 was released in early January. What are some of its most important new features?
DB: Usability is the number one new feature. It's basically the biggest improvement, made up of hundreds of changes.
We've also re-written the database layer to use PHP5’s PDO abstraction layer. Our new APIs support master-slave configurations, transactions, multi-insert queries, and lots of extra goodies that allow Drupal to run bigger sites and on more architectures. We have better support for MS SQL, Oracle, and even NoSQL document stores.
We also make it easier to integrate content delivery networks and Varnish for caching purposes.
Very early on we added a unique testing framework to Drupal 7. These tests will help us going forward as we refactor code, confirming that our changes don't break anything.
A new API properly manages files, which have become first class citizens. We also improved image handling and moved the ImageAPI and ImageCache into Drupal core. We can create thumbnails, and offer image effects such as rotating or desaturating an image. Image handling has always been a pain point for Drupal, but now contrib modules can standardize on one core API and advance what they do.
CCK was rewritten and moved into core, becoming the Field API. CCK traditionally has allowed you to add custom fields to nodes, while with the Field API you can also add fields to users, comments and taxonomy terms. That's sort of an avalanche that will bring lots of innovation in contrib. I think it will take years to really figure out fields and entities and the positive ramifications of these new features. I'm pretty excited about its flexibility.
JA: Is there anything about Drupal 7 you’re not happy with?
DB: Yes, I’m never content with Drupal and probably never will be. We certainly have a lot of work to do in Drupal 8.
I'm disappointed performance has regressed in many situations. I believe we made the right tradeoffs between scalability and performance, but I wish performance had improved. I’ll push us to make progress with that in Drupal 8.
There are lots of unsolved problems as well. For example, while we've learned a lot with Features during the Drupal 7 release cycle, there’s more we could have done to improve configuration management in core. It will be a big topic for Drupal 8.
Content staging is also a hard problem. While we made progress, there is a lot more to do during the Drupal 8 development cycle.
I’m glad about the usability improvements we made in Drupal 7, but we only scratched the surface of what needs to happen in order to see many more people adopt Drupal.
JA: A large number of contrib modules found their way into Drupal 7 core, far more than in any previous release. Why were so many modules merged?
DB: A lot of these modules started as contrib modules, and then evolved into part of the standard infrastructure that everyone uses to build Drupal websites. Once that happens, it really makes sense to add the module into core where it gets maintained by a larger group of people, improving stability and ensuring it will be upgraded in future releases.
JA: Views shows up in Drupal.org download statistics as the most popular contrib module of all. Does this mean it will be merged into core?
DB: That's a good question, and it's something we need to decide as a group. Views is like other modules that have already been integrated into core; it’s part of the Drupal infrastructure that almost everybody uses. To me it makes sense to move the Views query builder to core, but maybe to leave the Views UI as a contributed module. In a way, we started to pave to path for that by improving things in core that helps Views development. For example, the new Drupal 7 database abstraction layer should have simplified the Views query builder. Regardless, it remains a big job, and I probably wouldn’t want to do it without Earl Miles’ support.
JA: With Drupal 7 released, when can we expect Drupal.org to upgrade?
DB: The sooner the better. Like many other large sites, the drupal.org upgrade is blocked by contributed modules that need to be upgraded to Drupal 7. The Drupal.org team has also been focused on addressing leftovers from the redesign, and the preparations required for the Git migration. I would say once we completed the redesign and the Git migration, we'll be able to focus on upgrading Drupal.org to Drupal 7.
JA: It was announced that Drupal 5 isn't supported any longer after Drupal 7 was released. What happens to people still running websites on Drupal 5?
DB: A lot of people ask me this question. It's true that we no longer officially support Drupal 5, but I'd be happy to still commit patches and make the occasional Drupal 5 release. If there's enough interest, then the community will step up and maintain Drupal 5.
JA: As many as 4,000 people are gathering in Chicago for the largest DrupalCon ever. What do you think about the growing size of these events?
DB: 4,000 people is the maximum capacity of our venue in Chicago, and we would love to sell out like we've done in all the previous years. It's our target, but whether we'll make it remains to be seen.
I think it's tremendous that these conferences keep growing. It's obviously very exciting, but it's not something I ever imagined would happen. I helped organize the first conference in Antwerp, and I was completely flabbergasted that 30-40 people showed up! The fact that there's potential for 4,000 people in Chicago is mind blowing for me. It's a strong sign of a healthy ecosystem and a growing project. I wonder how big these things can grow, if we will ever get to 10,000 or 20,000 people? Who knows?
JA: How involved were you in the early DrupalCons?
DB: It wasn't a coincidence that the first conference was in Antwerp where I was living. I basically kicked off the first one with help from other people. Back then a DrupalCon cost a couple thousand dollars. We needed a small meeting room for a few people for a couple of days, at a cost of maybe 500 Euros a day.
We expected 15 people to show up so we started with one meeting room. We panicked when suddenly there were 30 people and we needed to rent another room. That required another 500 Euros, money I didn't have. John VanDyk pitched in to help fund this and helped organize the conference.
JA: Is there anything you miss about the original, smaller DrupalCons?
DB: For me, I liked that in the early DrupalCons I could spend quality time with everyone. Now that the conferences are so big, there are so many people that want a piece of me that I sometimes feel bad I can't spend quality time with all of the people in the community, especially the people that I work with closely and that have become my friends.
JA: You helped start Acquia in 2007. What is Acquia, and what does it do?
DB: Acquia is my company. It provides a number of products and services around Drupal.
The Acquia Network combines various support and cloud services. It includes access to our Drupal experts and knowledge base but also electronic services like Acquia Search, New Relic (performance monitoring), heartbeat monitoring, Mollom, etc. We started the Acquia Network in early 2008, and it's our main revenue driver today.
We also offer Acquia Hosting, which is a “platform as a service” offering for Drupal. At the core, it is a managed hosting environment built in the cloud, designed to be highly-available and to scale to largest Drupal websites. What makes it different from other hosting solutions is that it comes with our support services, as well as with a range of really great developer tools.
You get an SVN or Git repository and everything you need to create a production, staging and QA workflow. By DrupalCon Chicago we hope to announce a single-server version of Acquia Hosting, targeted at smaller websites.
Drupal Gardens is Drupal “software-as-a-service”. Often organizations have smaller sites to build, and they want to be able to roll them out quickly without having to make it an IT project. Drupal Gardens provides them a fast and easy way to build smaller websites without having to worry about the ongoing maintenance, security patches or udgrades. It’s still in beta, but it seems to be well received as we have close to 30,000 websites built with Drupal Gardens already. We’re currently working on adding support for Views, and hope to have that ready by DrupalCon Chicago
JA: How big is Acquia?
DB: We’re about 95 people right now, with 75 of us based in our Boston headquarters. We recently opened an office in Europe, and have close to 10 people in Europe. I expect we’ll be 100 people by DrupalCon Chicago.
JA: What do you most enjoy about your work at Acquia?
DB: I'm involved in many aspects of the business, from the roadmap of our products to helping the sales and marketing team, to human resources and finance. I surrounded myself with great people, and that allows me to focus on the things that I believe are most important, be it in product management, engineering, sales or marketing. I spend a lot of time talking to customers, and use their feedback to help set the roadmap of our products, as well as how we market our products. What I enjoy most is the variety of the things that I’m involved with, and that I’m learning how to build a company.
JA: How has Acquia impacted your involvement with Drupal?
DB: It allows me to do more. I’m able to work on Drupal more than I would have if I'd continued Drupal as a hobby project.
I also feel like my role at Acquia has only helped me do a better job as the project lead.
Acquia has enabled me to get closer to end users of all kinds. I travel to more Drupal events and interact with more Drupal users and developers. I've pitched Drupal in front decision makers of some of the largest organizations in the world, and gone on to work with them. Acquia has helped me to listen more and to build a better picture of the Drupal world, and that is increasingly important in my role as the Drupal project lead.
JA: You're the founder of a large and successful Drupal company, and you're also the leader of the Drupal project. Does this mean that Acquia essentially owns Drupal?
DB: No. Not at all. Drupal is built through a very collaborative process with lots of people involved in writing core. I run the project and make decisions in a way that allows anybody to be involved. That is how I always have run the project, and that hasn’t changed since I started Acquia 3 years ago.
JA: How do you separate Acquia from Drupal? Can you prevent your work at Acquia from impacting decisions regarding the direction of Drupal?
DB: My priority is to help make sure that Drupal is successful. Drupal is fundamentally changing how people build websites. I believe that Drupal is an extremely disruptive force, and that it has the potential to change our entire industry. Making Drupal succeed is my big passion, and that happens to align well with my role at Acquia. Quite simply, Drupal has to be successful for Acquia to be successful. I believe this strongly enough that I would make decisions that negatively impact Acquia if it's the best decision for Drupal.
JA: Has there ever been pressure on you to commit code to help your work at Acquia?
DB: No, this has never happened, and I would never allow that to happen. I even added a clause in my contract with the Board of Directors that says something like, “we all agree that I'll make decisions in what's right for Drupal even if it might cause Acquia problems”. I care deeply about this, and it is also part of Acquia’s DNA. I hope this shows in everything Acquia does; how we're contributing back to core and contrib modules, how we’re helping with promoting Drupal and organizing events, code sprints, and more. We’re committed to help grow Drupal, and will put Drupal’s success first.
JA: Does Acquia have plans to start a Drupal certification program?
DB: We've talked about it, and we believe it's something that will happen. At some point Drupal will grow to the size that the market demands a certification program. I don't mean to say that Acquia will or won't do it, but I believe we’ll see one or more companies create Drupal certification programs in the future. Once it happens, it can be good or bad for Drupal.
I think there's a lot of nervousness toward certifications, and rightly so. However, I also believe that certification programs can be done well. Being Cisco certified, for example, truly means something. They put people in labs and confront them with hard problems and short deadlines, testing their practical experience at solving problems. Having a college degree is also a form of certification; it usually means something when you can put MIT or Stanford on your resume. Similarly, I think the market will define whether a certain Drupal certification program means something.
I'm not saying we won't ever do it. We'd need to be sure our certification would really mean something. This takes quite a bit of investment. And if it is bound to happen, you want the right companies to do it, before the bad companies cause problems.