I've already written up copious (and semi-coherent) real-time notes about Drupalcon Barcelona, and you might want to read those: if you can make sense of them. However, now that I've had a couple of weeks (including a house move) to think more about what went on there I think I can see a few bigger themes that are worth summarizing.
Community and welfare
The most important message coming from Drupalcon is that we've started talking a lot more about how we maintain our community. While a lot of open-source projects claim an orbiting community, Drupal is one of the few that has always genuinely fostered and boasted about all the people involved in it, both separately and as a crowd. But our community has grown rapidly, and maybe not entirely organically: from 850 attendees at Drupalcon Paris in 2009, to over two thousand in Barcelona.
While some of that might be considered to be Drupal being a victim of its own success—adopting standards in favour of Drupalisms has opened doors to historically non-Drupal programmers, and I see a lot of new faces for that reason alone—it's hoped that the bane can also be the antidote: a bigger community has potentially more resources to devote to the very community matters it entails.
And so, alongside the influx of wonderfully unfamiliar faces, we have: a whole pre-conference day of community summit, alongside the business and training tracks; a considerable firming up of the mentored sprints programme, thanks to YesCT, alimac and others; ethnographic interest in how our community functions from David Rozas; and Mike Bell highlighting welfare and mental health; and continued focus on the pain points of contributing to Drupal from Kalpana Goel and Valery Lourie.
There's still a lot we could do better in Drupal, but it's heartening to see that, as Drupal's codebase pays back its technical debt (more on that later), we can look to the more important aspects of Drupal's past and long-term future successes.
Drupal 8 is mostly ready if you can handle it
The recent announcement of zero release-blocking critical bugs in Drupal was followed by the first Drupal 8 release candidate, consistent with the prediction during the Driesnote! It's been a long hard slog, for sure, but the amount of technical debt—the inevitable accumulation of out-of-dateness that comes from a 15-year-old PHP project trying to maintain some kind of historical continuity—that we've repaid is immense, and it puts
Because Drupal 8 is "nearly ready", its major APIs have "mostly settled". Barring any serious problems, interesting new frameworks in Drupal 8 like Configuration Management can and should be used with gusto: not least because that shakes out the bugs! Having Views and Field API "fully cognisant" of each other also means that these will be really exciting to delve into.
Another consequence of Drupal 8's architecture is that we were able to spend a lot of Drupalcon talking about code that was effectively not Drupal. Because one consequence of moving to a 2015 flavour of PHP means abandoning "Not Invented Here", we can talk about how Symfony and Drupal both compare and contrast; we can delegate our handling of HTTP to a third party library (and maybe even standardize on PSR-7); and we can much more easily drop complete innovations like GraphQL into Drupal, and just sort of see how they work. The last item is a potential powerhouse of Dries' own suggestion, that Drupal could provide a "progressively decoupled" CMS through support for complex data transport to semi-headless frameworks, rapidly improving the in-browser experience.
From not-Drupaling to not-even-CMSing
Personally, I was also really pleased to be able to step out of Drupal entirely and focus on aspects like content, usability and business management. Pamela Barone showed how to plan for a siteful of readable, findable, usable content, and how this was too often neglected in the face of technical demands on the project's time. Alongside Jody Lynn's talk about IA fundamentals in Drupal—what its menus, breadcrumbs and paths do well or badly—these two talks provide a good starting point for getting content right from a really early stage in the project.
Drupal's usability and the user experience of working with it was brought into sharp focus by Angie Byron, Lewis Nyman and Bojhan Somers. However we proceed with the results of the studies—and in the past it's been too easy to let UX concerns be dismissed—it remains a wake-up call for everyone working in Drupal. Even something as simple as making sure help text is consistent and relevant, as Antje mentioned during the questions, can reap huge rewards in usability.
Finally there was a number of engaging talks on the business track. Dania Gerhardt talking about how a business might diversify beyond Drupal, and how heart and mind should march in step when it came to big decisions during the process. And Ashleigh Thevenet explained how they handle fixed-bid quotes: the upshot is that it's still not a totally solved problem (especially in the public sector); but that there are a number of tactics you can bring into play to keep costs on track, even if your project cannot for whatever reason support "full agile".
Summary
As Drupal becomes a "good" modern-day PHP citizen, everyone involved in Drupal can spend less time having to learn Drupal ways of working, and more time thinking about problems which, while common to many software projects and usages, come with a Drupal twist. And so Drupalers can think about how we keep our existing community vibrant and welcoming; we can look to international standards, rather than code we might ourselves have to maintain; and we can start looking towards.
This has often been the case with software: word-processing software went from complicated, expensive solutions, to off-the-shelf offerings, to essentially background noise, where "anything will do"; rich-text editors have gone the same way. And so will, and should, Drupal: most of us don't use CMSes, in order to use CMSes; we use it to get other things done.
