I attended Drupalcamp London and its pre-camp CxO business day last weekend, and it was as good as I'd predicted if not better. A lot of what's so great about it is difficult to write down—the conversations in hallways, the putting of names to faces, the "a-ha" moments for your own way of working—but here's a few notes on what I picked up on the day. The kind folks over at Real Life Digital have already written something more succinct, so feel free to read theirs first.
A note on the format of Drupalcamp London
Tempted though I am to plough straight into my own findings, I also want to exhort people who haven't been to a Drupalcamp, to go to a Drupalcamp. Honestly, there's no better value for money, pound for pound. The whole weekend took place at the amazing City University buildings near Barbican; we were all amply housed in what feels like a relaxed (if quite well populated) sprawl, with a dozen rooms off a long, branching corridor. (The Friday was in a slightly different part of the building, somewhat smaller and more focussed, but still worked well.)
That long stretch of corridor was good for seeing people, chatting to people, stopping to sit with people... almost too good, in fact: when I stopped on Sunday for a breather, I spent the entire session I was breathering for in discussions. But meeting people is really what a Drupalcamp is about, and its smaller scale (400–500 people) means that you're bound to bump into someone who doesn't actively want to avoid being found!
Although the schedule is technically less formal than a full Drupalcon, the choice of venue means talks still feel very professional, and are of a very high overall quality. University lecture theatres and other resources are probably less polished than posh conference centres, but more focussed on learning and getting a message across. Similarly, the food is always a bit more utilitarian than what's on offer at bigger conferences: but generally great for vegetarians like me, and always tasty and filling.
We are finally off the Drupal island
What was clear from the camp—and didn't feel quite so much so at Drupalcon Barcelona, prior to the D8 launch—is that Drupal as a community has finally started looking outwards at other standards, other third parties, other communities. D7 will be around for a long time yet, but the focus has shifted, and in part because it's such a relief to be able to finally move away from technologies that were hard work to use, or of limited use outside the Drupal project.
Two of the big elements of developer "Drupalese"—the hook system and the theme system—have had such a major overhaul that they've all but disappeared, from the perspective of a Drupal-only developer. Many hooks have been refactored away, and three of the big remaining ones—boot, init and exit—now use the Symfony EventDispatcher. Eric Smith's talk covered this in depth, and was a great primer for starting to work with those parts of the system.
Meanwhile, it's fair to say that D8 templating has been revolutionized by the adoption of Twig: Lauri Eskola spoke about PHP's own implementation of the cross-platform semi-standard Mustache-like zoo of templating systems. Not only does an absence of executable PHP remove a lot of the side-effect problems long associated with raw-PHP templating (even though PHP is in there somewhere, deep inside the cache of compiled templates) but any problems that arise are having the eyeballs of many non-Drupal developers on them, along with the existing cadre of dedicated Drupal debuggers.
A couple of things that getting off the island allows us to outsource:
Outsourcing recruitment. As with adoptions of other standards, these two major third-party replacements for code we Drupalers used to have to maintain are a big improvement; even discussing them felt like a breath of fresh air. But the panel session on the CxO day sounded a note of caution: we might be off the island, but we're not shouting about it enough. If we were to do so, then we might effectively outsource the solving of our recruitment problems, as more developers turned to Drupal, knowing that the skills then learnt would be more transferrable elsewhere.
Outsourcing experience. Another key thing we can outsource is developer experience, and this might let us shift the focus of our own UX efforts onto (much) less technical end users. Until recently, UX in Drupal has had to juggle so many different balls—technical programmer, frontender, site builder, power user, occasional editor, site visitor—that making any headway has been a nightmare; pace the valiant efforts of D7UX and D8UX, Drupal UX improvements have tended to be very many, but tightly boundaried, because so many stakeholder requirements can be difficult to herd efficiently.
But when we live in a Drupal world where Twig is helping to cater for the frontenders, and Symfony for the technical programmers.... Suddenly our stakeholder focus can be tightened on the remaining users. Keith Jay's talk on the "unboxing" experience of Drupal was (as these things always are) quite the eye-opener. When a non-technical site builder can put together a very nice-looking Wordpress site in a day; when potential future clients are actively put off during the tender process by the "is that it?" experience of unwrapping Drupal for themselves: what purpose does it serve making non-distributioned, non-extended Drupal still such a "vanilla" experience? Can we make substantial improvements to client experience, while still letting seasoned Drupalers do what they need to do?
Explaining what our audiences should ought to be won't work when recalcitrant audiences—often those with serious influence over Drupal's spread—are nonetheless peeking under the wrapping-paper and not understanding what they see. Drupal doesn't advertise at the Superbowl like Wix, and maybe seasoned Drupalers don't see that worth commenting on; but other Drupalers, who find they can't get the clients who do watch the Superbowl: how do we help them to maintain market relevance, by helping potential clients see the value in freshly unboxed Drupal?
How Drupal can pull its weight in business
Because I went to the CxO day, I necessarily got a more business-y slant on Drupal than I would usually. The whole experience was, of course, entirely out of my comfort zone: as I've stated previously, I'm more of a software gardener than a Chief Xomething Officer; certainly the shock of an interactive session at 9.30 on the Friday isn't one I'll forget for a long time! Is this how businesspeople usually business the businessing? But, I told myself, they also serve who stand and hold a pen, and doing so let me wake up more slowly than others had to.
At that interactive session, our sub-group discussed sales and procurement for Drupal shops of all sizes. Again, as Julia from Real Life Digital prepared slides for presenting to all attendees afterwards, her notes are especially useful. The headline figures are themselves interesting: almost everyone present had procured from referrals, existing clients and partnerships, but very few from Gcloud or similar services. The low figure for contributing aside, this does at least show the power of the informal network, which is potentially open to all but does need cultivating. Prosaically, the panel discussion even mentioned having a press list, of personal contacts to mainstream, old-skool journalists. I know of at least one Drupaler who's had surprising success with the local press!
From a practical perspective, the key message from Stefan Haefliger's excellent talk on open-source software and business models was one of caution. In developing business models, we often make assumptions about people's motivations that are outdated, and don't make sense in the context of open collaboration. Reward-based motivations are a tough fit compared to a social-practice model, and while a lot of this seems obvious, you still get big companies—IBM, Oracle—that clearly don't get open source at a fundamental level.
Graham Lane's talk on the building of the GLA and Mayor of London's website struck an optimistic note on this same chord, however: despite an unpromising, barely-agile start (multiple product owners, a project board, monolithically long timescales, many brittle and tightly-bound dependencies) the project was still both a success on its own terms, and also had encouraged the takeup of agile within the rest of the organization. The public sector is historically the most in need of agile, the most suited to risking small-scale agile, and yet the most reluctant to do so, making this message practically heartwarming.
Focus is key: do any single thing, well
Another key take-home from both the interactive and panel CxO sessions was that focussing on a particular niche or vertical was key to gaining trust, respect and inbound leads. Niches give you confidence to push back and make you clearly more expert in the field. But the concept of niches, and establishing yourself in them, became a recurring theme throughout the weekend.
Prosaically, Alexis Cheshire's keynote about the Scout Association's experiences in adopting Drupal showed that applying focus where it counts had brought them many returns. In some ways the Scouts operate in a horizontal market, with very many and varied members and other customers (they even run an insurance broker that serves other large organizations like the Guides.) But by focussing on Drupal as a technical solution, they saw big security and maintenance returns, as they could then focus in a second phase on key technical partners from Drupal's wide range of agencies and single players, and tighten up other bolts on their software processes accordingly.
In comparison, Michael Schmid's talk about how to be a CTO, team leader and line manager was more of a deep dive on those specific topics, coming up with a lot of recommendations. Along with the reassurance that firing people is always going to be horrible (so at least forewarned is forearmed) he also came up with tips for how to avoid getting there: ask other team members, and expect them to not want to complain first time; define goals and deadlines, and don't accept baby steps; and definitely don't wait, because sloppiness is infectious. But another key take-home from Michael's talk was (again) that a company should find its niche, its focus. It can use that to explain: what it does; what it will do; and, more importantly, what it won't do.
With Drupal, we so often talk about all the many things it can do; and it can: community websites; e-commerce; media platforms; massively content-led charitable resources; academic websites; news. But that very lack of focus—represented in things like the unboxing experience—can make it hard to sell compared to tailored products. Without further, clear, coordinated promoting of the highest quality distributions, Drupal could have trouble attracting new, non-technical fans. And without clear, coordinated promoting of the specific, focussed, and sometimes exclusionary things your business does, then it could suffer too. Turning down work that isn't in your niche can be hard, but in the long run might attract more work in the niche itself.
A shoutout that doesn't really fit in the above, Philip Norton's talk on becoming a Drupal master builder is a quick and informative read that will hopefully change the way you Drupal. Once again, that great panacea of D8 is hoped to encourage better development practices; but there'll always be a need for sharpening your toolkit, and learning how to hold the damn things properly.
It's moments like that talk and Michael's, really, that are more indicative of a Drupalcamp than the big themes I've been trying to draw out here. Everyone takes home their own broad impressions, and tries to join their own dots: I know mine have been influenced heavily by business this time round. But the individual talks, the chats with peers, those flashes of understanding and revelations of gems and resources previously untapped: each of those little epiphanies is what a camp is really about. That and the pastries. How would you live with yourself if you missed it again next year?