Last week Megan Sanicki, executive director of the Drupal Association, and I published a joint statement. In this blog post, I wanted to follow up with a personal statement focused on the community at large.
I've talked to a lot of people the last two weeks, and it is clear to me that our decisions have caused much alarm and distress in our community. I feel this follow-up is important even though I know it doesn't undo the hurt I've caused.
I want to deeply apologize for causing grief and uncertainty, especially to those in the BDSM and kink communities who felt targeted by the turmoil. This incident was about specific actions of a single member of our community. This was never meant to be about sexual practices or kinks, so it pains me that I unintentionally hurt you. I do support you and respect you as a key part of our community.
Shortly after I started Drupal more than 15 years ago, I based its core values on openness and equality. Gender, race, religion, beliefs, sexuality ... all are welcome in our community. We've always had people with wildly different views and identities. When we walk into a sprint at DrupalCon, we've been able to put our opinions aside, open our laptops, and start collaborating. Diversity has always been a feature, not a bug. I strongly feel that this foundation is what made Drupal what it is today; a global family.
Serving a community as unique and diverse as Drupal is both rewarding and challenging. We've navigated through several defining moments and transitions in our history. I feel what we are going through now is another one of these defining moments for our culture and community. In an excruciating but illuminating way this has shown some of what is best about our community: we care. I'm reminded that what brings us together, what we all have in common, is our love and appreciation of open-source software. Drupal is a positive force, a collective lifting by thousands and thousands, created and maintained by those individuals cooperating toward a common goal, whose other interests have no need to be aligned.
I want to help our community heal and I'm open to learn and change. As one of the next steps, I will make a follow-up post on improving our governance to a healthier model that does not place such sensitive decisions on me. I love this community, and recognize that the things we hold in common are more important than our differences.
(Comments on this post are allowed but for obvious reasons will be moderated.)
The Drupal community is committed to welcome and accept all people. That includes a commitment to not discriminate against anyone based on their heritage or culture, their sexual orientation, their gender identity, and more. Being diverse has strength and as such we work hard to foster a culture of open-mindedness toward differences.
A few weeks ago, I privately asked Larry Garfield, a prominent Drupal contributor, to leave the Drupal project. I did this because it came to my attention that he holds views that are in opposition with the values of the Drupal project.
I had hoped to avoid discussing this decision publicly out of respect for Larry's private life, but now that Larry has written about it on his blog and it is being discussed publicly, I believe I have no choice but to respond on behalf of the Drupal project.
It's not for me to judge the choices anyone makes in their private life or what beliefs they subscribe to. I also don't take any offense to the role-playing activities or sexual preferences of Larry's alternative lifestyle.
What makes this difficult to discuss, is that it is not for me to share any of the confidential information that I've received, so I won't point out the omissions in Larry's blog post. However, I can tell you that those who have reviewed Larry's writing, including me, suffered from varying degrees of shock and concern.
In the end, I fundamentally believe that all people are created equally. This belief has shaped the values that the Drupal project has held since it's early days. I cannot in good faith support someone who actively promotes a philosophy that is contrary to this. The Gorean philosophy promoted by Larry is based on the principle that women are evolutionarily predisposed to serve men and that the natural order is for men to dominate and lead.
While the decision was unpleasant, the choice was clear. I remain steadfast in my obligation to protect the shared values of the Drupal project. This is unpleasant because I appreciate Larry's many contributions to Drupal, because this risks setting a complicated precedent, and because it involves a friend's personal life. The matter is further complicated by the fact that this information was shared by others in a manner I don't find acceptable either and will be dealt with separately.
However, when a highly-visible community member's private views become public, controversial, and disruptive for the project, I must consider the impact that his words and actions have on others and the project itself. In this case, Larry has entwined his private and professional online identities in such a way that it blurs the lines with the Drupal project. Ultimately, I can't get past the fundamental misalignment of values.
Collectively, we work hard to ensure that Drupal has a culture of diversity and inclusion. Our goal is not just to have a variety of different people within our community, but to foster an environment of connection, participation and respect. We have a lot of work to do on this and we can't afford to ignore discrepancies between the espoused views of those in leadership roles and the values of our culture. It's my opinion that any association with Larry's belief system is inconsistent with our project's goals.
It is my responsibility and obligation to act in the best interest of the project at large and to uphold our values. Decisions like this are unpleasant and disruptive, but important. It is moments like this that test our commitment to our values. We must stand up and act in ways that demonstrate these values. For these reasons, I'm asking Larry to resign from the Drupal project.
Update March 24th
After reading hundreds of responses, I wanted to make a clarifying statement. First, I made the decision to ask Larry not to participate in the Drupal project, and separately, the Drupal Association made a decision not to invite Larry to speak at DrupalCon Baltimore or serve as a track chair for it. I can only speak to my decision-making here. It's worth noting that I recused myself from the Drupal Association's decision.
Many have rightfully stated that I haven't made a clear case for the decision. When one side chooses to make their case public it creates an imbalance of information. Only knowing one side skews public opinion heavily towards the publicized viewpoint. While I will not share the evidence that I believe would validate the decision that I made for reasons of liability and confidentiality, I will say that I did not make the decision based on the information or beliefs conveyed in Larry's blog post.
Larry accurately pointed out that some of the evidence was brought forth in a manner that is not in alignment with Drupal values. This manner is being addressed with the CWG. While it's disheartening that some of our community members chose the approach they did to bring the matter regarding Larry forward, that does not change the underlying facts that informed my decision.
Update March 31st
Megan Sanicki, Drupal Association Executive Director, and myself posted a follow-up statement on Drupal.org. As with any such decisions, and especially due to the circumstances of this one, there has been controversy, misinformation and rumors, as well as healthy conversation and debate. Many people feel hurt, worried, and confused. The fact that this matter became very public and divisive greatly saddens all of us involved, especially as we can see the pain it has caused many. We want to strongly emphasize that Drupal is an open-minded and inclusive community, and we welcome people of all backgrounds. Our community's diversity is something to cherish and celebrate as well as protect. We apologize for any anxiety we caused you and reiterate that our decision was not based on anyone's sexual practices. It will take time to heal, but we want to make a start by providing insight into our decision-making, answering questions, and placing a call for improvements to our governance, conflict-resolution processes, and communication.
Update April 9th
I posted an apology for causing grief and uncertainty, especially to those in the BDSM and kink communities who felt targeted. This incident was about specific actions of a single member of our community. This was never about sexual practices or kinks.
Update April 10th
It is clear that the current governance structure of Drupal, which relies on me being the ultimate decision maker and spokesperson for difficult governance and community membership decisions, has reached its limits. It doesn't work for many in our community -- and frankly, it does not work for me either. Community membership decisions shouldn't be determined by me or by me alone. I announced a framework for how we can evolve our governance model.
Update April 16th
The Community Working Group published a more complete explanation for what happened to address some of the misinformation and speculation: "We strongly reject any suggestion or assertion that Larry was asked to leave solely on the basis of his personal beliefs or what he does in his private life. If any of us had any reason to believe that was the case, we would have resigned immediately from the CWG."
(Comments on this post are allowed but for obvious reasons will be moderated.)
The YMCA is a leading nonprofit dedicated to strengthening communities through youth development, healthy living and social responsibility. Today, the YMCA serves more than 58 million people in 130 countries around the world. The YMCA is a loose federation, meaning that each association operates independently to best meet the needs of the local community. In the United States alone, there are 874 associations, each with their own CEO and board of directors. As associations vary in both size and scale, each YMCA is responsible for maintaining their own digital systems and tools at their own expense.
In 2016, the YMCA of Greater Twin Cities set out to develop a Drupal distribution, called Open Y. The goal of Open Y was to build a platform to enable all YMCAs to operate as a unified brand through a common technology.
Open Y strives to provide the best customer experience for their members. The distribution, developed on top of Drupal 8 in partnership with Acquia and FFW, offers a robust collection of features to deliver a multi channel experience for websites, mobile applications, digital signage, and fitness screens.
On an Open Y website customers can schedule personal training appointments, look up monthly promotions, or donate to their local YMCA online. Open Y also takes advantage of Drupal 8's APIs to integrate all of their systems with Drupal. This includes integration with Open Y's Customer Relationship Management (CRM) and eCommerce partners, but also extends to fitness screens and wearables like Fitbit. This means that Open Y can use Drupal as a data repository to serve content, such as alerts or program campaigns, to digital signage screens, connected fitness consoles and popular fitness tracking applications. Open Y puts Drupal at the core of their digital platform to provide members with seamless and personalized experiences.
The founding principle of Open Y is that the platform adopts a philosophy of collaboration that drives innovation and impact. Participants of Open Y have developed a charter that dictates expectations of collaboration and accountability. The tenets of the charter allow for individual associations to manage their own projects and to adopt the platform at their own pace. However, once an association adopts Open Y, they are expected to contribute back any new features to the Open Y distribution.
As a nonprofit, YMCAs cannot afford expensive proprietary licenses. Because participating YMCAs collaborate on the development of Open Y, and because there are no licensing fees associated with Drupal, the total cost of ownership is much lower than proprietary solutions. The time and resources that are saved by adopting Drupal allows YMCAs around the country to better focus on their customers' experience and lean into innovation. The same could not be achieved with proprietary software.
For example, the YMCA of Greater Seattle was the second association to adopt the Open Y platform. When building its website, the YMCA of Greater Seattle was able to repurpose over a dozen modules from the YMCA of the Greater Twin Cities. That helped Seattle save time and money in their development. Seattle then used their savings to build a new data personalization module to contribute back to the Open Y community. The YMCA of the Greater Twin Cities will be able to benefit from Seattle's work and adopt the personalization features into its own website. By contributing back and by working together on the Open Y distribution, these YMCAs are engaging in a virtuous cycle that benefits their own projects.
In less than one year, 18 YMCA associations have committed to adopting Open Y and over 22 other associations are currently evaluating the platform. Open Y has created a platform that all stakeholders under the YMCA brand can use to collaborate through a common technology and a shared philosophy.
Open Y is yet another example of how organizations can challenge the prevailing model of digital experience delivery. By establishing a community philosophy that encourages contribution, Open Y has realized accelerated growth, feature development, and adoption. Organizations that are sharing contributions and embracing collaboration are evolving their operating models to achieve more than ever before.
Because I am passionate about the Open Y team's mission and impact, I have committed to be an advisor and sponsor to the project. I've been advising them since November 2016. Working with Open Y is a way for me to give back, and it's been very exciting to witness their progress first hand.
If you want to help contribute to the Open Y project, consider attending their DrupalCon Baltimore session on building custom Drupal distributions for federated organizations. You can also connect with the Open Y team directly at OpenYMCA.org.
One of the key reasons that Drupal has been successful is because we always made big, forward-looking changes. As a result, Drupal is one of very few CMSes that has stayed relevant for 15+ years. The downside is that with every major release of Drupal, we've gone through a lot of pain adjusting to these changes. The learning curve and difficult upgrade path from one major version of Drupal to the next (e.g. from Drupal 7 to Drupal 8) has also held back Drupal's momentum. In an ideal world, we'd be able to innovate fast yet provide a smooth learning curve and upgrade path from Drupal 8 to Drupal 9. We believe we've found a way to do both!
Before we can talk about the upgrade path to Drupal 9, it's important to understand how we do releases in Drupal 8. With the release of Drupal 8, we moved Drupal core to use a continuous innovation model. Rather than having to wait for years to get new features, users now get sizable advances in functionality every six months. Furthermore, we committed to providing a smooth upgrade for modules, themes, and distributions from one six-month release to the next.
This new approach is starting to work really well. With the 8.1 and 8.2 updates behind us and 8.3 close to release, we have added some stable improvements like BigPipe and a new status report page, as well as experimental improvements for outside-in, workflows, layouts, and more. We also plan to add important media improvements in 8.4.
Most importantly, upgrading from 8.2 to 8.3 for these new features is not much more complicated than simply updating for a bugfix or security release.
After a lot of discussion among the Drupal core committers and developers, and studying projects like Symfony, we believe that the advantages of Drupal's minor upgrade model (e.g. from Drupal 8.2 to Drupal 8.3) can be translated to major upgrades (e.g. from Drupal 8 to Drupal 9). We see a way to keep innovating while providing a smooth upgrade path and learning curve from Drupal 8 to Drupal 9.
Here is how we will accomplish this: we will continue to introduce new features and backwards-compatible changes in Drupal 8 releases. In the process, we sometimes have to deprecate old systems. Instead of removing old systems, we will keep them in place and encourage module maintainers to update to the new systems. This means that modules and custom code will continue to work. The more we innovate, the more deprecated code there will be in Drupal 8. Over time, maintaining backwards compatibility will become increasingly complex. Eventually, we will reach a point where we simply have too much deprecated code in Drupal 8. At that point, we will choose to remove the deprecated systems and release that as Drupal 9.
This means that Drupal 9.0 should be almost identical to the last Drupal 8 release, minus the deprecated code. It means that when modules take advantage of the latest Drupal 8 APIs and avoid using deprecated code, they should work on Drupal 9. Updating from Drupal 8's latest version to Drupal 9.0.0 should be as easy as updating between minor versions of Drupal 8. It also means that Drupal 9 gives us a clean slate to start innovating more rapidly again.
Why would you upgrade to Drupal 9 then? For the great new features in 9.1. No more features will be added to Drupal 8 after Drupal 9.0. Instead, they will go into Drupal 9.1, 9.2, and so on.
To get the most out of this new approach, we need to make two more improvements. We need to change core so that the exact same module can work with Drupal 8 and 9 if the module developer uses the latest APIs. We also need to provide full data migration from Drupal 6, 7 and 8 to any future release. So long as we make these changes before Drupal 9 and contributed or custom modules take advantage of the latest Drupal 8 APIs, up-to-date sites and modules may just begin using 9.0.0 the day it is is released.
If you are one of the more than a million sites successfully running on Drupal 7, you might only have one more big upgrade ahead of you.
If you are planning to migrate directly from Drupal 7 to Drupal 9, you should reconsider that approach. In this new model, it might be more beneficial to upgrade to Drupal 8. Once you’ve migrated your site to Drupal 8, subsequent upgrades will be much simpler.
We have more work to do to complete the Drupal 7 to Drupal 8 data migration, but the first Drupal 8 minor release that fully supports it could be 8.4.0, scheduled to be released in October 2017.
If you are a module or theme developer, you can continually update to the latest APIs each minor release. Avoid using deprecated code and your module will be compatible with Drupal 9 the day Drupal 9 is released. We have plans to make it easy for developers to identify and update deprecated code.
If you are a Drupal core contributor and want to introduce new improvements in Drupal core, Drupal 8 is the place to do it! With backwards compatibility layers, even pretty big changes are possible in Drupal 8.
We don't know yet, but it shouldn't matter as much either. Innovative Drupal 8 releases will go out on schedule every six months and upgrading to Drupal 9 should become easy. I don't believe we will release Drupal 9 any time soon; we have plenty of features in the works for Drupal 8. Once we know more, we'll follow up with more details.
Yesterday, after publishing a blog post about Nasdaq's Drupal 8 distribution for investor relations websites, I realized I don't talk enough about "Drupal distributions" on my blog. The ability for anyone to take Drupal and build their own distribution is not only a powerful model, but something that is relatively unique to Drupal. To the best of my knowledge, Drupal is still the only content management system that actively encourages its community to build and share distributions.
A Drupal distribution packages a set of contributed and custom modules together with Drupal core to optimize Drupal for a specific use case or industry. For example, Open Social is a free Drupal distribution for creating private social networks. Open Social was developed by GoalGorilla, a digital agency from the Netherlands. The United Nations is currently migrating many of their own social platforms to Open Social.
Another example is Lightning, a distribution developed and maintained by Acquia. While Open Social targets a specific use case, Lightning provides a framework or starting point for any Drupal 8 project that requires more advanced layout, media, workflow and preview capabilities.
For more than 10 years, I've believed that Drupal distributions are one of Drupal's biggest opportunities. As I wrote back in 2006:
Distributions allow us to create ready-made downloadable packages with their own focus and vision. This will enable Drupal to reach out to both new and different markets..
To capture this opportunity we needed to (1) make distributions less costly to build and maintain and (2) make distributions more commercially interesting.
Over the last 12 years we have evolved the underlying technology of Drupal distributions, making them even easier to build and maintain. We began working on distribution capabilities in 2004, when the CivicSpace Drupal 4.6 distribution was created to support Howard Dean's presidential campaign. Since then, every major Drupal release has advanced Drupal's distribution building capabilities.
The release of Drupal 5 marked a big milestone for distributions as we introduced a web-based installer and support for "installation profiles", which was the foundational technology used to create Drupal distributions. We continued to make improvements to installation profiles during the Drupal 6 release. It was these improvements that resulted in an explosion of great Drupal distributions such as OpenAtrium (an intranet distribution), OpenPublish (a distribution for online publishers), Ubercart (a commerce distribution) and Pressflow (a distribution with performance and scalability improvements).
Around the release of Drupal 7, we added distribution support to Drupal.org. This made it possible to build, host and collaborate on distributions directly on Drupal.org. Drupal 7 inspired another wave of great distributions: Commerce Kickstart (a commerce distribution), Panopoly (a generic site building distribution), Opigno LMS (a distribution for learning management services), and more! Today, Drupal.org lists over 1,000 distributions.
Most recently we've made another giant leap forward with Drupal 8. There are at least 3 important changes in Drupal 8 that make building and maintaining distributions much easier:
Open Restaurant is a great example of a Drupal 8 distribution that has taken advantage of these new improvements. The Open Restaurant distribution has everything you need to build a restaurant website and uses Composer when installing the distribution.
More improvements are already in the works for future versions of Drupal. One particularly exciting development is the concept of "inheriting" distributions, which allows Drupal distributions to build upon each other. For example, Acquia Lightning could "inherit" the standard core profile – adding layout, media and workflow capabilities to Drupal core, and Open Social could inherit Lightning - adding social capabilities on top of Lightning. In this model, Open Social delegates the work of maintaining Layout, Media, and Workflow to the maintainers of Lightning. It's not too hard to see how this could radically simplify the maintenance of distributions.
The less effort it takes to build and maintain a distribution, the more distributions will emerge. The more distributions that emerge, the better Drupal can compete with a wide range of turnkey solutions in addition to new markets. Over the course of twelve years we have improved the underlying technology for building distributions, and we will continue to do so for years to come.
In 2010, after having built a couple of distributions at Acquia, I used to joke that distributions are the "most expensive lead generation tool for professional services work". This is because monetizing a distribution is hard. Fortunately, we have made progress on making distributions more commercially viable.
At Acquia, our Drupal Gardens product taught us a lot about how to monetize a single Drupal distribution through a SaaS model. We discontinued Drupal Gardens but turned what we learned from operating Drupal Gardens into Acquia Cloud Site Factory. Instead of hosting a single Drupal distribution (i.e. Drupal Gardens), we can now host any number of Drupal distributions on Acquia Cloud Site Factory.
This is why Nasdaq's offering is so interesting; it offers a powerful example of how organizations can leverage the distribution "as-a-service" model. Nasdaq has built a custom Drupal 8 distribution and offers it as-a-service to their customers. When Nasdaq makes money from their Drupal distribution they can continue to invest in both their distribution and Drupal for many years to come.
In other words, distributions have evolved from an expensive lead generation tool to something you can offer as a service at a large scale. Since 2006 we have known that hosted service models are more compelling but unfortunately at the time the technology wasn't there. Today, we have the tools that make it easier to deploy and manage large constellations of websites. This also includes providing a 24x7 help desk, SLA-based support, hosting, upgrades, theming services and go-to-market strategies. All of these improvements are making distributions more commercially viable.
Updates from Dries straight to your mailbox