 So my name's John Kennedy. I'm the Program Manager for the D8 Module Acceleration Program. I'm going to give a little intro to what we've tried to achieve over the last six months. But mainly, it's about the power. These guys are amazing developers who've come together to accelerate the Drupal 8 module ecosystem without reporting or creating new modules to drive Drupal adoption. We'll have a lot of time in this session if you'd ask them questions about the challenges they faced, about what's ready in D8, about how to do things. So if you want to have questions ready for the end, I'm also going to touch very briefly because this is a business showcase session on Lightning, which is an open source distribution we've been building with the help of a lot of the modules we've had. Feel free to come on down to the front of the room. Yeah, plenty of seats up the front of the room. And so let's get into it. I'm going to introduce everyone first. We've got Ken from Palantir, Larry here, who's with Platformer's H. We've got Adam, who's my tech lead. And we've got David Snopak. And we've got Dick Olson, and Tim Millwood, and Ted Bowman. And Adam's with me. David? So I'm a Drupal consultant. I also work for Mind Drop Wizard. We do Drupal support maintenance. And hand it on down. And my name is Dick. So I work for Pfizer, a big pharmaceutical company. We use Drupal for our marketing websites. So yeah, I'm also a partner of Pfizer. I'm a long time contributor to both core and country maintainer of the deploy module and a few other bits and pieces. I'm Tim. I work for Atnovation. And I've been working with Dick on the workflow initiative stuff. Ted Bowman, Ted Bowman, Drupal.org. And at the time I was doing this, I was a contractor with them. Now I'm working at the office of the CTO at Acquia. And I guess long time in contributor. Now you better hand it to the other end, because you're all doing formal introductions. So bring it back to Ken. I'm Ken Rickard. I'm the director of professional services at Palantir. It's funny, because I was a long time Drupal contributor. And now I'm in the business side. Interesting perspective that Ken will bring. So yeah, I'm a product owner, actually. But I can develop. I'm Larry Garfield, been around Drupal forever. The stuff we're talking about here was when I worked at Palantir.net with Ken. I just recently moved to PlatformSH, a hosting company. So yeah, I'm just talking about code, because that's most of what I was doing for this initiative. And I'm Adam Balsam. I work for Acquia. I'm the tech lead for Lightning. And I helped organize this model acceleration program with John. Great. So I'm going to talk really briefly about the purpose of the initiative. Because what we found, we looked, and this actually is a set of functionalities from Forrester, who are analysts. They look at web content management systems. But when we looked at these capabilities, on left you see what's provided by Drupal Core. But on the right, you see all the things that have to be provided by the module ecosystem, at least until we bring them into Core. And so that really puts a lot of responsibility on the ecosystem to put out these features for Drupal 8 so that people have a full and rich experience with Drupal. So recently, as Drew said in his keynote, he did a survey. And what did he find? Is the top reason people weren't coming to D8? Modules. They needed to feel that modules were in a state they could use in production. They had the capabilities they needed to build digital experiences. So we had a mission in October. And this really kicked off with the authoring summit that we had over at Bad Camp, where we gathered a lot of people together to talk about authoring experiences and modules and what was required to bring people into Drupal 8. And the mission for the module acceleration program, which was to drive Drupal 8 adoption, to engage the module contributors and to build a better Drupal. So, Acquia put the money forward. They put forward, we put forward $500,000, thank you Tom, to go directly to contributors. As I said before, we went out to Bad Camp and a number of other places to engage the community. And we also supported this development with resources from Acquia that was a part of our professional services department and also Adam Baltham, who's the technical lead and coordinated the whole program from a technical standpoint. So after six months, we've got over 4,000 hours of developer time in the program. We've got over 10 contributing agencies who couldn't necessarily be represented here, all of them are in Europe. As you can see, over six countries, over 20 developers, and we've released over 36 production-ready modules. And generally, they're the tough ones. They're big, hard modules that we knew were gonna be really hard to accomplish for a single developer, and it made sense to try and develop them as a part of a group effort. So maybe Adam, you can take up the mic and just talk really briefly about how we can coordinate across a lot of different modules that are being developed independently by groups of people. Yeah, this is our Trello board that we used to just kind of get a general overview of where we were at with all of our modules. So first of all, we identified what modules belong down here. And then we built our team out. And some of the people that we brought on were very specific, like Larry. He worked primarily on Workbench Moderation, which was a module that he already owned. He actually inherited some of that work from somebody else for the Drupal 8 version. But then there was other things that we didn't necessarily have somebody in mind when we knew that we had to port it. So it was really a matter of figuring out personalities and where the expertise lied, who preferred to work on a team, who preferred to work individually. And throughout that, somebody like Wampie, who came to us from Lullabot, I think he touched well over a dozen modules, not necessarily porting them straight from Drupal 7 to Drupal 8. But without him, there was issues that would have languished, that needed review. Then you had people like Larry, who worked primarily just on one module, and then people like Ted, who bounced around, but ultimately developed entire modules. So it was really a matter of finding the right personalities and the right technical chops and letting people direct their own destinies. I don't think people would have appreciated saying I wouldn't have asked David, who is very involved in the panel's ecosystem, to work on Workbench Moderation. So people kind of migrated to what they knew best, and it really worked out well. Yeah, and this was a lot about people who wanted to develop their modules. They wanted to do the ports, but they didn't have the time or they couldn't justify it, and we brought them together. And then there were also people who came in, like Dick and Tim, who had projects and donated their time. So FISA donated time and an innovation donated time into the program because they had their own problems they were solving, and we could help them with that as well, contribute to their effort in some ways, and they were contributing to ours as well. And that, it really grew the effort out beyond who we were funding directly to parties who wanted to collaborate. And we ended up, Adam, with a few externals, and we kind of had the daily scrum, but also we had an external meeting that was happening every week. Right, that's important to note. So what we started doing is we picked a time that people in Switzerland, India, and the East Coast, and Oklahoma could all make. So every day we got together at 10, 15 a.m. my time. Boston. Which may have been 10, 45 p.m. for some other people that were involved in the project. But every day we made it a point that we all got together and talked for at least 15 minutes. That was our daily standup. And I think it was really useful. A lot of times it was, yeah, I'm still working on it. But it was just really good to touch base every day. And then on Tuesdays what we did is we called that our external scrum. So everybody that came to our daily meetings came to Tuesday. We also invited some managers and then some other organizations that are doing similar acceleration efforts. So maybe they were working on projects that were related or not related, but it was a good time to bring everybody together and say we're picking up the DMAPS module. So don't anybody else worry about that or we need help with this. Maybe somebody could jump in and review an issue for them or something. So on Tuesdays we kind of had our bigger meeting that we caught everybody up. And then every day we tried to keep it quick our standup at 10.15. And that seemed to be really productive. It was really useful, good use of time. Right, so I just wanted to mention as part of this effort was to get D8 going and now we're seeing a large adoption of D8. And Drew's talked about it in his keynote but now we're seeing large companies come on to D8, a lot of sites reporting on DDoDo, a lot of sites on Aqua platform that we can measure. And we think that the module acceleration program has been a part of that. And some of the reason we believe that is we look at the top 12 modules that we built as a part of the program and we see big adoption of those modules between January and April. We launched in October, we probably started releasing modules in January and we've seen a lot of adoption of those modules since then. So we're gonna go to questions now and this is the real point of the discussion because I think the point today is that we want to enable people to form groups as we did within the program and go after these initiatives that Drew's is talking about and self-organize and get more modules ported and more functionality into D8. And these guys have had on the ground experience of how to self coordinate and they've set up subgroups around things like workflow and that's been really successful. So I'd like the developers on the panel maybe to pick out a question they would like to answer and we'll go down and we'll go person by person. If you wanna raise your hand, we can pass the microphone across and guys. So, this is Larry, for the recording, yeah. I work primarily on workbench moderation. I've done some work with the workspaces and multi-version modules as well. Workbench moderation is a module that Palantir developed originally for Drupal 7 and we knew we wanted to redo it for Drupal 8. There had been changes in Drupal 8 that made it a lot easier to build, even just some minor changes in the core APIs that took out several thousand lines of terrible, ugly code from the Drupal 7 version of the module. Probably the biggest question we had though, I'll answer that one, the other hard decisions was in Drupal 7 we had two different versions of workbench moderation. We had the workbench 1.x branch which was basically you're straightforward, build a couple of states, assign them to nodes and moderate them and you're done. And then a 2.x branch that was trying to be a much more robust kind of workflow engine type thing that for various reasons never fully solidified. And the question for Drupal 8 was, all right, which approach do we take? Do we want to do the 75% use case that we can nail pretty straightforward, but doing so not be able to get to that last 10%? Maybe that middle 15, if I can do math? Or do we try and get to that 90% with the one module? Do we do that 70, 75% version and then hope that's tying into multi-version and workspace that other 15% will just kind of happen on its own? And we went around on that for actually, even pre-map we were having that discussion internally and tried taking one approach, didn't quite work. Finally with map, we were talking about it, all right, we'll take this junior approach and then Lee Rowland, you know, Leroland did a quick proof of concept for us and said, by the way, I have this proof of concept. And we said, oh, okay, yay GPL, go community. And so it decided, you know, workbench is going to be the, I'm going to say low-end module. It's going to be the simple straightforward version, not the kitchen sink approach. And we'll just do that and see where it lands. And that was a gamble to an extent to say, all right, we're just going to do, we're not going to cover all of these cases we know we can think of, but it meant that we could actually build it and build it well within the timeframe and budget we were looking at building it. And as it turned out, working with Dick and Tim on workspace and multi-version, that other 15% is being handled by that combination. And in fact, we were able to integrate workbench moderation into those modules as well so that that high-end use case can get taken care of by the combination of modules. And I think that really helped to just have that coordination of saying, by the way, we're going to want to do this thing in six weeks, keep that in mind as you're building this standalone, technically smaller version system. So, yeah, making that scope call was a risk, but it worked out because we had a coordination with others working in the same space. That's great, thanks Larry. Dick? So just to touch on what Larry said there. So we had our own initiative already going when we came into the program. So for us, the opportunity was really just what Larry said there. The opportunity to collaborate together with other people in the community. Because that, how strange it might sound, that doesn't necessarily happen naturally. I see issue queues and so on, doesn't necessarily give people the opportunity to get on a call, have someone that organizes that, pulling people together. So that was super useful. And something that might not have happened if we just had our own initiative going. So that was really to answer the first question there. That was what got me really excited. Excited, that collaboration opportunity. And for the last question, did collaboration within the DMAP accelerate your efforts? No, it slowed us down. A lot. Great. But for the very, very right reasons. We had, we were just pushing the button almost to publish beta versions of our modules. I think in November or something like that, back in November, that just got ripped up. All of that got ripped up. But again, for the very right reasons. So we sort of dove into a period after touching base with everyone else, saying okay, we need to re-architecture a few things here to make this work better across the spectrum of modules that we're working on. And I'm super happy with the outcome. It did delay us, it did sort of set up some internal goals that we initially had. But again, for the very right reasons. So it didn't necessarily accelerate, but the outcome is way better. And set us up much better for the future. Yeah. Did you want to talk about where multi-version might be going and its potential inclusion into core? Because there were some really powerful outcomes out of that slowing down process. Exactly, exactly. So during this whole process, getting out more in the community, talking to contrib developers, talking to more core committers, et cetera, there's been a lot of excitement around the combined functionality of many modules. So there's a suite of modules that we're talking about here. Workbench moderation, multi-version, and there's a module called Workspace and the Deploy module itself. That sort of combined suite of modules has turned into an official core initiative that Reece announced during the keynote today, of which I'm supposedly the initiative coordinator. So that's super exciting, which means that there is commitment with the core committers and in the general community as well to make this happen. So lots of details here that seem to be figured out, of course, and so on, but that's super exciting. Excellent. And that was very much an outcome of the collaboration that happened over the past couple of months. Great. So Ted, I know you have stories to share, even though you're shy, sir. So I worked on a few modules. I think one sort of interesting related to the question was scheduled updates. And probably one of the ways I developed it differently because of the program was initially it was for scheduling work bench moderation updates, but with a lot of the changes in D8, everything moving to fields and stuff like that is that we're able to make a module that just basically schedules the updates of fields. And I don't think I would have probably made it as generalized if I wasn't working on a larger team and getting more feedback. And sort of if I was making it just for myself or contrib in my spare time, or if I was making it for a client who had a specific really small need to schedule something, I probably wouldn't have made the time to make it a more generalized module to say schedule all the things. So I think hopefully it will be useful in other aspects of just work bench moderation. As far as collaboration with other team members, I think it really helped because working can trip a lot. And you do get feedback from people when you post issues or something or they post issues, but usually not in especially timely manner. So you might just have to make a decision, post some feedback or post an issue to get feedback, but you don't get feedback so you just kind of make the decision on your own. So to be able to have that daily call where, hey, I was thinking about doing this with the module where somebody might look at something or they just might, just the 10 or 15 minutes to put an idea out there and people say, oh no, don't do it that way, do it some other way. Yeah, that's a good way to do it. I think made the work across the different modules that I made better and probably accelerated stuff because I probably didn't go down as many dead end paths that I might have. If I didn't get the feedback and just like, oh, I'll just try this way and I'll try that way and I'll eventually find the way that I think works, but I probably would have hit a lot of more dead ends in that process. And I think also because it wasn't such early stages of D8 that all of that collaboration was more useful than it maybe would have been if it was, if D8 had been out for two years is because it's hard to know all the different problems or changes in D8. So having people who worked on core and worked on contrib modules to sort of ask questions right away. I think the benefit of being part of that team was a lot more important because of the time that it happened. Not that it wouldn't be important in two years, but it was even more important that it happened starting in November as far as getting a trip. Larry? Just to piggyback on that, one of the, I think really nice outcomes of this process is, Drew Blaise still knew a lot of the recommended patterns are different in eighth and in seventh, the way you go about tackling the problem is different and having a number of different people at a number of different places in the process of ramping up to D8 who can all collaborate on figuring out, okay, which of these seven ways is probably the best way given D8 for a problem was, I think invaluable, just saying, oh, I'm coming from D7, I would never have thought to take that approach to solve this kind of problem, but that totally works because D8 and that kind of being able to take the time and establish those best practices for D8 means that the modules we were working on had the eyes of a half dozen senior level people looking at the architecture together and saying, all right, this approach will work, this approach won't work because D8, this approach totally works now because D8 and lets us collectively figure out what those are rather than all coming to slightly different conclusions over the course of the next six months and then nothing being consistent. So a lot of things that I, even I wouldn't have thought of doing working with the other people on the MAP team and other people from Palantir who are working on it, we're able to say, what's the nice D8 way of doing this? Okay, let's all do it the same way. Yeah, and I think one of the concepts that was really strong in terms of changing architectures was the idea of the plug-in system and we found this with the workspace preview system that we're looking at integrating into lightning. Lightning might have a slightly different use case to other people who are using the module set that Dick and Tim are building out and when we're thinking about systems of resolving conflicts of content, it's really specific but because we have a way to build a generalized module and then integrate, then build out certain methods to decide how this particular project needs to approach that problem, it gave us a much more generalized architecture. David, you worked with us on panels and David also still building Panoply and are involved. One of the co-maintainers of Panoply, we are still pushing forward relatively slowly on Panoply for Drupal 8. If you're coming to the sprints on Friday, we're definitely going to be working more on the Panoply for Drupal 8 and all the panels ecosystem modules. So the effort to bring panels or some sort of block and layout system to Drupal 8 had been going on for a really long time. I've been involved in it for like the past two and a half years. So when the module acceleration program came around, like we already had an existing team that was already executing a roadmap but relatively slowly since we were all doing it in our contrib time, my contribution up until that point was primarily organizational, getting everyone together and figuring out where we are and how we're going to move forward and making sure that everyone talked to each other. This program was awesome because I could finally sit down and write some real code, which was really cool. Otherwise, it's trying to find client work to fit it in. And if you're doing it just in your sort of community open source time, I mean, I got to write code at sprints. But no, this was really cool. We've been doing it for two years until the acceleration program. We still have a lot of work to do to get the panel's ecosystem fully feature complete in Drupal 8, but we made more progress than we have at any other time during this program. So yeah, it was just super exciting to say, this thing that you're doing in your free time that you love and that you care about, like, hey, you can get paid to do that instead of client work for three months or four months. So yeah, I think this was a fantastic effort. Great. Adam, I'd like you to talk a little bit about our decision around web form. And then, I'd love it if other people would chime in because this is, we had to make some tough decisions in terms of what to accelerate, what would have the most impact. You know, we thought about a grid of, we thought about a grid of high impact, high difficulty, low impact, low difficulty, and what we could execute and what would make the most difference with the resource available. So. Yeah, we were actually moving forward with the port of web form at one point. I think Ted had already taken that on. He could talk about it a little bit further. And then what would happen, I think it was a result of the everybody that's on this panel plus quite a few more, you know, really thinking it through a little bit more and looking at what we considered our 80% use case scenario and what we could achieve with contact in core and contact storage and maybe just a few hours towards polishing those up a little bit. And what we ended up realizing was that our 80% use case was essentially metal already. So that was, I don't know how many hundreds of developer hours saved in some regards. We were able to polish up contact and contact storage a little bit, meet a couple of use cases that weren't met with those with some resources. And now we're waiting on somebody to really need web form, to actually port web form, which I'm not sure when the metal happened. But that was another one. I think that the role that we brought up before is identified, you know, there are some things that contact and contact storage don't do, but I don't think that those are 80% use cases. So yeah, that was a tough decision. And like we said, we were moving forward with it. I think that we made the right decision by catching it. Yeah, and if we, when we have the questions at the end, you know, I'd love for the audience to put forward their modules that they're interested in and we can talk about, you know, whether they're in process or whether they are in priority list and, you know, and how we can prioritize them. Does anyone else have anything to say about web form with that particular kind of dilemma around modules? Another kind of generalizing that a bit. In many cases, there's a module that existed in Drupal 7 that doesn't need to exist in Drupal 8 or, you know, the 80% of that module that you would have used it for Cork and now handle on its own, like contacting one example and then is it a better use of time to just make contact in core that extra 20% better and then web form doesn't exist, contact module is just everything. Maybe, you know, there is talk of that. But, you know, don't look for a particular module name that is or isn't the D8 yet. Look for functionality and capability that is or isn't ready for D8 yet because it may be coming from a different angle and be way better and already works. It's just under a different name. So be open to that. Yeah. And, you know, one question I've got for the panel is because we often have clients approach us with a list of user stories of functionality. What do you think of best ways to find out what modules are out there that potentially fulfill that functionality? Knowing that they use something in D7, now they're gonna have to look in D8. What would be your way of finding out how to get something done in D8? The reason Larry wants me to answer this is because I still write all of our project estimates. Okay. So the answer is basically, you keep your ear to the ground in the contrib space, but you also have to know what Core is capable of. So yeah, it's true. I was actually trying to convince WebChick this morning that she didn't need Webform. She's like, you know, what's gonna be the great thing of Drupal 8.2? And I'm like, put contact storage in Core and say you don't need Webform anymore. She's like, we can't do that. I'm like, yes, you can. It's a marketing problem, not a technical problem. We can solve. So yeah, you need to know what Core is capable of now. There's some great stuff. I remember seeing Michael Schmidt from who's he with? From a Maisie lab doing a talk about, well, here's what you can do with blocks in Drupal 8, which means I don't need these eight modules anymore. That was a great presentation from Amsterdam last year. So knowing what's going on in Core is important. And then we're at a state now where just sort of watching new module releases as they come out. I was working with some of the Acquia folks on a gigantic RFP last week. And there were like three modules released last week that tick requirements off for that project. And it's like, well, great, now I don't have to write that. So I mean, that's really what you have to do. But from a non-technical standpoint, like I said, as a product donor here, basically telling Larry, no, that's not in scope. Don't do that. But I'm the one who was advocating for the 75% use case, right? Just giving the development team requirements and actual use cases and actual personas. I mean, Dick and I had an argument this morning where he's like, oh, this is really important. And I was like, no, Dick, that's a 10% use case because Pfizer is special and Pfizer is huge. And 90% of people who use Drupal don't need that feature. So that's my advice. Have arguments, got it, okay. I'm not saying to have arguments. I'm saying, I'm actually saying to present some evidence. Yeah. That says this is the expressed need. Here's who is expressing it. And this is why that's important. Great, thanks Ken. Tim, I'm not gonna let you escape this process. I'm sure Atnovation has an approach for this, so. If I can say what Ken's already said, it's just a case of keeping your ear to the ground and seeing what's sort of coming out. And the best way I find is social media. And everybody's tweeting about what they're up to. There are Twitter accounts about core changes and about contrib changes. Just keep an eye on them and see what's being released and see what's getting out there. Yeah, there's so much good stuff going on. Yeah. Adam, I know that there was a channel on IRC D8 ports as well. Yeah, IRC, I was gonna say that at the very beginning. Not everybody uses IRC, but social media covers that. We do have a channel, Drupal 8-ports, where most of the members of this team tend to hang out and hash out things. So that's a great space. And people are generally pretty friendly and willing to answer questions that you might have about specific modules, too. So Drupal 8-ports, yeah. Maybe we could kick-start the hashtag, yeah. The follow-up to something Tim just sort of jogged my memory. This is, again, not a unique problem to Drupal 8. Dries mentioned his keynote, right? It's like, I've seen this cycle over and over again. The first time I ran into this was actually in Drupal 4.5 when NodeQ came out the day I decided I needed it. Literally, I was about to write it. I was like, I better see if anyone's done this before. And it was released like an hour later, it was great. So, again, this is not a unique problem space. And the community knows how to handle it. I do really like this kind of project. I've got more to say about that, but we'll let Larry talk. One other note on that. If, while working with Drupal 8, you come across, hey, I would have done this thing this hard way in Drupal 7, and now there's this easy way in Drupal 8 that it wouldn't have thought of, please write a blog, get it on Drupal Planet so that everyone else in the room can read the blog and use the easy way too. So if you're not following Drupal Planet, follow it. And if you find a way that is, oh, contact module solvers, they don't need a web form anymore, or whatever else you run into, tell people about it so that they can benefit from it too, because everyone can give. Yeah. So just three concrete tips that I sometimes use for searching for new functionality and so on. One, I search Drupal Planet, and then two, I go to Drupal.org slash list-changes, which is a summary of all the change notes in Drupal, both draft change notes and published ones. Super good summary, high-level summary in sort of natural language that summarizes new functionality, and then I also go to Drupal Association's YouTube channel and just search for a module name, and there is gonna be a presentation about your module there, either how it works in Drupal 8 or why you don't need it, because these are the things for places in. So those three things, Drupal Planet, Drupal.org slash list.changes, dash changes, and then the Association's own YouTube channel. Great tips. I'd like to add to that that JAM has also been running a module of the week program where he highlights modules that are ready to go, and so that's a great place to look for modules as well, his blog. So I think there's a question in here for Ken, which is what effect do you think the program may have had on Palantir, building out Workbench and building out that ecosystem? How do you think that affects your business? It's really good for our business. I'll say, this goes to what I was just thinking. I mean, there are three basic models for module development, right? One is, solo developer has a great idea, wants to get it out of her head, she writes it, she releases it. That's a great model, I've done that before. Two is, someone comes to you with a requirement and pays you to do that thing. That can get you some really interesting challenges. The example I'd have is actually for Dave, because in panels for Drupal 7, we had one of the panel's contributors on staff at the time, so we have a client site still using like panel 7.1 alpha 2, which then got trashed and forked and never used again, and so it's a dead-end code branch and that site is just stuck. So those are both siloed approaches, and then you have something like module acceleration program where it's like, okay, let's take a bunch of people and let them collaborate, and yes, they're working on different things, but again, they're working on the same types of problems. So for instance, even in the work that I've been doing, sort of in my side, it's like, I talked to Larry about data storage, which is a very different thing in Drupal. So that's been really, really beneficial, and I will also say actually to John and Adam's credit, the other thing that MAP gave to us as an agency was some deadlines, right? Deadlines, this is the other dirty little secret, right? Deadlines matter in software development, right? Because without a deadline, you're not going to finish, right? Because you're not gonna make the hard choices you have to make in order to declare something. So that's what I think we've been able to do, and what that's gonna do is, again, generating a lot of excitement. We're doing a workbench, I'll give you an example, we're doing a workbench webinar, right? The last webinar I did had three attendees. The workbench webinar got two dozen attendees within two hours of its announcement. That'll be on the 24th, by the way. I know now. I know now. No, that's great. Is there anyone who wants to add anything I'm gonna skip on, probably for a couple of minutes, describe Lightning and then get to the questions. Is there anything else from the panel? Cool. All right, I wanna talk to you just for a minute about Lightning. We couldn't have done Lightning without MAP. So many of the modules that we built in MAP are now in Lightning. And it's another way that Acquia is giving back to Drupal. This is a completely open source distribution. It's available on Drupal.org and through Composer. And it's for enterprise authoring. So that means that it wraps up certain functionality. And for Acquia, we, by default, when we build on Drupal 8, we build with Lightning now. That's not gonna be for everyone, but the type of client we have where they need to have sophisticated authoring functionality, that makes sense for us. And really, what Lightning does is it serves the developer. It accelerates the development experience. It gives you that 20% of the beginning to get going. It gives you standards and module configurations so that the developer can serve the site builder and the content author and the site designer, giving them the tools they need to build out great experiences. So Lightning is a foundation or a starter kit. It tightly couples over 20 modules and configures them. It's a lightweight framework with documentation and best practice examples for Drupal. And it's really made up of four functional areas, layout, workflow, preview and media, and three development principles, security, integrations and testing. So layout really wraps up a lot of the work that David did for us in the panel's ecosystem and gives you things like drag and drop layouts, changing how many columns you have on a page, being able to create landing pages. And workflow brings arbitrary workflow states. It's really workbench moderation and configuration that we've brought to be able to allow you to put content through a workflow. In preview, we're gonna be bringing from a workspace preview system, which is what Dick and Tim have built out and will be in Lightning 1.1 and media. We've got so many people to thank for media integrations. There's too many for right now, but the ability to bring in social media into your web experience. So Lightning wraps all this up with some automated testing. It's really useful for developers. So we've got B-HAT tests. So if you're building on top of Lightning, you can actually test whether you've broken any of those modules or their functionalities. And that should mean you can go really fast and set up continuous integration and continuous deployment. Lightning's got great adoption. We've had a bunch of people in our beta program from large agencies like Miram and VML and Phase 2. Princeton EDU is gonna launch on Lightning in the fall and One of Music is using it for their next big platform. And there's lots of people coming onto Lightning. As I said, Acquia now uses Lightning by default for every build they do on D8. So Lightning's available on Dev Desktop. As I said before, dribble.org through Composer. And there's a lightning.acquia.com site for developers. So they know how to install it and how to upgrade it, which by the way can be a one line upgrade. We'll provide an upgrade path between all versions of Lightning and you basically get functionality for free as we build more into Lightning. So I wanna now go into a Q&A session for the panel. So if you wanna step up, I'm not sure if we have a second microphone. What I'm gonna do though is I'm just gonna see if I can, that's not gonna go. Okay, so if you step up and ask a question, I'll repeat your question and then the panel can answer. So if anyone wants to come up right now and form a line at the pole, the mic-less pole. If you talk, I'll be able to hear you, yeah. So I might let you repeat that one, Larry, just so we've got the question on a record and then you can answer it. The question was, there's also a module called Workflow. So what made us decide to go with Workbench Moderation over Workflow? We actually looked at the Workflow module and considered using that as a basis. What we decided was a lot of the functionality was similar between that and Workbench Moderation, but it had enough other things tightly coupled on top of it that we would have had to rip off, in a sense, and that would also add another dependency that we didn't wanna bring in. So it ended up being less work to just have our own states and transitions and then lay our own functionality on top of that rather than trying to fight what another, the assumptions in other modules are already making. I would love to see just the states and transitions concept become its own thing. Spoiler, that's something we've been talking about, may end up in core at some point as it's just a thing on its own. And then if you wanna extend that in contria, then you have a more common baseline for it. That was basically the thinking there was, fewer dependencies to have to work around and just let's just get this thing working nicely. We actually brought the developer into a couple of meetings too. I think that's worth noting. We did some collaboration and I think we kind of mutually decided that these were two independent projects just for the record, yeah. Great, thanks. Adam, do you wanna reiterate the questions so we've got it on the mic? Yeah, so the question was triple comments to using external libraries and any uses for external libraries and stuff that we're doing. There's not so much have you found. This is a use case we have that tons of other people have. Did you find any opportunities to take things and be like, oh, we've solved this problem, let's, but it doesn't have to be as tightly coupled to Drupal as it's been. So continue back to PHP, not exactly back to Drupal. Right, so the one thing that we've been doing with our deploy modules, so multi-version workspace and deploy is we allow cross-site content staging. So you can have a staging site in a production site and move your content between them. For this we're using CouchDB's API and we've got a couple of external libraries that we're using for that. One of them is a PHP replicator which uses the same protocol as CouchDB to replicate content, but it's all written in PHP. This uses then a CouchDB client which is a Doctrine project. So we've also been contributing back to that as well. So we include this into the relaxed module via Composer as external PHP libraries. The replicator was actually done as a Google Summer of Code project last year. So Dick mentored a student last year for Google Summer of Code. And we're planning to do the same again this year. We've got another Google Summer of Code project and we're looking at building out a conflict management system. So when you're replicating content between sites or between workspaces on the same site, we'll both be able to flag up and resolve conflicts with an external PHP library that can solve these conflicts. Great. Is there anyone in the room? Oh yeah, we got another question. Oh yeah, oh. So the question was what's missing from contacting contact storage? So I made entity form for Drupal 7. So I think I made sort of like the alternative that does the 80%. But I think the thing that web form does really well, there's a couple of things. One, having tons of forms. And two, having some forms that have just tons and tons of fields. So the fact that contact or entity form or e-form would use the field system is gonna bring some complications if you have like a 500,000 field form, which apparently happens. Cause there are some, like there's a big issue on web form about porting to Drupal 8. There's a really long discussion about the benefits and should we just make it all bundles and fields and you know, I sort of put my two cents in there and I think general consensus was you'd lose some of the functionality if you did that. So I would think anytime you're thinking of like forms as content on your site, I feel like the contact form solution maybe falls down a little bit because contact forms are a config entity, your fields are config entities. So if you really wanna hand off making forms to your clients right now, I'm not sure that contact and contact storage is the way to go and I was sort of one of the people that talked them out of porting web form basically. They hired me and web form was the first project and I said, oh, you don't need it and please hopefully give me something else to work on. So yeah, I mean I think, but it's hard to say like what percentage that use case is but I think a lot of people use web form in Drupal 7 for stuff that wasn't necessarily where web form was great for. My feeling is if you have, if your forms are gonna be made by site builders, then maybe web form is not the way to go but if your forms are made by your clients on an ongoing basis without necessarily contact with you or Drupal developers seems like that's where web form really shines. Yeah, so the short answer to that question was if you really wanted web form in the map project, blame Ted. I mean, I think. Repeated Ted. So he was reading some of the contact comments on Jesus last post about, I don't forget what it was. About the better interface they potentially had through web form and that might actually be with form builder that you're talking about which is an extension to web form. I think there's a gotcha to that is web form when you make fields is not making tables in your database, anything else you do is making fields in your database. So I think the idea that you pass off, you could clean up the field UI and make it sort of simple and there was like a attempt at that in D7 but if you're clean it up and make it easy and pass it off to your clients, you're not cleaning up the fact that underneath they're making tables in your database and they're scaling, I think they're scaling issues. I'm probably not the best person to speak on that but you're doing something, even if you change the interface, you're doing something fundamentally different with any other, basically any other form system in Drupal besides web form. On web form, it's not producing new tables, all the submissions go in the same place whereas contact storage and e-form in a new form in Drupal 7, like every time you make a new field you're making two new tables. Right. Yeah, so it's a whole different sort of storage and I think just cleaning up the field, just cleaning up the field UI or making a form builder on top of the field UI to make it easier for clients is not really, I feel like almost you're opening up a can of worms that, oh, I made the field UI a whole lot easier and now I'm gonna pass it off to my clients and I don't think you're passing off something to your clients that they don't like. Larry vigorously shakes his head. Implications up. Okay, we've only got a couple of minutes left so are there any other modules that you're interested in specifically from the audience? Anyone wanna raise any particular modules that you think should be prioritized? You think we should be thinking about going forward apart from web form? Anyone in the audience? Yes? Organic groups? Or is that already in the program? Organic groups, it is not currently in the program. We suffered a similar, oh Ted, do you wanna tell them why we're not including it? No, no. I can't. I don't know that, I don't know that. I know, have you looked at the groups module? It seems like a lot of people like the groups module. I mean, I love organic groups, it's crazy flexible but it's also hard to configure and I'm not sure that everybody needs the crazy flexibility. I haven't actually used the group module myself but I've talked to a lot of people who really sort of like it and basically the main difference is groups are their own type of entity whereas in organic groups you add a group field and you can make anything a group. So organic groups I think still they're developing it but you know- They are developing it, yes. Yeah, it gives you crazy amounts of flexibility but there is something out there now if you needed something group like but you look at the groups module and say hey, this does what we need and it seems like there's a podcast on modules on Ravel, the developer talks about it so it seems like it was built in a pretty sane way so it's fieldable and I think memberships are fieldable and stuff like that. So you do get some of the flexibility of organic groups is just not the flexibility to say hey, I want this user to be a group or a term to be a group. Thanks Ted. Got a question out the back, yeah? Drupal console. Okay. Okay, interesting. I don't think we've got any comments on that. We haven't thought about Drupal console yet being a command line tool rather than a talking stick, Adam. Yeah, it's been brought up before and I know you've reached out to me directly and we're definitely interested in that. It's not something that's something that we need to discuss. Let's talk. Yeah, let's talk. It doesn't fit the strict definition of what we've previously put in the module coloration program but I personally think it's very worthy and I'd be interested to find exactly what we're looking and what it needs to get pushed across the finish line. So just to wrap up, unless we've got anyone with a burning module they want to talk about, no? Okay, great. So just to wrap up, Adam, you probably got an idea of a couple of the modules we have coming out fairly soon and in our roadmap and things that we're focusing on we've just brought on MD systems that are going to be working with us and commerce guys have just signed up to work with us. So we've got some amazing developers who are coming on to build out some of the Meteor ecosystem and Adam, do you want to? Yeah, that's not so many real Meteor modules anymore. Like a lot of the big ones are done by the people that are sitting up here but Fast 404 is Ultimate Chron and then a lot of like pushing across the finish line stuff in the Meteor world, the Drop Zone module in the Meteor world. There's over a dozen modules in the Meteor world right now that we're looking to push across but those in Ultimate Chron, Fast 404 is. Yeah, so we hope that that will spin into the Meteor initiative as well and really help drive that forward. So if you'd all give a big hand to these guys they've done a hell of a lot to advance the module ecosystem and they're really fantastic developers. Thank you much there. Oh, we've got one more. Go Dick. And me and Tim, we've been sitting here sort of representing the multi-version workflow modules. Yes. But we also have Andre here in the room. He's done a huge amount of work on these modules as well. So he's sitting here on the front row, give him. Thank you very much. Great. Larry? Let's get around for the create team who's coordinating all of this stuff and courting the wee cats, so. Aw, thanks. All right, thank you very much for coming along.