 Good afternoon, everyone. Welcome to Lessons from WordPress Core. My name is Steve Perche, and I'm joined as well here by Andrew Taylor. We both work at Pantheon. If you stop by our booth, you know that Pantheon is a website management platform for Drupal, and also WordPress. We cover both use cases. A little bit of background on myself. I'm an agency and community engineer at Pantheon, so I come from the background of building Drupal sites with agencies. I basically worked at Palantir.net. Before that, I built a couple WordPress sites in my day. That's how I got started as a web developer back in 2006, 2007, making a couple of WordPress sites. After that, I've switched pretty hard to Drupal, and that's been my focus up until the past couple of months, now working at Pantheon, looking into both worlds. So you can find me on the internet as Steve Vector on Twitter, Drupal.org, GitHub. You can also find me as Drupal Haikus on Twitter. So I've been very focused on the Drupal community, and my co-worker Andrew here, more on the WordPress side. Yeah, I'm also an agency and community engineer at Pantheon, like Steve, and I come from more of a WordPress background. I've been with Pantheon since January, and before that, I was working on enterprise sites with WordPress, such as amc.com, and really kind of learning the lessons from WordPress, the good and the bad, both with code and user experience, and we're going to talk about some of those today. I'm also on GitHub and Twitter at atailrme, if you want to look me up there. So why should we be talking about WordPress now? My own perception, up until a couple of months ago, was that the Drupal community was far ahead of the WordPress community in every respect. Our code is now object-oriented. We've got a REST API. The WordPress that I remembered was a PHP4-oriented system, but now as I look to the WordPress community, I see some lessons that we can learn. Now that we are past Drupal 8.0.0, we're at Drupal 8.1.1. So over the life of Drupal 8, the idea is to maintain backwards compatibility within the Drupal 8 lifecycle. We can be adding new large features every six months with these point releases. So this is something that the WordPress community has been doing for a number of years. WordPress has been maintaining backwards compatibility pretty much since the beginning. They've been on a release schedule of every four months. For a number of years now, they've developed a number of systems for maintaining that release cycle, for maintaining the people, the core team, who makes that all possible. So in this session today, we'll be talking about that WordPress release cycle, that every four month release cycle, how new features get into WordPress core, the role of the release lead in WordPress core, managing commit access. We'll be talking about two of the biggest players in the open source ecosystem, Acquia and Automatic. We'll be talking about the Calypso project, which is an alternative administrative user interface for WordPress itself. It's written with ReactJS. And we're going to talk about backwards compatibility and the philosophy of user trust that is so central to WordPress development. As a frame of reference, as a background for what the space looks like with WordPress and Drupal, according to BuiltWith.com, across the entire Internet, for any website using a CMS, WordPress is 51% of that market, and Drupal is too small to see at 2%. 47% is anything else. Today we're just talking about WordPress and Drupal. As we look at larger sites, more heavily trafficked sites, we can see that Drupal is a bigger player in this space, at 9% compared to 39%. And that partially confirmed my incoming assumption that Drupal is better suited towards more complex websites, though as I've learned more about WordPress, I can see it's more than just a blogging tool. It's more than just a blogging tool than I remembered from 2006 and 2007. So now I'm going to hand it off to Andrew, who will go more in depth on the WordPress release cycle. So the WordPress release cycle has four phases. The first phase is a planning phase, and this is where they decide kind of which features are going to be pursued in the lease, who's leading each feature in different parts of WordPress, securing those team leads, managing those people, and actually the first phase of development, the first phase planning takes just as long as the second phase development. So they spend as much time planning and thinking out and realizing how they're going to achieve these goals as they do actually doing the work. And then we're going to talk about beta and release candidate a little bit more. Beta is basically no more new features coming in. We're just going to squash existing bugs that are there. And when we get to a release candidate, those little minor bugs we're not going to worry about so much. We're only worried about blockers and things that are going to stop WordPress from getting out the door. And then after launch, usually within two or three weeks, there's a point release that goes back and captures those small bugs that weren't taken care of in the release candidate. WordPress also has this concept of features as plugins. This is where WordPress plugins are extra pieces of software you can install and kind of opt into on top of the core software similar to Drupal modules. And WordPress keeps them features separated in plugins instead of being in core so that they can be isolated and feature development can continue without hindering core and keeping that base set of software stable for developers and users. And it allows things to be tested, refined, polished. People who are using these features can opt into them, give feedback, it kind of lets features go through a beta phase and a little bit of a honeymoon period before WordPress decides that they're actually ready to be considered as a release candidate. And one thing they found that going back to that planning is that successful featured plugins are ones that follow that same clear thought out purpose as WordPress core itself. So we said initially WordPress in the first phase is just as long as development with the planning cycle and that is also true of featured plugins. These are often months of planning and deciding which direction we're going to go, who's going to lead these teams, who's going to build these features, what does this API going to look like, and then following through with that execution can take many more months before it's actually ready to come into core. WordPress.org has lots of features to track this progress. This is showing the current featured plugins that are being worked on, who's the lead of that project. WordPress has Slack channels where you can go in for weekly meetings and things like that. And then these are the features that have already landed. So if you want to go back and, oh, that cool new feature that just came out, I wonder who worked on that project. Then you can go in and take a look at that. And also some inactive things. These might be features that kind of got to the planning phase and the team decided that they're not worth coming into core and they're kind of on hold. If someone wants to come back and revisit those, they can pick up those initiatives. And as we're going through this and WordPress is in these planning phases with not only core, but with these incoming features, and we have all these teams of existing features, new features, WordPress kind of had to decide how we're going to handle managing those people, facilitating communication. And that's where this idea of a release lead role kind of evolved. It started in 2012 with an announcement post. We can see here is our whiteboard of all the teams and who's going to wrangle all those. And so the release lead role is pretty much a technical project manager for WordPress. It's somebody who's going to facilitate that communication, make sure that, okay, we don't have one feature that's ready to go and three more that are lagging behind and are going to mess up our release cycle. If we need to allocate resources and have somebody hop off one thing onto another and keep everything up to speed, keep everyone informed. They're often coordinating WordPress is really transparent with what's going on in core. So there's, on WordPress.org, there's a blog and every couple of weeks there's a summary of what's going on in core this week, what are we working on, and making that really visible to users and contributors. This started with WordPress 3.5, which was a big overhaul to the media manager, and the lead was Andrew Nason, and there's a co-lead Darrell Cooper Smith as well, and they kind of took this release lead role, and the intent was to have them be kind of facilitators and product managers and not so much like heroic coders, but it kind of didn't get off to a great start. They spent 80 to 100 hours a week, and they actually iterated over a feature 72 hours before release. So this was kind of the way things were going before the release lead role matured. But since then, it's come a long way, and it really has grown into that project management type role that it was designed to be. It also allows new contributors coming in, WordPress cycles release leads with every release, so new contributors can come in, get more involved with core development, and people can kind of see it into their work. If you're leading release, it's very taxing. It's a lot of work to organize all that and get through that release. So people can say, okay, we have a targeted date. We know we're going to hit that because we have a four-month release cycle, and I know I'm going to be passing this off, so I can go plan the vacation with my family or whatever they want to do. In WordPress, in addition to the release lead, has a core leadership team. These are the founders, the core contributors, the people who are involved with the WordPress project, not just over a single release, but over a period of WordPress' lifecycle, and they affect decisions that kind of, which way is the ship being pointed? Where is WordPress going to go? Which of these features are we going to pursue? Kind of those high-level decisions and some architectural decisions about the code as well. And one good distinction I want to point out here is that the release lead is responsible for what happens in their release, but ultimately they're not in charge of what goes into the software. If you have that final authority to say, I think this feature is ready to go, it should come in. If there's other core contributors, other people look at it and say, well, did you think of this? What about this use case? We don't think it's ready to go. Then everyone kind of goes back to the drawing board and reevaluates those, and maybe it doesn't come out for another release or two. A good example of this is the WordPress REST API. It came out with the infrastructure similar to the Drupal API, the default endpoints WordPress has pages and posts which are similar to articles in Drupal don't exist. You have the infrastructure, but you don't get those default endpoints out of the box. You kind of have to build them. And so WordPress has been working on this, and that's one of the features that some people feel are ready to be merged in, and some people feel, well, we need more coverage. We need to cover more use cases like user permissions and things like this to get a more complete coverage before it's merged in, and those are things that the team is working out before they actually come into core. In WordPress.org, we talked a little bit about how they track featured plugins. They also track who's maintaining different components and different features that have already landed within WordPress, what the activity is like, and this goes back to that transparency within the process of development for not only the end user, but other contributors as well. WordPress kind of has a unique way to manage commit access. We talked about the release lead cycling and getting new people involved, and so now we're going to talk about kind of how those people progress through the stages to become a WordPress core committer. And it starts with being a contributing developer. This is someone who's submitting patches. Maybe they find a place in the software where they're really interested and they start contributing more and more to that release over release, and at that point they can become a guest committer. They keep doing well contributing to this section of the software. We're going to give you guest commit access for maybe the next couple of releases. You can go in and continue improving that specific feature. And at that point, if someone is improving that, the guest commit access goes really well and they're also improving other areas and getting more involved with the community, then they can become a full-time core developer with permanent commit access so that guest's label is dropped. This is the lead developer. These are people who have been core contributors with permanent commit access for a long time and kind of embody the values and direction and they're more involved with the community than just the code and kind of taking it to that next level where they can be involved with steering the ship and not just doing the grunt work. So my hope is that while we as Drupal developers are hearing this description of WordPress is that we're thinking, this all sounds very familiar because we have a lot of similar structures. I was seeing some smiling recognition as we hit some of these points. Our core team in Drupal 8 looks somewhat similar to what we just heard described for the world of WordPress. As I've dug more and more into our own governance models, I see that we have seven people with commit access to Drupal 8 right now, each with a specific designation, each with a role indicating the types of decisions that these people make. So we have some people designated as framework managers making framework level decisions. Some people designated as product managers making product level more end user experience level decisions. We have release managers in Catch and XJM who are operating in a role that I think is directly analogous to this release lead role that we just heard described for WordPress. With every single release a new person is coming into that role and managing that four month period. I want to thank Catch and XJM for helping us get to our release dates exactly on time. That was it, that was, oh did I just lose Oh Oh gosh XJM and Catch can get Drupal 8 out on time and I can't even stay connected to a projector. Gosh So yes, round of applause for them because that was a huge achievement. For years we had been saying it's ready when it's ready. It'll come out when it's ready. It's a huge increase in our stability and our ability to plan as a community when we can say Drupal 8.1.0 is going to come out on April 20th to be able to say that five, six months in advance and hit that. That is a huge help to the community. It's a help for companies like Pantheon that have to update or make updates available to help for agencies responsible for any number of websites where security updates have to be applied. The more we can be specific about our schedule the better off we'll be. So we have a Drupal.org project called Drupal Community Governance. Raise your hand if you knew that this project existed on Drupal.org. So a fraction of the room. So this is a project like Ctools is a project on Drupal.org. It has an UQ, it has a repo. The repo though doesn't contain PHP code, it contains pros documentation describing in really good detail the core team, the core processes, both for our code level and both our community level it describes how Drupal.org itself is maintained. So again we've been able to develop a much more thorough release schedule in Drupal 8. Thanks to this higher level of organization that we've been adopting. A lot of this work is here to meet a goal that Dries laid out a couple months ago in a blog post of always be shippable. The idea is that our main line of development the branch that we're committing to should always be in a shippable state. Yes we are planning release dates well in advance so we shouldn't have to release 8.2 at the drop of a hat but the idea is we shouldn't be thinking oh there are all these unfinished works in 8.2 and 8.2.0 can't come out until those problems are fixed. If we're always shippable then we don't have or we have less of the last minute stress. One of the reasons that this was difficult is because in the Drupal 8.0 we had a lot of overlapping initiatives each with their own schedules each with different sets of priorities and different sets of long-term milestones that were difficult to line up. So we had the configuration management system initiative. We had the multilingual initiative views in core each with its own set of milestones and getting those to line up to a point where we could say 8.0.0 is done and ready to go was an incredibly difficult task. So in the last week or two we have a new road maps page that this I think is a direct analog to what we saw in that WordPress world of an overview of Drupal core in progress. So thanks to XJM and WebChick we have a new page www.drupal.org slash core slash roadmap. I recommend everyone check it out. This I think will become the central place to find out at a high level what initiatives are being worked on for Drupal core. Where are our priorities? This is a much better overview of what's happening in core than an issue queue with thousands and thousands of issues. So let's go ahead and get involved in Drupal core because we'll be able to see at a high level what is the focus right now. So we can see that we already have community plans under review. So yesterday in the keynote we heard from Dries this idea that we should have separate stages for these initiatives. We should have stages where they are in a planning phase stages where they are being proposed and under some kind of formal review that's still being defined what happens in each stage so that we don't fall into the same bike sheds over and over again in a less well-defined process. So I recommend everyone check out Gabor's blog post on being an initiative lead because this spelled out in wonderful detail how you can get big changes done in Drupal core. So he summed it up being an initiative lead is the responsibility of setting a shared goal showing the community that the goal is achievable and helping people get there. That's the role that Drupal and really any open source project needs. Making it clear what those goals are and helping people get there. So one of the ways we're doing that on the code level is with experimental modules. I think this is probably our closest analog to that feature plugin idea in WordPress. The idea that we can encapsulate a lot of our functionality into a single module. So big pipe is one of the newest ones here as of 8.1.0. This is a module that's in an experimental phase and we have documentation saying exactly what experimental means. So this is a module that may be changing more actively than other modules in core. It might break backwards compatibility. Migrate for instance between 8.0 and 8.1 changed some of its interfaces and it was able to do so. It was able to keep iterating because it was designated as an experimental module. So catch writing in that same 2014 discussion that Gabor was writing in around the way we organized our work in core. Emphasize that what's needed most is facilitation and communication. Not individuals with vested authority telling one another what to do. So this is something that I think we've seen be successful in the WordPress community. That release lead role doesn't have the authority to simply say, oh I'm in charge for this. So I'm deciding that this feature plugin is going in now. That's not how open source communities operate. The leaders that we have are most successful when they're able to rally a group of people to a common cause. Get facilitation and communication. I was talking with Larry about this earlier this week and he emphasized that for an initiative to be successful it probably needs one blog post a week just saying what's happening. There are multiple forms that we can take. It could be a blog post, it could be a docs page, but just to keep the community as a whole abreast of what's happening you need constant communication. So in Drupal 8 we have new tools as a community for doing this kind of facilitation and communication. This is the contrib con bond board that Matt Glomman wrote. So this is reading information off of Drupal.org's REST API and putting it into a con bond board. I raised this example because I think these tools we build as a community when we aren't constantly rewriting our core software. When we're rewriting core every five years we're probably not going to get to these brand new types of tools that can be built on top of a stable base. By having a stable base now in Drupal 8 that we're not going to break immediately we can build all kinds of exciting new tools that help us facilitate and communicate even better. This one is in particular helping us track just the port status of modules going from 7 to 8 and you can use this for really any project on Drupal.org. One quote I've been referencing a lot lately is Conway's law. The idea that organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. One way we've seen this in Drupal core is that our data structures got a lot more specific a lot more organized when our teams started getting a lot more organized. The code in Drupal 8 is much more organized than the code in Drupal 7. I think that's a direct result of the people working on Drupal 8 being more organized as a whole than the organization structures at the people level in Drupal 7. Two other big parts of these communities automatic and Acquia. As background automatic is a company started by Matt Drupal and one of the co-founders in the project lead of WordPress. So automatic is a company that owns WordPress.com and a number of other properties in the WordPress space. WordPress.com has consumer oriented hosting, a free tier, paid tiers VIP hosting. WordPress.org is more the analog to Drupal.org. It's where the plugins live, themes live there, the community discussions happen on the .org rather than the .com. So the WordPress foundation, a nonprofit organization that's directly analogous to the WordPress association. So some more points of comparison. Matt Mullenweig seems to be a more actively involved person who puts his opinions forth more commonly. That seems to manifest both in automatic and in WordPress itself. And that can be a double-edged sword. Sometimes it's great to have a leader who says this is the direction we're going and that's it. Sometimes it can be difficult for the community. WordPress recently had some controversy over the REST API when Matt made a decision that he was going to hold merging part of the REST API into core. Dries seems to be of the personality where he prefers community consensus to build as much as possible before forcing his own opinion. So both companies as well have a lot of support and have all the pressures that come with it. They've both acquired businesses in their ecosystem. They've both sponsored significant amounts of core development. And I think for both communities that was a source of unease at least at first. There was some apprehension certainly in the Drupal community of what does it mean to have one company sponsoring so much core development. I think in both communities a couple of times it wouldn't be as stable as it is without the sponsorship of Acquia. We wouldn't have as much of contrib ported to Drupal 8 without the sponsorship of Acquia. The same dynamic is present in automatic and I think on the whole it's a hugely positive influence. So they both have paid hosted sites. You can get a site on WordPress.com. This is somewhat analogous to Drupal Gardens. I think WordPress.com is the bigger force to be more of a commentary on WordPress's suitability to the end user market. And they both offer high-end hosting in the form of WordPress VIP and the Acquia cloud. So the reason I'm bringing this up is because again I'm hoping that this sounds familiar. We've been hearing in the Drupal community that we should get off the island. Larry wrote that blog post about three or four years ago now encouraging us to get off the island to visit Symphony Island that a composer can take us to. Well, we have a twin island, an island that's right next to us that has all the same pressures that we do, that has people with very similar backgrounds to ours serving clientele, very similar to ours. They've gotten to a couple problems before we got to them. We've gotten to some problem spaces before WordPress. They could learn from our great Git migration. They're still using SVN on WordPress.org and actively talking about what can we get to Git. So I hope we're able to share some more with them as well. One area that they've gotten to ahead of us is an alternative administrative interface built entirely in JavaScript. That's something Andrew's going to talk about right now. So the Calypso project was started by Automatic as a way to have a decoupled admin interface. The existing WordPress interface is largely PHP. It's familiar to users but it's a little bit of that older style, right? This one's built with React so it's that single-page application that's fast, that's quick, it's responsive, it has the nice animations, all those things that a traditional kind of PHP page doesn't have. They also wrapped it up in a desktop app. So if you're on OSX or Linux or Windows and it's even a web app on WordPress.com you can get up and running and edit your content there easily. The kind of kicker here though is the WordPress.com API and not the REST API built into WordPress itself. This distinction has kind of had some things where it's blocking adoption. You can opt into it with an extra plugin and use it with your self-posted version of WordPress instead of the WordPress.com sites but you can only use it with the standard content types. WordPress has pages and posts so imagine if you have an e-commerce store and you can't edit your products or you have a food blog and you can't enter a new recipe. That kind of is a blocker. So there's a lot of things there but Automatic said like this is possible, we're not adopting a JavaScript framework into WordPress core because if you want an alternative admin interface you can just go build it and they did. They took the first step and said we're going to show you this is possible if you want to extend it and add those custom content types then you can do it. It's completely open source. Here's some pictures of the interface we talked about. It's definitely a much nicer interface than the standard kind of thing. It's more web-appy, has that modern fresh feel. As I said it's open source, the components are there so if you're looking to do something similar in Drupal go check out this project, grab those React components even if you're not doing something with Drupal you want to build a React project on the side go pull these out. There's accordions and bulk select and very generic things and projects. I would love it if as part of the discussion about components in Drupal if we could see a proof of concept I think in some of the discussions I've heard or been a part of there's an assumption that we would have to go all the way or we would have to rewrite Drupal all over again in JavaScript in order to get components and I don't think we have to. WordPress has shown us you can write an alternative administrative user interface in JavaScript and we're talking to a system that's still very much in the PHP4 world. I think we can do it with Drupal 8. I'd love to see someone just make a React component that edited the simplest possible config entity so an image style or something else in core that doesn't have as much complexity as say I don't know a views exportable. We don't need to keep this assumption that breaking backwards compatibility is the only way to get new things and that leads us into a discussion of user trust which is central to the reason WordPress maintains backwards compatibility as much as it does. This is a quote from one of the WordPress lead developers that users must be able to trust the software they use and this is a very big part of WordPress's values and its cores and why it's maintained backwards compatibility for so long. Some of the reasons WordPress users trust the software is that there are consistent releases for years and years and years I know every four months I'm going to have new features. I have something to look forward to. We talked about transparency earlier or it's not waiting years and years for a new release. Automatic updates that work WordPress automatic updates when they're enabled have a 0.00 4% failure rate which is really, really awesome. That means pretty much everyone who clicks that button is going to have things update and not have to worry about it. Then backwards compatibility which we're going to get into a little bit more and then WordPress really places an emphasis around the content. It's not so much about us as developers as a developer WordPress can be tougher to work with but we talk a little bit about how the experience is more for the people who are actually going to be using the software after you build it. Keeping their content safe, having autosaves, having drafts and having that user trust no matter what happens their content they worked on is going to still be there. And don't burden users. This goes for the end users that it might be frustrating to have to update and work through new things or I have to go get my site rebuilt. Things like that. Or developers we're working on a project and we want to go from Drupal 7 to Drupal 8. That's a big undertaking. With WordPress keeping backwards compatibility it's not that big burden on the core team. The idea is that the core team is efficient and they know what's going on with core and they can squash these bugs. If they take an extra week to squash a bug that affects 1% of WordPress that's thousands and thousands of sites. And that's a big burden for them as developers. And in many cases keeping backwards compatibility is not a big burden to the core team. The idea is that the core team that's thousands and thousands of sites. And thousands and thousands of users that they're saving that headache. Thousands and thousands of developers that aren't as proficient as core developers who aren't going to be able to go in and solve it in a week. Maybe it takes them three weeks. And they're saving all that time for the people in the community. And so it's worth it for them to pick up that extra slack as the core team. And WordPress does break backwards compatibility. We're not saying it never happens but when we do do it carefully and deliberately. A great example of this is the WordPress 3.5 media manager. The media interface went from being PHP to a complete overhaul with JavaScript. That vastly improved the user experience, faster media handling. New APIs to empower developers and kind of let them do greater things with media. But they did it in a way that didn't need to break anything. Going completely from PHP based system to a JavaScript based system on the front end. Without breaking things. And this is a screenshot of what the old interface looked like. You'll notice kind of at the top there's some tabs there. From computer, from URL, media library. Developers could opt in with the filter to add more tabs for custom content. If they're developing a plugin or a feature. So they could add a tab to do some new functionality, have some text, have some extra features there. And it kind of looked like this. This is truncated a little bit for readability. But there's basically an array that had the defaults. And there's a filter where they could hook into that and kind of add extras as they wanted to. And then here's the same code after the 3.5 update. There's a lot of goodies. A lot of that is being done in JavaScript. But this filter is still there. And if people still use it and they add items to that array, even though WordPress now doing this interface in JavaScript isn't reading it, it doesn't use those as the default values anymore, if people add them well it pulls that in and it just tax them on at the bottom of the JavaScript interface. And it actually when you click on those will load an iframe and give you the old PHP experience with the text and the functionality that that plugin developer had before someone ran an update. And they had to do no work. The plugin developer didn't have to go learn these new JavaScript APIs. They didn't have to go in to make it compatible. It just worked. And backwards compatibility has been a huge, huge thing towards WordPress growth. We talked about that user trust, that developer trust, and we saw kind of at the beginning WordPress's market share and I think those are really those core values driving the adoption rate. And I think that quote that we just saw is a good example of a key difference in attitude between WordPress and Drupal. So we've been highlighting a lot here the similarities. I think this is a key philosophical difference. So Dries writing in 2006 wrote that the ability to constantly innovate is of higher importance than breaking or then preserving backwards compatibility I should say. So in 2006 in this blog post about backwards compatibility, Dries is thinking of backwards compatibility as baggage that we would have to be dragging around. And he didn't want to drag around this baggage. He was concerned about being able to keep up with the latest and greatest in the entire web and that's the philosophy that Drupal carried forward ever since. Rewriting Drupal from not from scratch, but rewriting Drupal significantly, Drupal 6 before Drupal 5 or after Drupal 5, Drupal 8 is probably the biggest rewrite that we've had. And we heard again from Dries yesterday, so 10 years after this blog post that he's hoping that this rewriting will increase our reach. We saw that diagram showing the reach that Dries is hoping that Drupal will get and breaking backwards compatibility as we did between 7 and 8. We hope will increase our reach. WordPress shows us that it's not quite that simple. WordPress has increased its reach to 51% of all sites using any kind of CMS because they never leave anyone behind or they very rarely leave anyone behind. If we were to change that diagram to what percentage of sites are running the latest version of Drupal or WordPress, the discrepancy would be even bigger because any WordPress site built really in the last 10 or 15 years can just keep upgrading all the way to the latest version of WordPress core with no problem. That's not true of Drupal. So why has Drupal broken backwards compatibility? Again the idea is we're freeing innovation and in Drupal 8 we have a dependency section container. We have a new routing layer. We have CCK, a rich text editor in core. These are all types of innovation. For some of our end users, the innovation that we have in Drupal 8 isn't necessarily all that interesting. For the content author, a new routing layer may not be of particular interest. A CCK rich text editor in core is, but we didn't necessarily need to do the huge level of overhaul that we did in Drupal 8 just to get a rich text editor into core. The idea is that by breaking backwards compatibility we move faster. To support this point, Larry, I think I've heard from you that with Drupal 8 we made 10 years worth of progress in five years. So by that measurement, yes, we have been moving faster, but at the same time Drupal 6 after Drupal 5 took longer. Drupal 7 took longer than Drupal 6. Drupal 8 took longer than Drupal 7. By that measurement we've been moving slower because we've been breaking backwards compatibility. Reducing the support burden on contributors. We've been reducing the support burden of maintaining Drupal 5 and Drupal 6 because we simply start ignoring those sites at a certain point and say we're no longer going to provide security updates. We're no longer going to provide support. That's one way to reduce the support burden, but it certainly reduces our reach sites from our awareness. So we've gotten some of these benefits, but I don't think we've gotten all of them. Looking more specifically at, say, the REST API. So both Drupal 8.0.0 and WordPress 4.4 came out within about a month of one another. They both added a partial REST API and they did so in completely different ways. So what we heard at the beginning of the Drupal 8 cycle was that in order to get a clean REST API we should break backwards compatibility. We should add symphony components. We should introduce this object-oriented architecture that will make a REST API much better, much easier to maintain long-term. WordPress did not do that and they still got to a REST API at the same time. So I think it's worth asking what do we really mean? So Larry, writing in 2012 around the time that this REST API was getting architected, emphasized that backwards compatibility is something that should be designed for. That you can't just have backwards compatibility. And to a certain degree he's right that backwards compatibility will be a lot easier to maintain in Drupal 8.0 than in WordPress. I don't think anyone in the room would want to inherit the WordPress code base and say good luck maintaining backwards compatibility. It's really hard but not impossible. I'm still trying to figure out just exactly how they do it because it's difficult and yet they just have done it. So at this point I may be preaching to the choir because we are in Drupal 8.0. We are maintaining backwards compatibility. Within 8.0 we're adding new features. We may be getting a media initiative. We may be getting a content workflow initiative. That's all very exciting but I think the attitude might still be there that maintaining backwards compatibility is stifling our innovation and I just want to challenge that initiative or that attitude with what we see in WordPress. It's very easy to point to the features that we did get by breaking backwards compatibility. We can say we have the dependency injection container. We have this object-oriented architecture because we broke backwards compatibility. We can't know for certain what features we don't have because of the instable base we had. Maybe we would have had media in core by now if we had just stayed on the Drupal 7.0 architecture. I don't know. That may not be better but it's worth asking what benefit do we actually get by breaking backwards compatibility. As we approach Drupal 9 eventually we have plenty of functions all over Drupal core marked as to be removed when we get to Drupal 9. We're supposed to remove entity load for example when we get to Drupal 9. When we remove entity load any custom site or any custom code written with that entity load function is going to break and it's worth asking how much benefit do we get from removing entity load. We're going to break sites. We're going to break user trust when that removal happens. We need to ask ourselves what benefit do we really get. Is there a way we can have a middle ground? Maybe a deprecated module in core that maintains deprecated functions. Maybe a contrib module that maintains these functions. I've heard this idea before and it's worth considering. So to wrap up with some key lessons here. I just wanted to talk about we always want to make sure we talk about the who, the what, the when, the where, the why of core work and talking again about that visibility and transparency. Setting those teams up, planning things, making sure that there are those constant blog posts that people are informed that they know what's coming and planning things long term and syncing up those teams and their schedules with the release schedule so things move smoothly. So people can avoid burnout. Wordpress rotates those release leads because if you're a core maintainer in Drupal and you've been doing this for maybe a decade, at some point it takes a toll and there's always more and more contributors coming into a project and you need to take advantage of that and kind of bring their knowledge and their skills in. As we keep getting off the island, let's visit our twin. We don't have the bridges built. Wordpress itself is just figuring out what to do with composer. I think we got to composer a little bit before Wordpress so we can share that knowledge with them when we go and visit our twin island of Wordpress. And then backwards compatibility thinking of it as an asset. Going back to that user trust and that developer trust where we talked about people being able as an agency to have those maintenance contracts and they're really easy to fulfill because I can just run the update and say okay I'm going to have this maintenance agreement and it's going to be quick and easy and when someone updates the next time I log in, I don't have to worry about it. Yeah so we can make big changes without breaking backwards compatibility and we're already seeing that. I think we should keep asking ourselves how much can we do without breaking up this wonderful stable base we have now with Drupal 8. So if you're interested, please do check out our slides. We've linked to some documenting the way Wordpress does things, their page on feature plugins and we have a bunch of old and new pages on Drupal.org explaining our governance model and this new roadmap page is something I definitely recommend everyone check out. So please join us at the sprints. I'll be there. Anyone interested in talking about Wordpress can come find us and we'll be there to chat. Please do raid our session. Thanks everyone and we'd love to hear some questions. Thank you for working now. So you discussed the I'm Jess, I'm XJM on Drupal.org, I'm one of the Drupal 8 Release Managers. You discussed the structure of both Wordpress's core governance team and Drupal's core governance team and then after that compared the structure of automatic and Acquia. I just wanted to make one note that I don't think was necessarily clear in case people were accidentally relating those two things. So Drees' relationship to Acquia versus Matt's automatic is interesting, but in terms of the core committers, I should note that not all of the core committers work for Acquia. Of the core committer team we have Drees plus three committers who work for Acquia and then there are three other committers who work for different companies who are also receiving sponsored development time. So shout out to 3rd and Grove Chapter 3 and Digital Echidna for providing at least some if not all of those employees, to commit to core. And then the question related to that is, do you have information on other than Matt, on the other people who are in that similar sort of architectural planning governance role in Wordpress what the sort of distribution of their employment is like? Yeah, so in Wordpress there was a survey, I think it was three or four months ago now about core contributors. These are people with commit access, whether it's that guest, that full time, different permissions and over 60% were not employed by automatic. They were either individuals committing on their own time, sponsored by another company or things like that. If you'd like to reach out to me later, I can find the link to that and share it with you that has the entire breakdown. That would be really interesting I think because over 60% still sounds like almost 40% work for automatic. So that's actually compared to us a huge chunk compared to all of the core contributors. Sounds very interesting. And then I just also wanted to add a little bit more depth around backward compatibility to sort of help facilitate future discussion around it. The core committer team is committed fun to backward compatibility in Drupal 8 and we are committed to numerous minor releases over the course of several years that all retain backward compatibility. We have not opened Drupal 9 yet for a comparison. Drupal 8 was opened just a few months after Drupal 7 and started breaking backward compatibility basically right away. We hope to not open Drupal 9 for several years yet essentially. So we will have minor releases we can have everyone form a queue down here that's loud. In terms of deprecating code and what the costs are for keeping that deprecated a code around versus removing it for the most part we are now retaining code that's currently deprecated until 9 opens which I said isn't going to happen and it will remain in Drupal 8 forever as long as Drupal 8 is supported which is going to be numerous years even after the release of Drupal 9 but there is a cost associated with keeping deprecated code around which is that you have now two separate code paths that you need to maintain to do the same things and if you've converted to a new API for something you retain the deprecated API in core nothing in core exercises that API maybe its test coverage is not even complete it's very very easy to break that deprecated code while still while not breaking the the new API for it and so you end up in a situation where even though the deprecated code is there and supported it ends up breaking any way introducing bugs for a subset of sites so there is a there is a potential for twice as many bugs so that is the cost with it but that said we're not going to be removing any code from Drupal 8 for a very very long time so I think there's a balance there yeah thanks for sharing that and one anecdote I heard at a WordPress core session was that occasionally in order to test if they can sensibly remove something is occasionally they'll have a release candidate specifically introduce an error in a deprecated chunk of code just to see if anyone reports the breakage so they'll intentionally break the deprecated code just to see if anyone reports my photo gallery stop working or something oh yeah go ahead thanks for that it was helpful it was actually helpful to a talk that I gave that was kind of trying to look at the whole CMS landscape earlier on Tuesday my question is is there any is there any meaningful serious attempt for leadership in either WordPress and Drupal 2 come together on certain things my assessment is for the most part communities developers within I'm not a WordPress guy Drupal guy or gal of course is there any thought that that might come to a conference that could start I don't know something that this is us hoping to start building those bridges so we're here doing lessons from WordPress core we hope to submit lessons from Drupal core to WordPress conventions I'm just speaking from my own experience up until a few months ago I was entirely Drupal focused and thought I don't need to know anything about WordPress so for myself that attitude was entrenched pretty deep so I hope we can start building those bridges across because I think there are things to be learned yeah I think that's hard because it's hard to find fun so there are events like that so there's community open source community events where people get together from different communities and share their knowledge so you know how so not specifically you going to a different product event or vice versa but I think it's hard to find funding and like find like there's it's a very long view for a company to say that I'm so invested in something that I can look for a year for a value years out to send you there and just like something else well I would say maybe a counter to that is there's a lot of agencies that are mixed you're primarily a Drupal agency and you have a new client come in and they really want WordPress because their content author whatever they like the interface and their personal blog is on it something like that then kind of embrace that and take it on and maybe don't do it for an enterprise project right the Drupal is better suited for don't do it for the thing that you know is super complex but start out of smaller sites start with a few start go to a local WordPress meetup talk to some of those developers and just start building that communication and if you have it coming from a client you're able to meet their needs and they're happy and also get a little bit of that adoption and start building that bridge yourself then it's a win-win I think we could also see collaboration around specific areas I'm just imagining putting 10 Drupal core contributors and 10 WordPress core developers in a room and saying collaborate please like I don't think that would do any good but if we said something like responsive images discuss I think that could trigger a more fruitful conversation so when I was at word camp US basically the Drupal kind of WordPress they were talking about well we're 25% of the internet if we decide how we want to do responsive images then maybe some browsers will start following us I think we could look to collaborate on specific topics like that and say okay how are you doing responsive images let's do responsive images in the same way I'm just pulling that as a arbitrary example I think if we could find specific areas of interest AMP for instance as another I think that would start building those bridges more concretely even if they are narrow bridges around specific topic areas yeah so just to repeat from the for the recording there are WordPress camps that specifically have tracks like this like the horizons track that are geared towards learning about other communities so that's a good lead up to what I wanted to say so I'm actually in six weeks I'm presenting at word camp Europe which is there Drupal in Europe and about the process that we used in the multilingual initiative with Drupal 8 and how we involve the thousand or so people in that and how we made that successful so I'm actually needing to leave Drupal dev days early to be able to go to WordPress events so that's kind of interesting is it first for me but I look forward to that and share some know how and I'm sure we can learn a lot from them as well one little note I'm not sure if I've seen all the names of the committers on your slides but I think you miss Jennifer Hodgdon did you you missed it so it's actually eight core committers I copied from the maintainers .txt but thanks for the clarification on the places to build bridges front I also want to plug for PHP world it's a conference in November in DC that's set up very deliberately for exactly this kind of cross-pollination they've got a Drupal track a WordPress track a symphony track a Zen track a Laravel track that they actively want to have be a place where that kind of collaboration can happen so submit sessions to that and attend it if you can it's a good conference also WordPress is not a member of the framework interoperability group unfortunately but it's again the same kind of goal of cross-pollinating with whoever we can that's another area that backward compatibility is an interesting topic because it's a lot more complicated than people give it credit for you touched on this as well I've talked about this before backward compatibility is not a thing you do or don't do it is a very much sliding scale that you have to plan for some features are a lot easier to do in a backward compatible way we could redesign media browser no APIs or extremely few totally doable probably will happen within the Drupal 8 cycle we could make vast improvements to the views UI and not really break backward compatibility the cache tag support in Drupal 8 that enables big pipe and all of the really really robust caching I have no idea how that could have been done without removing globals as an API so that's cannot be done otherwise also different code bases that can support BC or not it's something forward compatibility is something you need before you have backward compatibility Drupal 8 I think we're already seen with 8.1 is a more forward compatible version than Drupal 7 ever could have been and that's why we're able to have 8.1, 8.2, 8.3 so in many ways the big break of Drupal 8 was so that we don't need that big break in the future so that we can have a base that can evolve in a smoother fashion I can't speak to WordPress's internals for how they handle that I haven't dug into them but that forward compatibility is I'd say we almost want to talk about forward compatibility more than backward compatibility because you have to plan for it to be something that you're setting yourself up for later Larry can we look forward to a forward compatibility blog post on Garfield Tech soon? I think you already quoted from the run I posted 2 years ago alright thanks alright well thanks everyone we're at time