 out by making room for our neighbors. If you have an empty seat next to you, do you wanna just like maybe push into the middle a little bit? Can you do that now? Everyone, come on, stand up. It's a good exercise. It's all the exercise you're gonna get this week. Let's go. Stand up, move into the middle. Excellent. Yeah, well we're making room at the ends for all the people coming in. Excellent, thank you guys for doing that. Brilliant, well welcome to DrupalCon Barcelona. My name is Holly Ross. I'm the executive director of the Drupal Association, and I am really thrilled to be here. If we could have our slides, that would be awesome. Ta-da, all right. So welcome back to Barcelona is what I should say. How many of you were here in 2007? Lots of you, excellent, good. Well when we were here in 2007, there were about 400 people at DrupalCon Barcelona. And in 2015 there's about 2,000 of you. It's a very big change. But it's not just the cons that have changed in all of that time in the last eight years. And I wanted to hear about all the things that have been going on in Drupal since 2007. So I asked you on Twitter, what's changed in the last eight years? And what we learned is that the technology has changed. 2007, first iPhone came out, right? We're glad that some of that technology has changed. This is from Dries' keynote in 2007. We suck at flash. Anyone concerned about that today? No? Oh, all right. We also learned that some of the technology has not changed. Larry Garfield reminded us that back in 2007, he was talking about the new PHP5, right? Here we are. We also of course found out that our infrastructure, like how we work together as a community has changed significantly in the last eight years. Back in 2007, if you wanted to test something in Drupal Core, you asked Angie. And according to Angie, she went beep boop, beep boop, beep boop. And then it was tested. But now, we have all kinds of amazing test bots managed by our volunteers and the association staff that help keep the project going forward. DrupalCon Barcelona gave rise to some of our community's most infamous or famous people, depending on how you wanna talk about it. So lots of people got to come out of their shells and become butterflies. And of course, the project itself has changed a bunch too. Since 2007, the project has become giant and not just core itself, but the thousands and thousands of contrib modules and distros and themes that make up the work that we do on Drupal. So of course, other things don't change about our technology at the cons. If you've tried to get on the Wi-Fi this morning. We also have seen that since 2007, some amazing companies have been born. A whole ecosystem of companies have been born around Drupal that are creating all kinds of economies. Thousands of jobs have been created. Families have been created since 2007. I don't know if you guys remember Merlin of Chaos there, his family. And our Drupal family has been created. I love this one from Wim, this is my favorite. It's pretty amazing. So lots has grown in Drupal, including of course, the number of people that are helping to make Drupal. So back in 2007, we had about 830 patch writers for Drupal, what was it, six back then? Yeah, and Drupal 8 has over 3,000 contributors today, which is pretty amazing. So congratulations to you guys. That's really, really big. And all of this has been leading, you guys have been making all this change happen, which has been pretty remarkable to see. One of the things that you guys have been doing to help get Drupal 8 out the door, in addition to all the technical stuff, is helping to help fund the work to close those last few critical issues, the release blockers, and help get Drupal 8 out the door. And we asked you to help us make that happen by raising $250,000 U.S. dollars to fund some of this work. And we are really thrilled to share that thanks to a generous donation from the Drupal Dev Days that just happened in Montpellier, and Leon are here? No? Oh, Leon? No, I can't see hands very well. Well, I wanna thank the folks who are involved with Drupal Dev Days, Montpellier, for helping to make a donation from their event, our partners at Atnovation Technologies. And overnight, we just got another donation from Drupal Camp Colorado. And now, our total is, look at that, look at that. And Colorado just came in overnight with another couple hundred dollars. So we are less than $750 away from fully funding a Drupal 8 release, which is pretty amazing. So thank you all so much for the contributions, hundreds and hundreds of individual contributions, along with the companies who've helped make this happen. Thank you for helping us reach this goal. And we hope that you'll help us put us over the top here at this event, and we can finish the campaign out. So thank you, and give yourself a round of applause, please. That was a really big deal that we did that. And of course, it's all in service of Drupal 8. We're getting really close. We hope we'll have some news at this con. That would be very nice to share. And I just thank you for letting the association be part of the ride with that community. We've learned so much from the people that we work with in the community every day. And we're really proud that we can partner with you to make Drupal happen in all the ways that we do. So thank you for that. Now, I don't know how many folks have had a chance to ever meet Erin Winborn. But Erin Winborn was a prolific Drupal contributor and a really remarkable human being who helped make many people feel very welcome and find their way in the Drupal community. And he was diagnosed with ALS a few years ago and just this spring, he passed away. But he epitomized what makes Drupal so amazing. I mean, he was a great coder, but what he really was was a fantastic human. And it's his contribution to the community that really inspired the community working group of Drupal to put together an award to celebrate Erin's life. So over the spring and through the summer, they took nominations of community members who represented the kind of ideals that Erin represented. These are some of the folks that were nominated. And they put together an award of a DrupalCon sponsorship allowing one person to come to a DrupalCon every year in Erin's honor. So this is our first award and on behalf of the community working group, I hope that everyone will join me in thanking them and applauding our very first awardee, Ms. Kathy Thays. So Kathy has been an amazing member of the community. How many of you guys know Kathy? All right, if you don't know Kathy yet, you're about to because Kathy has been organizing sprints for years. But one of the things that she's most famous for is helping people get involved in Drupal no matter where they're at. I can personally test to it because she sat next to me in Amsterdam for an hour trying to help me memorize Git commands. And they lasted a whole week. You wanna do it with me again? Right now? No. But Kathy, thank you for all you do and you wanna share any thoughts? Thank you, it's really an honor, thanks. Thanks, Kathy. Awesome. All right, and in addition to our amazing community members, individual community members, like I mentioned, there's a whole business ecosystem around Drupal and now, and they do a ton to help support the work that Drupal does through the association and directly as well. So just wanna take a moment to thank all the people who help fund things like test spots and localize.drupal.org and sprints and camps all over the country, all over the world. Main header. That's a good typo. I try, but I gotta have one in every presentation, right? All right. So we have, of course, all the sponsors who help us get here. Going from 400 to 2,000 people is no small move and these folks help make this event run as smoothly as it does. Let's get into some of the logistics because this con, we want it to go very smoothly for you so I wanna share some of those words with you and also just remember that you'll get into what you put out of it this week. So go in and do everything. Meet everyone and have a great time and here's some of the ways that you can do that. The first here is, as Jan mentioned earlier, we're gonna have a group photo. It's what we do at every con. So after the Drees note today, we're gonna ask you to exit out through these doors down the escalators and out into the courtyard area in front of registration where we'll take our group photo. So head on outside soon after the keynote to make sure that that happens. And then you can have fun trying to find yourself later. A couple words about the Wi-Fi here. Here is the network and the password. You may have noticed we've been having some trouble with the Wi-Fi so please be patient with us. We have some outside network issues that are affecting what's happening inside the building. So hold tight with us, everyone's working on it. If you do find that service is disconnecting, anyone in a white T-shirt with the Barcelona logo on it is staff, they can help alert folks and get the guy that we call Wi-Fi will to run over and see what we can do. So we're working on it the best we can and we're really sorry for any disruptions that it causes. But nobody has any live demos in their presentations, right? Nobody did that? Okay. All right, after Wi-Fi you care about coffee. So here's where to get it. Free coffee in the back of the exhibit hall will be available for the morning breaks that's right after our photo today. And paid coffee will be available throughout the day back there in the exhibit hall. So you can always go get a cup of coffee there. Your meals today will also be in that exhibit hall. Couple of notes, if you have a special meal, you have special stations for yourself there on the right hand side of the buffet. So if you are a vegan kosher or halal, that's where your things will be, don't eat the vegan meals if you're not vegan because we don't want them to starve. And if you have a kosher or a halal meal, do ask a waiter for your meal so that they can get that to you in the appropriate manner. All right, social media at the con. Lots of things here. This is how to get connected and share what's happening with the outside world. Important for today in particular, during Driz's keynote, the hashtag is Driz Note. That's also where you're gonna wanna send any questions so that the excellent Mike Amello can help feel those following the Driz Note and the Q&A that we have. All right, a couple of schedule changes today. We have a change in the core conversations track, so we'll now have Drupal 8 and media status updates by Yana, so it'll be one o'clock or 1300 in the core conversations room. And for buffs, if you were interested in scheduling a birds of a feather session, that's offline now, so you'll need to write that up on the boards in the hallway, and there's still a little bit of space available there. Okay, as Jam, anyone catch the pre-note this morning? Anyone? You guys are all here, try again. Okay, thanks, Jam. I'm glad you caught it. All right, so Code of Conduct, as Jam reminded us, is sort of the thing that holds this community together. If you have an issue while you're at the con, you're gonna wanna contact Adam Hill. There's his contact information, or Mateo, our local contact, or Donna. Adam and Donna are on our community working group, so if you have any issues, please let us know, but just remember, everyone here deserves a great con, so let's try to keep it that way. Trivia Night, that is a great social event you don't wanna miss, even if you're new to Drupal. Come learn about Drupal at Trivia Night. So doors open at 2100. This is the venue and the address. It's also available on the site. It's a bit of a hike. Thursday, not Wednesday. Second typo number two. Come to Trivia Night on Thursday, not Wednesday. Good job, me. All right. How about Women in Drupal? Is that tonight? Yes, I got one right. That's tonight. So come at six o'clock, it's at the Bamboo Beach Bar, not too far, a little map about how to get there, and you can also find that up on the site. And we definitely wanna celebrate the best of Barcelona while we're here. And as you know, Drupal cons are a team experience, so we put those on with an amazing set of volunteers every year, including Pedro and Christina from here. Welcome everyone to Barcelona. We've prepared a welcome party tonight at 8 p.m. There will be live music, lots of fun, and hopefully most of us. Well, or maybe hopefully not, because we are a lot. So it's 8 p.m., be puntual, Spanish style, okay? And if you want free tickets, just come to the Spanish Association, both in the exhibit hall, and first come, first set. There are not a lot of them. Thank you guys, and thanks for all your work in helping to put this together. Great, you also don't wanna go to those parties without looking like a true Drupal-er. I went for a walk last night, I saw a lot of you jogging in your Drupal gear, that was fun. If you need more teas while you're here, sweatshirts, something for your dog or your baby. If your dog is your baby, you could do that too. There are, you can find, they don't have any cat onesies though, just for dogs. I'm upset. But you can go to the Drupal store in the exhibit hall and stock up there. Sprints, sprints, lots of chances to sprint here this week. And one of the most amazing things is whether you have been a long time code contributor or if you've never contributed before, we're gonna help you get started. So come to the sprints, especially Friday. All this information is available on the site as well, but we hope you'll join us. For the Friday sprints in particular, please keep your badges. You may have noticed that security really cares about that. So don't lose your badge and have that on Friday. And now I would like to turn things over to one of our most long standing partners to help introduce what you're all waiting for. So help me welcome to the stage, please, Njane from XOV. Hi everybody. I just donated that it's now 250,000 euros and 79 cents. So consider that done. You know what, Drupal 8 is closer than ever. And we made a fancy game to celebrate the long, long, long march together. You can see here a Drupal bird flying through the frozen versions of Drupal to the Golden 8 and beyond. So if you want to play, see whether you are worth of it, you go to Drupalbird.com. And this is what it should look like. So fly pass the frozen versions, not hit them. And then you get the Golden 8 and profit. And yesterday when we had the first people on the stand, it looked like this. And people were standing there with their mobile phones. But you will master it by practicing. I can guarantee that. So when you have played, come to our booth, number 300 to claim your prize. If you play the game but you don't succeed to eight, there will be some of you, you will get the great player sticker. And then if you manage to get to the level eight or more, 17 is current record, you will get the boss player sticker. Both of these are limited. We have printed 300 boss players and 600 great players stickers. And when they run out, there won't be no more. And then we will have a t-shirt sweepstake every day that everybody that has played on that day will have an option to get this fancy t-shirt. There will be only three of them. We probably need to shred the others because we have some sizes. So you find the game at Drupalbird.com. But try not to play too much during the keynote that if the people are nodding, they're looking a bit angry, then they are not agreeing with Reece, but they are playing the game. That's it. Now I want to introduce a man that doesn't need introductions. It's the reason why we are here. The primary person behind Drupal and the man who scored six points in Drupalbird. Please join me welcoming Reece Budard. Is my mic on? It is. So I actually did try Drupalbird and I don't think I got past three. So I have to do some more practicing. All right, welcome everybody to Barcelona. I did something a little bit special. You saw me fiddle with my slides. So normally I make my slides in keynote. This time I made them in slides.com, which is nice because it's HTML and CSS and JavaScript, right? And so you should be able to follow along on the, if you go to this URL for those maybe not in the audience that are watching the video cast, you can follow the slides. All right. So how many of you struggle with work-life balance? I definitely do. You remember those days or those nights where you're working on a project for work or maybe you're working on Drupal 8? And in doing so, you're kind of ignoring your partner. He or she doesn't get the time, the quality time that they deserve and over time, that starts to build up, right? And you know the tension in the back of your mind. Like you know it's gonna go wrong, but you keep working on your project. But at some point, obviously, you've crossed that threshold and he or she will basically be, you know, we need to talk. Let me get my clicker working here. We need to talk. And so you do talk about these things and once you're done talking, it actually, you know, clears the air. Like, you know, you agree to make some changes and by implementing those changes, you basically feel better, you have a path forward. And so I think this is just one example, maybe an example that we can relate to, but I do think it is true for many things in life. And so sometimes it's better to actually talk about the things that are in the back of our minds instead of not talking about them. And so in this keynote, I wanted to do something a little different. And you know, instead of talking about all the things that are great and all the great things we've done, I wanted to talk about some of the things that are, you know, that keeps people up or that are in the back of people's minds. And hopefully by doing so, you know, we'll feel better. All right, all right. And so basically in talking to a lot of people and I do talk to a lot of people, there's all these like sort of uncomfortable questions. And so I made a list of those. I think one that I think is on a lot of people's mind is, you know, is Drupal losing momentum? You know, some companies, they're not doing as well as they used to do. You know, my phone isn't ringing off the hook anymore and so what's going on? And so we need to talk about that. You know, why can't we release Drupal 8 on time? You know, it's been three years since we decided to start releasing Drupal 8 and we haven't released it yet. Maybe we should talk about that too. A lot of people that I do talk to, they're also nervous about other players in the market. They'll say, wow, WordPress is growing so fast. Makes me a little nervous or, you know, Squarespace has evolved from maybe just an end user tool to having better developer APIs or so many of the large proprietary competitors have more features. What are we doing there? And what about the emerging new platforms that are basically focused on just providing APIs? Right, there's a series of these as well. And so lots of questions that I get at least about how we as Drupal can compete in that market. And so we need to talk about that as well. The other thing is usability. I think Angie has a presentation, I think it's on Thursday, about some of the results of the usability study that we did in Minnesota. We do one, you know, on a regular basis. I think this was the third version. And there's still a lot of things, basic things that people report to us. And so why is it so hard to get some of these basic usability things right? So we need to talk about that as well. All right, here's another one. A lot of people that I talk to, they look at these client-side apps, Backbone, Ember, Angular, GS, and they see them emerging. Maybe they're dabbling a little bit with them. Maybe they feel like they're cheating on Drupal by doing that. And so it's also a thing. And I wanna spend some time talking about that as well. All right, so all these questions that I'd like to address in this keynote, at least to some depth. And then I roughly organized them in these three buckets. I think some of them are related to our development process. Some of them are related to our position in the market. And some of them are more technical and, you know, about the relevance as a technical platform. So let's talk about all of them and let's start with the first one. Because clearly we have a lot of things to talk about. The first one is, is Drupal losing momentum? And I think the answer is yes. We have lost a lot of momentum. But in talking to a lot of people, it's very clear that almost all of them are waiting for Drupal 8, right? And in fact, this is a known phenomena. This is not unusual. There is in fact a name for this thing which is called the Osborne effect. And the name actually came from, I think his name was Adam Osborne. And this was in the 80s. He ran a technology company that was creating personal computers. And so they had the Osborne one at the time. And then they went on to announce the next version of the Osborne one. And the fact that they announced that the next version of the Osborne one came, you know, was on the horizon, basically stopped all sales and the company went bankrupt, right? And I think, I think we also know it from maybe in our personal lives, from buying a phone, maybe it's an iPhone, maybe it's another phone. But if you know that there's gonna be a new iPhone in three months or in one month, you're not probably not gonna buy an iPhone. And in fact, Microsoft suffered from this as well. And I think, I don't know the exact details because I'm not a Microsoft user, but they had a really bad situation with this too where that one version of the Windows phone and not only was there a new version coming out, but also they said that the next version will not be compatible with the previous version. And so it made it even worse so they couldn't actually just upgrade the software. And so this is exactly what's happening with Drupal as well. And this has happened in the past too. Maybe it's been so long ago that we don't remember, but if you look at what happened with Drupal 6, roughly six months or more before Drupal 7 was released, we saw a real drop, a 30% drop almost in adoption. So we've seen this before. But what we've also seen is that once that major release comes out, there is a huge spike. And so I'm very confident that we will see a similar spike once Drupal 8 comes out. And historically, Drupal adoption has roughly doubled every major release. And so yes, maybe we're losing some business right now because our customers, our users are waiting for Drupal 8, but once we get Drupal 8 released, you should expect things to pick up very rapidly. And so what we really have to do here is get Drupal 8 released. I mean, of course, that isn't anything new, but there's a lot of different ways to help. You can donate money. Thank you for pushing us over that limit, or not limit, but that a goal. But I think the most important thing you can do actually today is to start building your websites on Drupal 8. Even though we haven't released Drupal 8 yet, for a certain type of projects, you can start building today. Projects that don't need contributed modules, projects that won't release, you don't have to run them in production quite yet. Some of these projects take a few months to develop, and it's pretty safe to do the development on Drupal 8. Not saying you should run them in production, but you can start building them in Drupal 8, and in building them, you find critical bugs. You can help port modules and do all of these things. And this is what will help the ecosystem advance. All right. So we've actually come a pretty long way. Holly already shared some of these statistics, but if you look at the history of Drupal 8, we accepted patches from more than 3,000 different contributors. That's a lot of people. That's more people than are in this room, right? And in fact, we accepted over 15,000 patches. Last year in Amsterdam, that number was around 11,000. So in just one year, we've added, we've accepted more than 4,000 new patches. We've fixed 1,300 criticals in the process. That's a big number too. And probably the most exciting two stats are the two at the bottom. So for one month, we've not seen any surprises. When we manage the criticals, the release blocking bugs, we haven't seen anything that surprises in a month. And what that means is that we're getting more and more stable and that things are getting more and more predictable. And also there's only one real problem left. So if you actually go to the critical issue queue, you may actually get a different perception because you may remember that a week or two weeks ago, we hit an all-time low of three remaining critical bugs. And if you were to look today, it's probably at 18 or 19 critical bugs. It's a little bit misleading because what we've done is, we've taken one of those critical bugs and we split it out in smaller critical bugs. So the total amount of work is actually the same. Adjust that the way we choose to organize it is in making smaller critical bugs for everything that was in that one critical bug. And so really we've never been closer to release and we've never felt better about the kind of bugs that come in and they get reported. And so as a result, we've decided to make a first release candidate available on October 7th. I think that's very exciting. The caveat though is that while we feel really good about the bugs that come in and the fact that there's no surprise criticals, of course you never know and we may find the security bug or a severe data loss issue that would cause a change in this date. But we haven't found any of those in one month. So we're feeling pretty good about not finding anymore but you never know. So I think that's exciting. It means we're only about two weeks away, I think, from having the first RC and we're going into that with a lot of stability. However, something sort of needs to change too, right? The process to get there was incredibly hard. In fact, it took us almost three years since we first announced feature freeze to where we are today. Last year in Amsterdam, we rolled the first beta. Now a year later, we're still not at RC. And in fact, if you think about it, Drupal is 15 years old, almost 15 years old and almost five years of Drupal's life, we've spent on Drupal 8. It's kind of crazy, you know, it's a third of our life we've spent on working on Drupal 8. And so it's not very healthy for a release to take that long. So why can't we release on time? First of all, I want to say that no one is to blame for this. You know, I think it's not because we don't work hard. It's not because we're not smart. In fact, I think Drupal is one of the hardest working and smartest people that I've ever seen. And you know, many people have worked days and nights and weekends and probably gave up a lot of that work-life balance. You know, traveled around the world even to get Drupal 8 released. And so a lot of people have done incredible things so no one is to blame for this except, you know, maybe me for not seeing this problem earlier, for not making some changes earlier. But I think the lesson here is that, you know, it's not about people, it's not about us, it's really about the process. We've been working the wrong way. And so here's how I'd like to explain how we've worked, so if you think about how we think about building a feature in Drupal, we roughly plan it out. We say, this feature we're gonna split in smaller steps. You know, each of these steps is gonna be patch, that patch is gonna get committed and we do that in seven steps or four steps or whoever many steps. But in reality, as you all know, things work a little bit different. Each of these steps takes maybe a little bit longer. There's things that we didn't predict that need to happen as well. Sometimes people disappear. You know, things happen in their life. They lose interest, they have to focus on something else. They move away from Drupal, either permanently or temporarily. And so the work is then left behind and we lose a lot of time when that happens because then somebody else needs to step in and pick up that work. And so reality always takes a little bit longer. And you know, this is nothing new. I think a lot of us in our daily lives working for agencies, you know, we see this planning is really hard and humans are actually really bad at any kind of planning. And so it's called the planning fallacy. You can go read about it, but I think Mike Tyson put it really well. Everyone has a plan until they get punched in the mouth. And so that's exactly what happens with every feature that we put in Drupal. There's a lot of ways we can stumble and we do. And so now multiply this by many features, right? Because at any given time, we're working on many of these features at the same time. Plus, we do all of that in a single branch. It's called trunk-based development where all of these patches get committed to the main branch, the trunk. And so what happens with this process is that, you know, when we set a release date, which we've done multiple times or, you know, milestones, I should say, when all the features aren't ready, we can't meet that milestone. And so we have to move the milestone, right? And so really what that means is we can only go as fast as our slowest feature, which obviously isn't great. And so now imagine what we did in Drupal 8. We added hundreds of features. So we have hundreds of these, you know, timelines that we're trying to get to a finish line. And all of these are going, you know, slower than expected, or most of them go slower than expected. And we need to get all hundreds or 200 of these over the finish line before we can release. It's kind of a bad situation. And in fact, you know, that's exactly what we did. And now we're down to just one feature, which is twig. You know, all of these criticals that I mentioned, they basically come down to, you know, twig and twig Ido escaping and save markup. So we're literally down to getting the last feature over the finish line, which is quite exciting, but we really have to stop doing this. You know, like if we don't change the way we work, we will literally kill ourselves. Not just individuals trying to push Drupal over the finish line, but the momentum and the innovation coming out of the project will be too slow. And so, I'd like to propose and adjust the starting point for a bigger discussion is that we change the way we work, that we build, that we use a methodology that accepts the reality, which is humans are really bad at planning. Things happen, it's a complex world, but that we figure out a way to do what we do or to do what we have to do in a way that kind of takes it into account. And in fact, there is a, you know, other projects use a system that lends itself better to that. And so what they do is they move, basically create feature branches for each of the features. And so what you do is for big features, you built them in a feature branch and only when the feature is shipable, you merge it into the main branch, right? And so they're really firm on keeping the main branch shipable. We cannot commit patches that require follow-up to the main branch because we never get the amount of follow-up right. And so by developing each of the features in a feature branch and only merging when they're shipable, we can get to a much more shipable main branch. That doesn't mean we can no longer use our patch-based workflow. People can still submit patches to a feature branch and feature branches can still accept multiple patches, right? We can still do the development the way we used to do it. The only difference is that we'll have to merge a feature branch in the main branch. Whenever we feel it is shipable, and by shipable I mean we would make a release with that stuff in. Like we wouldn't say, well, we have to do these other things before we can release, all right? And so what that allows us to do is to switch to a date-based system or time-based releases or something that is much closer to that. And so the way it works is if the feature is shipable, we merge it in. If a feature isn't ready, we can still release when the feature can go into the next version of Drupal or maybe the version after that. Pretty simple, I think. Or at least it sounds simple, but the complexity is in, now we have to manage these merges. And it's pretty complex sometimes if you have all these feature branches and merges become kind of a mess. But I think it's still much better than having to work for three years on fixing all of the bugs. Like even if a merge takes us three weeks, even if a merge takes us six weeks, it's still better than working for three years on fixing all the bugs, right? And there's also things we can do to make it a little bit easier. Like we can still break up features. We can break them up in MVPs. Again, at the end of an MVP, we could merge it in and we could ship it, right? Even if it doesn't mean the feature is complete, it would still be a good idea. I think the other thing we've learned is that with the initiatives in Drupal 8 is that the best initiatives were the ones with a cross-functional team. And so I'd love to see a lot of these features of cross-functional teams. Because they get the best velocity, but they also get the consistency. If one person can no longer contribute because something changed in his or her life, then the rest of the team can carry on with the work. And the knowledge is being shared. So really encourages to think about how we can embrace the notion of teams more. And then I think the role of the technical leadership of the core committers will basically be what they do today, review patches, commit patches to feature branches, but it will also be about orchestrating merges. Like even if something is ready, we may not choose to merge it yet because we want something else to be ready first and to get that merged in before. The way we would do it is based on, on the one hand, we want to maximize the impact on the project in the next release. We want to merge in great features. On the other hand, we want to minimize the impact of a merge on the developers. Because if you merge a feature, all of the other feature branches may have to be updated. And so we'll have to get really good at that and we'll have to learn a lot about how that will work for us. But I think by doing this, I think we'll be in a much better place. So to sum up this section, we didn't release on time. In fact, we're many years late, but it wasn't our fault. I really don't think it was any individual's fault. It was really the way we worked. And I think we're gonna fix the way we work. A lot of details to figure out. But ideally, we would never see this happen again. We would have regular releases and regular innovation coming out of the project. All right. So that was the first part, some of the first questions. On the market position, people wonder, can we compete? And typically, I think sort of the elephant in the room that I hear when I talk to people is WordPress. They're growing fast. They're moving up the stack. They're adding new features like they're dabbling with things like field UI and stuff like that. And so in people's mind, the world looks a little bit like this. WordPress being huge, Joomla being bigger than Drupal and Drupal being the smallest of the three. But I also think we have to move on from that because the reality, I think, looks a little bit more like this. Where Drupal is the dominant platform for large and complex websites. Drupal is more powerful for those sites. The things we have, our ability to scale, the content modeling tools that we have, WordPress doesn't have those. They're starting to build those, but we are like literally years and years ahead of them. And that's reflected in the adoption of Drupal. Obviously, WordPress is very big on the lower end of the market. And there is definitely things we can learn from them. Right? I think the key is, first thing to remember is, I don't think it's, I think we have to stop comparing Drupal to WordPress because we're so vastly different. We serve different audiences. We're focused on a different size of the market. But what we can learn from them is that, WordPress has done a great job focusing on the usability of the author, but also the side builder. And we, Drupal, we've done a great job focusing on the developer. Like we've been really focused on the developer. And for a long time, we've tried to change that. Actually, if you go back to my DrupalCon Barcelona slide in 2007, that's eight years ago. What I did is I did this survey and I asked everybody that wanted to fill out the survey, what do you think we should put in the next version of Drupal? And at the time, there was Drupal 7. And so I looked at all that survey data and out of that came this notion of the Drupal 7 killer release. Like what would be the ultimate release? And so I looked a little bit like this. And I suggest that at the time, that we would spend 70% of our efforts on things related to user experience, side builders. And only 30% focused on the developer experience. And so funny enough today, we've actually done all of these things. It took us eight years, but most of these things we've now done, we've put custom content types in core. Drupal 8 will have a WYSIWYG, some of the work on BigPipe will give us great performance, views is in core, but then also for the developer stuff, we've also done these things. So it took us eight years, but we finally reached this killer idea with Drupal 7. And one of the things I actually did in Barcelona, it's not on this slide, I had forced in another item, which was 11, which user experience. But really what we've done is we've done all of these things, but then we've done all of these other things as well. And most of it is for developers, which is great. But how can we get better at getting the user experience? And I think we really have to start thinking about Drupal as not just as a tool for us developers, but as a tool for side builders, a tool for authors. And we need to spend more time, focusing on these kinds of features. And it's not just a list of features, like I had on the slide. Now, in fact, we have a lot of these features, it's about making the experience better, making it very easy and seamless for people to use. I think the field UI is a great example of that. We have all these great features that give incredible power to our users and to our side builders. They're just too hard to use sometimes. And that was very clear coming out of the usability testing. So I encourage you to go watch Angie's session on that where she will share the results. So then how do we do that? And I think it's another processing. We have to let them try it. And so instead of working like this, we should really consider embracing a lot of the best practices that have been around for many years, which is involving these users in the development process. And by paper testing, making prototypes, doing some user testing along the way, instead of too often we wait until everything is complete to go test it. We did this with block management and we build all of these things and then we learned that it's not actually usable. I have to go rebuild it. And so we can learn from that and I really think we should. And I believe if we do that, we can go after the real opportunity, which is in fact 80% of the world does not use a CMS. There's all this white space. We worry about competitors, but really the opportunity is to go after all of these sites that don't use a CMS at all. And so we need to convince these people, these organizations that Drupal is the right tool for them. So to sum this up, I actually do believe Drupal is in a very strong position. I think we have some of the best content modeling tools. I think we have some of the best page building tools, although they're a little hard to use. I think we have some of the best developer experience, especially with the stuff we did in Drupal 8. And it's way better than WordPress. It really is. But we can still learn from WordPress about how to make the user experience better. So and also let's not just focus on WordPress because I think, as you saw in the graph, things like Adobe, CQ5, they're quickly coming up and getting bigger as well. All right. So the third part of the keynote, I wanna talk a little bit about the technical relevance of Drupal and what are these frameworks? The JavaScript, MVC frameworks are the client-side apps and how should we react to them? How should we think about them? A lot of people ask me, so imagine it's on a lot of people's mind. And it is because decoupled Drupal or headless Drupal is probably one of the biggest trends or how to stop it to discuss. All right, so there are big trends. I don't think the trend will be going away. I think it's here to stay, so we need to adopt accordingly. Before I go there, not everybody may be familiar with these, so try to explain it very quickly what's been happening. So in the early, early days of the web, the way people built websites is by writing HTML. And they would write HTML in a browser, in a notepad or something, and then upload it to the server. The server would serve it to the client, to the browser. And so the rendering literally happens with somebody's hands. They would create a layout, put the content in there, all of these things, and just upload it. CMSs came along and really would change that the rendering kind of moved from the desktop to the server. So now people would provide content to the server, through a user interface, but they would not write HTML, they would write content. And the server or the CMS would build a layout, put the content in there, and send it to the client. I think we're all very familiar with that model, because that's effectively what Drupal does. And so then now with these client-side apps, the rendering kind of moved one step further, right? So now it's the browser, the app, that's basically building the layout, and it's requesting content from the server. Could be a MongoDB database, and so they do some REST APIs to get the content, but the browser will all put it into a layout and push it to the, and present it to the client, if you will. All right, so, and this is actually very good, because there's a lot of advantages to this model, by pushing the rendering to the client. There's a couple of things you can do more easily, and one of them is called optimistic feedback, which you can see on this slide, which this is a screenshot of Pinterest. And so what you can see is it kind of sends the layouts and sort of the blocks ahead of time, and then the images are filled in in a second step. And they're actually quite smart about it because they kind of sample the pixels, and they come up with a kind of average color of the image. Anyway, that's a detail. But the idea of optimistic feedback is that it's, you know, it's a better experience. It's a faster experience. It's perceived performance for the visitor of the website. Another example is non-blocking user interfaces, and this is a screenshot of my Facebook page. Maybe a little bit hard to see, but what you can see here is that I can effectively start playing the video while the rest of the page is still loading. You see the little, whatever it's called, below the video that shows it's still loading. And so this is also pretty powerful because the result is that, you know, users within a few milliseconds, they can start reading content and trying to understand what's going on, and then more expensive things are being added later on. And alas, but at least, often these client-side applications have sort of an application-like experience. So here's another little screenshot or, you know, animated gif of Trello, which is really a website, but it kind of works like an application, right? And so this is the kind of stuff people want. It's not going to go away, right? It's great. So we need to figure out a way to merge these things and to embrace them with Drupal. All right, so let's go back to this architecture. So in the traditional CMS architecture, what happens, and sorry if this is a little repetitive for some of you, just want to make sure everybody can follow. Basically, as I said, the CMS sends the layout and the content, basically sends the whole page to the clients. So these client-side apps, it's a little bit different. First, or typically first, the app builds the layout and then we'll do multiple, or, you know, one or multiple requests to the server to get all of the content. So you may call a MongoDB database on the server side to get bits and pieces of content back in JSON and then convert them to HTML and put them in the layout and then send them to the client or something along those lines. All right, so that's cool, but there's a lot of things you lose, right? You lose the editorial tools of Drupal, like the way you have to put the stuff in the MongoDB database may not be that easy. And so this has led to what people call decoupled or headless CMSs, where really instead of sort of MongoDB serving the content to the app, it's really the CMS that's been adjusted to serve content into the app. And so in this model, and so Drupal 8 is ready for this, so we have a rest contract effectively, and people can use that to retrieve content from within Drupal and to return it as JSON. But typically in this kind of architecture, the application still builds the layout and will then just pull content from Drupal, and like one example would be weather.com, one of the biggest websites in the world, in the top 20 websites in the world, and also probably the biggest website in Drupal, you know, billions of users every month. They did this and they use, like Drupal in a deep-coupled architecture, and what they had to do on the app site, they had to build their own layout manager and they had to rebuild block placement, things that were available in Drupal that they had to redo, like reinvent on the application site. All right, so in general, Drupal 8 really loves apps. We have a RESTful API for pretty much everything in Drupal, including views which will make it very easy to build these kinds of decoupled applications. But like in the case of weather.com, it's not always easy because there's a lot of things you lose. And here are some examples. You know, you lose the Drupal toolbar at the top of the page typically. You often lose the layout management and the block placement. We've also spent many, many years perfecting the accessibility of Drupal and often these things need to be reinvented now, form validation. There's a lot of things that you lose when you build these applications and it's basically not great. And so this begs the question, can we have our cake and eat it too? Is there a world where we have all of the benefits of Drupal, all of your site building tools, faster performance with BigPipe? Because this is the thing I haven't talked about. It's a little bit too much for the keynote. But I'll do a blog post probably tomorrow which goes into much more detail. But BigPipe actually has a performance advantage compared to client-side apps. The way we can cache things on the server based on knowledge that we have that does not exist in the client is because of the advantage. And I'll have a little video in my blog post. So how can we get all of these benefits of a traditional CMS but still keep all of these benefits of a client-side app? And I think we can, I've called it progressively coupling or component-based coupling and the idea is a little bit like this. So first, instead of the app Drupal sends the layout. That way we can maintain our layout tools. Drupal will also send a lot of the content and often we can bundle the content with the layout. Things which are very cacheable, things that we know are going to be needed on every page, like maybe a menu. We can send along. So with BigPipe we can actually be smart about it. So what BigPipe does, it sends the layout and then it will send sort of the fast content first and more expensive content it can schedule if you will to be sent after. It's a little bit like what you saw in Facebook. Things already appear on the page but other things come later. And then the app can still request content as well after Drupal has sent the content and so this model, I think, will give us the best of both worlds. A good news is that with Drupal 8 we keep all of these options open. You can still build traditional Drupal sites if you will with our built-in theme system which we've actually improved quite a bit with Twig. So that will be great. On the other side of the extreme you can feed your Drupal site data just like in a purely decoupled application and that's actually great too because native apps and the likes, that's typically what you would use but I think there's a large amount of situations where you don't want to rebuild everything on the client side but in fact you want to keep all of these tools that are in Drupal and I think that's kind of the progressive decoupled option and our content modeling tools, our page building tools, all of these things we're really good at these. We can actually preserve in this world. We're not quite there yet. There's things we can improve and actually one of the challenges with these kinds of architectures is typically the fact that they're using REST and the way these APIs are built so right now often you have to do multiple REST calls to get all the data you want. You have to do multiple of these calls and then you also get often too much data or sometimes too little data like for example if you want to use a username and maybe that's all you want, this is a username often Drupal will send you the email address and this and that, you don't want all that data you just want the right amount of data and you want that with the minimal amount of calls because that affects performance, the REST API calls and then the other challenge is that figuring out these APIs and what the response objects are is a little bit of a challenge too, it's not easy but we really need I think the ideal solution would be as I mentioned to do a single API call one request and then to be able to get exactly the data that you want not too much, not too little and to build those queries with a much better developer experience and in fact we have that Fubi or Sebastian has been working on this for quite some time as presented about this Drupal come before and I really think we should pay attention to what he's doing and consider it for inclusion and core even and I'll give you a little bit of a demo it's called GraphQL how many of you have heard about GraphQL? All right, not that many people but I'll show you a video, I'll try to talk about it while the video is playing but it gives you an idea of how this works so here is the GraphQL UI it's actually in Drupal, hold on I need to restart this video so this is a Drupal site it has some nodes or entities or events all of the Drupal cons you can see there's a city field or region or year that kind of stuff so now we switch to this UI which is also in Drupal it's basically a query language you can say give me give me node 3 really and here's what I want I want you to give me the title field so every turns is JSON object so pretty easy so you can do more complex things you can start with a view and sort of pick it apart you can say give me let's see what it's going to do you can see all the nodes and return the title so you get a list of all the Drupal cons you know, on my site so you may want to say actually filter all of these by the ones that were in Europe so you can apply a very quick filter so you can see now it only is returning European Drupal cons and it can be a little bit more explicit about anything else that you want and so you do if the returns are you can see node conference please show me the city the separate field that you saw in EY and also show me the year that event took place so very easily you can create these queries with a very easy to use tool it just like really helps you build the queries and here you go all in a JSON format the other cool thing you can do is you can actually follow references and this is where you can start to eliminate multiple queries but you can see use the user ID and then follow that down in the object model in the Drupal model and give me the name of that user ID so you can see it returns admin there and then there's all sorts of other little things you can do, you can like alias the user ID just to make the output a little bit nicer to work with for front-end developers instead of user ID so this is a very quick demo but it gives you an idea of some of the power of GraphQL and how it actually would be better than REST in my opinion so I don't know if Sebastian is here, is he here I don't see him but if he has a session go check it out and so really what it does is it takes this REST concept to GraphQL and reduces the number of queries and all of this is actually made possible and this is another example of why we are ahead of the others this is made possible because of the serialization and the type data in Drupal 8 these are the things you guys have to keep in mind when people compare ourselves with other competitors and in fact all of this is already in contrib for Drupal 8 so we can start playing with that today and making it better and so I think this idea of progressively coupling and making that better so we can maintain all of the features of Drupal and yet leverage all of the advantages of client side apps combined with GraphQL I really truly believe it puts its way ahead of virtually any other competitor so I'm very excited about that and I really do believe we need to keep exploring that in future versions of Drupal so to sum it up I think fully decoupled is not always the best solution in fact I only think it's the best solution in a very narrow set of use cases I think progressively coupling is often a better solution and gives us the best of both worlds and I do believe that Drupal 8 combined with GraphQL is going to be an ideal platform for building websites and for building apps I think it's a very exciting place to be for us I talked about all of these three things I think the key takeaways are we have to release Drupal 8 and when we do I can promise you that some momentum will come back what's going to happen there's a lot of evidence from talking to people almost everybody that I talked to they're waiting for Drupal 8 so we just have to unleash that momentum fortunately we're close we need to move to a more sustainable release process a more sustainable development process you know one that's healthy healthy for the project and healthy for the contributors I think we need to do a better job putting just first to increase our impact you know the thing we can learn the most from WordPress and four I really believe that Drupal will be a go-to platform for both sites and apps so I hope you guys are excited about all of that then I have one final note this is more of a thought but I've always been pretty excited about the web and the impact that the web can have on the world how it helps to connect people so if you think about it today there is roughly 3.1 billion people online people that have internet access so if you think about the fact that Drupal powers 1 in 40 websites we sort of touch every user on the internet because everybody that uses more than 40 websites chances are where statistically speaking that person has used Drupal I thought it was a really really cool idea that Drupal basically touches everybody on the internet and then in the next few years the growth is actually quite staggering so they predict that in the next few years like 1.8 billion people will come online new people that don't have internet today so the idea that Drupal 8 will be able to touch all of these you know it's quite special and makes me very proud to be part of this project and to have started Drupal to see that we can have that reach and touch that many people in the world if you want a little bit more details about everything I talked about go to my blog you can subscribe to it if you want but for each of these things I'll do maybe even double the amount of information than that I covered in the keynote so it will be great to continue the conversation or to get a little bit more technical in some of it just get a little bit more data so feel free to do that and that's it thank you very much we have about 10 minutes for Q&A we've had a lot of great feedback come in some nice compliments on the design it's not me another talent so where do you think the most feedback from your what topic because there was one that was overwhelming more questions about I have no idea future Drupal core development workflow so I wrote down probably about six questions so I'll pop a few of them so you mentioned we're going to change the way we work after DHS so does this mean that we need to figure out this new process before we move past 8.0 I mean it would be good to do, I mean we're going to actually try and spend some time on this this week to figure out some more details I mean we don't have to you know it only becomes relevant once we decide to build new features after Drupal 8.0 is released so sooner we figure it out the better in a way but we can afford to take the time to figure out how we're going to do it I would say ideally we figure it out by the time Drupal 8.0.0 ships fair enough alright so I'm going to apologize in advance for butchering some of these names so a couple of questions that came in Julien Dubriel I believe does changing the approach of releasing Drupal and MVPs and chipable features means Drupal will stay in version 8.0 indefinitely will there be a Drupal 9.0? That's a good point yeah it's a good question you know I think it could be because it should allow us to add more features to Drupal 8.0 as we go but the one thing that we committed to is that we would maintain backwards compatibility right and so in an ideal world where we can add a lot of features to Drupal 8.0 for all of the minor versions of Drupal you know Drupal 9.0 version and actually we discussed this already a little bit with you know Cachin, Alex and NG and just that technically Drupal 9.0 could be like the last Drupal 8.0 version where we just remove the layers of backwards compatibility so it could be close to that but we're still going to need these points where we remove you know a lot of the backward compatibility just so we don't slow down the system and you know we clean up some of the code but I guess a short version is yes hopefully we'll see more continuous innovation where you know fairly big features will be added to Drupal 8.0 along the way can we add the ability to fork core and power developers to create their own feature initiatives and then merge them back in yeah I mean I think that's one of the open questions like you know how many of these feature branches are are there going to be official feature branches and then unofficial feature branches can anybody start a feature branch yeah so we don't know yet however I will say that I'm pretty passionate about sort of keeping this idea of you know permissionless innovation where anyone can say oh I'm gonna you know add this you know I'm gonna try and get this feature into the next version of Drupal like I think some of the best things that happen to Drupal is exactly that like the unexpected unplanned features so the big question is how can we how can we keep that in our in our process right so that these unexpected things that are great can happen at the same time it's not too hard to imagine that having 200 of these feature branches is going to be a little bit unwieldy and that we may have to you know we may have to have a process that says alright let's work on these things now maybe let's wait for this feature to get started so we kind of not complicate our lives too much but again a lot of these details we have to figure out I think we'll what we'll do is we'll think about them we'll try to document them we'll solicit feedback from the community but a lot of it will be learning as we go and adjusting the process as we go so what you should expect us to see do is kind of ease into it maybe a little bit more restrictive then you may like but then it's going to open it up more and more as we get our sea legs if you let me know exactly how things will will work so so I think this question is going to have a similar answer but I'm going to ask anyway because it popped into my head as you were talking and then somebody asked on Twitter and it got retweeted a bunch of times I believe the original poster was a sheesh took her again sorry if I put your name feature based branching sounds cool but current issues in Drupal.org get infrastructure is not fit for that do we shift to GitHub or a similar model yeah it's a good question it's a very complex question as well there's so many things that we use that do not exist in GitHub so I don't think I have an answer for that but it seems you know I think it's safe to say that feature branches will not be the trigger to the only trigger if we do decide to move to GitHub it will be much more holistic approach to it I think for now we're pretty set on staying you know we did it though Donna Benjamin asks a new topic here so we need to recognize non-coders in the community as first-class citizens we've kind of started moving that direction with updates to the Drupal.org profile pages but how do we go further what are the next steps in making sure that people who don't code but contribute huge amounts of time are considered first-class citizens I totally agree with Donna first of all we have to recognize all of the contributors people that write documentation people that sponsor events people whatever it is they do I think we need to figure out how can we best recognize that a lot of the and so far actually we've been rolling out the credit system that I talked about last year that's actually in place we're still kind of rolling out where these credits are being shown but they're still only focused on people that contribute code in a way that's a great thing it's a good first step it's okay to make incremental improvements we can't expect to kind of roll out a system big bank style that incorporates every single kind of contributor but what's important now is that we keep iterating that we keep adding these other ways of recognizing contributions how exactly we're going to do that I don't know right now I would have to talk to the Drupal association about that because they're actually building all of these things we should do that okay so a couple of months ago I believe Larry Garfield published a blog post actually back in July I have here my notes arguing that we should focus Drupal core more to possibly stop trying to be all things to all people I think you use like the peanut butter analogy or spreading ourselves too thin so for instance maybe we should focus on the structured content capabilities of Drupal as a differentiator and that if your site needs structured content you should be looking at Drupal if we do something I don't want to say officially focus Drupal more it means we're going to deprioritize other parts of the market how do we deal with that how do we handle that yeah again great question not an easy answer there's definitely no like I have some easy ones coming up but I do think we focus Drupal through the initiatives and stuff I think we have brought a focus to the table it's not official though it's not in the mission statement it's not in the mission statement but it's Apple's mission statement is build great products they don't say what features they're going to add to the next iPhone either but based on what I talked about today clearly what I'm pushing for is recognizing the content modeling tools recognizing that Drupal can be great for multi-channel publishing recognizing that we can build multiple heads to Drupal and so I think we're really good at that that's what I explained today and I also suggest that we even need to get better at that I'm not saying that's the only thing we have to focus on there's going to be other things that we need to focus on as well like user experience but other than the things in the keynote there's going to be other things but yeah I think saying no to things will be very helpful so again it's going to be a process to figure out what exactly we're going to focus on I run low on time so I have two quick ones for you this one came in from Twitter via Mike Herschel if you had a time machine and it can go back to I looked up the date March 11th, 2011 when the Drupal 8 development branch opened if you can go back in time what advice would you give yourself about the Drupal 8 development cycle huh well if I knew what I knew today I would probably push the feature branching to be honest I think you would that would have been great alright so last one just because we honored Kathy earlier with the award and now I just want to see her head explode we had someone on Twitter, Jason Mark I tried to join the sprint yesterday and told no one needs a UI person how do I help I think the answer is just to go find Kathy right we definitely need a lot of UI people that's what we need the most I would say so alright well thank you very much for your time you're welcome, thank you and I believe Jam is going to lead us there he is right there to the group photo