In this article, I use data from the Drupal Git commit history, as well as other sources, to demonstrate how dramatically the Drupal core “code committing” landscape has changed. My analysis below argues that the process of committing code to Drupal core is a far more complex process than some might assume of a project with a BDFL.
When I attended my first DrupalCon in San Francisco I brought three suits. At that point, I had been speaking at (academic) conferences for a decade, and in my experience conferences were places where attendees dressed formally and speakers literally read their papers (here's a real example from a 2005 Women's and Gender Studies Conference where I spoke). I arrived in San Francisco thinking I would spend some time exploring the city while I was there, but I ended up spending nearly all of my extra time in the ChX Coder Lounge learning everything I could about Drupal from kind people in the Drupal community.
Drupal has a great reputation as a CMS with excellent security standards and a 30+ member security team to back it up. For some Drupal sites, we must do more than just keep up-to-date with each and every security release. A Drupal site with private and confidential data brings with it some unique risks. Not only do you want to keep your site accessible to you and the site’s users, but you also cannot afford to have private data stolen. This article provides a checklist to ensure the sensitive data on your site is secure.
The Drupal community can bring people together, discourage hate, and promote democracy. I hope that we can find common ground, build on what we have accomplished, and organize against the forces that seek to divide us against ourselves.
Dries Buytaert and I examined commit data to help understand who develops Drupal, how much of that work is sponsored, and where that sponsorship comes from. We illustrate that the Drupal community is far ahead in understanding how to sustain and scale the project, and show that the Drupal project is a healthy project with a diverse community of contributors. Nevertheless, in Drupal's spirit of always striving to do better, we also highlight areas where the Drupal community can and should do better.
Recently the Drupal Association announced accepted sessions for DrupalCon New Orleans. While it looks like we can expect another great DrupalCon (this will be my 7th straight North American DrupalCon), one particular session on the program about the sale of Drupal modules caught my attention. Although I have tried to stay focused on preparing my own sessions, I have had conversations with other people in the Drupal community about “paid modules” that have led me to the conclusion that confusion about this topic persists. So here I would like to offer a perspective on why these kinds of plans consistently fail. Specifically, I hope to expand the scope of this frequently discussed issue and suggest why so many paid module initiatives fail: the Drupal community protects its free software with the same vigor that other communities protect artistic freedom.
Today we are proud to announce a new Drupal 8 module that provides support for the Accelerated Mobile Pages (AMP) Project. The AMP Project is a new open source initiative which drastically improves the performance of the mobile web. In January 2016 Lullabot and Google started working together to create the Drupal AMP module. A beta version of AMP module for Drupal 8 is available immediately, and we are starting work on a Drupal 7 version of the module that will be available in mid-March.
While the new configuration system in Drupal 8 strives to make the process of exporting and importing site configuration feel almost effortless, immensely complex logic facilitates this process. Over the past five years, the entire configuration system code was written and rewritten multiple times, and we think we got much of it right in its present form. As a result of this work, it is now possible to store configuration data in a consistent manner and to manage changes to configuration.
I believe that the Drupal community will be most successful not merely by convincing more people to work with us through technological manipulations, but instead by focusing on improving interactions within the community and a goal of cultivating social solidarity. Instead of using technology to grow the Drupal project, we should focus on adjusting our culture in order to improve our technology.
Drupal is always changing. The community constantly reinvents Drupal with new code and reimagines Drupal with new words. This article seeks to examine the current narratives about Drupal. By examining the stories we tell about Drupal — the so called cultural constructions — we can better understand what is going well and what should be making us uncomfortable.