In my DrupalCon Paris presentation I talked about what it means for Drupal to grow up -- and I wanted to elaborate on that a bit more in this blog post. I hope that the analogy that I'll use in this post can provide a framework for thinking and discussion about it.

We, as a community, are growing up and there is not much you can do about it.

If you're my age (currently 30 years old), sometimes you remember how great it was when you were in your teens. Unfortunately, you have no choice to grow up: you can't roll back time nor freeze it. I think this will ring true with most of us, and frankly, the same is true for Drupal: Drupal is growing up, and we have no choice but to grow along with it. Growing up is inevitable. Life changes every day and excessive nostalgia kills happiness.

So if Drupal is growing up, where is it in its life?

For me, Drupal is a young adult in the early phases of its professional career. Drupal is fresh out of college with A-grades, did some highly-visible internships while in college, landed its first job in a high-profile company, and built up some initial work experience. He has everything it takes to become successful, but being a junior team member, hasn't yet proven himself in a big way. He has the raw talent to become a key part of the business. In fact, his first promotion is just weeks away, and it remains to be seen how he'll handle some additional responsibilities. Either he is happy with his life as it is, and takes it the easy way, or, instead, embarks on a bigger career path in a somewhat naive but admirable desire to conquer the world.

But, enough with the analogies. For Drupal, growing means we must continue to innovate at the framework layer by improving our code, our tools and our developer workflows. We have to continue to do what we have been doing the best. But, there is also a really big "and" that is key to us growing up ...

As a community, we have to embrace increasingly more end-users, content editors, designers, usability experts and organizations. It may sound obvious, but we have to learn to build software for the people that are our users, rather than mainly designing for ourselves like we've always historically been doing. We, developers, should be the primary target audience of "Drupal: the developer framework" and we should continue to invest heavily in it. But end-users, and content editors in particular, have to be the primary audience of "Drupal: the content management system". Both areas have to thrive and work together. We can either succeed at making that happen with a somewhat naive but admirable desire to conquer the world, or we can fail at making that happen and remain insignificant in the bigger picture.

There is a lot of richness in the Drupal platform that we haven't really figured out how to package in order to reach many more people. Drupal 7 will hopefully be a big help with that, but we'll need to continue that trend with Drupal 8 and beyond. Doing so may provide some initial discomfort as we break out of our traditional mindsets, but it is also tremendously exciting. It's like getting a promotion.

At the end of the day, it is all part of growing up and part of Drupal's natural evolution as a product and technology. Growing up is inevitable -- you can't freeze time. Part of growing is learning to take on more and bigger problems. It is no coincidence that the biggest challenges tend to be ahead of you. This is true for your personal life as well as for the life of an Open Source project. Being a young adult is one of the most exciting times of life, and is filled with lots of changes. What's not to like?

Maybe in a few year's time, I'll write about how Drupal is getting married, and that they are talking about getting kids. ;-)


Ronald (not verified):

Great comments as usual Dries.

I think that we as Drupal developers and designers need to cultivate the Drupal brand among our community to get more people involved. However, I am not sure about whether end users need to know that what they are using is Drupal. I am not sure about Drupal as the end-user brand.

End users may be using things like Open Atrium or Open Publish or Acquia Gardens or Tatler App and build their websites and grow their businesses with those products. At the heart of those products is the Drupal framework / CMS but will they pay much attention to that?

Perhaps in a tangential "my laptop has an Intel processor" kind of way. Intel is a brand but end users interact with Apple, HP, Compaq, etc.

And at the end of the day that is one of the key questions.

Do you want to be Apple (total solution - one brand) or do you want to be Intel (the smart guys that make things happen but end users know them as the company that puts a sticker anywhere anyone will allow them... :-)

This does not mean that we should not embrace the needs of end users, etc. It simply means that the way we embrace it is by enabling great things to happen for end users - through more modular code, better documentation, great examples, etc but perhaps not expect that Drupal itself as a zip you get off will actually directly answer all the needs.

The community will then create products and products will answer specific needs. Drupal needs to make sure that the community can create the best possible end products and they will be promoted the best way the team that created them can manage.

Hope this makes sense!

Jeff Eaton (not verified):

This realization that Drupal is entering a new phase of its life cycle is one that a lot of people in the community are experiencing. And you're right -- determining how to capture and package that power and flexibility of Drupal is one of the key challenges. We've made it through the period of frequent personal reinvention and we're finding our place in the world. Figuring out how to be [i]better[/i] at what we're good at is a new challenge.

It's one of the reasons that the 'small core' movement has captured my attention. Fundamentally, Drupal's power and flexibility makes it very difficult to tailor the end user experience and 'package' a single, polished product. Without fundamentally crippling it, at least. Making it easier for site builders, developers, and teams to create focused products built on top of Drupal is where I believe the future lies.

Exciting times!

Shai Gluskin (not verified):

I couldn't be in Paris, but I just watched your talk, Dries. At the part of the talk when use the growth metaphor, "In high school we had all that freedom, but..." I was hoping you would take the metaphor back to your personal life and say something like, "But I wouldn't give up my kids for anything... no amount of time or freedom could replace them and the amazing gratification that adulthood brings."

In the short term, I think the most important part of Drupal's "growing up" is launching the redesign. Drupal 7 is probably more important, but that has a huge amount of momentum and the community knows how to pull off a big new release.

Whereas there haven't been many major overhauls of Pulling off the redesign will be a tangible model of how Drupal can be used as a product and a service. From the margins, it seems that the re-design is floundering a bit. I was disappointed that you didn't mention the d.o. redesign in your keynote.

It comes back to "eating our own dogfood." Can the Drupal community itself create a polished site to facilitate its own work and make it easier and more welcoming for others to join that work?

I just went over to the redesign issue queue and it's pretty quiet. I'll try to get more involved in testing and docs for it. Some goals and some fresh direction might help.

I, for one, would also contribute monetarily and reach out to others to contribute to a fund dedicated to hiring folks to help do the coding needed in order to launch the d.o. redesign.

Larry Garfield (not verified):

I'm only a year or two younger that you are, Dries, and I would hardly look back at my teen years as "great". :-)

But yes, Drupal is growing and growing up, and we can either grow with it or drag it down with us. That means we need to evolve both our code, our approach to software, and our development process, too. Matt Farina had an excellent blog post recently on one way that we could improve the development process to account for these changes, which I highly recommend to anyone who is interested in core development.

Jonas (not verified):

Interesting that you specify the sex of Drupal as male.

Yoann Babel (not verified):

Congratulations for growing up and best whishes for becoming an adult. Great challenge is facing us.

BTW, I'm a little bit concerned about wysiwyg in D7 which is a recurring problem for my clients. I didn't manage to find any information about it, nor anything in D7dev.

Caleb D (not verified):

@Shai: I feel similarly. What happened to the redesign? I haven't heard anything about it in months. I can't even find a lot of information about what I can do to help and what needs to be completed.

@Yoann: The WYSIWYG module ( is very useful for implementing editors in Drupal 6 and I'm sure sun will be providing a Drupal 7 version soon after D7 is released. Since Drupal 7 is new feature frozen there won't be any type of WYSIWYG editor in Core. It's possible that there will never be, because Drupal has a minimal amount of third party dependencies.

sun (not verified):

Not because of third-party dependencies.

But because of countless Drupal use-cases and different users. And countless, ugly designed editor libraries, which all come with their own flaws.

It's not Drupal that sucks. It's the editors that suck.

Primarily, because every single editor library on this planet is duplicating the work of others. Re-inventing the wheel all over the place. And if you look at the underlying concepts and APIs, you'll quickly notice that many are even using very, very similar models and methods to achieve... the same result.

Yes, Wysiwyg module will continue. It will continue to abstract back that duplication into a single interface.

Actually, my hope is that Wysiwyg module will turn into a paradigm change in the editor library developer world in the long run:

Stop duplicating and start joining efforts.

For that sake, I'd really like to see other CMS forking most of Wysiwyg module's code. Systems leveraging jQuery might even be able use the JavaScript parts without many alterations.

Ben Stallings (not verified):

"Maybe in a few year's time, I'll write about how Drupal is getting married, and that they are talking about getting kids. ;-)"

You joke, but if Google Wave lives up to its hype a week from now, the Internet may soon have a de-facto standard way to edit and share content. Drupal and other CMSes then would take the role of organizing and theming related content that is maintained on one or more Wave servers rather than in a traditional database. Or perhaps (probably) some other merger that I'm not foreseeing.

One of the things I appreciate most about Drupal is how the Drupal Organization stays on top of new trends and anticipates their impact and how Drupal can be part of the action, rather than waiting to see the impact before reacting. If it turns out that an analogical marriage with kids is the best way to accomplish Drupal's goals, I hope the DO will be open to that.

Ted Stein (not verified):

But there are also questions about what kind of grown up Drupal will become. I got nervous when I learned Drupal 7 would sacrifice speed for scalability.

Why should growing up mean going corporate?

Drupal doesn't have to grow up to be a corporate executive with a single large project. She could also grow up to be a consultant with a lot of smaller projects.

Drupal is a great tool for me; I do several installs a week for clients. If Drupal becomes something designed for big organizations, I will have to switch tools. That would be unpleasant.

I agree with your thoughts related to end users and usability, but I hope that you still hear the voices of developers like me. I worry (perhaps unfairly) that you are listening to your larger Acquia clients more than the Drupal community.

Great post and thanks for initiating this conversation.