Who sponsors Drupal development?
We know who contributes
A few weeks ago, Dries Buytaert published his annual who sponsors Drupal development. His report acknowledges individual and organization contributions and what projects they are supporting. This report provides a high-level overview of who contributing in the Drupal community. There are some old names on this list and some new names.
Asking why they contribute
Now that we know who is contributing to Drupal, the next and more difficult question is “Why are they contributing to Drupal?” Knowing the story behind why an individual or organization contributes to Drupal will inspire more people to get involved and give something back to Drupal and Open Source.
My contribution to Drupal
This year, I was the number three individual contributor to Drupal. The previous year, when I first appeared on the top contributor list, it was completely unexpected. I joked with my son, Ben, that, "I won a race that I did not know I was running." Being included on this list was an honor that I did not expect to achieve, partially because I’m always in awe of the ongoing work by all the core maintainers and contributors.
Since last year, I have not slowed down on my commitment to the Webform module for Drupal 8. So I was not surprised to be included in this year's list. Over the past year, I have had several interesting conversations with other developers on the top contributor list, and what resonated with me the most is that everyone on this list has a different history as to why he or she contributes to Drupal. Here is more of the story.
There are different types of contributions
I found one of the biggest difference in our contributions and commitment to Drupal is whether our work is primarily sponsored or volunteer (aka unpaid).
Only 12% of the commit credits that we examined in 2017-2018 were "purely volunteer" credits (6,007 credits), in stark contrast to the 49% that were "purely sponsored". In other words, there were four times as many "purely sponsored" credits as "purely volunteer" credits.
Right now, I would estimate < 10% of my contributions are sponsored (aka paid). The fact that I am doing all this work for free is not the norm for most contributors. It is essential to note that every single contributor that I know on the top contributor list has at one time or another contributed a ridiculous amount of volunteer contributions to Drupal before being finding an employer or organization to sponsor their work. Some people, including Dries, started contributing to Drupal in college, others do it as a hobby, and some just do it.
We all have different stories about how we discovered Drupal. Our stories begin with our first experience with Drupal, the software, which is quickly followed by our first experience with Drupal, the community. At some point, we contribute our first patch, it might take months or years for us to start contributing regularly or maintaining a project. Finally, for me and other major contributors something changed and suddenly we are spending a significant amount time contributing and helping maintain Drupal Core or a contrib project.
Why am I contributing so much to Drupal?
If I had to pick one word to describe why I contribute so much to Drupal I would have to say "Brand." I am willing to bet that most people did not expect me to summarize my contribution to Open Source with a word generally associated with marketing.
The concept of a personal "brand" never really crossed my mind until I started to work with Marco Salazar, who is been my career coach for the past two years. I was inspired to work with a coach by Michael Schmid's (@Schnitzel) community keynote at DrupalCon Baltimore called "Your brain health is more important than your standing desk". Michael's first of many great suggestions was “get a coach.”
Marcos introduced me to the notion that everyone in the digital/social media world has a story and that story is communicated by one’s personal brand. The moment we create a Facebook page, a LinkedIn profile, a Twitter account, or a Drupal.org user profile, we have started to distinguish ourselves from others (aka rivals in the eyes of customers). Ironically, I never post to Facebook and rarely engage in social media, but I love to write and share code. You might say that the work that I do, the writing and sharing of code is how I’ve defined myself - my work is my way of defining myself - my content is the work. That said, all that posting, writing, creating on social media, and even coding is content
Code is content
At the heart of what I consider my personal brand is code, specifically the Webform module. Code alone is not really content.
In Open Source, our shared and freely available code is still computer code but everything around the code is content. If documentation is content, presentations are also content, even a response to a question is content.
For the past three years, I have generated a lot of content around the Webform module beginning with my personal website, this blog, documentation, videos, presentations, and responding to support requests in the Webform issue queue and Drupal Answers. Ultimately all this content has succeeded in creating a name for myself in the Drupal community. Yes, being the maintainer of something like the Webform module will help get me a job interview, more importantly, content like this blog post and even how I respond to support requests help future employers and clients understand who am I and how I work.
I understand the value of people knowing about the work I do and how I do it because in the fast and changing tech industry, it is essential not to become obsolete. My favorite children’s story about overcoming the challenge of being obsolete is "Mike Mulligan and His Steam Shovel" by Virginia Lee Burton.
The story of Mike Mulligan and his steam shovel
In this story, the main character is Mike Mulligan, a steam shovel operator, and his steam shovel, Mary Anne, are being replaced by newer diesel and electric shovels because the industry and its corresponding tools are changing. The diligent and hard workers that they are, get word of an upcoming job and in an effort to not only do their job but to also prove they can do it well and efficiently, Mike and Mary Anne boast that they can dig as much in a day and 100 men can do in a week. Mike gets the job and he and Mary Anne succeed in digging the foundation for the town hall of Popperville in one day. It turns out to be their final digging job, however, the story's ending has a wonderful approach to addressing the shift in time and technology. Remarkably, the ending which was suggested to the book’s author by a 12-year-old boy is really special and should be saved for the first time you read this book to a child. I won’t totally give it away but suffice it to say, that Mike and Mary Anne are acknowledged, remembered and valued for who they are - the town of Popperville and the world shifts, but Mike and Mary Anne still have a place in society and are not lost in obscurity.
Everyone in the software industry can relate to the challenge of feeling obsolete. Even if we master the latest and greatest programming language or framework, there are dozens more that we should/could be learning. Mastering a programming language, even writing test coverage is challenging when our work is tied to deadlines and budgets. Open Source projects don't generally have budgets or deadlines; people are just sharing ideas and working to solve challenging problems.
Contributing the Webform module provided me with a new professional challenge and community
The challenge of contributing
One of my first blog posts provides a history and the process around of my work on the Webform module. That post gives a fairly complete overview of the actual work I am doing on the Webform module. In comparison, this current blog post is exploring why am I doing all the work in the first place.
Three years ago, I was reviewing my resume and felt that working with the same institution, Memorial Sloan-Kettering, for so many years (18+) was potentially going to hurt my career prospects. I noted that my work/consulting experience was very independent and contained minimal speaking and project management experience. It is worth stating that there is nothing wrong with staying a job for years, especially if they are one of the best employers in NYC
Maintaining a large Open Source project like the Webform module is more of a software architecture and community coordination challenge, then a coding challenge.
People are watching me code
In the story "Mike Mulligan and His Steam Shovel", Mike and Mary Anne get to work on what is to be their final digging job, intermittently stating that “we always work harder and faster as more people are watching us”. And there is undoubtedly something to this. It’s very rewarding when people appreciate the work I am doing on the Webform module. Watching people gradually move to Drupal 8 and start using my work is a great feeling, especially organizations and non-for-profits that I have a personal connection with, like the YMCA who include the Webform module in their OpenY distribution.
Now, that you know the story behind why I contribute to Drupal, it is also worth discussing precisely what am I contributing to Drupal.
What am I contributing to Drupal?
Every presentation and screencast I record begins with…
My sole contribution to Drupal is the Webform module. This is a very personal and deliberate decision. I am a one project kind of guy. I do my best work when I can focus on a concrete goal and purpose. Maintaining and working on a single, isolated project is not the norm for Open Source contribution. Open Source works better when people maintain some projects while contributing to others. But for me, I find I lose a lot of momentum when having to jump from one project to another. I also feel with subsystems like Webform, someone needs to be fully engaged able to add features, respond to issues and fix bugs in a timely and efficient manner.
The Webform module is a feature-rich application. I generally add one or two new features each week and try to refactor some existing code on a bi-weekly basis. I try to break down most tasks into one to two hours of work, and almost never estimate a feature or change that will take more than four hours into a single ticket.
While working, I am very bullish when it comes to committing code - I like maintaining a certain amount of velocity as I do things. I find it really challenging to get people to review patches and frequently I will post patch, let it sit in the issue queue for a day, come back to issue, do another code review (of my code) and commit the patch.
Everyone has different levels of availability and it's understandable that someone might have time to create an issue one day but not be able to come back to review the solution. I find maintaining a certain level of quality with peer review in Open Source incredibly challenging.
Drupal's core committers do an amazing job of requiring peer review and enforcing code quality. Drupal's contributed projects are a slightly different beast. Still, certain key projects like Webform need to define and continually review their process. When Webform 8.x-5.x is finally released on Christmas, I am going to review the process for maintaining a stable version of the Webform module.
Knowing that my code is not always getting enough peer review and sometimes can cause regressions makes it crucial that I respond to issues and bugs.
Responding to issues and fixing bugs
Everything we post online is content, including how we respond to issues, which means our response is part of our personal and professional profile. I do my best to respond to every request almost immediately, especially if the research and resolution of an issue might only require a few minutes.
Over the past three years, I have responded to 100's of issues and support requests. Sometimes it is incredibly challenging dealing with people who take for granted that I am generally working for free. Surprisingly, sometimes my biggest feeling of accomplishment comes from being able to help someone who initially posts an issue that has "negative undertones". I always respond professionally and help them resolve their problem; they always say "thank you." I think I find hearing gratitude from someone whose initial tone was difficult or agitated to be a complete 360. And to have that kind of affect on someone feels good.
Around 50% of my commit credits are earned through quick bugs and support requests that usually take less than an hour. I also get to decide when an issue is resolved and a commit credit is earned. I agree with Dries that…
Not all code credits are the same. We currently don't have a way to account for the complexity and quality of contributions; one person might have worked several weeks for just one credit, while another person might receive a credit for ten minutes of work. In the future, we should consider issuing credit data in conjunction with issue priority, patch size, etc. This could help incentivize people to work on larger and more important problems and save coding standards improvements for new contributor sprints. Implementing a scoring system that ranks the complexity of an issue would also allow us to develop more accurate reports of contributed work.
It’s really hard to determine what is and is not commit credit worthy. Even though responding to a support request does not take long, the fact that I provide ongoing and immediate support contributes significantly to people’s success with using the Webform module and Drupal.
Showing a breakdown of how a commit credit is earned, whether it be from a core or contrib task, bug fix, support request, and documentation can help us understand how everyone's commit credits are earned. And there are layers of value in constantly evaluating, learning and discovering the time, effort, energy and attitude that goes into these things.
The Drupal Association has already done an amazing job of continually improving Drupal.org user profiles, which for me is as important as my resume. The Drupal Association has also improved the tools available for creating and maintaining documentation.
As the Webform module's features and user base grew, I realized that I needed to start thinking about documentation. I code better than I write but the Webform module's needs documentation. I set up the Webform module's documentation section and gradually revised different sections and pages. Before a stable release, the Webform Features page needs to be updated.
Producing help videos
I discovered the best medium for me to create documentation is screencasts. I found an amazing Creative Commons slides template and started creating and producing very simple screencasts. These screencasts are available within the Webform module and on Drupal.org. Putting a voice behind the Webform module has helped assure people that this is a supported project. Yes, these videos also help promote my 'personal brand.'
How am I able to make this level of contribution to Drupal?
The reported data shows that only 7% of the recorded contributions were made by contributors that do not identify as male, which continues to indicate a steep gender gap….The gender imbalance in Drupal is profound and underscores the need to continue fostering diversity and inclusion in our community.
I am incredibly fortunate to have ongoing work as a consultant for a client like Memorial Sloan Kettering. This relationship gives me the ability to contribute to Drupal in between paid work. I can also write-off a lot of Open Source related expenses as professional development.
I am fortunate to have the means to contribute to Drupal.
It is important to acknowledge that gender and race play a role in how much people earn and how much (free) time they have available to contribute to Open Source. Without embarking on a much larger discussion, it’s essential to realize the gender and race inequality is more directly addressed when organizations and businesses get involved in changing things.
If more tech companies work to improve their diversity while also allowing their employees to contribute to Open Source this could tip the scales where gender and race imbalance in our community reside.
What is going to be my next contribution to Drupal?
I am committed to maintaining the Webform Module for Drupal 8 for the foreseeable future and…
There needs to be a stable release of the Webform module.
In 2019, I would like to start exploring the next generation of Drupal Form API and Webform module. If I keep plugging away at the Webform module I can write a follow-up to this blog post in a year and maybe some of Drupal's top contributors can also share their story.