Q and A with Dries — All questions and answers summarized from Drupalcon Amsterdam 2014

One Drupalcon session of particular interest to many in the community, since the first “episode”, has been the “Q&A with Dries”, a core-conversation-track session in which Dries is joined by a panel of his initiative leads and others in the “inner circle” of Drupal 8 core development. Since I’d wished, in the past, that sessions like these had a video recording to show who was talking, I brought my DSLR and a shotgun microphone this time, thinking I’d contribute the resulting video. I don’t think the video I shot was technically perfect enough to share; perhaps I could fix that, but I also realized that one panel member prefers to limit her exposure on the Web—and respect that, of course; since it’s much easier to blur or block out a face in a few images than in a video, and since you can read this summary in much less time than the hour+ -length session, I decided to provide stills from the video, along with a summary of the questions and answers, which ranged from the whimsical (a bet on how long it would be till Drupal 8 would be released as “stable”), to various business and architecture questions, and other concerns.

(You’ll find a more serious answer to that question if you read on...). Of course, Dries began by asking each of his panelists to introduce themselves. Those present were:

Gábor Hojtsy, who works for Acquia and introduced himself, first, as the Drupal 6 maintainer; he also leads the Multilingual initiative for Drupal 8.

Nathaniel Catchpole (catch), a major core maintainer with special focus on optimizing performance.

Alex Pott, who works for ChapterThree, and supports Drupal as a core maintainer, also contributes actively in the configuration management initiative for Drupal 8.

Yves Chedemois (yched), a freelancer and volunteer contributor to Drupal core, especially active as the maintainer of the Drupal 8 Field API (he formerly maintained CCK).

Wim Leers (of Acquia, who works on the Spark initiative and Drupal 8 performance

Jess (xjm), who was the major heavy lifter for getting Views into Drupal 8 core, alongside her very active community mentoring role, now is most active with release planning and other steps toward getting Drupal 8 to the community.

Dries made everyone laugh, then, by introducing himself… and pronouncing his name as if it rhymed with “rice”. He followed by submitting the first questions to the panelists; these initial questions were selected from those emailed to him before the day of the session. Everyone had something to say for the first question.

Q: Are there any lessons learned, so far, from the Drupal 8 release cycle?

Alex Pott pointed out that changing core is taking longer and longer as the complexity increases and the needs of the greater Drupal community become more varied. “It’s no longer a matter of developers having a good idea and putting a patch on Drupal.org”, he said. You have to get everything reviewed and tested and re-tested, usually through many iterations, before a patch finally makes it into core.

Yves Chedemois (yched) added that it really helped having a bigger team of people assisting in the Field API initiative, compared to how things have sometimes been in the past, before the initiatives, with only one or two people working on a particular sub-system; so now he might have five or six developers actively supporting him and who are all able to review each others work, and take over from one another if anyone is ill or leaves the team. He pointed out that, of course, finding five or six people who can keep active for the full 2-3 years that has been this development cycle has been one challenge; it’s just not realistic to expect.

Gábor weighed in with the fact that the whole extra communication with the community was something that hadn’t been so present before and has helped to find people identify their strengths and find ways to contribute to the development process. Extra communications on Drupal.org, the core conversations like this Q&A session, and the initiatives, themselves, helped to build a better level of involvement and ability to contribute.

Dries also added that people asked whether the initiatives, themselves, were a success, and wanted to say that he, indeed, found them very useful for the development cycle. It helped communicate a sort of roadmap for Drupal with the key areas that needed work. Having clearly communicated, specific goals, and teams working with specific areas of interest, in turn helped gather more people to help. He pointed out that the initiatives which were most successful in gathering a team to rally to their cause tended to be the ones with leaders with the best ability to communicate their goals; and of course they also had to have great technical skills and be skilled project managers. Dries added that, if he were to do it again, he would try to get a small team together for each initiative, from the start, with individuals able to bring all important strengths to work for each initiative. It’s a lot to ask from one person.

Q: How do you best prepare for Drupal 8?

Nathaniel Catchpole (catch), suggested that if you are a site-builder, experiment with building up a Drupal 8 version of a site you want to migrate to Drupal 8, or just begin building up a site; just remember that we are just at the first beta, so things might be changing. But if you just practice building up your site structure and learn what you can do, that can be very helpful as a first step to being comfortable with Drupal 8.

Wim Leers added that it’s a good time for the community to get the input from experienced site builders who have familiarity with how things work in Drupal 7 and might find some areas where performance or user experience have been affected in a negative manner; there might still be time to fix remaining issues identified now.

Jess recommended that users who need to migrate from Drupal 6, which is scheduled for “end of life” about six months after the release of a stable Drupal 8.0.0, practice building up the functionality they need in Drupal 8, determining any areas where core functionality doesn’t fill their requirements. A lot of functionality which was formerly only in contrib is now in core, but you can identify what contrib modules you still need to see ported. Keep your Drupal 6 site running, but you can locally test and practice the migration path from Drupal 6 to Drupal 8. Currently this path lacks a user interface and has some other rough areas, but there is documentation. Then you can follow and support the development of contrib modules that are blockers for your ideal upgrade.

Alex Pott added that if you are a PHP developer, it’s a good time to be learning about all the new object-oriented stuff in core; getting your head around that. He recommended looking at PHP: The Right Way for some good tips. Themers should work on learning Twig and a new base theme, Classy, just committed to Drupal 8. But beware, the others added: the theme layer will not be frozen until closer to the final release date, so there are still some things that will change. Also, there is now a full-featured Entity API in core, so when modeling your site, think in terms of entities and think about what is really content or not.

Gábor reminded us that even if you aren’t ready to dive into Drupal 8, there are a lot of good talks, blog posts, and development surrounding bringing a lot of “Drupal 8 improvements” into Drupal 7 sites, so you can learn your way around PHPUnit, Composer, etc, as a first step to getting comfortable with Drupal 8.

Dries then opened the floor to additional questions from the audience. The first participant actually asked two questions, one more serious than the other.

Q: If you had to bet on the release date for Drupal 8, what date would that be?

This question got a good laugh and perhaps more discussion time than was necessary. After skipping it to take his serious question, this one actually did get some answer time; Jess made some cogent points: that it’s not a good idea to base business decisions on any predictions around the release date of Drupal 8, but that the community is betting on it being soon and successful. She suggested that any really large projects which will take years to develop are good candidates for looking at the components of Drupal 8 as appropriate building blocks and starting work. His second question was one that, perhaps other developers who haven’t yet worked (much) with Drupal 8 code, could relate to.

Q: In the past, someone who doesn’t do a lot of development could still make a simple tweak to simple module. Now there is so much code for the new Symfony-based modules. Isn’t all this code scary?

catch pointed out that once you are familiar with it, there are still lots of places you can easily make the same kind of tweaks with Views in core, and with plugins and the configuration management. yched added that most of the hooks available in Drupal 7 are still available. Gábor said that he could remember a time, not so long ago, when he’d also been daunted by the complexity and differences between the way things are done in Drupal 8 versus how they were done in Drupal 7, but after starting to work with it, you will learn the new patterns and it starts to make sense and actually be easier, in many ways. Dries added that it’s common to be daunted by the “more-lines-of-code”, but that the object orientation actually reduces the complexity and makes it easier to extend and understand, once you are familiar with the design patterns. He also pointed out that in Drupal 7 you had to know all the hooks and that now, it’s more declarative and you can work with what you want to happen, based on events. So there is less you need to learn, and less “magic”.

Wim reminded us that Drupal 8 introduces greater strictness, which translates to an increase in verbosity, but also makes it easier to find and avoid problems.

Q: How does Drupal 8 architecture matter to clients? Why should they care about developing a site in Drupal 8?

Chris Amato (knectar) asked this question, to which Dries began by pointing out that there is a lot more support “out-of-the-box” for things like mobile content, with responsive designs and services deeply integrated. yched added that every entity type is now natively translatable and versionable and that every field can be manipulated with the same familiar tools. Gábor added that there are lot more Views and things that can be individually tweaked to a clients needs. Even admin pages are Views-based and the modules you use will also incorporate this flexibility, so there should be less need for hacks to work around what a client needs.

The next question had to do with decoupling in Drupal 8 and so-called “headless Drupal”

Q: (paraphrased) How does “headless Drupal” and decoupling fit in and is this something we will be seeing more of in Drupal 9?

Dries said that it was really too early to know what the focus of Drupal 9 would be, but that it would likely involve greater decoupling, yes. Others pointed out that it’s already possible to do a lot with headless Drupal and that we can look for a big growth in that direction coming from contrib and possibly making its way into core before Drupal 9.

The next question brought us to the issue of documentation.

Q: Will there be some books for Drupal 8 and better documentation?

Gábor started by pointing out that there is already a Drupal 8 API section, a lot of which is pretty well fleshed-out. There are still places for people to get involved and help update since there have been so many changes since the initial pages were written. And Jennifer Hodgdon is already working on a book for Drupal 8 development. Dries pointed out that there are now about 50 or so books on Drupal 7, and that things are still changing enough it’s still too early for publication of Drupal 8 books, but that we can expect a variety of books on Drupal 8 soon after its release. The API documentation and other Drupal 8 usage documentation is in various stages of completion. xjm pointed out that we need help with the documentation on drupal.org and that this is a great way to get involved.

Q: “What is being done or can be done to help bring funding to Drupal development?” (heavily paraphrased)

Rudi van Es, an Amsterdam-based member of the local Drupal shop, limongroen, came with this question.

Dries indicated that the Drupal Association can sometimes help find parties who would also benefit from certain development to help find funding for some projects, but that this is part of what Large Scale Drupal is working to accomplish and that maybe we also need a “Small Scale Drupal” to work more directly with individual developers. Some of the funding that has already come out of Large Scale Drupal went into improving workflows for media and publishing companies on Drupal; this effort has been added to the Workbench project. Dries also reminded us of his keynote, where he discussed better incentivizing contribution. And some organizations might be more willing or able to donate than actual time and expertise to Drupal development. Dries acknowledged that there are limits to the number of companies who are actively funding Drupal projects and initiatives and this is one of the challenges facing the community. While Wikipedia has been able to successfully crowdfund, they have a unique advantage in being able to directly access the end users; Drupal end-users are largely unaware of Drupal.

Q: Is it possible for us to reach a point where we can remove the trouble of upgrading and Drupal is just Drupal, regardless of version number?

That question came from Matt Smith of Lingotek, who asked a question I have asked before; a tough question. catch started by discussing what they have planned for Drupal releases now, which is already a huge improvement, that Drupal 8.1.0 and 8.2.0 can bring new functional improvements without breaking the API and that by growing slowly, they can minimize the API breakage needed when when it finally is necessary, to re-think a way of doing something and that would be the point we move to 9.x development. We might not be able to avoid breaking the API, because avoiding this can put us in a place the we have to deal with stagnation, but we will make our best efforts to minimize this going forward and it may be that in the beginning of Drupal 9, modules that have worked with each progressive minor version will, mostly not be broken by the initial changes in Drupal 9. As the architecture becomes closer to ideal, we should be able to greatly improve this, as we move forward. xjm added that the release cycle they have adopted now is like Ubuntu and there will be long-term support for some releases.

The final question taken was about tools. In short, the question was…

Q: What development tools are you (core committers) using to manage your work?

This question came, again, from the same fellow (sorry, I didn’t quite get your name), who asked “stable release date”, and the “Isn’t the big, new code complicated and scary?” questions. As the code-base becomes more and more complex, people who used to simply work with a text editor are finding it harder to manage and more and more developers are using IDEs, in particular PHPStorm, which this guy felt seems to be so prevalent now as to be almost a “soft requirement” for Drupal development.

Here, Dries suggested each of the panelists provide a quick answer about their preferred editors of choice and then wrap up the session: xjm started by saying she still mostly uses Emacs, but has started “tasting the forbidden fruit of an IDE in the form of PHPStorm” and said that without 16 years of using Emacs, it wouldn’t be a tough decision. It does make your development life a bit more sane. Gábor said that he has adopted PHPStorm. catch said that he’s still using Vim and holding out as long as he can, but will probably give in at some point and start using PHPStorm. There was brief discussion then, about fear that if everyone adopts a commercial product like PHPStorm, that this could lead to JetBrains taking advantage of us with monopolistic behavior. (Personally, I'm not worried and have respect for the offer they continue to honor: free licenses for open-source contributors.) Moving back to the panel, Alex Pott confessed that he uses PHPStorm. yched also uses PHPStorm and added that it really just makes navigating a large object-oriented codebase so much simpler; navigating between the classes, implementations, overrides, and so on. Wim Leers said that he continued to use text editors until a few months ago and has now also started using PHPStorm. Dries joked that he uses email, then confessed that he doesn’t get to code that much these days, so shouldn’t be taken as a reference, but still uses vi when he needs to make some quick changes.

Final thoughts…

It may be late in the game, but it’s a good time to help with the final work to get all the biggest bugs resolved so that Drupal 8 can be considered stable. There are lots of way to help, from identifying issues (beta testing or areas where documentation is lacking, etc), to simply verifying that bugfixes do what they are supposed to do. And there are a lot of nice tools, now, for helping review tickets. If tickets can be reviewed right away, it is more likely they just get finished before they drag on for months, require “re-rolls”, and all those hassles, and many such tickets are not difficult to review. I’m glad I made it to the Drupalcon rather than just watching/listening when I had the time.

And I should probably say that it’s been far too long since I’ve written a Drupal-related blog post here. I’m not going to make excuses: the truth is that I’ve been pretty much inundated with OtherStuff™, including some work on a complex, semi-mature project which only involves Drupal and so stopped having time to contribute, look at much actual Drupal code, or spend much time learning about all the “new things” going on. So I didn’t feel qualified to write about what was going on in the Drupal world. But I came to Cocomore for the Drupal, so I’ll work on reaching a better balance and hope to find time between all the OtherStuff™ to see you again, soon. The sprint Friday and weekend got my Drupal-thirst going again; Randi and I are already looking at a vacation rental for the full week in Barcelona next year (woohoo!), so you can count on it at least not being too long.