Part 2 – Larry Garfield and I had a long chat in front of my camera at DrupalCon Amsterdam to warm him up for writing "Building Bridges: Linking Islands" in the Future of PHP guest blog series on Acquia.com. In this second part of our conversation, we touch on Drupal's specialist value-adds over and above straight PHP, what defines community, sustainable contribution and services v products businesses, rebuilding Drupal's foundations to make a better project for everyone, the php[world] conference and Drupal 8 itself as manifestations of all the good changes coming with PHP interoperability, how communities are building bridges between their islands and sharing innovation, and how to do the Drupal Hug™.
In part one, we covered Larry's start in Drupal, some project history, what Drupal can teach (and needs to learn) about contribution and community ("celebrating the newbie" and the power of "thank you"), The New PHP, fuzzy project boundaries and inter-project collaboration.
Community beyond the code
In the past, I think a lot of us in the community thought "Drupal is this code and we happen to be working on together so I'll hang out with these people." When the codebase (What is Drupal? What is not Drupal?) becomes more amorphous, how do we maintain a positive community identity?
Larry explains, "At some point our mission statement shifted from 'build a product' to 'be a community'. That means in some ways, we've lost focus on the user; lost focus on what we are trying to accomplish. I would argue growing the community for the sake of growing the community is the wrong approach. If our goal is to build a world-class content management system (or platform), then there are some places where community is not necessarily the answer. It's a part of it. We need to have some hard conversations around [whether there are] parts of building Drupal, the platform, that are better handled in a non-grassroots-community fashion. Dries talked about some of this in is [Amsterdam] keynote; we've got 2000+ contributors to Drupal 8, but still 80-90% of the work is done by 200 people. Dries talked about how we need steady resourcing and how we can incentivize companies to pay people to work on core in large chunks. That does change the dynamic. It might be, if we make that change, Drupal 9 – years down the line – has fewer contributors than Drupal 8. We should not automatically think that that's a negative. It's not a bad thing if there's still a healthy community and a successful platform as a result.
Building the better Drupal
He continues, mentioning something I say a lot (and I wonder if it was me who said this to Larry in Denver :-) ... "One of the things that makes Drupal so powerful and so special is that we can disagree, we can argue, we can fight, we can have different views, but at the end of the day, you know the people you're dealing with when working on Drupal, their goal is to make life easier for somebody else. They may disagree on how to do that, on what that means, but at the end of the day, our goal as the Drupal community is to make life easier for someone else ... using Drupal. That's something we should make sure we never lose."
But to get to the best experience for everyone from developers to end users, Larry points out the need for strong fundamentals: "If you try to build on something that is complex, you inherit all of that complexity. If you have a weak foundation and you build on top of it, there's a limit to what you can do. If you fix that foundation, if you make that lower level simpler and less coupled and higher quality, that ripples out to everything you build on top of it."
"The analogy that I used for Drupal 7 to Drupal 8 back when we first started was that our house is getting old. We've got some nice furniture, but the foundation is cracking, so let's pick a foundation off the shelf (Symfony components), build a new house on top of that. That house can be much taller, have much more modern electrical wiring ... and then move our furniture over. To do that, you need to have a better foundation and that ripples out through the whole system."
"Making sure that core is solid. Making sure that core is architecturally clean and well-maintained has a ripple effect. If core gets crappy, then modules, no matter how good they are, are hamstrung. And that means site builders are hamstrung. And that means end users are hamstrung. If core is rock solid and unit testable and clean and fast and powerful, that means modules could be solid and clean and powerful (or crappy) and then you can let evolution take its course there. Then that means site builders can build something that's clean, on clean modules, on clean core and that's how you get the really powerful end user experience. You need to have that whole pipeline. You need to be thinking in terms of how we enable the next layer up, rather than focusing on the thing at the end."
- Building Bridges: Linking Islands" – Larry's post in the Future of PHP guest blog series on Acquia.com.
- Getting of the island in 2013 – Larry's blog post from December 31, 2012.
- Emma Jane Westby's DrupalCon Austin core conversation, "The Danger of Having no Why"
- Dries Buytaert's DrupalCon Amsterdam keynote
- Larry's DrupalCon Amsterdam talk Managing Complexity (watch the video and read the comment thread on that page) and a subsequent follow-up post and discussion.