For those who don't know him, Aaron Seigo is one of the leading KDE developers and community leaders. (KDE doesn't have a "lead developer" position, just as Drupal does not, but my understanding is if you merge Earl Miles and Angie Byon you sort of have Aaron's role within the KDE community.) He also blogs far more than is probably healthy, but his posts, while long, tend to be very spot-on.
His latest article is one that is of particular interest to the Drupal community, I believe, because as a large, minimally-structured, Open Source development community we face many of the same challenges that other such projects do, such as KDE. In particular, the challenge of who to listen to.
The "smallcore" debate has heated up again of late, with all its various tendrils. However, I still see a lot of the same misunderstands that I've been seeing for weeks. That can only mean one thing. Time for me to write something. :-)
I do not consider myself a "smallcore" advocate, for one very simple reason: It's horribly misleading. Allow me to repeat what I already said there:
The goals of the "smallcore" movement can be obtained without removing one single module from Drupal core.
Instead, I look at the question of Drupal's future direction from a simple architectural perspective: Is Drupal going to be an additive system, or a subtractive system?
As many people who know me know, I've been a Palm OS affictionado for years. Starting with the Palm III back in 1998, I've used 8 different Palm OS devices personally, 5 of them Palm, Inc.-branded.
So it is therefore with much sadness that I now say "Palm, go to hell, preferably bankrupt".
DrupalCon Paris 2009 is now in the past. As usual there was last minute chaos, lots of people running around behind the scenes going insane, people hugging friends they see once every six months, presentations ranging from super-technical to light and fluffy, general geekery, and of course copious amounts of beer. (This time we didn't drink out any of the bars, but then it is Paris.)
But there was something else, too, that I saw as an undercurrent of much of the conference: Maturity. Not the "acting like boring, responsible adults instead of having fun in Paris" kind of maturity (may that never happen), but the "thinking about more than just being code ninjas" kind of maturity. Drupal, as a whole, is growing up.
Just when you thought it was safe to go to DrupalCon, here comes... schedule change!
It turns out there was a late cancellation, so the DrupalCon Paris team has asked me to fill in with Drupal Design Patterns on Wednesday afternoon.
If you write modules for Drupal, you want to be there. Although we'll be approaching the subject from a slightly theoretical slant, the main thrust will be how to write code that other developers will understand quickly, that they'll be able to extend, and how to not reinvent the wheel by leveraging existing solutions and approaches.
Do you have a Drupal module you want to upgrade to Drupal 7?
Do you want to know how to leverage the Drupal 7 database layer to make your module better?
Will you be at DrupalCon?
There should be about 500 of you that meet that criteria, by my estimate. More than enough for a BoF. :-)
Are you all set for DrupalCon Paris?
Through the mysteries of scheduling, Paris ended up with not one, but two sessions on Views. The first, from Frédéric Marand, is a 4 hour workshop on Views 2 for coders on day 1. The second is yours truly in a 50 minute session on Views for Developers on day 2.
Sounds very similar, doesn't it? Yeah, we thought so too. Not to worry, though, as we've worked out how to keep both sessions distinct and interesting.
Here's how it will break down, so you can decide which session you want to go to (and you'll want to be at least in one of them; this is Views, after all):
There has been some discussion in recent days regarding Object-Relational Mappers (ORMs), Drupal, and why the latter doesn't use the former. There are, actually, many reasons for that, and for why Drupal doesn't do more with the Active Record pattern.
Rather than tuck such discussion away in an issue queue, I figured it better to document a bit more widely.