I've been working with Drupal since 4.6 and was somewhat involved in the process of making 4.7. That was about 8 years ago. Here are some truths I've learned in that time.
There is at least one arc to people's involvement: people go up and people go down
Think about your involvement in Drupal. Did it start at some level, stay at that level, and continue at that same level indefinitely? Probably no. You are somewhere on an arc of involvement. You may be on a mini-arc within a bigger arc. When you first heard of Drupal you didn't immediately jump in and file bug reports and help do usability studies and write documentation. You tried it out. Then you did a little contribution and you liked it (or hated it) but your involvement probably kept increasing for a while. Right now maybe you're headed up or down - maybe you're involvement is decreasing right now because of a big project at work but you know it will increase 2 months from now because your next project will make it easy to contribute to a given module (or core?). Let's look at some real world arcs of involvement.
Let's look just at Drupal Core involvement. I've used the data from marvil07 which includes analysis on commits to the main branch of core (originally CVS and then migrated to git) since 2000. Here are the top committers for the years 2000 to 2003, inclusive:
|natrak (pseudonym of Kjartan)||82|
Very interesting! I only recognize 8 of those 13 people, but they are the foundations of Drupal for the first quarter of its life. Let's look at the next 3 years: 2004 to 2007.
|Neil (pseudonym of drumm?)||82|
So, looking at the 2004 to 2007 time frame we see a few interesting new faces. Gabor has shot up in involvement. There are some brand new faces (drumm, chx, webchick, pwolanin, JonBob) who seem to be doing a lot of work. Moshe, Gerhard (killes), and Kjartan are still doing a lot of work. And lots of people who were essential contributors from 2000 to 2003 are no longer in the top list.
Now, let's take a look at the top contributors from 2008 and see what has happened.
Do you see some interesting patterns in there? I think I do. Over the course of years we can see that people spark up and then fall off. Look at drumm, who was key in the 2004 to 2007 time period. His involvement in core has steadily fallen since 2008. JamesAn was pretty busy in 2009 and has done a lot less in core since then. I'm not picking on these people to criticize, just pointing out a pattern. It happens. It's OK. That last table was based on the ongoing behavior of the top contributors from 2008. Let's look at the list of top contributors in 2013:
Compare the 2013 list to the 2008-biased list. Alexpott, dawehner (2 commits in 2008), tim.plunkett, damiankloip, swentel, Wim Leers are either not present or barely there in the list from 2008. That's right: 6 of the top 13 contributors in 2013 were not in the top of the list from 2008.
As Emma Jane Westby said in her Reddit "ask me anything":
Lead, Follow, or Step aside. It's a question that I have to force myself to answer on a pretty regular basis. "Am I leading effectively? Am I happy to follow someone else's lead? Or am I trolling, and is it time to step aside?" OSS communities are so tight-knit that it makes it really difficult for someone prominent to "quit" their community.
My conclusion from this is that people come and go. And in some cases, they come back and go again and...you get the idea.
It's nice when we can rely on people, but it's naive to think they will always be there always doing the same amount of amazing work in the same way. Does it mean that Drupal is dying because some people have left? Hardly. It is part of a normal cycle.
Why do people get hyper involved?
I think it's fair to say that most people in these lists are "hyper involved." Dave Reid has said that a big part of his involvement (core involvement peaked in 2009) was because he was learning Drupal which then turned into a job. I know that some of my biggest involvement was possible when I was purposefully between jobs and living on the thrill of commits and fixing bugs for other people. So, what are some of the motivators?
- The thrill of seeing their code committed (in this data it's to core, even)
- The thrill of closing out issues - klausi has said he just loves closing issues
- Learning PHP/Drupal/web development (the core queue is one of the best free universities I've ever seen)
- Feeling wanted - people submitting issues and getting bugs fixed means you are valued in the world
- They get a new job that requires them to work on Drupal and...hey...might as well contribute it
But, once that hyper involvement is gone, once Dave got a job, once my purposeful stint between jobs was over, it becomes harder to find time for hyper involvement. Should we be mad at Dave for reducing his involvement in order to be a good employee? Should we be mad at Palantir for hiring him and giving him at least partially funded time to work on contributing code?
Why people decrease involvement?
- They get burned out on the guantlet that is our issue queue or on using git instead of hg or on...whatever
- They do more work in less visible areas of the project (drumm with infrastructure and drupal.org, rfay with testing)
- They have a babby
- Their spouse's work situation changes
- Their hobby, which they like more than Drupal, becomes their job
- They get a new job that doesn't involve Drupal (you could argue that Drupal jobs are so prevalant that this is more of a choice than a force)
- They lose the joy from getting code committed
- Their original involvement level was unsustainable (in between jobs, before a job, part of learning) unsustainable trends must end
Which, if any of those, should we do something about?
What about the Security Team?
As a Security Team member of many years and Security Team Lead for 2 years, I've looked very very closely at a lot of metrics about the team. In addition to metrics we've gathered more subjective data: we have brainstorming sessions every 6 months and we've also done formal surveys of the team. Based on all that feedback we made improvements:
- to educating module maintainers
- improved APIs to make them harder to create vulnerabilities
- to the infrastructure we use to communicate with researchers and maintainers
- to the advisory creation process
And I can say with a strong degree of certainty that these changes have greatly reduced the number of vulnerabilities that exist and improved the speed we publish security patches. But...they can't help that a team member no longer gets a thrill from finding a bug. They can't help that people have babies or other shifting personal priorities that make them care less about fixing bugs. They can't help a lot of things that cause people to be less involved in fixing security issues. So? So we keep working smarter but we also just keep working: we actively recruit new people. There was a time when everyone on the security team was a brand new member. There was a time when they all made their first blunder or got confused about how CSRF works and how to protect against it. New people will make mistakes too and that's OK. Mistakes are part of learning.
Another example of someone who was "new": Look at Dawehner's core involvement from 2008 until now. It's like a rocketship. 2 patches in 2008 and above 390 in this past (incomplete) year. Wow. We should be looking out for more people with the potential to move on a path like that. We should find out what activated him and see if we can create those conditions for other people.
Make new friends, but keep the old
I'm not by any means saying that we should accept people leaving the project. I am sad when people decide in some way to leave the project or reduce involvement or...whatever. But I respect their decision.
A few thoughts:
- We should not encourage people to do unsustainable things. If someone is stepping down, respect that need.
- If and when people step down, they should do so considerately as our Code of Conduct reminds us.
- It's better to know that someone has left (and get someone to fill that void) than it is to have a ghost maintainer.
What does it mean to leave in a considerate way. I think this is worth a lot of thinking. It's easy to justify your own behavior - after all, most people think they are doing the "right" thing and convincing others to do that same right thing is pretty natural human behavior. While I'm being somewhat relativistic here, I want to be clear: it's easy to leave some role, see others replacing you who make mistakes, and come back and criticise them in an unconstructive manner. That's not really helpful.
So, I respect the issues where Nate Haug and Dave Reid asked to be removed from MAINTAINERS.txt. In theory I should hope that everyone has the energy and consistency that webchick and Dries bring to the project (look at their commits per year from 2000 through 2013 and you get a sense of what I mean). But, that's not realistic. So I think Nate and Dave for the work they've done and hope that they may be in a moment of reduced core involvement that will turn back up. But until then, we can find other people to do that work.
It's important to set realistic expectations for people both in terms of what can be done per time period and how long that energy can be maintained.
The Drop is always moving - because everything else is too
I've read a lot of articles and books about Drupal over time. When I first learned it...that's about all I did was learn it and build horrible sites for myself exploring site architectures. A lot of people say that Drupal 8 is too confusing. If you feel that way I'll ask: are you still learning about the technologies involved as voraciously as you were when you first learned Drupal? Are you still learning about Drupal with as much passion as you were at first? If not...consider if Drupal is more complex or if you are just complacent. PHP is not going to sit stagnantly. Web technology is not going to sit stagnantly. They are moving forward and we must move with them.