Dries Buytaert

Subscribe to Dries Buytaert feed
Updated: 19 hours 2 min ago

Our quest to see the Northern Lights

18 June 2017 - 8:22am

In February we spent a weekend in the Arctic Circle hoping to see the northern lights. I've been so busy, I only now got around to writing about it.

We decided to travel to Nellim for an action-packed weekend with outdoor adventure, wood fires, reindeer and no WiFi. Nellim, is a small Finnish village, close to the Russian border and in the middle of nowhere. This place is a true winter wonderland with untouched and natural forests. On our way to the property we saw a wild reindeer eating on the side of the road. It was all very magical.

The trip was my gift to Vanessa for her 40th birthday! I reserved a private, small log cabin instead of the main lodge. The log cabin itself was really nice; even the bed was made of logs with two bear heads were carved into it. Vanessa called them Charcoal and Smokey. To stay warm we made fires and enjoyed our sauna.

One day we went dog sledding. As with all animals it seems, Vanessa quickly named them all; Marshmallow, Brownie, Snickers, Midnight, Blondie and Foxy. The dogs were so excited to run! After 3 hours of dog sledding in -30 C (-22 F) weather we stopped to warm up and eat; we made salmon soup in a small make-shift shelter that was similar to a tepee. The tepee had a small opening at the top and there was no heat or electricity.

The salmon soup was made over a fire, and we were skeptical at first how this would taste. The soup turned out to be delicious and even reminded us of the clam chowder that we have come to enjoy in Boston. We've since remade this soup at home and the boys also enjoy it. Not that this blog will turn into a recipe blog, but I plan to publish the recipe with photos at some point.

At night we would go out on "aurora hunts". The first night by reindeer sled, the second night using snowshoes, and the third night by snowmobile. To stay warm, we built fires either in tepees or in the snow and drank warm berry juice.

While the untouched land is beautiful, they definitely try to live off the land. The Fins have an abundance of berries, mushrooms, reindeer and fish. We gladly admit we enjoyed our reindeer sled rides, as well as eating reindeer. We had fresh mushroom soup made out of hand-picked mushrooms. And every evening there was an abundance of fresh fish and reindeer offered for dinner. We also discovered a new gin, Napue, made from cranberries and birch leaves.

In the end, we didn't see the Northern Lights. We had a great trip, and seeing them would have been the icing on the cake. It just means that we'll have to come back another time.

Categories: Drupal

From imagination to (augmented) reality in 48 hours

1 June 2017 - 12:31am

Every spring, members of Acquia's Product, Engineering and DevOps teams gather at our Boston headquarters for "Build Week". Build Week gives our global team the opportunity to meet face-to-face, to discuss our product strategy and roadmap, to make plans, and to collaborate on projects.

One of the highlights of Build Week is our annual Hackathon; more than 20 teams of 4-8 people are given 48 hours to develop any project of their choosing. There are no restrictions on the technology or solutions that a team can utilize. Projects ranged from an Amazon Dash Button that spins up a new Acquia Cloud environment with one click, to a Drupal module that allows users to visually build page layouts, or a proposed security solution that would automate pen testing against Drupal sites.

This year's projects were judged on innovation, ship-ability, technical accomplishment and flair. The winning project, Lift HoloDeck, was particularly exciting because it showcases an ambitious digital experience that is possible with Acquia and Drupal today. The Lift Holodeck takes a physical experience and amplifies it with a digital one using augmented reality. The team built a mobile application that superimposes product information and smart notifications over real-life objects that are detected on a user's smartphone screen. It enables customers to interact with brands in new ways that improve a customer's experience.

At the hackathon, the Lift HoloDeck Team showed how augmented reality can change how both online and physical storefronts interact with their consumers. In their presentation, they followed a customer, Neil, as he used the mobile application to inform his purchases in a coffee shop and clothing store. When Neil entered his favorite coffee shop, he held up his phone to the posted “deal of the day”. The Lift HoloDeck application superimposes nutrition facts, directions on how to order, and product information on top of the beverage. Neil contemplated the nutrition facts before ordering his preferred drink through the Lift HoloDeck application. Shortly after, he received a notification that his order was ready for pick up. Because Acquia Lift is able to track Neil's click and purchase behavior, it is also possible for Acquia Lift to push personalized product information and offerings through the Lift HoloDeck application.

Check out the demo video, which showcases the Lift HoloDeck prototype:

The Lift HoloDeck prototype is exciting because it was built in less than 48 hours and uses technology that is commercially available today. The Lift HoloDeck experience was powered by Unity (a 3D game engine), Vuforia (an augmented reality library), Acquia Lift (a personalization engine) and Drupal as a content store.

The Lift HoloDeck prototype is a great example of how an organization can use Acquia and Drupal to support new user experiences and distribution platforms that engage customers in captivating ways. It's incredible to see our talented teams at Acquia develop such an innovative project in under 48 hours; especially one that could help reshape how customers interact with their favorite brands.

Congratulations to the entire Lift HoloDeck team; Ted Ottey, Robert Burden, Chris Nagy, Emily Feng, Neil O'Donnell, Stephen Smith, Roderik Muit, Rob Marchetti and Yuan Xie.

Categories: Drupal

Acquia's next phase

23 May 2017 - 9:08am

In 2007, Jay Batson and I wanted to build a software company based on open source and Drupal. I was 29 years old then, and eager to learn how to build a business that could change the world of software, strengthen the Drupal project and help drive the future of the web.

Tom Erickson joined Acquia's board of directors with an outstanding record of scaling and leading technology companies. About a year later, after a lot of convincing, Tom agreed to become our CEO. At the time, Acquia was 30 people strong and we were working out of a small office in Andover, Massachusetts. Nine years later, we can count 16 of the Fortune 100 among our customers, saw our staff grow from 30 to more than 750 employees, have more than $150MM in annual revenue, and have 14 offices across 7 countries. And, importantly, Acquia has also made an undeniable impact on Drupal, as we said we would.

I've been lucky to have had Tom as my business partner and I'm incredibly proud of what we have built together. He has been my friend, my business partner, and my professor. I learned first hand the complexities of growing an enterprise software company; from building a culture, to scaling a global team of employees, to making our customers successful.

Today is an important day in the evolution of Acquia:

  • Tom has decided it's time for him step down as CEO, allowing him flexibility with his personal time and act more as an advisor to companies, the role that brought him to Acquia in the first place.
  • We're going to search for a new CEO for Acquia. When we find that business partner, Tom will be stepping down as CEO. After the search is completed, Tom will remain on Acquia's Board of Directors, where he can continue to help advise and guide the company.
  • We are formalizing the working relationship I've had with Tom during the past 8 years by creating an Office of the CEO. I will focus on product strategy, product development, including product architecture and Acquia's roadmap; technology partnerships and acquisitions; and company-wide hiring and staffing allocations. Tom will focus on sales and marketing, customer success and G&A functions.

The time for these changes felt right to both of us. We spent the first decade of Acquia laying down the foundation of a solid business model for going out to the market and delivering customer success with Drupal – Tom's core strengths from his long career as a technology executive. Acquia's next phase will be focused on building confidently on this foundation with more product innovation, new technology acquisitions and more strategic partnerships – my core strengths as a technologist.

Tom is leaving Acquia in a great position. This past year, the top industry analysts published very positive reviews based on their dealings with our customers. I'm proud that Acquia made the most significant positive move of all vendors in last year's Gartner Magic Quadrant for Web Content Management and that Forrester recognized Acquia as the leader for strategy and vision. We increasingly find ourselves at the center of our customer's technology and digital strategies. At a time when digital experiences means more than just web content management, and data and content intelligence play an increasing role in defining success for our customers, we are well positioned for the next phase of our growth.

I continue to love the work I do at Acquia each day. We have a passionate team of builders and dreamers, doers and makers. To the Acquia team around the world: 2017 will be a year of changes, but you have my commitment, in every way, to lead Acquia with clarity and focus.

To read Tom's thoughts on the transition, please check out his blog post. Michael Skok, Acquia's lead investor, also covered it on his blog.

Categories: Drupal

Friduction: the internet's unstoppable drive to eliminate friction

18 May 2017 - 4:02pm

There is one significant trend that I have noticed over and over again: the internet's continuous drive to mitigate friction in user experiences and business models.

Since the internet's commercial debut in the early 90s, it has captured success and upset the established order by eliminating unnecessary middlemen. Book stores, photo shops, travel agents, stock brokers, bank tellers and music stores are just a few examples of the kinds of middlemen who have been eliminated by their online counterparts. The act of buying books, printing photos or booking flights online alleviates the friction felt by consumers who must stand in line or wait on hold to speak to a customer service representative.

Rather than negatively describing this evolution as disintermediation or taking something away, I believe there is value in recognizing that the internet is constantly improving customer experiences by reducing friction from systems — a process I like to call "friduction".

Open Source and cloud

Over the past 15 years, I have observed Open Source and cloud-computing solutions remove friction from legacy approaches to technology. Open Source takes the friction out of the technology evaluation and adoption process; you are not forced to get a demo or go through a sales and procurement process, or deal with the limitations of a proprietary license. Cloud computing also took off because it also offers friduction; with cloud, companies pay for what they use, avoid large up-front capital expenditures, and gain speed-to-market.

Cross-channel experiences

There is a reason why Drupal's API-first initiative is one of the topics I've talked and written the most about in 2016; it enables Drupal to "move beyond the page" and integrate with different user engagement systems that can eliminate inefficiencies and improve the user experience of traditional websites.

We're quickly headed to a world where websites are evolving into cross­channel experiences, which includes push notifications, conversational UIs, and more. Conversational UIs, such as chatbots and voice assistants, will prevail because they improve and redefine the customer experience.

Personalization and contextualization

In the 90s, personalization meant that websites could address authenticated users by name. I remember the first time I saw my name appear on a website; I was excited! Obviously personalization strategies have come a long way since the 90s. Today, websites present recommendations based on a user's most recent activity, and consumers expect to be provided with highly tailored experiences. The drive for greater personalization and contextualization will never stop; there is too much value in removing friction from the user experience. When a commerce website can predict what you like based on past behavior, it eliminates friction from the shopping process. When a customer support website can predict what question you are going to ask next, it is able to provide a better customer experience. This is not only useful for the user, but also for the business. A more efficient user experience will translate into higher sales, improved customer retention and better brand exposure.

To keep pace with evolving user expectations, tomorrow's digital experiences will need to deliver more tailored, and even predictive customer experiences. This will require organizations to consume multiple sources of data, such as location data, historic clickstream data, or information from wearables to create a fine-grained user context. Data will be the foundation for predictive analytics and personalization services. Advancing user privacy in conjunction with data-driven strategies will be an important component of enhancing personalized experiences. Eventually, I believe that data-driven experiences will be the norm.

At Acquia, we started investing in contextualization and personalization in 2014, through the release of a product called Acquia Lift. Adoption of Acquia Lift has grown year over year, and we expect it to increase for years to come. Contextualization and personalization will become more pervasive, especially as different systems of engagements, big data, the internet of things (IoT) and machine learning mature, combine, and begin to have profound impacts on what the definition of a great user experience should be. It might take a few more years before trends like personalization and contextualization are fully adopted by the early majority, but we are patient investors and product builders. Systems like Acquia Lift will be of critical importance and premiums will be placed on orchestrating the optimal customer journey.

Conclusion

The history of the web dictates that lower-friction solutions will surpass what came before them because they eliminate inefficiencies from the customer experience. Friduction is a long-term trend. Websites, the internet of things, augmented and virtual reality, conversational UIs — all of these technologies will continue to grow because they will enable us to build lower-friction digital experiences.

Categories: Drupal

Think beyond with Acquia Labs

15 May 2017 - 11:18am

For most of the history of the web, the website has been the primary means of consuming content. These days, however, with the introduction of new channels each day, the website is increasingly the bare minimum. Digital experiences can mean anything from connected Internet of Things (IoT) devices, smartphones, chatbots, augmented and virtual reality headsets, and even so-called zero user interfaces which lack the traditional interaction patterns we're used to. More and more, brands are trying to reach customers through browserless experiences and push-, not pull-based, content — often by not accessing the website at all.

Last year, we launched a new initiative called Acquia Labs, our research and innovation lab, part of the Office of the CTO. Acquia Labs aims to link together the new realities in our market, our customers' needs in coming years, and the goals of Acquia's products and open-source efforts in the long term. In this blog post, I'll update you on what we're working on at the moment, what motivates our lab, and how to work with us.

Alexa, ask GeorgiaGov

One of the Acquia Labs' most exciting projects is our ongoing collaboration with GeorgiaGov Interactive. Through an Amazon Echo integration with the Georgia.gov Drupal website, citizens can ask their government questions. Georgia residents will be able to find out how to apply for a fishing license, transfer an out-of-state driver's license, and register to vote just by consulting Alexa, which will also respond with sample follow-up questions to help the user move forward. It's a good example of how conversational interfaces can change civic engagement. Our belief is that conversational content and commerce will come to define many of the interactions we have with brands.

The state of Georgia has always been on the forefront of web accessibility. For example, from 2002 until 2006, Georgia piloted a time-limited text-to-speech telephony service which would allow website information and popular services like driver's license renewal to be offered to citizens. Today, it publishes accessibility standards and works hard to make all of its websites accessible for users of assistive devices. This Alexa integration for Georgia will continue that legacy by making important information about working with state government easy for anyone to access.

And as a testament to the benefits of innovation in open source and our commitment to open-source software, Acquia Labs backported the Drupal 8 module for Amazon Echo to Drupal 7.

Here's a demo video showing an initial prototype of the Alexa integration:

Shopping with chatbots

In addition to physical devices like the Amazon Echo, Acquia Labs has also been thinking about what is ahead for chatbots, another important component of the conversational web. Unlike in-home devices, chatbots are versatile because they can be used across multiple channels, whether on a native mobile application or a desktop website.

The Acquia Labs team built a chatbot demonstrating an integration with the inventory system and recipe collection available on the Drupal website of an imaginary grocery store. In this example, a shopper can interact with a branded chatbot named "Freshbot" to accomplish two common tasks when planning an upcoming barbecue.

First, the user can use the chatbot to choose the best recipes from a list of recommendations with consideration for number of attendees, dietary restrictions, and other criteria. Second, the chatbot can present a shopping list with correct quantities of the ingredients she'll need for the barbecue. The ability to interact with a chatbot assistant rather than having to research and plan everything on your own can make hosting a barbecue a much easier and more efficient experience.

Check out our demo video, "Shopping with chatbots", below:

Collaborating with our customers

Many innovation labs are able to work without outside influence or revenue targets by relying on funding from within the organization. But this can potentially create too much distance between the innovation lab and the needs of the organization's customers. Instead, Acquia Labs explores new ideas by working on jointly funded projects for our clients.

I think this model for innovation is a good approach for the next generation of labs. This vision allows us to help our customers stake ground in new territory while also moving our own internal progress forward. For more about our approach, check out this video from a panel discussion with our Acquia Labs lead Preston So, who introduced some of these ideas at SXSW 2017.

If you're looking at possibilities beyond what our current offerings are capable of today, if you're seeking guidance and help to execute on your own innovation priorities, or if you have a potential project that interests you but is too forward-looking right now, Acquia Labs can help.

Special thanks to Preston So for contributions to this blog post and to Nikhil Deshpande (GeorgiaGov Interactive) and ASH Heath for feedback during the writing process.

Categories: Drupal

7-Eleven using Drupal

8 May 2017 - 6:23pm

7-Eleven is the largest convenience store chain in the world with 60,000 locations around the globe. That is more than any other retailer or food service provider. In conjunction with the release of its updated 7-Rewards program, 7-Eleven also relaunched its website and mobile application using Drupal 8! Check it out at https://www.7-eleven.com, and grab a Slurpee while you're at it!

Categories: Drupal

State of Drupal presentation (April 2017)

1 May 2017 - 12:41pm

Last week, 3,271 people gathered at DrupalCon Baltimore to share ideas, to connect with friends and colleagues, and to collaborate on both code and community. It was a great event. One of my biggest takeaways from DrupalCon Baltimore is that Drupal 8's momentum is picking up more and more steam. There are now about 15,000 Drupal 8 sites launching every month.

I want to continue the tradition of sharing my State of Drupal presentations. You can watch a recording of my keynote (starting at 24:00) or download a copy of my slides here (108 MB).



The first half of my presentation provided an overview of Drupal 8 updates. I discussed why Drupal is for ambitious digital experiences, how we will make Drupal upgrades easier and why we added four new Drupal 8 committers recently.

The second half of my keynote highlighted the newest improvements to Drupal 8.3, which was released less than a month ago. I showcased how an organization like The Louvre could use Drupal 8 to take advantage of new or improved site builder (layouts video, workflow video), content author (authoring video) and end user (BigPipe video, chatbot video) features.

I also shared that the power of Drupal lies in its ability to support the spectrum of both traditional websites and decoupled applications. Drupal continues to move beyond the page, and is equipped to support new user experiences and distribution platforms, such as conversational user interfaces. The ability to support any user experience is driving the community's emphasis on making Drupal API-first, not API-only.

Finally, it was really rewarding to spotlight several Drupalists that have made an incredible impact on Drupal. If you are interested in viewing each spotlight, they are now available on my YouTube channel.

Thanks to all who made DrupalCon Baltimore a truly amazing event. Every year, DrupalCon allows the Drupal community to come together to re-energize, collaborate and celebrate. Discussions on evolving Drupal's Code of Conduct and community governance were held and will continue to take place virtually after DrupalCon. If you have not yet had the chance, I encourage you to participate.

Categories: Drupal

Drupal is API-first, not API-only

25 April 2017 - 9:59am

More and more developers are choosing content-as-a-service solutions known as headless CMSes — content repositories which offer no-frills editorial interfaces and expose content APIs for consumption by an expanding array of applications. Headless CMSes share a few common traits: they lack end-user front ends, provide few to no editorial tools for display and layout, and as such leave presentational concerns almost entirely up to the front-end developer. Headless CMSes have gained popularity because:

  • A desire to separate concerns of structure and presentation so that front-end teams and back-end teams can work independently from each other.
  • Editors and marketers are looking for solutions that can serve content to a growing list of channels, including websites, back-end systems, single-page applications, native applications, and even emerging devices such as wearables, conversational interfaces, and IoT devices.

Due to this trend among developers, many are rightfully asking whether headless CMSes are challenging the market for traditional CMSes. I'm not convinced that headless CMSes as they stand today are where the CMS world in general is headed. In fact, I believe a nuanced view is needed.

In this blog post, I'll explain why Drupal has one crucial advantage that propels it beyond the emerging headless competitors: it can be an exceptional CMS for editors who need control over the presentation of their content and a rich headless CMS for developers building out large content ecosystems in a single package.

As Drupal continues to power the websites that have long been its bread and butter, it is also used more and more to serve content to other back-end systems, single-page applications, native applications, and even conversational interfaces — all at the same time.

Headless CMSes are leaving editors behind This diagram illustrates the differences between a traditional Drupal website and a headless CMS with various front ends receiving content.

Some claim that headless CMSes will replace traditional CMSes like Drupal and WordPress when it comes to content editors and marketers. I'm not so sure.

Where headless CMSes fall flat is in the areas of in-context administration and in-place editing of content. Our outside-in efforts, in contrast, aim to allow an editor to administer content and page structure in an interface alongside a live preview rather than in an interface that is completely separate from the end user experience. Some examples of this paradigm include dragging blocks directly into regions or reordering menu items and then seeing both of these changes apply live.

By their nature, headless CMSes lack full-fledged editorial experience integrated into the front ends to which they serve content. Unless they expose a content editing interface tied to each front end, in-context administration and in-place editing are impossible. In other words, to provide an editorial experience on the front end, that front end must be aware of that content editing interface — hence the necessity of coupling.

Display and layout manipulation is another area that is key to making marketers successful. One of Drupal's key features is the ability to control where content appears in a layout structure. Headless CMSes are unopinionated about display and layout settings. But just like in-place editing and in-context administration, editorial tools that enable this need to be integrated into the front end that faces the end user in order to be useful.

In addition, editors and marketers are particularly concerned about how content will look once it's published. Access to an easy end-to-end preview system, especially for unpublished content, is essential to many editors' workflows. In the headless CMS paradigm, developers have to jump through fairly significant hoops to enable seamless preview, including setting up a new API endpoint or staging environment and deploying a separate version of their application that issues requests against new paths. As a result, I believe seamless preview — without having to tap on a developer's shoulder — is still necessary.

Features like in-place editing, in-context administration, layout manipulation, and seamless but faithful preview are essential building blocks for an optimal editorial experience for content creators and marketers. For some use cases, these drawbacks are totally manageable, especially where an application needs little editorial interaction and is more developer-focused. But for content editors, headless CMSes simply don't offer the toolkits they have come to expect; they fall short where Drupal shines.

Drupal empowers both editors and application developers This diagram illustrates the differences between a coupled — but headless-enabled — Drupal website and a headless CMS with various front ends receiving content.

All of this isn't to say that headless isn't important. Headless is important, but supporting both headless and traditional approaches is one of the biggest advantages of Drupal. After all, content management systems need to serve content beyond editor-focused websites to single-page applications, native applications, and even emerging devices such as wearables, conversational interfaces, and IoT devices.

Fortunately, the ongoing API-first initiative is actively working to advance existing and new web services efforts that make using Drupal as a content service much easier and more optimal for developers. We're working on making developers of these applications more productive, whether through web services that provide a great developer experience like JSON API and GraphQL or through tooling that accelerates headless application development like the Waterwheel ecosystem.

For me, the key takeaway of this discussion is: Drupal is great for both editors and developers. But there are some caveats. For web experiences that need significant focus on the editor or assembler experience, you should use a coupled Drupal front end which gives you the ability to edit and manipulate the front end without involving a developer. For web experiences where you don't need editors to be involved, Drupal is still ideal. In an API-first approach, Drupal provides for other digital experiences that it can't explicitly support (those that aren't web-based). This keeps both options open to you.

Drupal for your site, headless Drupal for your apps This diagram illustrates the ideal architecture for Drupal, which should be leveraged as both a front end in and of itself as well as a content service for other front ends.

In this day and age, having all channels served by a single source of truth for content is important. But what architecture is optimal for this approach? While reading this you might have also experienced some déjà-vu from a blog post I wrote last year about how you should decouple Drupal, which is still solid advice nearly a year after I first posted it.

Ultimately, I recommend an architecture where Drupal is simultaneously coupled and decoupled; in short, Drupal shines when it's positioned both for editors and for application developers, because Drupal is great at both roles. In other words, your content repository should also be your public-facing website — a contiguous site with full editorial capabilities. At the same time, it should be the centerpiece for your collection of applications, which don't necessitate editorial tools but do offer your developers the experience they want. Keeping Drupal as a coupled website, while concurrently adding decoupled applications, isn't a limitation; it's an enhancement.

Conclusion

Today's goal isn't to make Drupal API-only, but rather API-first. It doesn't limit you to a coupled approach like CMSes without APIs, and it doesn't limit you to an API-only approach like Contentful and other headless CMSes. To me, that is the most important conclusion to draw from this: Drupal supports an entire spectrum of possibilities. This allows you to make the proper trade-off between optimizing for your editors and marketers, or for your developers, and to shift elsewhere on that spectrum as your needs change.

It's a spectrum that encompasses both extremes of the scenarios that a coupled approach and headless approach represent. You can use Drupal to power a single website as we have for many years. At the same time, you can use Drupal to power a long list of applications beyond a traditional website. In doing so, Drupal can be adjusted up and down along this spectrum according to the requirements of your developers and editors.

In other words, Drupal is API-first, not API-only, and rather than leave editors and marketers behind in favor of developers, it gives everyone what they need in one single package.

Special thanks to Preston So for contributions to this blog post and to Wim Leers, Ted Bowman, Chris Hamper and Matt Grill for their feedback during the writing process.

Categories: Drupal

Thoughts as we head to DrupalCon Baltimore

20 April 2017 - 7:20pm

The past weeks have been difficult. I'm well aware that the community is struggling, and it really pains me. I respect the various opinions expressed, including opinions different from my own. I want you to know that I'm listening and that I'm carefully considering the different aspects of this situation. I'm doing my best to progress through the issues and support the work that needs to happen to evolve our governance model. For those that are attending DrupalCon Baltimore and want to help, we just added a community discussions track.

There is a lot to figure out, and I know that it's difficult when there are unresolved questions. Leading up to DrupalCon Baltimore next week, it may be helpful for people to know that Larry Garfield and I are talking. As members of the Community Working Group reported this week, Larry remains a member of the community. While we figure out Larry's future roles, Larry is attending DrupalCon as a regular community member with the opportunity to participate in sessions, code sprints and issue queues.

As we are about to kick off DrupalCon Baltimore, please know that my wish for this conference is for it to be everything you've made it over the years; a time for bringing out the best in each other, for learning and sharing our knowledge, and for great minds to work together to move the project forward. We owe it to the 3,000 people who will be in attendance to make DrupalCon about Drupal. To that end, I ask for your patience towards me, so I can do my part in helping to achieve these goals. It can only happen with your help, support, patience and understanding. Please join me in making DrupalCon Baltimore an amazing time to connect, collaborate and learn, like the many DrupalCons before it.

(I have received a lot of comments and at this time I just want to respond with an update. I decided to close the comments on this post.)

Categories: Drupal

Next steps for evolving Drupal's governance

10 April 2017 - 3:42am

The last time we made significant changes to our governance was 4 to 5 years ago [1, 2, 3]. It's time to evolve it more. We need to:

  • Update the governance model so governance policies and community membership decisions are not determined by me or by me alone. 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. I want to help drive the technical strategy and vision of Drupal, not be the arbiter of governance or interpersonal issues.
  • Review our the Code of Conduct. Many have commented that the intentions and scope of the Code of Conduct are unclear. For example, some people have asked if violations of the Code of Conduct are the only reasons for which someone might be removed from our community, whether Community Working Group decisions can be made based on actions outside of the Drupal community, or whether we need a Code of Conduct at all. These are all important questions that need clear answers.

I believe that to achieve the best outcome, we will:

  1. Organize both in-person and virtual roundtables during and after DrupalCon Baltimore to focus on gathering direct feedback from the community on evolving our governance.
  2. Refocus the 2-day meeting of the Drupal Association's Board of Directors at DrupalCon Baltimore to discuss these topics.
  3. Collect ideas in the issue queue of the Drupal Governance project. We will share a report from the roundtable discussions (point 1) and the Drupal Association Board Meeting (point 2) in the issue queue so everything is available in one place.
  4. Actively solicit help from experts on diversity, inclusion, experiences of marginalized groups, and codes of conduct and governance. This could include people from both inside and outside the Drupal community (e.g. a leader from another community who is highly respected). I've started looking into this option with the help of the Drupal Association and members of the Community Working Group. We are open to suggestions.

In order to achieve these aims, we plan to organize an in-person Drupal Community Governance sprint the weeks following DrupalCon Baltimore, involving members of the Drupal Association, Community Working Group, the Drupal Diversity & Inclusion group, outside experts, as well as some community members who have been critical of our governance. At the sprint, we will discuss feedback gathered by the roundtables, as well as discussions during the 2-day board meeting at DrupalCon Baltimore, and turn these into concrete proposals: possible modifications to the Code of Conduct, structural changes, expectations of leadership, etc. These proposals will be open for public comment for several weeks or months, to be finalized by DrupalCon Vienna.

We're still discussing these plans but I wanted to give you some insight in our progress and thinking; once the plans are finalized we'll share them on Drupal.org. Let us know your thoughts on this framework. I'm looking forward to working on solutions with others in the community.

Categories: Drupal

An apology to the Drupal community

9 April 2017 - 5:10am

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.)

Categories: Drupal

Living our values

22 March 2017 - 9:26pm

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 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.

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.

It's not for me to judge the choices anyone makes in their private life or what beliefs they subscribe to. I certainly don't take offense to the role-playing activities of Larry's alternative lifestyle. 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.

First, 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.

Second, I believe someone's belief system inherently influences their actions, in both explicit and subtle ways, and I'm unwilling to take this risk going forward.

Third, Larry's continued representation of the Drupal project could harm the reputation of the project and cause harm to the Drupal ecosystem. Any further participation in a leadership role implies our community is complicit with and/or endorses these views, which we do not.

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.

(Comments on this post are allowed but for obvious reasons will be moderated.)

Categories: Drupal

How the YMCA uses Drupal to accelerate its mission

17 March 2017 - 10:00am

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.

Features of the Open Y platform

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.

Philosophy of collaboration

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.

The momentum of Open Y

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.

Categories: Drupal

Making Drupal upgrades easy forever

8 March 2017 - 4:54am

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!

Upgrading from Drupal 8.2 to Drupal 8.3

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 sizeable 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.

Upgrading from Drupal 8 to Drupal 9

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 the 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.

What does this mean for Drupal 7 users?

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.

What does this mean for Drupal developers?

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.

What does this mean for Drupal core contributors?

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.

When will Drupal 9 will be released?

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.

Thank you

Special thanks to Alex Bronstein, Alex Pott, Gábor Hojtsy, Nathaniel Catchpole and Jess (xjm) for their contributions to this post.

Categories: Drupal