Drupal Fire - Quick Roundup from important Drupal blogs and sites
Drum roll, please!
We’re incredibly proud to announce WorldPulse.com’s most recent award: a Gold Best in Biz “Website of the Year” for 2015.
Four Kitchens is pleased to announce the launch of the Forcepoint website. Headquartered in 4K’s own Austin, TX, Forcepoint, a joint venture between Raytheon and Vista Equity Partners, is the result of a merger between cybersecurity firms Raytheon Cyber, Websense, and StoneSoft. Forcepoint is set to become an industry leader in online security solutions, allowing both businesses and governments to protect themselves from cybercrime — safeguarding against both insider threats and external attacks.
On December 29, 2000, I made a code commit that would change my life; it is in this commit that I called my project "Drupal" and added the GPL license to it.
The commit where I dubbed my website project "Drupal" and added the GPL license.
A couple weeks later, on January 15, 2001, exactly 15 years ago from today, I released Drupal 1.0.0 into the world. The early decisions to open-source Drupal and use the GPL license set the cornerstone principles for how our community shares with one another and builds upon each other's achievements to this day.
Drupal is now 15 years old. In internet terms, that is an eternity. In 2001, only 7 percent of the world's population had internet access. The mobile internet had not entered the picture, less than 50% of the people in the United States had a mobile phone, and AT&T had just introduced text messaging. People searched the web with Lycos, Infoseek, AltaVista and Hot Bot. Google -- launched in 1998 as a Stanford University research project -- was still a small, private company just beginning its rise to prominence. Google AdWords, now a $65 billion business, had less than 500 customers when Drupal launched. Chrome, Firefox, and Safari didn't exist yet; most people used Netscape, Opera or Internet Explorer. New ideas for sharing and exchanging content such as "public diaries" and RSS had yet to gain widespread acceptance and Drupal was among the first to support those. Wikipedia was launched on the same day as Drupal and sparked the rise of user-generated content. Facebook and Twitter didn't exist until 4-5 years later. Proprietary software vendors started to feel threathened by open source; most didn't understand how a world-class operating system could coalesce out of part-time hacking by several thousand developers around the world.
Looking back, Drupal has not only survived massive changes in our industry; it has also helped drive them. Over the past decade and a half, I've seen many content management systems emerge and become obsolete: Vignette, Interwoven, PHP-Nuke, and Scoop were all popular at some point in the past but Drupal has outlived them all. A big reason is from the very beginning we have been about constant evolution and reinvention, painful as it is.
Keeping up with the pace of the web is a funny thing. Sometimes you'll look back on choices made years ago and think, "Well, I'm glad that was the right decision!". For example, Drupal introduced "hooks" and "modules" early on, concepts that are commonplace in today's platforms. At some point, you could even find some of my code in WordPress, which Matt Mullenweg started in 2003 with some inspiration from Drupal. Another fortuitous early decision was to focus Drupal on the concept of "nodes" rather than "pages". It wasn't until 10 years later with the rise of mobile that we started to see the web revolve less and less around pages. A node-based approach makes it possible to reuse content in different ways for different devices. In a way, much of the industry is still catching up to that vision. Even though the web is a living, breathing thing, there is a lot of things that we got right.
In the end, I feel fortunate that our community is willing to experiment and break things to stay relevant. Most recently, with the release of Drupal 8, we've made many big changes that will fuel Drupal's continued adoption. I believe we got a lot of things right in Drupal 8 and that we are on the brink of another new and bright era for Drupal.
I've undergone a lot of personal reinvention over the past 15 years too. In the early days, I spent all my time writing code and building Drupal.org. I quickly learned that a successful open source project requires much more than writing code. As Drupal started to grow, I found myself an "accidental leader" and worried about our culture, scaling the project, attracting a strong team of contributors, focusing more and more on Drupal's end-users, growing the commercial ecosystem around Drupal, starting the Drupal Association, and providing vision. Today, I wear a lot of different hats: manager of people and projects, evangelist, fundraiser, sponsor, public speaker, and BDFL. At times, it is difficult and overwhelming, but I would not want it any other way. I want to continue to push Drupal to reach new heights and new goals.
Today we risk losing much of the privacy, serendipity and freedom of the web we know. As the web evolves from a luxury to a basic human right, it's important that we treat it that way. To increase our impact, we have to continue to make Drupal easier to use. I'd love to help build a world where people's privacy is safe and Drupal is more approachable. And as the pace of innovation continues to accelerate, we have to think even more about how to scale the project, remain agile and encourage experimentation. I think about these issues a lot, and am fortunate enough to work with some of the smartest people I know to build the best possible version of the web.
So, here is to another 15 years of evolution, reinvention, and continued growth. No one knows what the web will look like 15 years in the future, but we'll keep doing our best to guide Drupal responsibly.
Last weekend, a bunch of linguists met up in Washington DC for their annual professional conference. Tucked in among debates on language rights advocacy and descriptions of new kinds of NOs and NOTs emerging on Twitter, the American Dialect Society voted on the 2015 Word Of The Year.
Welcome back, readers! It’s the top of the year, a new dawn, a new calendar, and a set of goals and resolutions to ring in the twelve months ahead. We here at Four Kitchens — along with the usual “go to the gym”, “drink a little less beer each week”, and “call home more often” — have a resolution for the business we’re in. A Design Resolution, as it were. And here it is:
You do you.
I am confident that adopting a client-side framework through progressive decoupling will give us the best of both worlds. Of course, this does not mean I oppose fully decoupling through any other framework; in fact, I believe we should redouble our efforts toward a first-class API-first Drupal. But progressive decoupling means that we will be able to work toward a next-generation user experience without abandoning much of the work we've done so far.
Special thanks to all of the following experts who provided review and input: Miško Hevery (creator of Angular; Google) and Igor Minar (technical lead for Angular; Google); Ed Faulkner (core maintainer for Ember); Amitai Burstein (Drupal and Elm contributor; Gizra); Sebastian Siemssen (Drupal contributor, Elm and React developer; Zensations); and John Albin Wilkins (Drupal 8 mobile initiative lead), Alex Bronstein (Drupal core maintainer; Acquia), Wim Leers (Drupal core contributor; Acquia), and Preston So (Drupal contributor, Acquia).
First, have we decided on the right criteria regardless of the frameworks themselves? This is probably the most important at this stage. While many organizations choose to adopt client-side frameworks for fully decoupled implementations, Drupal is the first to consider layering a framework on top to allow both richly dynamic and more traditional modules to coexist gracefully through progressive decoupling. What issues around templates, rendering, and client-side caching should we incorporate into these criteria? Is there anything missing or overemphasized?
Finally, have we drawn the right conclusions against these criteria? In other words, did we fill out the cells correctly? While they have been reviewed by some of the frameworks' experts, there might be unexpected gotchas or caveats.
At the moment, the most promising candidates in the comparison matrix appear to be Angular 2, Ember, and React, given their technical robustness, relative suitability for progressively decoupled Drupal, and their strong levels of community support and broader adoption. Given that Backbone is already in core and several modules already rely on it, we have included it too.
What we've learned from talking to the different projects is that they are often converging on similar techniques and best practices; they are by and large adding support for Virtual DOM implementations or rehydration (seamless state transfer), and they are all obsessing over small payload size and performance, better testability, etc. Therefore it is important to focus on the fundamental, often philosophical, differences between the projects that will likely be unchanged in time; key architectural differences, their release cadence and stance on backward compatibility, their license, their governance model, their flexibility and learning curve, etc.
From a quick glance at the criteria and our needs, it seems that Ember is currently our best candidate, as it appears to have a slight technical edge overall. Ember 2.0 has an all-new rendering engine named Glimmer, and it has server-side rendering through FastBoot. On the other hand, however, Ember is quite bulky and opinionated (enforcing patterns for code structure) compared to other candidate frameworks. A more fundamental difference is that unlike Angular and React, which have corporate governance and funding, Ember is a community-driven project like Drupal.
While React is lightweight, it needs integration with a variety of other libraries in the React ecosystem to work as a full-fledged implementation, which gives it a steep learning curve from an implementation standpoint. Because React is a relatively young project, best practices are shifting quickly and making it less attractive. The Virtual DOM, among React's most compelling features, has also seen its core ideas filter into other framework projects. But more importantly, React is licensed with what I believe to be a potentially unacceptable patent clause, which states that an organization can no longer use React once it sues Facebook for any (unrelated) patent infringement. This has already generated some concerted pushback from both WordPress's Calypso and React contributors.
Whatever the result of the debate around which client-side framework to adopt, I believe that Drupal needs to move quickly to embrace a framework that will aid development of a progressively decoupled architecture and corresponding user experience improvements. By providing some baseline criteria and including our accomplished community, I have no doubt we can reach this decision quickly but also intelligently.
Special thanks to Preston So for contributions to this blog post.
As many of my loyal blog readers know, I sit down to write a retrospective at the end of each year. It's helpful from the perspective of seeing how far Acquia has come in a single year, but it should also give you a glimpse of what is in store for Acquia in 2016 and beyond. If you find it interesting to take a look back at previous retrospectives, here they are: 2014, 2013, 2012, 2011, 2010 and 2009. These posts provide a pretty detailed overview of Acquia's trajectory as a company.
Since Acquia started eight years ago, we've believed that open source offers significant advantages over proprietary software because of its faster innovation, higher quality, freedom from vendor lock-in, greater security, and lower total cost of ownership. Early in our life as a company, we made a big bet that open source combined with the cloud, offered through a subscription model rather than perpetual license, would be a very compelling solution for the market. Few people believed us at the time, but now it is clear that our early vision is starting to pay off; perpetual software licenses are on the decline and Deutsche Bank analyst Karl Keirstead recently called cloud and open source the two leading themes in Silicon Valley.
The market demand for Acquia's digital business platform continues to grow; three of the top analyst firms, IDC, Gartner and Forrester have all named digital business transformation a top strategic imperative for the C-suite in 2016 and beyond. Open source, cloud computing, big data, the Internet of Things (IoT), and artificial intelligence are all catalysts for the expansion of digital transformation into all corners of the organization.
Organizations are rapidly expanding the range of digital interactions with their customers and partners, moving Drupal and Acquia to the core of their business. There is a growing focus on personalization and data-driven automation, which bodes well for products like Acquia Lift. In general, I believe that the growing reliance on digital provides Drupal and Acquia with a multi-decade opportunity.
Within the last 12 months, some of the largest technology companies including Apple, Google, Microsoft and Facebook have open-sourced key components of their business. There are many motivations for this shift. According to Apple, the company open-sourced its Swift programming language to extend it to new platforms. Google open-sourced TensorFlow, its artificial intelligence platform to make an even bigger impact outside Google, even though the company employs 2,000 engineers working on artificial intelligence alone. Microsoft open-sourced .NET to increase its relevance with developers and play nicely with other operating systems. In Deutsche Bank's 2016 predictions, Keirstead says "open source keeps eating the world", causing major price deflation for the traditional enterprise software industry. Whether the motive is faster innovation or increased adoption, companies are relying less and less on proprietary software and embracing open source.
Amazon's SVP of Web Services Andy Jassy explained in his 2015 AWS re:Invent presentation that websites have been a "critical gateway" to AWS' wider cloud adoption in the enterprise. His rationale: nearly every organization has one or more websites, and many aren't considered "mission-critical applications". Therefore, most organizations feel comfortable moving some or all of their websites to the cloud. Websites are an important stepping stone for organizations to build up the knowledge and confidence to migrate their entire businesses to the cloud.
As cloud adoption grows, we're seeing our customers use a mixture of SaaS, PaaS and IaaS. In particular the Platform-as-a-Service (PaaS) model continues to grow fast, which is great news for Acquia Cloud. A growing number of enterprises are choosing PaaS ahead of Infrastructure-as-a-Service (IaaS) to save time and money on building, scaling and maintaining infrastructure so they can focus on building websites. Gartner sizes the PaaS market at $4.1B in 2015, attaining a compound annual growth rate (CAGR) of 65%+ through 2018. We are a few years ahead of our competitors (Adobe, Sitecore, IBM, Oracle) when it comes to PaaS, and I don't see that changing in 2016.
The migration to the cloud is only getting started. When I met with Eric Schmidt this year, he told me that he believes Google's cloud business could outpace its advertising business in five years. To put that in context, Google made more than $65 billion in advertising in 2015, roughly 90% of its total revenue. Amazon's cloud business, bigger than its four closest competitors combined (including Google's cloud business), generated roughly $7 billion in revenues in 2015 and is expected to grow 80% year-over-year. Needless to say, it is exciting for Acquia be a "critical gateway" in such a massive movement to the cloud.
A photo of Andy Jassy's keynote at AWS re:Invent 2015.
As the web evolves, the idea of a "digital business" takes on an entirely new meaning. I've said this before but digital is not just about building websites anymore; many of our customers are using digital to change the way their business operates, automate manual processes, and save millions of dollars in the process. Digital strategies are no longer confined to the marketing department; they're quickly becoming a boardroom priority.
Digital experiences are also getting more sophisticated. What used to be as simple as building a website now involves getting the right information, to the right user, at the right time, in the right context -- an idea I call B2One and talked about as part of my Big Reverse of the Web thesis. It's all about understanding the user's context and preferences to deliver the best next experience. We started investing in this area in late 2013, acquired a personalization company in 2014, and expect this trend to grow really big, especially as big data, the Internet of Things (IoT) and artificial intelligence mature.
Beyond personalization and contextualization, companies have a greater need for flexibility and freedom to integrate a variety of external services, ranging from commerce to marketing automation solutions. While there are plenty of point solutions on the market that achieve pieces of this puzzle, Acquia and Drupal uniquely provide a platform to do it all.
Acquia continues its growth
Acquia's growth is an indicator that businesses are already betting big on open source, cloud, personalization, and digital transformation. Looking at our numbers for 2015, it is hard to believe that last year was only our seventh full year as a revenue-generating business. Our new logo subscriptions -- the business that we get from companies new to Acquia -- continued its fast growth, while our renewal rates are among the best around.
To support our growth, we added $55 million in new venture capital funding in 2015, bringing Acquia's total raised to $188.6 million.
We dramatically increased headcount last year. In May, we moved into a beautiful new corporate headquarters in Boston, where we hosted a launch party with mayor Martin J. Walsh that established us as an anchor growth company for the city. Globally, we added 150 more employees in 2015, bringing us to 720 people. The executive team changed substantially in 2015, with the addition of Al Nugent as CISO, Preston Bradford as COO, Heather Hartford as Chief People Officer, and most recently Loren Jarrett as CMO. We also announced the appointment of Christine Komola, CFO of Staples, to Acquia's board of directors. We expanded European operations with the opening of a new office in Munich. Acquia now operates out of 10 global offices on three continents!
A photo of Acquia's headquarters in downtown Boston.
We made key investments in talent for our partner team, grew the number of Drupal certifications achieved globally, and strengthened our relationship with agency partners. We were proud to announce our WPP Global Alliance partnership this year, which brings Acquia closer to the organizations building the world's most amazing digital experiences.
Top industry analysts continued to recognize Acquia as a leading provider of digital experience software and services. In October 2015, we were named a "Strong Performer" in The Forrester Wave: Digital Experience Platforms Q4 2015. In August, Gartner named us a "Leader" in the 2015 Magic Quadrant for Web Content Management. This type of external validation supports Acquia as a viable alternative to proprietary solutions provided by companies like Adobe, IBM, Sitecore or Oracle.
Acquia Cloud continues to enable organizations to run their websites securely and reliably, while providing them with the tools to accelerate web development and shorten time to market. We manage over 13,000 AWS instances (virtual servers) powering approximately 197,000 websites. In December 2015, Acquia Cloud served 10.8 billion Apache hits and 6.2 billion Drupal bootstraps (requests handled by Drupal instead of one of different caching layers or the web server directly), with billions more served from our caching layers and Acquia Cloud Edge.
Last year, we launched Acquia Cloud support for the São Paulo, Brazil and Frankfurt, Germany regions. With our German expansion we became the first Drupal PaaS to offer pan-European high availability to accommodate EU data sovereignty requirements.
With the launch of Drupal 8 in late 2015, the Drupal community achieved our most significant release in the history of the platform. We implemented a more modern development framework, reimagined the usability and authoring experience, and made improvements that will help everyone build the multilingual, mobile and highly personalized digital experiences of the future. From how we model content and get content in and out the system, to how we assemble experiences on various devices, to how we scale that to millions of pageviews — it all got much better with Drupal 8.
Now that Drupal 8 is released, I'm convinced that it will attract new developers and site-builders to the platform. Nonetheless, the wait for Drupal 8 has been long and painful, temporarily slowing down much of the commercial Drupal ecosystem. Despite some turbulence, I'm proud that the Acquia team was a force in helping to push Drupal 8 over the finish line.
Acquia employs more than 150 Drupal experts, and has fixed upwards of 1,200 issues in Drupal 8. I reassigned our Drupal team from feature development (i.e. Spark) to working on criticals. This team was a major force in bringing the total number of criticals down from a high of 90 at the beginning of the year to zero in early October, through development, performance work, patch reviews, sprint coordination, and in helping to manage the Drupal 8 Accelerate program. To help jumpstart faster Drupal 8 adoption, Acquia is investing significantly in porting the top 50+ contributed modules. We have always believed in giving back more as a core part of our company's DNA. Our entire team is ready to enable and support companies working with Drupal 8.
Last year was an exciting one when it came to new products. We announced Content Hub, a cloud-based content distribution and discovery service. As more of our customers scale with Acquia across hundreds of sites, Content Hub lets authors and site owners reuse content from internal and external sites. And we added a critical commerce integration through a partnership with Hybris, which provides even more options for enterprises to drive commerce experiences.
We announced a variety of important security and compliance milestones that will be crucial to protecting our customers. First, we introduced Acquia Cloud Edge, a new DDoS security product developed in partnership with CloudFlare to keep our customers safer from external threats. Soon after, Acquia achieved HIPAA compliance upon passing an independent audit of Acquia Cloud Site Factory and Acquia Cloud. HIPAA compliance is significant because of Acquia's roster of healthcare customers, who require certain safeguards for data security and look to scale Acquia Cloud across their portfolio of sites.
In addition to this compliance milestone, our spam-blocking software, Mollom, has blocked over 10 billion spam comments.
Acquia Lift customers challenged some of our original assumptions about personalization. We worked to improve our Acquia Lift personalization product with the help of our customers, creating a new workflow and UX that supported more flexibility and freedom depending on the individual organization. In 2015, we learned a lot about the challenges organizations face when starting out with personalization and doubled down to help our customers become successful. Personalization will continue to be a huge focus of ours in 2016.
This year, we will be rolling out many new products and enhancing existing ones. Acquia Cloud will get a brand-new, responsive, card-based UX in early 2016, and we'll give development teams the ability to create on-demand environments. We will continue to focus on security enhancements from audits like SOC and ISO, as well as key control planes including FedRAMP, Single Sign-On, and much more. Our team was challenged to get the first cloud service running on our new grid architecture by the end of 2015. With a few hours to spare on the 31st, the "Uptime" service is now running on our grid architecture, a major milestone. A continued focus on developer tools, more microservices, personalization and a "jumpstart" Drupal 8 distribution are just some of the technology we will be rolling out in 2016. Overall, you'll see us getting faster, more secure and more efficient, and providing even more options for our customers to create highly personalized digital experiences.
Longer term, I'm very excited about Acquia's opportunity. I believe we've steered the company to be positioned at the right place at the right time. Time will tell, but 2016 promises to be another big year for Acquia.
File this under "better late than never". Before the year closes out, I wanted to post my 2015 DrupalCon Barcelona keynote video and slides. I archive all my DrupalCon keynotes on my site so anyone who is interested in taking a trip to memory lane or studying the evolution of Drupal, can check out all my previous DrupalCon keynotes.
My DrupalCon Barcelona keynote is focused on having a realistic, open and honest conversation about the state of Drupal. In it, I broke down my thoughts on Drupal's market position, development process, and "decoupled Drupal". You can watch the recording of my keynote or download a copy of my slides (PDF, 27 MB).
Still looking for a gift for your favorite UX or web designer? Look no further! The 4K design team has put together a list of a few of our favorite things.
These items are ordered (approximately) from least to most expensive, so you can find the right gift for your budget.
Drupal 8 makes huge-huge strides in terms of reaching more people on the globe by making everything translatable and automating translation downloads and updates from the community among hundreds of other improvements. What about software translation contribution though? We did not make progress on that front in core, but it is not very hard to do as a contributed module.
The Localization client module is available for Drupal 7 and 6. It does two things: it provides an alternate nicer user interface to translate Drupal (modules) and it allows you to contribute to the community right from that interface. Drupal 8 already improved the built-in translation interface considerably, so it made sense to start with porting the contribution functionality and integrate that first. The initial Drupal 8 port of that is available for your testing now!
To try it out:
- Join the https://localize.drupal.org/ team you want to contribute translations to (if not already). For testing, you can use the test language. Or better: just test with good translation suggestions so your reviewers will be happy.
- Grab the Drupal 8.x-1.0-alpha1 version of Localization client. Install the Localization Client Contributor submodule only (you would not be able to install the other one yet anyway).
- The module comes with contribution enabled by default, but you need to set your API key so localize.drupal.org can identify you. Edit your user account and enter the API key there.
- If you want to grant other people to contribute, grant them the Contribute translations to localization server permission to contribute and tell them to enter their respective API keys on their user profiles.
- Now when you go to the built-in software translation UI it will tell you that all things changed will also be submitted to localize.drupal.org and the submit button will reflect that too, to make it super-clear. If you did not set your API key yet, it will tell you to do that instead.
- Once submitting the translation changes, it will let you know how many strings were successfully submitted and any errors encountered as well. All messages are also logged for later review.
The resulting effect of submitting changes locally are visible remotely by the community as well, yay!
Happy translating! See known issues and report more at https://www.drupal.org/project/issues/l10n_client?version=8.x Further improvements are of course possible, issues are welcome!
As user experiences evolve from static pages to application-like experiences, end users' expectations of websites have become increasingly demanding. The Facebook newsfeed, the Gmail inbox, and the Twitter live stream are all compelling examples that form a baseline for the application-like experiences users now take for granted.
Many of Drupal's administrative interfaces and Drupal sites could benefit from a similarly seamless, instantaneous user experience. Drupal's user interfaces for content modeling (Field UI), layout management (Panels), and block management would benefit from no page refreshes, instant previews, and interface previews. These traits could also enrich the experience of site visitors; Drupal's commenting functionality could similarly gain from these characteristics and resemble an experience more like the commenting experience found in Facebook.
As Drupal's project lead, I ask myself: how can our community feel enabled and encouraged to start building rich user experiences?
In recent years, the emergence of decoupled architectures with client-side frameworks and libraries have helped our industry build these experiences. Does that mean we have to decouple Drupal's front-facing site experience (for site visitors or end users) and/or the administration experience (for content editors and site builders)? If so, should Drupal decouple the administration layer differently from the front-facing site experience? By extension, should a client-side framework guide this change?
Here is my current thinking: in the short term, Drupal should work toward a next-generation user experience under progressive decoupling for both the administration layer and the end user experience. At the same time, we should enable fully decoupled end-user and administrative experiences to be built on Drupal too. In my view, the best way to achieve this is to formally standardize on a full-featured MV* framework (e.g. Angular, Ember, Backbone, and Knockout) or a component-based view library (e.g. React, Vue, and Riot). In this blog post, I want to kick off the discussion and walk you through my current position in some more detail.
Should we decouple Drupal itself?
A framework can assume responsibility over very little, such as with Backbone, or a great deal of the stack, including the rendering process.
There is no doubt that Drupal's administration layer is very application-like and would benefit from an experience that is more interactive. For the end-user experience, a decoupled implementation is not always the best option. Some sites may not need or want the application-like interactivity that a client-side framework would provide, since not every site needs interaction. For instance, news sites or blogs do not need much interactivity, custom applications need a great deal, while e-commerce sites lie somewhere in the middle. It's not clear-cut, so let's look at our options in more detail.
Easy of implementation
No immediate feedback
Theme layer preserved
Modules in mostly PHP
Ad-hoc client-side code
No server-side change
No client-side change
No page refreshes
Theme layer preserved
Unified client-side code
Some server-side change
Some client-side change
No page refreshes
Theme layer replaced
Unified client-side code
Much server-side change
Much client-side change
How should Drupal decouple its user experience?
Drupal's administration layer (content editor and site builder experience) is effectively an application. Fully decoupling may be the appropriate call to achieve the best possible user experience for creating, managing and presenting content. However, rewriting the administration layer from the ground up is a monumental task, especially since its modules provide powerful interfaces that allow site builders to build robust, complex sites without a line of code.
The same expectations for application-like interactivity often hold for the end-user experience: users expect shopping carts, comments, notifications, and searches to be updated instantaneously, without having to wait for a page to load.
For both the administration layer and the end-user experience, I believe the Drupal front end should not be fully decoupled out of the box. We should advance from our traditional paradigm and default to progressive decoupling. It allows us to achieve the user experience we want without significant downsides, since not every use case would benefit from fully decoupling. Through progressive decoupling, Drupal could potentially reach the ideals of the assembled web more quickly by preserving a tight link between Drupal modules and their front-end components.
Nonetheless, we should empower people building fully decoupled sites and applications. Depending on the use case, Drupal 8 is a good match for decoupled applications but we should improve and extend Drupal's REST API, enhance contributed modules such as Services, and shore up new features such as GraphQL (demo video) so more functionality can be decoupled. Front-end developers can then use any framework of their choice — whether it is Angular, Ember, React, or something else — to build a fully decoupled administrative application.
Should Drupal standardize on a single framework?
All things considered, I do believe Drupal should standardize on a single client-side framework, but it should only make such an explicit recommendation for progressively decoupled Drupal, not fully decoupled architectures. It would result in a more seamless user experience, better compatibility across interactive components in modules, maximum code reuse, a more consistent front-end developer experience, more maintainable code, and better performance as we don't have to load multiple frameworks.
Despite the potential benefits, there are also good reasons not to embrace a single client-side framework. New front-end frameworks are being created at what feels like an unsustainable pace; every nine months there is a new kid on the block. It's hard for a project as large as Drupal to embrace a single technology when there is no guarantee of its longevity.
For instance, Backbone, with its underlying library Underscore, currently powers interactions in the toolbar and in-place editing in Drupal 8. Though Drupal could expand the scope of Backbone in core and encourage front-end developers to build with it, it means buying even further into a framework that is quite old among its peers.
To deal with the fast-evolving nature of the front-end landscape, we need to be thoughtful about which framework we choose, to reassess our choice from time to time, and to make sure we can migrate fairly easily if we so decide.
What client-side framework should Drupal standardize on?
Assuming we agree that embracing a single client-side framework makes sense for Drupal, there are actually three additional questions: what framework to standardize on, how to do it, and when to decide.
I'm the first to admit I'm not the best person to answer the first question. As I'm not a front-end developer, I'm looking at you, the Drupal community, to help answer this question. I'd hope that the chosen framework aligns well with both our architecture (modular, flexible) and community (collaborative, community-driven).
The second question — how to standardize on a framework — I can help answer. On the one extreme, Drupal could be opinionated and ship a client-side framework with Drupal core, meaning that every installation of Drupal ships with the chosen framework. This would be much like the adoptions of jQuery and Backbone.js. On the other end of the spectrum, Drupal could recommend a specific framework but not ship with it. Finally, somewhere in between, Drupal could provide a default standard framework in core but make it easy to replace with it a framework of a developer's choice, though the likelihood of this is quite small. This is akin to Drupal core shipping with a template engine (i.e. PHPTemplate) that could be (but was rarely) replaced with another. Ultimately, I think we get the best result if Drupal ships with a specific framework—much like the adoption of jQuery in Drupal 5.
The last question, when to standardize on a framework, is important too. I would recommend we experiment with possible directions as soon as possible in order to decide on a final vision sooner rather than later.
I believe that, for now, it makes more sense to progressively decouple Drupal sites and their administration layer by first building our pages with Drupal. Once the page is loaded, we can let a unified client-side framework take over as much of the page as needed to foster a next-generation user experience without reinventing the wheel or alienating developers.
That is not all! We will need module developers to bring rich interactions to their user interfaces with the help of the framework we choose. We will need designers to guide module developers in building a graceful user interface. We will need front-end developers to demonstrate how they want to develop the user experiences that will define Drupal for years to come. We will need users to test and validate all of our work. It will be tough going, but together, we can ensure Drupal stays ahead of the curve well into the future.
Two weeks ago (hey, I've been busy and trying to sleep for once), after 1716 days of work by more than 3312 people the Drupal community finally released Drupal 8, the latest release of the best community-driven web software in the world. The blogosphere is already filled with congratulatory blog posts celebrating the immense accomplishment, and deservedly so.
A number of people recently have asked me how I feel about Drupal 8's release, especially around the PHP community. Overall, my answer has to be that I'm happy, but not satisfied.
One thing that is exciting to me, is how much we appear to have gotten right in Drupal 8. The other day, for example, I stumbled upon a recent article from the LinkedIn Engineering team describing how they completely changed how their homepage is built. Their primary engineering objective was to deliver the fastest page load time possible, and one of the crucial ingredients was Facebook's BigPipe.
When a very high-profile, very high-traffic, highly personalized site like LinkedIn uses the same technique as Drupal 8, that solidifies my belief in Drupal 8.
LinkedIn supports both server-side and client-side rendering. While Drupal 8 does server-side rendering, we're still missing explicit support for client-side rendering. The advantage of client-side rendering versus server-side rendering is debatable. I've touched upon it in my blog post on progressive decoupling, but I'll address the topic of client-side rendering in a future blog post.
However, there is also something LinkedIn could learn from Drupal! Every component of a LinkedIn page that should be delivered via BigPipe needs to write BigPipe-specific code which is prone to errors and requires all engineers to be familiar with BigPipe. Drupal 8 on the other hand has a level of abstraction that allows BigPipe to work without the need for BigPipe-specific code. Thanks to Drupal's higher-level API, Drupal module developers don't have to understand BigPipe: Drupal 8 knows what page components are poorly cacheable or not cacheable at all, and what page components are renderable in isolation, and uses that information to automatically optimizes the delivery of page components using BigPipe.
Drupal's BigPipe support will benefit websites small and large. But it is exciting to see Drupal support the advanced techniques that were previously only within reach of the top 50 most visited sites of the world!
Building Drupal 8 with all of you has been a wild ride. I thought it would be fun to take a little end-of-week look back at some of our community's biggest milestones through Twitter. If you can think of others important Tweets, please share them in the comments, and I'll update the post.
Feeling nostalgic? See every single version of Drupal running!
— Cheppers (@cheppers) November 19, 2015
Here is how we opened the development branch for Drupal 8: live at Drupalcon!
The secretsauce of #drupal isn't code or features or market share, important thought they are. The secret sauce is community.
— Sean Yo (@seanyo) March 10, 2011
— Jeff Geerling (@geerlingguy) March 10, 2011
Drupal 8's first beta showed the power of community
Drupal 8.0.0 beta 1 released! https://t.co/FwdmRYaZUx Ahh the power of COMMUNITY driven software! :-)
— Doug Vann (@dougvann) October 1, 2014
— Gábor Hojtsy (@gaborhojtsy) October 1, 2014
We had issues ... but the queue steadily declined
— xjm (@xjmdrupal) September 19, 2014
Drupal 8.0.x-rc1 release window is today. Good sign of real stability is major issue count going down for 6+ weeks. pic.twitter.com/5VnHGmL9zb
— catch (@catch56) October 7, 2015
We held sprints around the world: here are just a few
— xjm (@xjmdrupal) July 5, 2015
Working on D8 Criticals at the Ghent DA critical sprint, this is how the "My issues" page looks for me right now! pic.twitter.com/y5SnavVtND
— Sascha Grossenbacher (@berdir) December 13, 2014
— Cameron Eagans (@cweagans) March 23, 2012
And we created many game-changing features
— Wim Leers (@wimleers) April 8, 2015
And.... there we go! http://t.co/ed6XtMIs MOTHER BLEEPING VIEWS IN MOTHER BLEEPING CORE!
— webchick (@webchick) October 22, 2012
— Alex Pott (@alexpott) February 15, 2014
With Content + Config Translation in core D8 core is more translatable than D7 with all of contrib. #drupal
— Tobias Stöckler (@tstoeckler) November 18, 2013
Amazing to see Drupal 8's multilingual capabilities explained on the multilingual release page (for example Farsi): pic.twitter.com/9owVE3xABo
— Gábor Hojtsy (@gaborhojtsy) November 19, 2015
The founder of PHP said: Drupal 8 + PHP7 = a lot of happy people
— Rasmus Lerdorf (@rasmus) April 21, 2015
We reached the first release candidate and celebrated ... a little
— Whitney Hess (@whitneyhess) October 7, 2015
Just LOOK at it.
8.0.0-rc1 is GREEN
— Manuel Garcia (@drupalero) October 7, 2015
Kudos to the 3000+ contributors and to the entire Drupal community that helped make this happen. https://t.co/FtATRtSmCU
— Leslie Glynn (@leslieglynn) October 7, 2015
And, just yesterday, we painted the world blue and celebrated Drupal 8 ... a lot!
— Drupal (@drupal) November 10, 2015
— Drupal (@drupal) November 19, 2015
— Taco Potze˙ (@tacopotze) November 19, 2015
— Duo (@DuoConsulting) November 19, 2015
— Shakeel Tariq (@shakeeltariq) November 19, 2015
— Agustin Rojas Silva (@Aguztinrs) November 19, 2015
— HornCologne (@HornCologne) November 19, 2015
— webchick (@webchick) November 19, 2015
— Paul Johnson (@pdjohnson) November 19, 2015
— Dries Buytaert (@Dries) November 18, 2015
We just released Drupal 8.0.0! Today really marks the beginning of a new era for Drupal. Over the course of almost five years, we've brought the work of more than 3,000 contributors together to make something that is more flexible, more innovative, more easier to use, and more scalable.
Drupal 8 has been a big transformation for our community. This particular reboot has taken one-third of Drupal's lifespan to complete. In the process we've learned that reinvention doesn't come easily or quickly. There are huge market forces happening around us, and we can't exactly look away. Mobile is moving our society to near-universal, global internet access. Most companies have begun to transform themselves digitally, leaving established business models and old business processes in the dust. Digital experience builders are turning to platforms that give them greater flexibility, better usability, better integrations, and faster innovation. The pace of change in the digital world has become dizzying. If we were to ignore these market forces, Drupal would be caught flat-footed and quickly become irrelevant.
But we didn't. I'm proud to see that we've responded to these market forces with Drupal 8, and delivered a robust, solid product that can be used to build next-generation websites, web applications and digital experiences. We've implemented a more modern development framework, reimagined the usability and authoring experience, and made technical improvements that will help us build for the multilingual, mobile and highly personalized experiences of the future. From how we model content and get content in and out the system, to how we build and assemble experiences on various devices, to how we scale that to millions and millions of pageviews -- it all got much better with Drupal 8.
I'm personally incredibly proud of this release. Drupal 8 is the result of years of hard work and innovation by thousands of people, with lots of attention to detail at every level. Congratulations to everyone who stepped up to contribute; this was only possible thanks to your persistence and tireless hard work. It took a lot of learning, our best thinking and our best people to create Drupal 8, and I'm very, very proud of what we have accomplished together.
For 15 years, I have believed that Open Source offers significant advantages to proprietary solutions through superior innovation. Today, I believe that more than ever. Drupal 8 is another key milestone in helping us win and doing what is best for an open web. Of course, our job is not done but now is the time to have fun and celebrate this monumental milestone. Tonight, we'll be hosting more than 200 parties around the world. (It's also my 37th birthday today and the release of Drupal 8 along with all those parties is pretty much the best present ever!)
In the previous tidbits we covered each language and translation capability one by one. The community translates the software interface on http://localize.drupal.org/ which you can customize with Interface translation. You can translate your local configuration and content with the Configuration translation and Content translation modules respectively. However, actual real life use cases are never clear cut like that. Content shows up with some shipped interface elements, local configuration and content. Menus contain elements from code, content and configuration. It is good to know how these pieces relate so you can translate every piece and know the right place to do it.
A couple of weeks ago a Chief Digital Officer (CDO) of one of the largest mobile telecommunications companies in the world asked me how a large organization such as hers should think about organizing itself to maintain control over costs and risks while still giving their global organization the freedom to innovate.
When it comes to managing their websites and the digital customer experience, they have over 50 different platforms managed by local teams in over 50 countries around the world. Her goal is to improve operational efficiency, improve brand consistency, and set governance by standardizing on a central platform. The challenge is that they have no global IT organization that can force the different teams to re-platform.
When asked if I had any insights from my work with other large global organizations, it occurred to me the ideal model she is seeking is very aligned to how an Open Source project like Drupal is managed (a subject I have more than a passing interest in).
Teams in different countries around the world often demand full control and decision-making authority over their own web properties and reject centralization. How then might someone in a large organization get the rest of the organization to rally behind a single platform and encourage individual teams and departments to innovate and share their innovations within the organization?
In a large Open Source project such as Drupal, contributions to the project can come from anywhere. On the one extreme there are corporate sponsors who cover the cost of full-time contributors, and on the other extreme there are individuals making substantial contributions from dorm rooms, basements, and cabins in the woods. Open Source's contribution models are incredible at coordinating, accepting, evaluating, and tracking the contributions from a community of contributors distributed around the world. Can that model be applied in the enterprise so contributions can come from every team or individual in the organization?
Reams have been written on how to incubate innovation, how to source it from the wisdom of the crowd, ignite it in the proverbial garage, or buy it from some entrepreneurial upstart. For large organizations like the mobile telecommunications company this CDO works at, innovation is about building, like Open Source, communities of practice where a culture of test-and-learn is encouraged, and sharing -- the essence of Open Source -- is rewarded. Consider the library of modules available to extend Drupal: there can be several contributed solutions for a particular need -- say embedding a carousel of images or adding commerce capability to a site -- all developed independently by different developers, but all available to the community to test, evaluate and implement. It may seem redundant (some would argue inefficient) to have multiple options available for the same task, but the fact that there are multiple solutions means more choices for people building experiences. It's inconceivable for a proprietary software company to fund five different teams to develop five different modules for the same task. They develop one and that is what their customers get. In a global innovation network, teams have the freedom to experiment and share their solutions with their peers -- but only if there is a structure and culture in place that rewards sharing them through a single platform.
Centers of Excellence (CoEs) are familiar models to share expertise and build alignment around a digital strategy in a decentralized, global enterprise. Some form multiple CoEs around shared utility functions such as advanced data analytics, search engine optimization, social media monitoring, and content management. CoEs have also grown to include Communities of Practice (CoP) where various "communities" of people doing similar things for different products or functions in multiple departments or locations, coalesce to share insights and techniques. In companies I've worked with that have standardized on Drupal, I've seen internal Drupal Camps and hackathons pop up much as they do within the Drupal community at-large.
My advice to her? Loosen control without losing control.
That may sound like a "have-your-cake-and-eat-it-too" cliche, but the Open Source model grew around models of crowd-sourced collaboration, constant and transparent communications, meritocracies, and a governance model that provides the platform and structure to keep the community pointed at a common goal. What would my guidance be for getting started?
- Start with a small pilot. Build that pilot around a team that includes the different functions of local country teams and bring them together into one working model where they can evangelize their peers and become the nucleus of a future CoE "community". Usually, one or more champions will arise from that.
- Establish a collaboration model where innovations can be shared back to the rest of the organization, and where each innovation can be analyzed and discussed. This is the essence of Drupal's model with Drupal.org acting as the clearing house for contributions coming in from everywhere in the world.
Drupal and Open Source were created to address a need, and from their small beginnings grew something large and powerful. It is a model any business can replicate within their organization. So take a page out of the Open Source playbook: innovate, collaborate and share. Governance and innovation can coexist, but for that to happen, you have to give up a measure of control and start to think outside the box.
Join us and the rest of the Austin community for a well-deserved par-tay! We have quite the party planned: including BBQ, a cake, a pinata and even a raffle.
Join us and the rest of the Austin community for a well-deserved par-tay! We have quite the party planned: including BBQ, a cake, a pinata and even a raffle.
Join us and the rest of the Austin community for a well-deserved par-tay! We have quite the party planned: including BBQ, a cake, a pinata and even a raffle.