Drupal

It is that phase of my life! I'm just turning 30 in a month, working with Drupal for 7 years and just had my third Acquia anniversary a week ago. Time to look back and evaluate how things went, all the good and bad things; even better if the wisdom can be shared with others. This was part of my thinking when I submitted the session titled "Come for the software, stay for the community" for Drupalcon Copenhagen. I was interested to distill and share how Drupal came to be as unstoppable as it is, what core values lie behind it, so someone coming fresh can understand and integrate with these.

When Dries Buytaert started Drupal he made a few key decisions which launched the project and kept being governing principles ever since. First of all he decided to make it free and open source, and release it under the GPL. The choice of one single license helps you use all the Drupal components together without the requirement to consult lawyers. Also, the choice of GPL in particular ensures that derivative works are distributed in the open as well.

Using PHP as the base technology was probably the best decision to help proliferation. PHP is not only the most installed backend software (thanks to all kinds of server side software), but its also easy to learn and jump into. While this can and did end up with some projects that gave PHP a bad name, it also opened the door wide to contributors. Having numerous contributors encouraged the tinkering, technology experimentation spirit that defined Drupal from the gate. What's more, Drupal was an integration platform from the beginning. Even Drupal 3 (in 2001) included RSS generation and consumption, a distributed and automated website directory and tagging. Drupal 4 (in 2002) added Jabber user account integration, XML-RPC services support and Drupal shared authentication. See, Drupal had lots of the base features we praise it for even 8-9 years ago. Woo!

Having a technologically advanced system that people can contribute to easily is not enough. You want to build a culture of building on top rather than forking to avoid the bad fate of many other systems grown up through the years. Establishing the hook system on the API level and the node system on the content handling level formed a good foundation to let people tinker even with the innards of Drupal without ever needing to fork.

Building a big home for all these contributions was the next major idea that distinguished Drupal from many other projects. Drupal itself was built on a sharing cultural mindset and drupal.org was set up for all kinds of contributors to follow suit: release code, designs, tools under the same licenses with the same issue handling system, etc. This helped people move between projects of their interest, contribute to each other's work. Having a strong central base versus everybody's own little kingdoms around the internet jumpstarted the large Drupal ecosystem. In 2009, we had above 2200 new projects started on drupal.org, that is above 6 per day.

Keeping the community all together, Drupal could embrace a culture of change as well. Drupal core could be rearchitected with every major release and have tools to help contributors keep up with the flow. This way Drupal can be at the forefront of innovation both in core itself but even more in contributed modules and themes. As Drupal itself keeps improving, contributed modules are forced to rethink their approaches, purpose, and get better in the process. Old and cumbersome solutions vanish while new ones take their place. Developers and users both come out empowered at the end.

This all provided with good ways to do power distribution without appointment. Everybody can be the king (AKA well respected lead) of their modules, themes, documentation sections, translation teams, and so on. There is no need to appoint people to positions per say and possibly face issues when people become inactive. The centralized project and code management space gave way for power transfer when needed, making it easy to hand off maintainership and continue work without breaking history.

All-in-all it is both Dries' forward thinking launch of Drupal and the bright minds who carried on and continued following the same basic principles for almost a decade. This is why we consider Drupalcons where people can meet and drupal.org where people do Drupal work our most precious possessions. This is why the Drupal Association puts money first and foremost into making drupal.org a better place for both newcomers (with the redesign) and for developers (with the git migration) as well putting on Drupalcons around the world. While looking for the next big thing is always on our mid, we managed to keep our values and build a happy community on the way. Win!

Ps. The new Drupal Code of Conduct was just published on drupal.org which might help you understand some of the basic human values we strive for.

As Drupal events grow around the world, more and more people find meetups and conferences closer to themselves. However, traveling to bigger events like Drupalcons can still be a financial problem for many. One of the solutions for this is couch surfing, where you could take a couch from someone who has it available in the host city for an event. Of course sleeping at an unknown person's place can be problematic. However, if we consider you already go for a Drupal event, and drupal.org has a profile for people with attached data on their activity, it can form as a reputation system. At Drupalcon Copenhagen, we discussed that maybe it would even be possible to build this tool as a group on groups.drupal.org (but definition of what is exactly needed is best to be done first).

I don't have the opportunity to help and build this tool but thought throwing the idea out would be useful for others to brainstorm and possibly help the community by making it work. We already had a nifty slogan for it when module maintainers couch surf: "I'm using your APIs, may I use your couch as well?"

Ever since Drupal uses major versions for compatibility changes and minor versions for bugfix and security updates (since Drupal 5), it was most often the case that a new minor Drupal release included bugfixes and security fixes packaged into one update.

The process to bundle bugfixes and security fixes into one was so common that the Drupal 6.17 release that did not include security fixes but only covered bugs was a grand surprise to many people. We have even seen "security researchers" who ran automated version detection scripts, and considered sites not running 6.17 insecure. That a Drupal 6 release would include security fixes is that strong in the minds.

Most Drupal 6 releases however included numerous other changes. These in an ideal world do not affect your site and will only fix stuff rather then breaking anything. However, sometimes people find that the bugfixes result in side effects we did not think beforehand. Therefore sites where quality assurance (QA) is applied take time to ensure the new update do not break existing functionality.

To help people roll out security fixes without the requirement for lengthy QA cycles, we followed the tradition to make patches available (see for example SA-CORE-2010-001). These patches let site admins to quickly fix the site while the other fixes are in testing. However, running a patched Drupal is not for everyone, it should be done with careful attention. It also obscures Drupal 6's update module processes, since your site will tell you a security update is available, until you actually deploy the full thing. Drupal.org's usage tracking will see you are running an insecure version. Automated bots and script kiddies will register your site as insecure and attempt to run exploits. If you do not apply the patch however trying to stay away form killing kittens, your site will actually stay insecure.

So if you do not update to the security release, it's bad for everybody. If you do apply the patch but not the full release with bugfixes, it's bad for many reasons. Ideally, Drupal would provide an official release with the security improvements only, so you can choose to use that only and maybe later upgrade to include the bugfixes.

That is what the Drupal Security team discussed and arrived to at Drupalcon San Francisco. The decision was to make available actual security-only releases as well as a security plus bugfix release. This now makes it possible to just deploy the security fixes as soon as possible, without maintaining a Drupal fork. Then - given the usual timeframe of Drupal releases - you'll have plenty of time to review the other bugfixes and ensure they'll not affect your Drupal website in any wrong way. (Not that its expected that bugfixes could break your site, but it does happen).

This new process is applied first to Drupal 6.18 and 6.19 which were released at the same time. We tried to explain this new concept in the release announcement and the security announcement respectively. We hope this will help in rolling out security fixes quicker and that this new process is well received.

You can hear more about Drupal security at Drupalcon Copenhagen at the Drupal security - configuration and process session and at Drupal security for coders and themers.

The Drupal Security team can be reached at security at drupal.org or via the form at http://drupal.org/contact.

Last week, the organizers posted detailed descriptions of the conference tracks for Drupalcon Copenhagen. As was announced, I'm helping to chair the code and development track, which is all about core and contributed modules, APIs, new technologies, databases and data stores, web services, JavaScript wizardry, security, etc, etc. Basically whatever makes the developer geek heart's warm.

To make this Drupalcon yet another developers paradise, I was starting off by looking at the existing session proposals and initiating contact with many session submitters. In some cases, I believe site building sessions crept into the track, so we are working to straighten out some session descriptions and placements. It is generally a good idea to include a good description of yourself with your prior experience explained as well as write up a decent session description so we can get a feel for what are you planning to cover in how much detail.

Trends with the presently submitted sessions seem to be mobile development/deployment, video management, the command line, best practices for coding, extending up and coming major contributed modules (Group, Ubercart on Drupal 7, Views 3) and learning from worst practices even.

It is not at all late to grow this list with exciting sessions. There are certainly some topics missing here getting people ready for some crucial new things in Drupal 7, like the new database layer or fields in core; an update of where the drupal.org git migration is standing, and so on. I'm trying to do my best to contact expert speakers in these areas, but would be extremely open to suggestions on what are you missing from the suggested list of sessions for the track. Let me know in the comments (or via my contact form), so I can do my best to get the content you'd like to see. It's one thing that you'll be able to vote on session proposals but your requested topics are also highly valued.

After some organization around travel and accommodation (which is still in flux to some degree), looks like there is nothing in the way for me to attend Drupalcamp Timisoara 2010 and contribute some content to the session schedule as well. Fun! This Drupalcamp is taking place in the Politehnic University of Timisoara in one month on June 5th and 6th, and is primarily English. I'm spotting others coming from as far as Belgium, Serbia, Moldova, Hungary, Austria and Germany.

The two sessions I've submitted for the schedule are the following:

Come for the software, stay for the community - how Drupal improves and evolves

"Come for the software, stay for the community" could become Drupal's new slogan (see the discussion), so what better title to use to explain what Drupal is about? In this session I intend to provide a brief overview of what Drupal is and instead of delving into technical details, focus more on how the different avenues to improve Drupal work. Systems like distributions, localizations, issue queues, the core and contributed modules repositories, the security team, automated testing and so on. How can you collaborate with the community and make money on the way?

This session is aimed at beginners or those who could use a good high level overview of different areas of Drupal.

What's up with Drupal 7?

Drupal 7 is about to be released sometime later this year. We don't yet know when, but it is steadily marching towards in its release cycle. As always, this new version of Drupal comes with all kinds of bells and whistles promising to improve our lives. What's even better is that many contributed modules are pledged to release on the day of Drupal 7's release. Automated testing is now the norm and Drupal Gardens is doing an immense deployment of beta testing on a Drupal 7 based service so no Drupal release will be as well tested as this one. Come see the improvements coming up in this release and see why the Drupal 6 maintainer is envious.

At the Hungarian community, we are organizing yearly local Drupal conferences ever since 2006 under the "Drupal Conference" and "Drupal Weekend" names. We've also just had our 22nd monthly meetup in a row. We've hosted Drupalcon Szeged 2008. Over these years, we've found that naming for all these events is tricky, and nowadays, the "Drupalcamp" name is sticky for local Drupal conferences. However István Palócz of the Hungarian community had a different dream around camps.

This year, we're gonna have the first Drupal Summer Camp in Hungary (and by the looks of Google search results maybe the first Drupal Summer Camp ever). Unfortunately (at least for my non-Hungarian speaking audience), the event is all in Hungarian (except all the jargon thrown around that is :).

The camp is on from the 23th of June to the 26th and is organized with community participation in mind. People can get experience translating interfaces and sharing their translations, look into drupal.org project maintainership aspects, work with the issue queues to get problems solved, etc. By the nature of being together for four consecutive days (with a complete dormitory floor rented for cost-concious and/or community addicted attendees), lots of hands-on experience can be gathered.

Széchenyi tér, Pécs by István Csuhai

And continuing our good tradition of organizing events with side parties (remember SZIN from Szeged?), this summer camp will take place in Pécs, which is 2010's European Capital of Culture with a vast number of options for chilling out. (Check out more photos of Pécs on Flickr).

I'm looking forward to how this model works out, and am happy to share experiences with anybody looking to make actual summer camps in the future.

With Drupalcon San Francisco just a few days away, being another great event including two days of "pure coding" and a ChX coder lounge each day for those who are inclined to join, I figured it would be a good idea to share some tips if you are about to work on Drupal 6 issues. Given the close to 2700 attendees coming, I don't know how many to expect on the code sprint days right before and after the conference, but I guess there will be people with diverse backgrounds as usual.

We have seen people sprinting to improve Drupal documentation, translate Drupal to foreign languages, improve core and contrib components, and I hope some of you will have itches to scratch around Drupal 6.

I remember how skeptical I was looking at some presenters traveling around to multiple conferences with "the same" presentation a decade or so ago. Having been a course instructor for years and being a presenter for even longer, it looks completely different now. It's not that the topics you cover under the same looking umbrella can be quite different, you also find much better ways to express whatever you want to tell your audience as you experience feedback.

Of course the best would be to present your story crystal clear from the start, but despite being an enthusiastic follower of Garr Reynolds and Nancy Duarte, you'll undoubtedly need lots of time anyway to take a relaxed look on your story and distill to the level needed to form a great presentation. I've actually found it quite hard to refine my slides without actually showing/presenting them to an audience. The faces, questions, smiles and sometimes plain staring expressions you get tell you how you'd done and you can derive ways of how can you improve.

Two interesting examples are my slides on Drupal 7 and localize.drupal.org.