We ditched the crowded streets of Seattle for a short vacation in Tuscany's beautiful countryside. After the cold winter months, Tuscany's rolling hills are coming back to life and showing their new colors.
Last week, many Drupalists gathered in Seattle for DrupalCon North America, for what was the largest DrupalCon in history.
Making Drupal more diverse and inclusive
DrupalCon Seattle was not only the largest, but also had the most diverse speakers. Nearly 50% of the DrupalCon speakers were from underrepresented groups. This number has been growing year over year, and is something to be proud of.
I actually started my keynote by talking about how we can make Drupal more diverse and inclusive. As one of the largest and most thriving Open Source communities, I believe that Drupal has an obligation to set a positive example.
I talked about how Open Source communities often incorrectly believe that everyone can contribute. Unfortunately, not everyone has equal amounts of free time to contribute. In my keynote, I encouraged individuals and organizations in the Drupal community to strongly consider giving time to underrepresented groups.
Improving diversity is not only good for Drupal and its ecosystem, it's good for people, and it's the right thing to do. Because this topic is so important, I wrote a dedicated blog post about it.
Drupal 8 innovation update
I dedicated a significant portion of my keynote to Drupal 8. In the past year alone, there have been 35% more sites and 48% more stable modules in Drupal 8. Our pace of innovation is increasing, and we've seen important progress in several key areas.
With the release of Drupal 8.7, the Layout Builder will become stable. Drupal's new Layout Builder makes it much easier to build and change one-off page layouts, templated layouts and layout workflows. Best of all, the Layout Builder will be accessible.
Drupal 8.7 also brings a lot of improvements to the Media Library.
We also continue to innovate on headless or decoupled Drupal. The JSON:API module will ship with Drupal 8.7. I believe this not only advances Drupal's leadership in API-first, but sets Drupal up for long-term success.
These are just a few of the new capabilities that will ship with Drupal 8.7. For the complete list of new features, keep an eye out for the release announcement in a few weeks.
Drupal 7 end of life
If you're still on Drupal 7, there is no need to panic. The Drupal community will support Drupal 7 until November 2021 — two years and 10 months from today.
After the community support ends, there will be extended commercial support for a minimum of three additional years. This means that Drupal 7 will be supported for at least five more years, or until 2024.
Upgrading from Drupal 7 to Drupal 8
Upgrading from Drupal 7 to Drupal 8 can be a lot of work, especially for large sites, but the benefits outweigh the challenges.
Preparing for Drupal 9
As announced a few months ago, Drupal 9 is targeted for June 2020. June 2020 is only 14 months away, so I dedicated a significant amount of my keynote to Drupal 9.
Making Drupal updates easier is a huge, ongoing priority for the community. Thanks to those efforts, the upgrade path to Drupal 9 will be radically easier than the upgrade path to Drupal 8.
In my keynote, I talked about how site owners, Drupal developers and Drupal module maintainers can start preparing for Drupal 9 today. I showed several tools that make Drupal 9 preparation easier. Check out my post on how to prepare for Drupal 9 for details.
I'm grateful to be a part of a community that takes such pride in its work. At each DrupalCon, we get to see the tireless efforts of many volunteers that add up to one amazing event. It makes me proud to showcase the work of so many people and organizations in my presentations.
Thank you to all who have made this year's DrupalCon North America memorable. I look forward to celebrating our work and friendships at future events!
With Drupal 9 targeted to be released in June of 2020, many people are wondering what they need to do to prepare.
The good and important news is that upgrading from Drupal 8 to Drupal 9 should be really easy — radically easier than upgrading from Drupal 7 to Drupal 8.
The only caveat is that you need to manage "deprecated code" well.
If your site doesn't use deprecated code that is scheduled for removal in Drupal 9, your upgrade to Drupal 9 will be easy. In fact, it should be as easy as a minor version upgrade (like upgrading from Drupal 8.6 to Drupal 8.7).
What is deprecated code?
Code in Drupal is marked as "deprecated" when it should no longer be used. Typically, code is deprecated because there is a better alternative that should be used instead.
For example, in Drupal 8.0.0, we deprecated
\Drupal::l($text, $url). Instead of using
\Drupal::l(), you should use
Link::fromTextAndUrl($text, $url). The
\Drupal::l() function was marked for removal as part of some clean-up work; Drupal 8 had too many ways to generate links.
Deprecated code will continue to work for some time before it gets removed. For example,
\Drupal::l() continues to work in Drupal 8.7 despite the fact that it was deprecated in Drupal 8.0.0 more than three years ago. This gives module maintainers ample time to update their code.
When we release Drupal 9, we will "drop" most deprecated code. In our example, this means that
\Drupal::l() will not be available anymore in Drupal 9.
In other words:
- Any Drupal 8 module that does not use deprecated code will continue to work with Drupal 9.
- Any Drupal 8 module that uses deprecated code needs to be updated before Drupal 9 is released, or it will stop working with Drupal 9.
If you're interested, you can read more about Drupal's deprecation policy at https://www.drupal.org/core/deprecation.
How do I know if my site uses deprecated code?
There are a few ways to check if your site is using deprecated code.
If you work on a Drupal site as a developer, run
drupal-check. Matt Glaman (Centarro) developed a static PHP analysis tool called
drupal-check, which you can run against your codebase to check for deprecated code. I recommend running
drupal-check in an automated fashion as part of your development workflow.
If you are a site owner, install the Upgrade Status module. This module was built by Acquia. The module provides a graphical user interface on top of
drupal-check. The goal is to provide an easy-to-use readiness assessment for your site's migration to Drupal 9.
If you maintain a project on Drupal.org, enable Drupal.org's testing infrastructure to detect the use of deprecated code. There are two complementary ways to do so: you can run a static deprecation analysis and/or configure your existing tests to fail when calling deprecated code. Both can be set up in your
drupalci.yml configuration file.
If you find deprecated code in a contributed module used on your site, consider filing an issue in the module's issue queue on Drupal.org (after having checked no issue has been created yet). If you can, provide a patch to fix the deprecation and engage with the maintainer to get it committed.
How hard is it to update my code?
While there are some deprecations that require more detailed refactoring, many are a simple matter of search-and-replace.
You can check the API documentation for instructions on how to remedy the deprecation.
When can I start updating my code?
I encourage you to start today. When you update your Drupal 8 code to use the latest and greatest APIs, you can benefit from those improvements immediately. There is no reason to wait until Drupal 9 is released.
Drupal 8.8.0 will be the last release to deprecate for Drupal 9. Today, we don't know the full set of deprecations yet.
How much time do I have to update my code?
Contributed module maintainers are encouraged to remove the use of deprecated code by June of 2020 so everyone can upgrade to Drupal 9 the day it is released.
Drupal.org project maintainers should keep the extended security coverage policy in mind, which means that Drupal 8.8 will still be supported until Drupal 9.1 is released. Contributed projects looking to support both Drupal 8.8 and Drupal 9.0 might need to use two branches.
How ready are the contributed modules?
As it stands today, 44% of the modules have no deprecation warnings. The remaining 56% of the modules need to be updated, but the majority have less than three deprecation warnings.
In Open Source, there is a long-held belief in meritocracy, or the idea that the best work rises to the top, regardless of who contributes it. The problem is that a meritocracy assumes an equal distribution of time for everyone in a community.
Open Source is not a meritocracy
I incorrectly made this assumption myself, saying:
The only real limitation [to Open Source contribution] is your willingness to learn.
Today, I've come to understand that inequality makes it difficult for underrepresented groups to have the "free time" it takes to contribute to Open Source.
For example, research shows that women still spend more than double the time as men doing unpaid domestic work, such as housework or childcare. I've heard from some of my colleagues that they need to optimize every minute of time they don't spend working, which makes it more difficult to contribute to Open Source on an unpaid, volunteer basis.
Or, in other cases, many people's economic conditions require them to work more hours or several jobs in order to support themselves or their families.
Systemic issues like racial and gender wage gaps continue to plague underrepresented groups, and it's both unfair and impractical to assume that these groups of people have the same amount of free time to contribute to Open Source projects, if they have any at all.
What this means is that Open Source is not a meritocracy.
Free time is a mark of privilege, rather than an equal right. Instead of chasing an unrealistic concept of meritocracy, we should be striving for equity. Rather than thinking, "everyone can contribute to open source", we should be thinking, "everyone deserves the opportunity to contribute".
Time inequality contributes to a lack of diversity in Open Source
This fallacy of "free time" makes Open Source communities suffer from a lack of diversity. The demographics are even worse than the technology industry overall: while 22.6% of professional computer programmers in the workforce identify as women (Bureau of Labor Statistics), less than 5% of contributors do in Open Source (GitHub). And while 34% of programmers identify as ethnic or national minorities (Bureau of Labor Statistics), only 16% do in Open Source (GitHub).
It's important to note that time isn't the only factor; sometimes a hostile culture or unconscious bias play a part in limiting diversity. According to the same GitHub survey cited above, 21% of people who experienced negative behavior stopped contributing to Open Source projects altogether. Other recent research showed that women's pull requests were more likely to get accepted if they had a gender-neutral username. Unfortunately, examples like these are common.
Taking action: giving time to underrepresented groups
While it's impossible to fix decades of gender and racial inequality with any single action, we must do better. Those in a position to help have an obligation to improve the lives of others. We should not only invite underrepresented groups into our Open Source communities, but make sure that they are welcomed, supported and empowered. One way to help is with time:
- As individuals, by making sure you are intentionally welcoming people from underrepresented groups, through both outreach and actions. If you're in a community organizing position, encourage and make space for people from underrepresented groups to give talks or lead sprints about the work they're interested in. Or if you're asked to, mentor an underrepresented contributor.
- As organizations in the Open Source ecosystem, by giving people more paid time to contribute.
Taking the extra effort to help onboard new members or provide added detail when reviewing code changes can be invaluable to community members who don't have an abundance of free time. Overall, being kinder, more patient and more supportive to others could go a long way in welcoming more people to Open Source.
In addition, organizations within the Open Source ecosystem capable of giving back should consider financially sponsoring underrepresented groups to contribute to Open Source. Sponsorship can look like full or part-time employment, an internship or giving to organizations like Girls Who Code, Code2040, Resilient Coders or one of the many others that support diversity in technology. Even a few hours of paid time during the workweek for underrepresented employees could help them contribute more to Open Source.
Applying the lessons to Drupal
Over the years, I've learned a lot from different people's perspectives. Learning out in the open is not always easy, but it's been an important part of my personal journey.
Knowing that Drupal is one of the largest and most influential Open Source projects, I find it important that we lead by example.
I encourage individuals and organizations in the Drupal community to strongly consider giving time and opportunities to underrepresented groups. You can start in places like:
- Drupal Core Mentoring to inspire, enable and encourage new contributors to get involved.
- The Drupal Diversity and Inclusion Contribution Team.
- The Drupal Apprentice Initiative by TalentPath, which helps organizations build a diverse talent pipeline through apprenticeships.
When we have more diverse people contributing to Drupal, it will not only inject a spark of energy, but it will also help us make better, more accessible, inclusive software for everyone in the world.
Each of us needs to decide if and how we can help to create equity for everyone in Drupal. Not only is it good for business, it's good for people, and it's the right thing to do.
Special thanks to the Drupal Diversity and Inclusion group for discussing this topic with me. Ashe Dryden's thought-leadership indirectly influenced this piece. If you are interested in this topic, I recommend you check out Ashe's blog post The Ethics of Unpaid Labor and the OSS Community.
For most people, today marks the first day of DrupalCon Seattle.
Open Source communities create better, more inclusive software when diverse people come to the table. Unfortunately, there is still a huge gender gap in Open Source, and software more broadly. It's something I'll talk more about in my keynote tomorrow.
One way to help close the gender gap in the technology sector is to give to organizations that are actively working to solve this problem. During DrupalCon Seattle, Acquia will donate $5 to Girls Who Code for every person that visits our booth.
I don't use Google Analytics or any other web analytics service on dri.es. Why not? Because I don't desire to know how many people visit my site, where they come from, or what operating system they use.
Because I don't have a compelling reason to track my site's visitors, I don't have to bother anyone with a "cookies consent" popup either. That is a nice bonus because the web is littered with those already. I like that dri.es is clutter-free.
This was all well and good until a couple of weeks ago, when I learned that when I embed a YouTube video in my blog posts, Google sends an HTTP cookie to track my site's visitors. Be damned!
After some research, I discovered that YouTube offers a privacy-enhanced way of embedding videos. Instead of linking to
youtube.com, link to
youtube-nocookie.com, and no data-collecting HTTP cookie will be sent. This is Google's way of providing GDPR-compliant YouTube videos.
<iframe width="640" height="360" src="https://www.youtube-nocookie.com/embed/video-id" frameborder="0"></iframe>
So I went ahead and updated all blog posts on dri.es to use
Breaking news: we just committed the JSON:API module to the development branch of Drupal 8.
In other words, JSON:API support is coming to all Drupal 8 sites in just a few short months! 🎉
This marks another important milestone in Drupal's evolution to be an API-first platform optimized for building both coupled and decoupled applications.
When you enable the JSON:API module, all Drupal entities such as blog posts, users, tags, comments and more become accessible via the JSON:API web service API. JSON:API provides a standardized API for reading and modifying resources (entities), interacting with relationships between resources (entity references), fetching of only the selected fields (e.g. only the "title" and "author" fields), including related resources to avoid additional requests (e.g. details about the content's author) and filtering, sorting and paginating collections of resources.
In addition to being incredibly powerful, JSON:API is easy to learn and use and uses all the tooling we already have available to test, debug and scale Drupal sites.
Drupal's JSON:API implementation was years in the making
Development of the JSON:API module started in May 2016 and reached a stable 1.0 release in May 2017. Most of the work was driven by a single developer partially in his free time: Mateu Aguiló Bosch (e0ipso).
After soliciting input and consulting others, I felt JSON:API belonged in Drupal core. I first floated this idea in July 2016, became more convinced in December 2016 and recommended that we standardize on it in October 2017.
Wim and Gabe quickly became key contributors alongside Mateu. They wrote hundreds of tests and added missing features to make sure we guarantee strict compliance with the JSON:API specification.
A year later, their work culminated in a JSON:API 2.0 stable release on January 7th, 2019. The 2.0 release marked the start of the module's move to Drupal core. After rigorous reviews and more improvements, the module was finally committed to core earlier today.
The best JSON:API implementation in existence
The JSON:API module for Drupal is almost certainly the most feature-complete and easiest-to-use JSON:API implementation in existence.
The Drupal JSON:API implementation supports every feature of the JSON:API 1.0 specification out-of-the-box. Every Drupal entity (a resource object in JSON:API terminology) is automatically made available through JSON:API. Existing access controls for both reading and writing are respected. Both translations and revisions of entities are also made available. Furthermore, querying entities (filtering resource collections in JSON:API terminology) is possible without any configuration (e.g. setting up a "Drupal View"), which means front-end developers can get started on their work right away.
What is particularly rewarding is that all of this was made possible thanks to Drupal's data model and introspection capabilities. Drupal’s decade-old Entity API, Field API, Access APIs and more recent Configuration and Typed Data APIs exist as an incredibly robust foundation for making Drupal’s data available via web service APIs. This is not to be understated, as it makes the JSON:API implementation robust, deeply integrated and elegant.
I want to extend a special thank you to the many contributors that contributed to the JSON:API module and that helped make it possible for JSON:API to be added to Drupal 8.7.
Special thanks to Wim Leers (Acquia) and Gabe Sullice (Acquia) for co-authoring this blog post and to Mateu Aguiló Bosch (e0ipso) (Lullabot), Preston So (Acquia), Alex Bronstein (Acquia) for their feedback during the writing process.
Today, the world wide web celebrates its 30th birthday. In 1989, Sir Tim Berners-Lee invented the world wide web and changed the lives of millions of people around the globe, including mine.
Milestones like this get me thinking about the positive impact a free and Open Web has had on society. Without the web, billions of people would not have been able to connect with one another, be entertained, start businesses, exchange ideas, or even save lives. Open source communities like Drupal would not exist.
As optimistic as I am about the web's impact on society, there have been many recent events that have caused me to question the Open Web's future. Too much power has fallen into the hands of relatively few platform companies, resulting in widespread misinformation, privacy beaches, bullying, and more.
However, I'm optimistic that the Open Web has a chance to win in the future. I believe we'll see three important events happen in the next five years.
First, the day will come when regulators will implement a set of laws that govern the ownership and exchange of data online. It's already starting to happen with GDPR in the EU and various state data privacy laws taking shape in the US. These regulations will require platforms like Facebook to give users more control over their data, and when that finally happens, it will be a lot easier for users to move their data between services and for the Open Web to innovate on top of these data platforms.
Second, at some point, governments globally will disempower large platform companies. We can't leave it up to a handful of companies to judge what is false and true, or have them act as our censors. While I'm not recommending governments split up these companies, my hope is that they will institute some level of algorithmic oversight. This will offer an advantage to the Open Web and Open Source.
Third, I think we're on the verge of having a new set of building blocks that enable us to build a better, next-generation web. Thirty years into the web, our data architectures still use a client-server model; data is stored centrally on one computer, so to speak. The blockchain is turning that into a more decentralized web that operates on top of a distributed data layer and offers users control of their own data. Similar to building a traditional website, distributed applications (dApps) require file storage, payment systems, user data stores, etc. All of these components are being rebuilt on top of the blockchain. While we have a long way to go, it is only a matter of time before a tipping point is reached.
In the past, I've publicly asked the question: Can we save the Open Web? I believe we can. We can't win today, but we can keep innovating and get ready for these three events to unfold. The day will come!
With that motivation in mind, I want to wish a special happy birthday to the world wide web!
Product marketing teams are responsible for bringing products to market and championing their success and adoption. To make this happen, they work closely with three sets of key stakeholders: the product team (development/engineering), the marketing team and the sales team.
In some organizations, product marketing reports to marketing. In other organizations, it reports to product. The most common pattern is for product marketing teams to live in marketing, but in my opinion, a product marketing organization should sit where the highest frequency of communication and collaboration is needed. That can depend on the type of product, but also on the maturity of the product.
For new products, companies with an evolving product strategy, or very technical products, it makes the most sense for product marketing to report directly to the product team. For mature and steady products, it makes sense for product marketing to report into marketing.
This reporting structure matters in that it facilitates communication and alignment.
For example, Acquia has recently decided to restructure product marketing to report to the product team (the team I'm responsible for), rather than to marketing. We made this decision because there has been a lot of change and growth on the product front.
We've also added to our product leadership team, hiring an SVP of Product Marketing, Tom Wentworth. Those of you who have followed Acquia's story may know Tom as our former CMO and head of product marketing. You can read more about it in Tom's blog post — he explains why he rejoined Acquia, but also writes about content management history and trends. Well worth a read!