Growing is learning to take on more and bigger problems. When you were a 4-year old kid, you basically had no problems, except maybe that you didn't feel like eating all those potatoes on your plate. Similarly, newborn open source projects have no problems either.

Once you start school, you might start to lose some sleep over your grades, whether you'll ever make your way through school or why you're not allowed to stay up a little longer at night. Remember how these used to be your biggest problems?

Later when you're done with school, you look back and you realize how ridiculous it was to even worry about your grades. If you'd have to go through school again, it would be the easiest thing on earth, you believe. However, you're now faced with new and seemingly bigger problems: will I ever find the right person to share my life with? How am I supposed to pay the rent? How to raise my kids? How am I going to cope with the loss of a close relative?

So growing is learning to deal with more and bigger challenges. 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.

Right now, Drupal's hardest challenge is to manage its explosive growth. We have raw and untampered ambition but we're left wondering how we can scale our infrastructure with the available resources, how we can attract more top-talent to help get all the work done, how to maintain -- and raise -- the high quality of our work, and how to make Drupal easier to work with. We're also learning how to deal with legal issues, we're figuring out how to better market ourselves, and how to efficiently organize large conferences.

This sounds a lot like "How will I be able to pay the rent?" (infrastructure) and "How can I score more girlfriends?" (more top-talent, easier to use, better marketing). So by that standard, Drupal is a young adult that just moved out from its parent's place. We have many new things to learn and to explore, but we have unlimited motivation and ambition.

I'm convinced that one day we'll look back and realize how ridiculously simple it was to scale our infrastructure, to organize a 400-attendee conference or to better market ourselves at drupal.org. After all, we no longer lose sleep over high-school problems either ...

Comments

Joeph (not verified):

Thanks for sharing your concerns. I am glad to read that your worries are the same as mine.

Specially the performance of drupal.org is IMHO one of the high priority issues.

Thanks, and keep up the good work!

TexasNomad (not verified):

Yea, having good performance on d.o. is good marketing of Drupal itself. I cringe from showing d.o. in meetings that I am in due to that. It makes it very difficult to sell d.o.

Let's git er dun!

ragaskar (not verified):

Specially the performance of drupal.org is IMHO one of the high priority issues.

saw this blog post in my reader and was just coming here to say the exact same thing. As a new drupal developer, I've found the slow load times on drupal.org extremely frustrating, as it makes it that much more difficult to do research quickly and effectively. Additionally, I have found the API reference down on more than one occasion, essentially forcing me to stop all work. Currently the 5.0 API reference has a source code tab that returns 'page not found', which I've found to be a pretty common occurence with drupal.org links.

If there was a fund that was specifically earmarked for "Buy more memory/hardware/webmasters/whatever-is-needed for the Drupal.org server" , I'd love to drop some money in. I'd also be willing to contribute, however possible, to any necessary work/maintenance for drupal.org that is within my ability.

morphir (not verified):

Funny analogy. I liked it, since I'm facing a lot of those questions myself in my private life.

Better yet, what happens: happens. What I think we adults can learn from kids, is when a kid trip and fall, he/she gets up and tries again. Over and over, until he/she figures it out.

Open source development is a lot like that too, right? We rewrite and review the code over and over again, til you Dries says: thanks, committed to head ;)

Roel Guldemond (not verified):

Last winter I decided to focus on one CMS. In march joining the https://dri.es/drupal-workshop-in-antwerp. During May start to work through "Pro Drupal Development", vanDyck/Westgate, 2007 (http://www.drupalbook.com). In June a first Drupal-site is being knocked into shape.

I encountered many people who started to use Drupal to organize their ideas. I have had good support in following this weblog. I have had much help from many other people in this Drupal-community. And I will be able to show another good example in Drupal's showcase.

Anxious to read about "growing pains". And anxious to participate in minimizing "growing pains" for others.

Steven (not verified):

Is Drupal really already a young adult? I don't think so, because, with each release, some unmissable features are added.

With a young adult, the features do not grow anymore, but are used more and more efficiently.

Therefore, Drupal is at this moment only 16 years old...

ragaskar (not verified):

Don't know if anything changed, but the drupal.org response time is absolutely snappy today, making reading through the API a much more enjoyable experience.

webchick (not verified):

The biggest obstacle seems to be in getting good, quality patch reviews. Committing by itself takes two seconds. :P I think two things would help with this: increased automation of testing the "stupid things" and increased education for the humans on what makes a good patch review.

Some ways to attack this might be the following:

a) Get some form of the patch testing automation framework that Rok worked on last year into production on d.o. This would save testers countless hours currently spent downloading patches, applying patches, and posting back to issues to mark them "code needs work."

b) Create unit tests that are run by the patch automation tool to tell us right away if a patch breaks things. My old philosophy was that we should actually leave HEAD in a code freeze next release until all functions in core have unit tests written. But even if we had a sub-set of the things that break the most often (login forms, node forms (especially polls) the install process...) we would be sitting well, and could add additional things later. This would tell us, again, instantaneously if a patch needed work and we wouldn't end up wasting valuable human brain-cells on the problem.

c) Write tests for something like Selenium (which I've never used, but have heard about :)) that can automate the "clicking through everything to make sure nothing breaks" stuff that I spend at least a half hour doing everytime I review a big patch like something that changes FAPI or menus and such.

d) Finally, the biggest problem is of course education on proper testing methodology, things to look for, the general "social" things like not setting your own patch RTBC, or replying simply "+1", general "Drupal philosophy" stuff like keeping patches small and manageable, etc. Maybe we need a discussion on the devel list to hammer out Dos and Donts and then do a Dojo lesson for anyone who wants to try their hand at testing. The biggest barrier here is it's a royal PITA to set Windows up for patch testing, but it can be done, and I know of one person who has plans to create a video on the subject. We could create a resource and display this prominently in a "how you (yes, you!) can help improve Drupal" thing.

pt (not verified):

I just love to read your posts. Insightful, thought-provoking but warm. Especially this one.

And I also admire pretty much the drupal project (the best in the field). Please, keep up the excellent work!