Part 2 of 3 - I got to spend a half a day with Drupal Project Lead, Dries Buytaert, in Antwerp recently. This was a rare pleasure, given the success of Drupal and Acquia in recent years and how busy we both are. In between shots for some professional video material, Dries and I sat down in front of my tiny cameras and microphones to talk about Drupal 8. In parts one and two, we touch on how we got here and lessons learned along the way, what Drupal 8 brings to the table, and more. If you don't normally take the time to watch the video version of the podcast, this week is the week to do it. Parts one and two each have a couple of nice visual moments, but part three is something very special. It's all "behind the scenes" video of us driving back to the dorm room where Drupal was invented and Dries seeing it for the first time in 15 years.
"Go port modules!"
Interview video - 19 min.
What did you learn from the Drupal 8 development cycle?
"There's a lot of things we learned and we made a lot of changes as we were learning. Process changes, policies that we put in place to optimise things as we were going. To pick out one, one of the biggest things we did in Drupal 8 is this idea of initiatives. We didn't have them before Drupal 8. We launched Configuration Management, Mobile, HTML5," and many more. "Overall they've been very successful, but we've learned there that the initiatives that were the most successful were initiatives that were run by cross-functional teams, versus one individual. That's an important learning. I would like to do initiative again, but we would structure them a little bit differently."
Scaling Contribution: burnout, bringing the fun back, deep or wide?
"Burnout is a difficult topic and I'm not an expert, but my initial reaction would be that we have to keep going. We have to keep innovating Drupal. We don't have the luxury of just doing nothing because the world around us is moving so fast. We have to find ways to keep innovating. At the same time, it doesn't have to be the same people that keep doing all the work and it doesn't have to be the same people doing even more work. We have to find a way of working that allows us to keep our pace of innovation going, but at the same time, gives people a break. And make sure people can work in a sustainable and healthy way. With burnout, it's often people themselves that have to change. I don't know what we could do in Drupal that would fundamentally change that. The challenge here is that these people in our community are so committed, they're so passionate, they're so driven that they are unable to take a break. A lot of it is you as an individual deciding that, 'You know what? I need to take a break, I need to reduce how much time I spend. I need to go to a healthier state. In my mind, I try to decouple these: the pace of innovation of Drupal and the pace than an individual works at in our community."
I have had conversations and seen presentations with Lauri Eskola, and others, especially in the Drupal mentoring community, who want to build a wider base--a larger number--of contributors to help solve both of these problems; keeping up with innovation and preventing burnout.
"Drupal has a great architecture that allows a lot of people to contribute to the project. We have 30,000 active contributors. The architecture and the modularity allow people to contribute and allows us to work at scale with a lot of people. There are parts of core that are really hard and we don't have enough people that know these things inside out. As a result, a lot of people in the core development community take real ownership of this--which is wonderful--but it also risks burning them out. There, the challenge is how do we get more people into the core developer community so that we can spread the workload? I am passionate about this. I dedicated a whole keynote to it [at DrupalCon] Amsterdam. I've been writing about it a lot and I've helped other people get hired as core developers, obviously at Acquia, but also helped coach other companies on how to hire core developers so we can have a more manageable work-life balance for these people and bring more people into the fold."
Should Drupal shops hire core contributors?
"I think so. John runs ChapterThree. Nica Lorber from ChapterThree wrote a blog post recently about the impact they've seen from hiring Alex Pott, one of the core committers." John and I also spoke about this in a couple of podcasts earlier in 2015 (Sustainable contribution, 1/2 - How Drupal has solved and evolved and Sustainable contribution 2/2 - Giving back is the same as making money). Dries wrote about this in 2014. Dries continues, "It really helps when these core contributors spend some of their time helping to do ... basically marketing and sales support. It can be as little as half a day a week where they're on calls with customers; where they do podcasts or blogs. If you can convert a percentage of those, that can really add up in terms of growing your revenues."
"There's also the effect internally with you employees, having somebody that's very knowledgeable about the next version of Drupal on staff and educate the rest of the organisation, get people excited about what's coming and all of these things. There are a lot of reasons why you should hire a core developer and it's great that we have examples like ChapterThree and John making those bets because we have to demonstrate to the world that this actually makes a lot of sense and that it can really help drive the your business. We're starting to see that now with some of the companies that have hired core developers, so hopefully that will inspire others to do the same."
Tiffany Farris, Co-Founder and CEO of Palantir.net, on the other hand, thinks that throwing all one's contribution-budget into a single person has drawbacks. For example, other team members also want to contribute, but have the rest of their job to keep on top of and this imbalance can create envy and related problems. Dries responds, "There's pros and cons to both models. Where we need help as Drupal is some of the harder problems and they're hard to solve if you only get four hour a week to contribute to Drupal. To solve some of these problems, we need dedicated people. At the same time, I definitely see Tiffany's point. A lot of people want to contribute to Drupal 8 and you want to make it a fair system. Depending on what you contribute, you might be able to do that in three or four hours a week. There are other ways you could do it. You could save up all of your time and you get one week to spend on contributing, versus a chopped up model. I think companies should experiment and should use the strategy that works for them. I don't think there's a right and a wrong way here."