I had the privilege of attending Drupalcon Prague 2013, thanks to generous funding from Omega8.cc. The event was, as now usual, a large conference for European standards, with around 2000 attendees, making it the largest european Drupalcon, again.

I was mostly there to promote the Aegir project, make the usual BOF session (because our session submission was refused this year again) and meet fellow Aegir developers and users.

I have attended various sessions and keynotes, which I detail here.

Dries' keynote and Drupal 8

The conference starts with the usual keynote, for which I arrived just in time to see Dries introduced by a signing choir of carrots chanting "gaaaaaardeeeens!". That was probably the weirdest introduction I have ever seen, but it was funny enough.

The keynote left me a little disappointed. I feel the community is in crisis yet our leader is still steaming ahead unhindered. I did hear him say that "Drupal is a large system", a euphemism considering the neverending growth of the Drupal core code size.

I was worried about the performances of Drupal 7, and I was right. Now I am really worried about the performances of Drupal 8, but all I hear is about how D8 will be "scalable", which seems to mean different things to different people. To me it means that it will perform on small or big servers or sites efficiently, but apparently, this now means, for Dries, MongoDB and edge side includes, which are really targeted at higher-end communities and users.

It seems that Drupal is targeting more and more large sites and corporate clients, which is a natural transition considering the actual clientèle of the big actors in the community, but this comes at a cost, which is that some of the community, the community where I come from, the small community groups, activist and small media, will be simply left behind.

Apparently, some of the performance improvements of Drupal 8 depend on ongoing API conversions, for which compatibility layers are still present and keeping some optimisations from happening, but somewhat this doesn't reassure me.

The fact that the Drupal Association decided to hire a public relations guy, sorry, a marketing and communication manager (whereas the DA already had a marketing coordinator) is also telling: Drupal is growing as brand, and the DA is trying to make sure it's going to control its image with fancy logos, parties and press releases. This hardly seems to me to be a priority at all.

Arguably, D8 is still at the alpha stages, and Dries acknowledges there's still lots of work to cleanup the APIs, and "we'll take the time to get it right". Also, a lot more people contributed to the Drupal 8 core (1600), double the number of D7 contributors, and a lot of those people are new people, which is encouraging.

Still, I am worried about the path the community has taken: porting to Drupal 8 will be a major undertaking, both for sites and contrib modules. With only 24% of the code of Drupal 7 remaining in Drupal 8, this "upgrade" is basically a rewrite for modules and a migration for sites.

What will happen to the hundreds of Drupal sites we are hosting, most of which are still Drupal 6? Will our clients be able or even willing to pay for the migration time for basically no extra functionality? And if we have to rewrite everything, why bother with PHP in the first place? There are plenty of nice programming languages out there and the hosting landscape has changed significantly since the days of "PHP, MySQL and FTP". I am personnally sick and tired of rewriting the world every day in PHP.

The way I see it, we have three alternatives:

• stick with Drupal and follow Drupal 8, which will mean we will again have to leave our users behind in 3 years
• start looking in to static site generators for our common use cases and clients, to provide cheap websites and focus on theming and useability
• upgrade to the Drupal fork, BackdropCMS and hope this will have a longer shelf life and better backwards compatibility between major releases

What Koumbit will choose remains to be seen, but I personnally feel like exploring static site generators a lot more. In fact, most websites I do are in ikiwiki these days.

The elephant in the room: Backdrop

Prague was extraordinary because of the historical context in which it happened: the Backdrop fork was just announced while the Drupal 8 development is dragging along. In Portland, the Drupal 8 release date was aimed for december 2013, but now we are talking about release candidates in 2014 and a "release when it's ready".

This was bound to create some tensions in the community, but I somewhat expected the tightly-nit community to behave a little better. There seemed to be a significant backlash against the brave forkers, who I had the chance to talk with. They were visibly nervous about all this and hesitant to openly talk about the fork, for which they hosted a BOF disguised as "small scale Drupal", which I attended. The backlash was important enough to warrant a [we will not punish dissent][] post from Jesse Beach.

The BOF took place in one of the cruelly small rooms in the back that could hold harldy a dozen souls, in stark contrast with the rockstar rooms for thousands of people that the Dries keynote took place in.

Other posts have explained better what the fork is about so I will not drag this along here other to emphasize that the point of the fork is to bring Drupal back in the "Wordpress sphere" of one person drupal shops, non-profits and lower the requirements. The objective is also to model Wordpress's "API will never change" model, or at least find somewhere in between "let's burn the house every 3 years" model of Drupal and "we don't care about those cracked foundations" model of Wordpress.

The idea is to reverse the pyramid. Whereas the core devs are at the top of the hierarchy right now, and users and the bottom, we would put the users, themers and site builders back on top, and put the desires of developers at the bottom.

There was some debate in the BOF about whether or not Drupal itself had long term support, some stating that there were basically 6-year long support cycles, although nobody in their right mind would setup a Drupal 6 site now, the CMS being basically dead.

In the end, it comes down to this: for quicksketch, it was easier to fork Drupal than to port the multitude of modules he maintains.

So while there weren't official talks about Backdrop during the conference, it certainly was on everybody's lips at every meal I went to, and was frequently mentioned in various Q&A.

Dries also had to answer a question about Backdrop after his keynote, which was oddly phrased as "what can we do about Backdrop", as if it was some sort of disease we needed to fix. In his answer, Dries said he didn't like that the fork was "splitting the community" and said we "should reach out to backdrop and see if we can pull them back in", but at least agreed to "make the break up honorable".

Aegir BOF and sprint

During the Aegir BOF, I had the pleasure of answering questions from a few users in a small 8 people session around a dinner table. A few observations: according to some Nginx users, the performance benefits of Nginx don't outweight the risks of the less supported platform. Also, it is possible to configure a similar FastCGI-based setup with Apache, which was documented on the community site during the conference.

It seems that the filesystem path changes due to the multisite nature of Aegir is still causing pains, maybe our documentation on this could be improved. It also seemed unclear to people that Ubuntu was a well-supported platform.

During the sprint, I had the opportunity to basically fix "subdirectory support", especially on multi-server. We have now probably one of the few working implementations of any Drupal hosting which supports http://example.com/foo and http://example.com/bar being different sites.

I also got help from cweagans to test the SSL support in clusters, which was completely fixed and should now be working properly. We just now need a small change in the frontend to support SNI, which is also great news. Thanks again to Cameron for the test cluster which made all this testing easy.

I finally had time to kick a lot of patches around and get more people involved (like danquah). I even had some dreamy times talking with tizzo about rewriting Drush or at least consider his fetcher project as a basis for the new backend in Aegir 4, see this post for a complete summary of that discussion.

Other takeaways

Drupal 8's i18n support was completely rewired, and in a good way. While it's not completely integrated, support is still much better than it was in D7 or D6. The full presentation is online.

Drupal 8 also has interesting performance improvements for caching sites, even for logged in users. "New" markers on comments, for example, are now dynamically loaded through AJAX calls, keeping the base HTML of the page basically static. The idea is to reach better "perceived" performance.

The Copenhagen municipality has embraced Aegir and is migrating to a install-profile based setup to host many Drupal websites on a few platforms. The Aegir project matched their self-hosting requirements, and was one of the rare open source projects that was aimed at providing Drupal hosting. It is easy to expand, and makes it easy to install upgrade and backup sites.

I learned about interesting Drupal distributions, Panopoly and Spark, which we should clearly look more into. I am still surprised at how distributions are oddly slow to pick up speed considering install profiles have been around forever.

Proviso is a really interesting project! One of the few people working on sharing their "secret sauce" of Drupal hosting, patconnolly and tizzo are sharing multi-vendor (chef and puppet) recipes for configuring servers for Drupal, SolR, memcache (...) hosting. Their presentation was fun to watch.

We also talked about OpenShift and how other shops (like Acquia and Pantheon) were reticent of sharing their recipes. It can be noted, however, that Pantheon is very similar in design to Openshift. The Example 42 Puppet modules are also something we should definitely look into.

There was a [future-friendly evolution and the drupal release cycle talk][] which I was really interested in, but was too full for me to join. However, it does look like D8 will be better geared at providing a more stable API in the long term, thanks to Interfaces and similar improvements to the API.

Other sessions I wanted to attend

As usual, there are a bunch of sessions I marked down in my schedule but couldn't get around to see. Here they are in chronological order:

• https://prague2013.drupal.org/session/not-invented-here-proudly-found-elsewhere-drupal-8-story
• https://prague2013.drupal.org/session/automated-acceptance-tests-behat
• https://prague2013.drupal.org/session/devops-and-drupal-large-organisation-what-we-learned
• https://prague2013.drupal.org/session/auditing-drupal-sites
• https://prague2013.drupal.org/session/reinventing-drupal-design-workflow
• https://prague2013.drupal.org/session/drupal-8-deployment-and-continuous-integration
• https://prague2013.drupal.org/session/writing-unit-testable-code-drupal-8
• https://prague2013.drupal.org/session/route-planning-drupal-openlayers-and-powering-phonegap-mobile-apps
• https://prague2013.drupal.org/session/mozilla-persona-webs-decentralised-identity-api
• https://prague2013.drupal.org/session/drush-do-i-really-have-use-it
• https://prague2013.drupal.org/session/git-makes-me-angry-inside
• https://prague2013.drupal.org/session/automate-drupal-deployments-linux-containers-docker-and-vagrant
• https://prague2013.drupal.org/session/monitoring-drupal-infrastructure-code-age
• https://prague2013.drupal.org/session/agile-monitoring-sensu
• https://prague2013.drupal.org/session/have-build-and-automate-it-phing
• https://prague2013.drupal.org/session/panopoly-building-powerful-base-distribution