Summary: 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...
