 I'm Jacob and I've probably met a lot of you before and some of you excited to meet today. I want to preface this talk by saying that you've been all fooled and this is not my talk at all. I actually inherited it from a colleague of mine who actually runs this program at Aquia and he was unable to come but it's actually an important topic and I think kind of interesting. And so he said, hey Jacob can you do this instead? So if it's bad you can blame him and if it's good you can give me all the credit. And I will have a couple people coming in. I think I'll probably answer a lot of the questions so let's make this look collaborative. I'm going to pass the mic around and figure it out. This is not working, what's going on here? That's odd, arrow keys aren't working, even that's not working, oh there we go. Now are you going to advance 10 at once? There's a lot of metaphors people use to explain open source in Drupal. How many of you are an open source developer? The rest of you what are you doing here? And how many of you are open source developers, how many of you go to parties? Wow, that's great, hold on. And then when you go to the party are everyone else an open source developer? Generally not. And so when they ask you what you do, what do you say? Software websites, anyone else? And what if they really like you and they want to get to know you and they're like what do you mean software websites? What does that mean exactly? Then what do you say? Yeah, brand websites. And they'd be like what's interesting about your company or your field then what do you say? Nobody? Nobody tries to explain their work to anybody? I get paid for doing free stuff. You get paid for doing free stuff, that's a great answer. What else? How do you describe Drupal to somebody who doesn't know? What it was if someone says to you if Drupal is open source then how do you guys make money? What do you say? Make life very simple? Right, so I think we hit across an actual problem here which is very hard to describe what you do. So a lot of times we use metaphors for that. For instance, has anyone heard that open source is free as in puppy? That one? What does free as in puppy mean? The puppy's free but you still have to take care of the puppy and that's part of it. One of the metaphors we often use as anyone heard of like a public road, like a rail system or something. We all need the road so we shouldn't all each own individual blocks of the road, we should just build a road for everyone to use, public commons and all that. What is the most common metaphor you've heard to use explain Drupal before? Legos. I know that Legos are super popular in the US and I think they're popular here now. I don't know if they were when everyone here was a kid. Who here played with Legos when they were a kid? Raise your hand please so I know. That's it. So who here knows what Legos are? Wow. Okay, we'll have to explain what Legos are. You guys really don't know what Legos are. You've never seen Legos? That's surprising. Okay, back up. So Lego is a set of plastic bricks that you can snap together to make just about anything. It's got wheels and it's got little flags and there's all different colors and all different shapes and you can snap them together and they stay together really well. You can build spaceships or cars or whatever you want to make. That's what Legos are. And why do we say that Drupal is like Legos? Well, one of the reasons is that it's got a lot of parts. Drupal's got tons and tons of parts. We call those parts modules or themes or the things where there's all these different parts you can assemble. You get this huge box of parts. It's not just one or two. You can't just pick red or blue or black. You can pick every color and every shape. There's so many different ways to do things. There's a lot of parts. If you use those parts in the wrong way, you can really hurt yourself very badly. That's another thing about Drupal, just similar to Legos. The most common reason why we say Drupal is like Lego would be what? You wouldn't know? I guess? What? Do you raise your hand or are you just stretching? I caught you. The main reason we say that Drupal is like Lego is that you can build all kinds of stuff with it. You can build all different types of contraptions and all different types of cities and forts and cars and whatever with it. Similarly with Drupal, it's not limited to just one type of application and building it a certain way. It's not like word. Word is what? Word is a word processor. It's always going to be a word processor. It'll never be a spreadsheet program. It'll never be a Wikipedia thing, whatever. Drupal you can make all kinds of things with and that is fantastic. There's a million ways to do it. There's a million ways to build it. You can snap all those pieces together and create anything you want. Flexibility is awesome. What is it? And if you agree with that statement, raise your hand please. Okay. And if you are a programmer, raise your hand. It's the same answer. This is you. The programmer represents, this is the IT buyer in an organization. Someone who is responsible for making sure that we can build things efficiently and fast and keep them running insecure for a large enterprise, any enterprise. And they love flexibility. That's really key to their job. That makes sense. Ask a really question. How many of you can drive a car? Okay. How many of you can fix a car? Even like oil changes, spark plugs? One or two? Yeah. Cool. Because my car is outside. I'm going to change the oil. Okay. And how many of you would prefer to buy your car or build your car? How many of you can build a car? Yeah. I don't think anyone in this room can build a car. So, when you look at that and you think, building a car? No. That sounds cool, but I've got other things to do with my time. I need to get to office. My job is not to build cars. My job is to get to office. That's the business buyer in an organization. That's the marketing head or the sales head or whatever who's responsible for getting results out of the software that's being built. In this person, they may appreciate technology. They may even be very technical themselves. But their job is to put the right content in front of the right people at the right time so that they do something the organization wants. You buy something, sign up for something, tell someone about something, whatever it is. That's their job. And building software is a nightmare for them. It's a huge distraction. Your job is to get to office. Your job is to go on a date. Your job is to get to grandma's house on the weekend. Building a car would be a huge distraction for you. And this brings up what we call the build versus buy sort of argument and the build versus buy problem. One side we have it's flexible and the other side is it's easy. And we can't just solve one problem. It's not enough to say that one of these guys is wrong. They're both required for the organization and they both have their needs which are relevant. So how can we figure out a system wherein there's something out of the box that will solve the goals of the business user that has his domain in mind, understands his problems and knows how to solve them. At the same time being flexible enough that you can enhance it, that you can build upon it, that you can create other things with it. It's a flexible system. Anyone have any ideas? How do we do that currently? No answers? Distributions. Distributions, yes. So how many of you know what a distribution is? Okay, how many of you have used one? And how many of you use one on like every project you do? Yeah, that went from like 50 to 20 to 2. Distributions have been moderately successful at solving this gap but not always getting there. So a distribution for those who are not aware is we take, you know, you have core, triple core, and you have a site. In between that you have a distribution layer. So a distribution is core plus a bunch of modules you'd use all the time and some configuration to stitch them together. On top of that you build a site. That's how it's typically worked. And now, you know, and then you can translate that into multi-sites to produce multiple sites. A lot of big enterprises don't produce one site. They have a distribution which may be like an insurance company. It might be a distribution called the insurance representative distribution. And every insurance draft gets a separate site but it's all based on the same distribution, you know, or something to have you. And so lightning falls in there. Lightning is a distribution for Drupal. It's a set of pre-built modules that are configured to work well together that you can build on top of. One of the key design differences though that we thought about with lightning is we said we want to make the best content authoring experience in the industry. Not just Drupal, right? And we know that we don't know what best is. We at AQUIA are not going to figure out what best is. IF3 even is a best because every organization works differently. We are not a marketing organization. We are much more the geeky IT guy with the C colon coffee mug. And we probably would not do a great job of it. So what we'd like to do was to say, hey, there's going to be this base and then there's going to be enterprise customizations on top of that that we can expect are going to come. And on top of that we're going to build sites. So we're trying to build a distribution distribution as it were. And provide a lot of really clean, really well-built components that sit underneath the enterprise customizations. Everyone with me so far? Yeah, okay. A little more specifically, unless theoretically, what problems are we trying to solve in lightning? I think these are problems which have played Drupal for a long time and we're trying to tackle the most difficult ones. We're going to follow layouts. So layout is something where both the block system was traditionally very inflexible. Panel system is incredibly complex and heavy. We're trying to be somewhere in the middle where a marketer can just say, okay, bop, bop, bop, my page, done. Put it off to market. That's something that's just been hard to achieve in Drupal today. Workflow, pretty good in Drupal today, to be honest. Some of the things that aren't there, though, is if you want to preview multiple pieces of content to publish at the same time, that's been a challenge traditionally. Maintaining multiple revision trees of content can be a problem at times. That's what we're focusing on. Again, the previous thing I just mentioned, seeing how the site will look, assuming that we publish four or five things at once, configuration changes as well. Media handling, that's kind of a difficult scene in Drupal, of which I'm partially responsible for. But anyway, that's a separate thing about embedding content, embedding rich media from other sources. And then, of course, at the other bottom layer below that, we're also looking at things that are really important to enterprises and having those pre-built in, making sure that we have automatic testing, security layers, et cetera. And without further ado, I've given you the reasons behind lightning. We can do a quick Q&A now, and then I have a demo video that was produced by the head of the lightning team, who's not here. Those of you who came late, this is not my talk, I'm sitting in for somebody. I mean, I made the talk, but it's his program. So I'm going to show the demo video. But any questions before we do that? Take a break? No? Okay. Is everyone ready to fall asleep? A little after lunch? Watch a movie? Sit back in your chair? Should I turn on the lights? All right, let's see a video, and we'll talk a little bit. It shows a little bit of features. This is still very much a work in progress. It's still a beta sort of product at this point. We're making a demo of a site which is trying to sell drones. And we're making a... We're going to create... First, we're going to create some content. We're going to create an article, a blog post on this site about a different kind of drone. And, you know, for that, we're going to need a little bit of content. So I apologize that this is all about bacon, and I understand that India's 20% Muslim population, but this is made in America. It wasn't my doing. So we're going to use this thing which is full of bacon words, like Laura Wipso. And we paste it in here. We're going to show a little bit of the media handling, so how we add rich content. This is Drupal 8. Yes, lightning is Drupal 8. So we go to a YouTube video. And this is not a cooking show. This is exactly how fast, how long it takes to do things. We're copying the YouTube URL. And then we go to the media library. We can pick existing media, or we can paste it in the embed code from YouTube. And we can save it to our library to use it later. And that will embed it right in the middle of the post. And now we're going to, again, create an embed. We're going to put an image here. This one we're going to upload from our hard drive. You just drag and drop it in there. And, again, we want to save that so we're going to use it later. And then finally, we're going to want to add some social media to the post. So let's do that. Over here we're going to Twitter. And we're going to find a tweet that we want to add from New York Times. So we copy the tweet URL, putting it back here. Again, for the embed, just paste it in. And he gives us that nice embed. And this is built for a lot of services, and it's a pluggable system. So other social networks can follow suit. What's that? Yeah, I think it is own, but I'm pretty sure. But, again, Q&A is probably not, I don't have all the details. But I have actually one of the guys in India who works on this team is actually going to come here and he'll be able to give you a lot more information. Cool. And so that was creating a piece of content. This is creating a landing page. So landing page being a more complex page around a specific topic, with its own layout and its own different blocks of content. Cool. So here we're going to be adding some blocks. In this case we're using just standard sort of Drupal blocks that are built the same way with embeds. And we're going to be adding another block when it gets down to it. The video block. Again, just built using a standard Drupal block with a video embed, just like we did earlier. We put that in our different regions, so the different regions for the layout of the page. And then here we can see how we can change the layout. We're going to add also an Instagram block. So this one is in a second. It comes to it. So this is a layout picker. You can pick different layouts and change layouts on the fly. And all the content will be positioned. And then you're also able to then resize it and be responsive. Here we're going to add a list of tweets from Twitter. This is a live thing coming from views. This pulls straight from tweet entities using the view system and entity system. So we can pick those. We want five tweets to show. Another call to action. Got it. There we go. Now the page is done. Or maybe it's not done. Sorry. That's pretty much all it takes to create a landing page. It looks like this. This is stock lightning out of the box right now. And the whole thing is responsive all the layouts, which is pretty much more of a Drupal 8 thing, but it also is part of lightning as well. Pretty cool. So we're getting there. I think it's looking not so bad, right? I think it's closer than I thought when I saw the demo. We're going to look at workflow a bit and how we handle revisioning and moderation. So this is back to our original post here. We're going to edit the draft. And make a quick change here. And that came from the media library. So we had that tweet in our media library, which I think is kind of cool to sort of newish feature. Now we're saving it as needs review, to the workflow state. None of this is particularly revolutionary. This is really the same kind of stuff you saw in Drupal 7 for the most part, but it's now working in Drupal 8 thanks to the lightning team. And now we're in editor review. And again, an editor can come in here, see a dashboard of everything that needs to be approved. The editor can go in and approve it or send it back and give comments on the workflow state. But then after it's published, assuming if there's anything that's wrong with it, the revision history is maintained and anyone can revert back to an earlier version. Again, none of this is particularly revolutionary, but in Drupal 8, things are still working in progress. So some of this stuff didn't exist a month ago or would have hurt two months ago. It is now working thanks to the efforts of the contrib efforts here. But a sort of more interesting one is probably where I scheduled updates. So here we're doing this and we're saying that we're going to want to release this content only on a given date, which obviously now is in the past, but not when this video was made. So we're saying that when the time comes to this, we want to change the state to published as that goes into the system, and that also works now. And that's pretty much it. I mean, that's the demo we have right now. So any questions about that? No? Good. What's that? I don't know the exact count of contrib modules. I think they say the team is like 20 or something to date. It's around there right now. I'll get to the team in a minute and who all is involved in this and how it's happening. This is a contrib effort primarily. The team that Gabor is on is the Octo team, and they're all full-time working on Drupal Core. So there's five or six of them and they only work on Drupal Core. And solving some of the biggest problems there. This team is specifically focused not just on contrib, but on solution space. Upgrading all the contrib modules and then making them secure, making them testable, and making them pretty and work well and work well for customers. So one of the reasons that... Well, let me ask you this. When we went from 20 people who had used a distribution to two who used them on every project, what is the delta there? Why is that not happening? Why did it not use distributions to become bulkier? Okay, anyone else? Too rigid, yeah. Too rigid meaning they have one way of doing things. It's hard to do it any other way. They're not like Legos. It's more like an action figure that you buy at the store. You have the chop of his head to get anything else on there. Anyone else? I think those are the same sort of things, yeah? Right. Because you're trying to undo so many things. You have code that's maybe conflicting with your code that you didn't write in your own thing. So I think, yeah, past certain point of complexity, distributions can be difficult. And so we tried to think about that differently in this case again. So we made a huge focus on automated testing one. So we said, we should upgrade the modules cleanly from 7 to 8 with roughly the same functionality as a first step, and we should make sure they have great testing behind them. We use behavioral driven developments. We use B-hat for that. And those tests are run on a regular basis. We make sure that each individual unit works really well as a unit. So they're not heavily coupled, I'll be sure. With others. You know, another one is our sort of philosophy around, there should be a toolkit. It shouldn't be a specific experience. It shouldn't be that we're building a distribution meant for a particular person, a particular use case exactly. It should be more of a toolkit. And so we're hoping that makes it, that keeps it lighter. You know, in Drupal 8 we have auto loading, which also helps with code bloat. It's not as much of an issue perhaps. You know, and I was going to add here. And we're also trying to do this in such a way where we're working with the community more as opposed to trying to build a solution for customers. We're really focusing on just improving the control modules as they are in the ecosystem and letting other people build those customer-centric solutions on top of them. It's a big risk for Acquia, but I think we'll see how it goes. And, you know, I think it's ready now. Like, you can use it. This is a bit of a beta... We don't have sites in production with Lightning yet, but you certainly could start building on it. Like I said, it's really just a very light layer on top of core and very commonly used control modules. So rather than tracking your own Drupal 8 and all those control modules that you need anyway, following a Lightning project is probably actually a really good move right now. I think it's certainly going to be stable enough to do that. Again, it's all about testing. In fact, it can be a good guideline as you get into Drupal 8. A lot of you probably are wondering, which modules can I trust? Which ones are ready? How do I get started? We're trying to provide that guideline to the community so that you can just follow Lightning and say whatever's in Lightning in the stable channel is going to be stable to build on. Or if it's not stable right now, I'll be told it's not stable. And I know that it will eventually become stable. So you can start using that for your projects. And all of this is built by a program we call the Drupal 8 Module Acceleration Program, or D8MAP. We have 15. That's actually not quite accurate. I think it's like 12 or something. Full-time aqua engineers who are dedicated to just doing this. All they do is upgrade contributed modules and refine their usability and do testing on them. Three of whom are in India. One of whom is here. We check on them. There he is. And that's what we do within Aquia. And then at the larger team, we put together over half a million dollars in grants. Which we are paying community members to work on their projects. So examples of that are like who are the good examples of that? They work our field. Workbench rules, Fago and Rules. Yeah? Okay, the multi-version module. You guys are getting paid on top of your jobs to do that? Not bad. You guys are getting paid on top of your jobs to do that? Yeah. I thought we had a rule that we were going to allow that. This is shameless. Very sorry. But this session in this room, right after this session, we're going to talk about the multi-version module and a few other modules. We're not going to demonstrate them within Lightning, but Lightning is looking to use these modules in a later beta version for full-site preview. So if you're interested in that in regards to the workflow piece here, you might be interested in joining the session after this. So if you guys... If you guys don't know what full-site preview means, I think it's kind of maybe a new concept for some people. It means that you saw the scheduling one where I said on such and such a date I'm going to publish this article. Imagine if you do that with 20 different articles. Yeah? How can you see what the whole site looks like on that date? How can you preview the entire site? Or say, I show different content for users if they're from North India or South India. Personalization. How do I see the whole site in one side of this? Is that right? Is that a good... Not quite. How should I say it? It's certainly quite tedious. There's no modules that are not related. But in the next session in this room... Check it out. He's a really smart guy and he always has a good session. I'm sure it'll be good anyway. That's what we're doing. I think it's a really exciting project. I know for the team in India it's a really exciting project to be a part of. And I think it's a... It's scary. Maybe for Aquiat. We're spending a lot of money on this on top of everything else with the Octo team. But we feel like it's necessary for us to kickstart all these things and really get a first edition of all these modules out there and something we can build on. And a big part of that is your participation. We need you to test this out. We really need you to try it out in real world scenarios. We need you to get involved early and make sure that we do it the right way. That it becomes really a best practices toolkit for how to build sites in Drupal. We need your feedback. We need it now and later as a continual basis. So please do check out Lightning. Go for the download and try it out to build a little test project to see how it goes. Feel free to write to me. But even better, you can get in touch with John Kennedy about the Lightning product owner. You can find him online or on the product page for Lightning. And with that, I think we'll just go into Q&A. Okay? Thanks everybody. And I think for Q&A, I wish I could come up here and answer the questions. Does anyone have any questions? You know, I think... Repeat the question in the mic. Okay, sorry. So his question is, you know, Drupal as a product, if you create a distribution is essentially a product and you have multiple instances of that product. So you work for Stanford, I'm guessing? How could I guess? And so at Stanford, they have a base distribution. They say that every... Is it departments or... You're a high wire or something? I don't know anyway. So anyway, you have one sort of template for what every department looks like and you create different instances of that. And the problem is that each of those different departments can go crazy and make their own thing. And so how do you maintain some consistency while allowing flexibility? I don't know. You know the answer to that question? You've done this a lot, tried to do this a lot. I mean, I have some ideas, but I think this is a good job. We have a similar problem where I work as well and there's definitely not a very good answer to it, especially not in Drupal 7. That becomes very tedious with features and features overrides and things like this. We've put I think the place where we work. We have hundreds and maybe almost up to a thousand instances of the same distribution. So for us, at least, I'm not sure about your specific use case, but we've built a lot of automation and a lot of tools to discover where people have overridden things. So we have lots of process going out to each and every side, figuring out where things are overridden. And then it just comes down to human communication to sort of solve these things. There isn't necessarily a good technical solution to this. In Drupal 8, I'm not sure, but discoverability and documentation and introspectability, is that a word? It becomes part of that. And then it's a conversation of what should be included in the base distribution. What can we do? That's how we solve it. So we've built a lot of automation to discover when and where and then be able to document around that. Why was this documented? Lock this or whatever it might be. I could also add works for Pfizer. When I was on the Drupal Gardens team in the early days, that was kind of a similar problem, but at a different level of complexity the sites are less complex than what you're dealing with. They're less customized, but there's a lot more of them. So when you have 60,000 sites to upgrade and you're upgrading your base framework and they're all run by different people. Some of them was like somebody who walked dogs for a living. Somebody was a dentist somewhere. Somebody had a weird porn site they put up. There's all different types of people from different walks of life. They can customize it over they want. They can't write code, but they can still do it. One of the tricks we did, which of course is something that only large enterprises could do, is we wrote a suite of very basic tests for things like logging in, logging out, creating a piece of content, creating a view and viewing the view or whatever. Just very basic stuff. We'd take about 50 or 60 reference sites and we knew to be fairly active users and we took a random sample of another 50. We automated every build. We got a lot more than we had expected. We'd break very simple things sometimes and we'd cut screenshots and stuff. We did some of that stuff. It didn't always work though. That's a fun answer. Anyone else? One more insight to the problem space there with Drupal 8. I think the community is still experimenting a little bit with environment-specific overrides and I think it touches the same problem space with environment-specific overrides and so on. There's a very useful functionality in the CMI system or the system in Drupal 8 where you can do full import of configuration but then after you can do partial import of configuration. So if you google for Dave Hall he has written a blog post on environment-specific CMI configuration where he suggests like a layered import of you first do full import of the full configuration which also then deals with configuration that needs to be deleted and things like that. But then you can do partial import. So you could structure a git repository to say it's the base distribution and here's the partial import that you need to be able to do on top of that. So google for Dave Hall and environment-specific configuration you'll find this blog there. That's some of the things that we are experimenting with at the moment for managing that type of problem in space in Drupal 8 as well. I was going to show this. If anyone has any other questions I was going to just talk a little about the modules we've been working on. I was trying to get the list up. What's the password? Do you guys know what it is? Got it. Thank you. Let's do it in a round. So one is I mean Abhishek do you want to talk a little bit about the modules you've been working on or the teams you've been working on? So currently in India we are a team of three people. Myself, there's another guy called Naveen and Neetu. I don't think I can find those guys in the room. So we three have been working on we started with a module called Autologout and that has an RC2 version. What we generally do is we take the module from whichever state it is to a release candidate and after that it is up to the maintenance to get into the state version. So that's what we have been doing. We have put Autologout, we have put ShareThis and now we are working on Ultimate Cron. At the same time SecurePages. SecurePages is interesting because I think Gabor would be able to talk more about it. The functionality has been removed from the core and in the contributed modules we are trying to replicate the switch functionality which switches from HTTP to HTTPS. So that is an interesting problem that we are trying to solve and if anyone is interested, he or she is most welcome to join us and help us with the work that we are doing. So that's pretty much it. So three people we have in last two months, two and a half months we have ported almost three and a half modules and there are a lot more to come. We have Search API and Facet API and a couple of other modules which we are going to pick up in the next month in March. I think that's the time when we are going to get those modules in stable release. I think also for any of you who aren't working at Acquia, it's still all of our Drupal, we all need to do this. Acquia, you contribute a lot but you can also do your own thing and if you are looking to gain experience in terms of working in the community and building reputation and building skills this is a really good opportunity to do this. If you follow the lightning project and you find out the roadmap, start looking at those modules because you know they are going to get very active from some very serious maintainers who are actually paid to do it which is amazing and so if you get in that issue queue you are going to get responses quickly you are going to be able to get involved in projects in a way which I think will work really well for you. So consider that also. Not all of the projects are like entity embed or field collection, really complicated just a little plug there. Alright, unless we have any other questions I guess we'll close, yeah. I don't know what it is. I'm just getting www.drupal.org slash lightning. Just like the other. This is next month, right? Panels, penalizers, or JPI facets. Here's the development team who's working on it, the core development team. Yeah, that's that. Alright, thanks everyone. Hope that was useful. We'll see you around.