 So just a kind of one programming note, this warning, this discussion's not going to be technical, so I'm not going to be getting into things like, you know, you have to configure varnish for authenticated users, otherwise your performance will blow up. This is more geared towards best practices in terms of process. I'll get a little bit technical in some areas so that there's at least some discussion in terms of what can be done to avoid common pitfalls. And then we can reserve for some of the technical stuff for the Q&A after. So just to go over the agenda, you know, we're going to start off with a brief introduction of myself so that you can get a sense for who I am, why I'm giving this talk. We'll also talk about some of the key components to success. So we'll actually start off positive. You know, I wanted to make the title provocative to be negative, but we're going to be positive, so. And then we'll go over some of the real use cases in terms of why they fail. So some of the common things that people are encountering, some of the red flags that I've heard. And then we'll actually talk about, you know, what can we do to overcome these barriers? So real-world actionable items that we can use to get through and to have successful Drupal projects. And then we'll take questions. So, you know, it is late in the day. I really appreciate you guys all being here. I'll try to move this along so that we're not stuck here too late. So just a little bit about me. My name is Chris Plakas. You can find me as Cplakas on Drupal.org. It's a funny Greek spelling, but that's how you say my name. I answer everything, so don't worry about it. I'm also the same handle on Twitter. I'm pretty consistent, so if you want to find me, I'm pretty easy to find. I can't hide. I'm a Drupal module maintainer. I have about 1,300 commits or so, which is a modest number, not too much, but it's a pretty good amount. I'm also a core contributor, very minor, but I have a few core patches in there. I'm also a Zen certified. So I'm a Zen certified PHP5 engineer. I'm a MySQL certified developer and administrator, and I'm also a Linux professional institute certified. So I have some experience in pretty much all areas of the LAMP stack. I've been working with Drupal for a little over three years. It's probably about three and a half. Last time I checked, it was around that time. So that's not an excessive amount in the Drupal community, but if you ask my wife, she'll attest for how many hours I spent behind the computer. Also, I was a member of Aquia's professional services team for a little over a year, and I'll talk more about that and why that's relevant. And right now, I am a solutions architect on the pre-sales team for Aquia. So I talk a lot about how to sell Drupal and explain why Drupal is a good solution and can fit the business needs of our various customers. So that's a little bit about me, but what makes me qualified? Why am I standing up here talking to you? And I think the first aspect is that I work with a lot of organizations. So as a member of the professional services team, what my job was to do is to go around to various clients, work alongside them, and talk to them about how to make their project succeed with Drupal. So it was a lot of architecture work. It was a lot of training, and then some implementation, and then some site audits on the back end. Formants audit, security audits, that sort of thing. So I got a pretty good overview of what it takes to make projects succeed. I also saw why our people were falling down. I'd kind of say with tongue in cheek that I worked on Wall Street. I taught at Princeton, and I helped secure our homeland. It sounds a lot cooler than it is, but just some various different aspects of Drupal. Also, I remember learning Drupal. So this is a little illustration of me learning Drupal. Truth be told, I absolutely hated Drupal for about four months. My goal was to eradicate Drupal from the company that I worked for. My wife remembers me just absolutely hating it, and there was a barrier there. The thing is, I'm not alone. This illustration is one of my favorite ones. I don't know who authored it, but it's great. It shows the learning curve of Drupal, and you can see we lost a few people along the way. So it's good to know that I'm not alone here. Also, I saw a lot of resurrections. So I worked for a company where one of the offerings was a rescue of Drupal products, which is a very, very difficult business and a tough business model if you've ever gotten into it. But it was pretty interesting for me because I get to see where some others kind of fell down and saw where they ran into the same issues. So I've been in the weeds. So I've been an implementer. I started off as an engineer, really got my start in Drupal as contributing with modules kind of messing around there. And I've also seen the big picture. So I moved on to more of a role where I'm looking at it from the business goals as opposed to what it's actually going to technically take to get a project done. So there's a wide range of experience there. And what I've found is that there are patterns. So what I wanted to do with this presentation was really share the patterns that I've seen and then open it up for discussion so we can have more of a dialogue and questions and see what you guys are experiencing and how we might be able to work through those problems. So I think the big thing for me is that there are really five key components to success. So these are the things that seem to be common to all the projects that are doing really well. And that's project management. So having strong project managers is really, really key to make projects successful. Process. We'll talk a little bit about process, but something that works and something that's well-defined is always present in Drupal applications that succeed. Development practices. This means that how are your developers interacting with each other? How are they actually building this stuff? What are they doing to facilitate the application development? And that's always present as well. Thought partnership is one that I think often gets overlooked. Sometimes as Drupal developers, or if we're implementing a product internally, we take requirements and we try to implement them. Thought partnership is something that we'll talk a lot about going forward. But that's something that's a key factor in shaping the discussions and really determining the outcome of the project. And then expertise. This may seem obvious, but we'll talk about where a lack of expertise might get you into trouble and how you can go forward and gain the expertise inside of your organization. So I guess these key components, what we're really talking about here is expectation management, communication, and execution. If we have those five key components, then these things will fall in place. And if these things fall in place, it really doesn't matter what technology you use, but for Drupal, it's critical that you have these in order to be successful. So let's go through some of the barriers. And these are the common barriers. Of course, there are going to be more, but these are really the big ones that prevent people from succeeding. So when I go on site, the first thing that I do is I listen pretty hardcore. I mean, that's what I'm there. The first day is me asking questions and just listening. I mean, these are some of the red flags that I always listen for. The first thing is we use, you know, company XDrupal. So this is something where an organization, you know, has their own slew of modules or their own little platform or something that they build on top of. And, you know, this works in some cases, but in most cases it actually doesn't. Another thing that I listen for is we do the impossible. If I hear those words, then, you know, the red flag goes up, because there's some interesting implications of that. And then a lot of times I hear, you know, we have a really good PHP developers and they just need a couple of days to get up to speed with Drupal. If you have this mindset, then there's some pretty big issues with that, as you saw with my experience with learning Drupal. One other thing that I listen for is, you know, we're pushing boundaries, so we don't work with the community. You know, we have a lot of IP intellectual property that we don't want to give away. This is our value and this is how we're going to make our money and how we're going to be successful. Also, you know, one thing that kind of raises the red flag, sometimes it works, sometimes it doesn't, but we have an offshore team do most of our development, and we'll talk about why that works, why that doesn't work. Also, you know, I think two big things is, you know, we cut our rates to get a project. We hear, we see a lot about, you know, there's the carrot and stick approach, where somebody dangles a million web properties for you if you kind of get this project out and get it working. And it kind of, you know, in tandem with that, we will get bigger projects if we meet the aggressive timeline. So these are the things, these are, you know, some of the red flags that I listen for, and it really makes my ears get pointed. So, you know, let's break it down. Let's talk about why these things are problematic. And I think, you know, the first piece is mismanaged expectations. And if you're going to leave with one thing, you know, leave with this, no matter the end result, a project will be viewed as a failure if the original expectations were not met. Most projects fail not because of technology, but because of the management of expectations. And this is absolutely critical. You know, and I think some contributing factors to expectation mismanagement is product misrepresentation. So that might be accidental or it might be intentional. An example of where it might be accidental is let's say you have, you know, a young sales staff that's coming on board, you know, they're really aggressive, they want to get the sale across, and they might not fully understand the technology and what they say might have, you know, implementation implications beyond what they intended. You know, this also happens in how we talk about Drupal. I'm probably the biggest Drupal apologist and I'm guilty of this more than anybody, but what I always say is, you know, there's a module for that. And that's not really the whole story. You know, what you really should be saying is, you know, there's a contributed solution that we could leverage and then, you know, explain the risks, but that's an example of accidental product misrepresentation. And then there's the intentional stuff and, you know, this actually happens where, you know, someone will say something that isn't really true in order to get a deal. And unfortunately we see this, you know, it happens in business, it's a way of life, but this is a huge factor. You know, this is where projects get lost as soon as the phone is picked up. Unsustainable precedence. We talked a little bit about this in the red flags, but, you know, if you do that first project and you agree to a really aggressive timeline and you agree to do it for a really low cost, that's something where that precedence has been set, right? That Pandora's box has been open. It's really hard to close it. So oftentimes, you know, you get into a situation where, you know, those client expectations during the next project are sky-high and they're really unattainable. They're unreasonable and they're not profitable for you. Communication breakdown may seem obvious, but, you know, I think there's seen a lot of instances where people develop Drupal applications and then they kind of go in a corner and they get really excited about it and they don't communicate with a client what the progress is and what they're doing. And then they show it back and that expectation is mismatched. And that's a big problem, you know, despite what work was done or how well it was done, if that communication isn't there, then that's a huge problem. And I think, you know, in open source, people are expecting transparency. But, you know, as you see with Drupalcom, people are sharing a lot of information. You know, I think, you know, being transparent is something that's really important. But, you know, a lot of companies, it's hard. It's not there. It's really not second nature to them. It takes some effort. And then, you know, one thing that's really problematic is when the client or stakeholder is driving the project. That's a big problem and that's really where expectations get mismatched as well. And this sounds funny coming from an American talking about exit strategy, but you have to develop an exit strategy, right? So, you know, this means, what are you going to do when the application is built? We don't think about that. Then those expectations are, you know, something breaks, well, who's going to fix it? Do they have to pay for it? What's the structure? So that's, you know, I think that's something that is often overlooked when we're developing these projects. So one thing to go on as well is lack of expertise. So this is really prevalent and people knew to Drupal. And this is really Drupal-specific. And that Drupal is very, very complex, right? So you can have very technical people. I actually got all my certifications and stuff before going to Drupal, so, you know, I had a boosted ego of myself and my capabilities. But when I went to Drupal, I didn't fully understand the complexity and I thought the code was garbage. I thought it was trash. I thought it was not well thought out. But, you know, I think the big thing is that I just didn't understand the problems. There are risks and challenges of Drupal. Same with any platform. There's no perfect solution. And you really, you don't know what you don't know. So going into a project for the first time, it's very, very difficult to know where this roadblocks are going to be and where the challenges are. You know, Drupal is not a magic bullet. I think sometimes during the sales process, we might say that it is or we might allude to the fact that it is. You know, Drupal is going to solve all your problems. It's free. It's better than everything else that's out there. And again, this goes back to expectation management. You know, that's not the case. It takes work. And I truly believe that Drupal is the best solution out there for content management and web experience. But there are still challenges. And it's important to note that the problems aren't trivial. So these are complex problems and they're trying to be solved by very smart people. So, you know, it's often the case that something's been run into many times before and it just doesn't have a good solution yet that that's been integrated back in the platform. So experience is knowing where these are. What am I going to run into? Because the problem with Drupal is that there's many ways to accomplish the same goal. This is also its strength, right? You could have the same module. You could have a totally different module do the same goal, accomplish the same thing. Which one do you take? Where are the roadblocks? And you know, I think it's important to note that your team can actually add hundreds of hours unknowingly. So we actually see this a lot with designers, not to pick on designers, but a lot of times people who are new to Drupal will add functionality, right? I think designers are very creative. I'm not a designer. I respect the creativity that people put in. But what ends up happening is that the focus is on the design and the creativity. And there's not a lot of conversation about how that mixes with Drupal. And this is really a Drupal-specific one because the theme layer is so decoupled from the functionality layer, which is good in many ways. But what often happens is that people will be done outside of Drupal with no consideration in terms of how Drupal works. And then once the functionality is complete the design will be plopped on top of Drupal and tried to make into a theme. And that's really difficult for a first Drupal project. And we'll talk about how we can combat that going forward. And also with developers, and I did this a lot, is that you try to reinvent the wheel. If it's not apparent how to do it in Drupal at first, my first inclination was to code, right? I love coding. You know, I have a saying, I love coding. That's why I don't do it for a work. But I was really, really interested in coding and learning. So I was reinventing the wheel a lot. And that added a lot of hours to a project that didn't need to be there. Another thing that we encounter is that people build platforms too early, right? So their first Drupal project or their second Drupal project, what they come in and they say, yeah, we have our own version of Drupal, right? We may or may not have hacked core, which means changing the core code, which is a bad idea unless you really, really know what you're doing. But, you know, the problem is that you really need deep expertise in order to build a repeatable solution. Again, with Drupal, there's a lot of flexibility and promise in terms of multi-site, in terms of distributions, in terms of installation profiles that are custom to your organization. But if you don't have the use case and you don't have the expertise in terms of what it takes to make these succeed, then it's going to be very, very difficult to go forward. One of the reasons is that a distribution will be made up front. It will satisfy the first site. That would be great. And then the second site rolls around, okay, this doesn't really fit. You know, we've sometimes elapsed. The requirements have changed. You know, now you're reinventing the wheel. So you're really blocking innovation. I think, you know, the power with Drupal is the value of innovation. So all the contributions that are coming in through the community. But if you kind of lock yourself into this platform idea too early in the problems, then you really block that innovation. And that's, you know, that's a great recipe for failure. You know, if you do have enough use cases, yeah, that's great. Like a platform is great. If you look at the existing ones that are out there, you know, Open Atrium, that was built from many projects. Had pulled great experiences from the development seed team. If you look at Phase 2 and their distributions, those are all built from projects that they've had. So there's a lot of expertise there as well. And there's use cases to make those happen. I mean, it's also important to know, you know, what are your business goals? It's very tough to make money off of a distribution unless, you know, you have solid business goals around how you're going to monetize that. So, you know, even though it might technically make sense or be the option that presents itself in order to reduce deployment and deployment, that sort of stuff, you know, it might be good to take a second look at that because, you know, it doesn't always align with the business goals of what you're trying to do. So let's talk a little bit about solutions, right? Let's talk about how we can combat some of these things. So the first, we'll talk about project management. And again, you know, this is really the key member of the team. I'm really big on this. The project managers, if there's a good project manager, then they can overtake some of the other bad practices that are there. A good project manager can really drive a project to success, and that's key. You know, I hear a lot from people that, oh, we became successful because we eliminated the project manager role. Well, maybe you just eliminated, you know, the problem. Maybe the project manager wasn't necessarily the right solution or the right fit in that instance. But that's more or less a band-aid. As you get projects that scale, the project managers become increasingly more critical, and they're really the focal point towards success. And the reason, you know, they have to be, actually goes for some characteristics. They have to be knowledgeable about the technology. It's really tough to be a great project manager and not understand basically what Drupal is or what the technology is that you're building on top of. You know, I have seen a lot of good project managers fail because they didn't understand the technology. And that's, you know, not a fault to them. They were probably brought into a situation that wasn't the best fit. But if you are a project manager, it's very, very important that you at least have a good understanding of how Drupal works and what it takes to actually build a Drupal site. Not on the sense of, you know, you have to be able to code a module, but maybe know the most important modules and know the basic solutions. Drupal is very friendly towards that. You can be a site builder. You don't have to be a developer in order to get started. So it really is a good tool that you can kind of dive into and learn going forward. You know, another key characteristic of a good project manager is that they understand process. So we'll talk about process in a little bit, but it's a cornerstone towards facilitating communication and combating a lot of those things that we talked about earlier. And it's critical that, again, the project manager is the person that really drives process. Because internally, they keep their team on track. Right? They're hard asses. I mean, the developers might not like them all the time, but they, you know, they're the guys that say, my projects don't go over budget. You know, what do you need for me in order for, you know, you to break down these barriers. You need to be really aggressive internally. But conversely, externally, they really need to protect the team. So these are the people that, you know, are taking the bullets in the front line. These are the people that are taking all the stuff from the customer, all the grief when things don't go right. You know, it's really important that they have that dichotomy. And, you know, another great characteristic is that a good project manager effectively pushes back. Saying no is much more important than saying yes. You know, I think a lot of times we get feedback, well, you know, the customer is paying the bill or this is, you know, move that kundra and, you know, we can't say no to him. Well, that's not the case. I think people, you know, are looking for you to say no if it doesn't make sense towards what they're trying to do. So it's really, really important that project manager pushes back and don't just, you know, take everything in and move forward with that. So let's go back to expectation management. We talked about, you know, if there's one thing we want to get out of this is that, you know, expectation is key in project succeeding. So I lost my... Oh, I'm sorry. What I meant to say is that what they're really doing is with all these things, they're managing expectations, right? So if you have good process, if you have good communication, if you're effectively pushing back, then you're managing the expectations and that's where the project manager is key. So let's talk a little bit about process. You know, I don't want to get into too detail, but, you know, I kind of want to leave this for the questions and the conversations because this is really important. Again, the project manager drives the process, but, you know, honestly, the methodology doesn't matter. I think a lot of times we get into these holy wars in terms of, you know, agile versus waterfall, that sort of stuff. But, you know, I think if... I forget who it was, but I think of Seth, the project manager from Lullabot is listening to a podcast and he says it's really hard to sell agile. And what they have to do is they have to start off with waterfall and then once the trust gets in, then they can move into agile. So just briefly, you know, what the difference is, is a waterfall method is kind of like an incremental steps, right? So you have a milestone. So, you know, milestone one is that you'll have blogs and Wikis done. Milestone two is that you'll have community features. You know, if that works for you, then it works for you and that's fine. The problem with that is that it's based on a huge assumption that everything works before moving on to the next step. And agile is more of an iterative approach in which, you know, you have things in a backlog. You do a certain amount of work and then you can revisit things that don't necessarily make it in. So it really forces you to prioritize and get the important things done where you can maintain a backlog with less important tasks and kind of move those into future iterations as necessary. You know, but again, it really doesn't matter just as long as everybody's on the same page and as long as everybody's following it. So it has to be very well-defined and it also has to be flexible at the same time. So that's a bit of a contradiction but it just has to be transparent, right? So it really has to be something that your development team can do and it also has to be flexible enough to meet any challenges that come up if something, you know, breaks the process. You know, I was part of an organization that was really focused on process and the problem is that we stuck to it too much, right? We stuck to it where it didn't really make sense and that caused problems. We said, you know, this isn't in the process and then we, you know, kind of cut off our nose despite our face. So, you know, it's very important that that flexibility is there and simple is key. I think with everything, I think, you know, we see a lot of organizations that do things like invest in very expensive project management software which may or may not be a good thing but then there's that learning curve and your development team has to go to it and if your development team is resisting it, that's a problem. I did a Drupal Commons podcast recently. It was an aquea podcast and one of the... I forget who said it but somebody alluded to the fact that, you know, when we're working with partners on Commons and we do these joint engagements, we have a Google spreadsheet as a bug tracking system and somebody tweeted this and was like, what? This is crazy. But, you know, we use other tools for other projects but, you know, in this case, granting access to various things and learning... getting people learned on all these different tools that we use internally wasn't the best case. Using a Google spreadsheet was really easy. People could jump in. They saw what was broken, you know, what needed to be fixed. Was it elegant? Probably not but they could really easily say, yeah, this is fixed or add another bug and it was done in a way that, you know, we could read it. So again, you know, that's not really a slick solution but it's something that everybody could rally around and everybody liked and they found very easy, very simple. You know, in that case, that's a process that works where people might think that it wouldn't otherwise. So we'll talk a little bit about development practices. Try not to get too technical here but, you know, I think the big thing is that you have to use source control. Whether it's a small project or whether it's, you know, the largest project, you know, you have to make sure that you're facilitating that. It's really important that your team uses it because it prevents, you know, it keeps a transparent log internally of what's done, it shows you who's changing stuff. You know, it also prevents conflicts, that sort of thing. It just adds a lot of automated communication to the process so people have a nice log of what's going on. And again, you know, it facilitates communication. So because you have this log and because you have access to see what's changed, you know, your developers will actually talk to one another. Source control isn't meant to be an automated project manager. What it's meant to do is it's meant to facilitate and foster communication. It's meant for one developer to walk down the hall, go to the other developer and say, why did you do this or, you know, what was changed? You know, it's really meant for that type of interaction. You know, in terms of Drupal, best practices are out there. I think a lot of times developers' designers resist this. So, you know, we talked a little bit about, you know, how a designer might theme something and then try to plop it on top of Drupal. This doesn't really work. This is really, really difficult to do. In terms of best practices for Drupal, there are a lot of starter themes that you can use and you can kind of build up on top of that. You know, by doing this, it'll do things that are behind the scenes. It might not be apparent at first, but it'll do things like, you know, it'll maintain the semantic markup, which gives you better SEO, better SEO theme in order to facilitate redesigns, that sort of thing. When you start from scratch and you don't have knowledge of how the Drupal teaming system works on a really, really deep level, then a lot of times you're omitting things that Drupal expects to be there. You know, and I think also with developers, the biggest thing that I've seen is coding standards. So coding standards are a way, you know, they don't affect the functionality of the code, but they're kind of like a structured way of writing this stuff so that people can read it in a consistent manner. And actually when I do site audits, the first thing that I do is I install the coder module and look for where coding standards are adhered to. And that sounds weird because it doesn't affect the functionality, but what it means is that it kind of points to code where someone didn't research the APIs or someone's kind of new to Drupal or, you know, someone was kind of going it alone and not using best practices or what's recommended in the community. It's a great way to identify where code might be problematic. And again, you know, the more that you're working with best practices, the more that your developers will actually understand what it takes to build a Drupal site and will go across documentation. They'll have to read documentation, security practices, you know, the theming practices, just best practices in general. And it's important to note, too, that it's publicly available. You know, a lot of times we hear, well, you know, there's Drupal coding standards or there's these security functions that you can use to prevent, you know, SQL injection or cross-site scripting. And a lot of times it's like, well, that, you know, where is that? Is there some secret thing that Awkward can provide? No, it's out there. It's publicly available on Drupal.org. So if you search for coding standards, you know, you'll actually see this on the Drupal documentation page. So that your developers are familiar with this. And again, you know, simple is better. This is a reoccurring theme. The more complex, you know, the more complex a process, the more problematic it becomes. If we keep it simple and we make sure that people have access to source control, we don't do crazy things in terms of what it takes to get them up and running, that's better. You know, we want to make it accessible even inside your team. And it's really important to do dev staging because, you know, this is touching on the technical stuff, but, you know, this is a process that's well-defined in the Drupal community. And if you're a project manager or you're a technical thought leader, this is really important to invest in and understand, just understand in general. You know, without these kind of mechanisms, then that leads the way for stuff getting on to production that shouldn't necessarily be there. And, you know, one thing that is unique to Drupal is deployment techniques. This means, okay, we have these three environments, so how do we port configuration changes from one environment to another? How do we port code from one environment to another? It's really, really important that there's some sort of strategy and some sort of knowledge gained around this area because this is one of the big problems of Drupal that's one of the challenges we mentioned earlier. So, you know, I think this is one of the biggest things that people stumble across. So, you know, investing some time in order to learn this is very key towards being successful going forward. And we talked a little bit about thought partnership. And what does this mean? So, what this means is that, you know, you really want to drive goals and innovation. So, if the client or the stakeholder is really driving the conversation, what ends up happening is that, you know, they say jump, you say how high, right, and it doesn't work that way. You know, I think when people say, okay, you know, I use an offshore development team for most of my stuff, you know, usually what they're referring to is that's outsourced and they say something and then it gets implemented, right? That's not necessarily the best way of doing things. The value of your organization isn't the code that you write. The value of your organization is whether or not you can understand, identify, and meet the business goals. So, when you're talking about projects, really ask, you know, what are the business goals that you're trying to achieve and really drive that thought partnership so that you can uncover the pain. What's not working for you, right? Why are we here? What problem are we trying to solve? And that way you can really drive the requirements as well. And that's critical because if you can drive the requirements, you know, you might not be able to drive the full requirements, obviously, because people have goals that they want to achieve. But if you can frame the discussion and be thought leaders and say this is best practice, this is, you know, the best way to accomplish what you're trying to do, that's where your value is and that's where people really respect you. So, you know, again, just not saying, yes, we'll do that, we'll implement that, you know, really be thought leaders and engage. You know, I think one of the big problems, too, is that people will say, yeah, we'll do it and then they take one direction and go. When we're coming up with solutions and when we're talking with people, be it a stakeholder, you know, someone higher up in your organization or be it a client if you're a Drupal shop, providing solutions and options is key, right? It's okay to say, yeah, you know, if you really want to do this, this is the method that you're going to have to take and it's going to be a little more expensive or, you know, this is another option that we could take which pretty much satisfies what you're trying to do and will cost a lot less and be a lot less effort, a lot more maintainable going forward. So, again, presenting these options and presenting, you know, what solution you feel is best in a way that makes sense for, you know, the customer or stakeholder is really where the value of what you're doing shows. And I think, you know, one thing, avoid courts. A lot of times people will say, okay, let's just get this on Drupal and then we'll go forward, right? This is a really, really tough business model and this is a really, really tough thing to do. A lot of times it's coming from other CMSs, they might be proprietary, they might be open source, they might be completely custom. Either way, they have a lot of things in here that make assumptions to the platform they're running on that may or may not be best practices, you know, they might be what people are used to, that's why they're asking for it. One example is that for Drupal Commons, we get a lot of requests that look exactly like a SharePoint spec, right? And that's because people are used to that. What we want to say is, okay, we're going to, you know, we're going to frame this discussion. We're not going to build SharePoint with Drupal Commons. What we're going to do is we're going to show you a new, a better way, a more efficient way, a more maintainable way of doing group management and collaboration. You know, we're not in the business of trying to make things that already exist and just make it Drupal. And experience, you know, obviously, experience just doesn't happen. It's really tough to find Drupal talent right now. You know, I think right now everybody kind of poaches from one another, and that's how Drupal talent transfers. It's very tough to find, you know, new up-and-coming talents and integrate them. It is possible. A lot of people are making the switch right now from technologies like Java.net. They're moving into Drupal because it's easier. It's a better solution for them. You know, it doesn't happen overnight. It's really important to understand that. So one of the things that we talk about is, you know, that people say, oh, I have a really strong PHP person, they'll just pick it up no problem. That's not always the case. It might be a completely different way of doing things than how they've done in the past. I was coming from the Zen framework where I was building everything. It was very much a framework-oriented, code-oriented page build, that sort of thing. It was a completely blew my mind because it was a transition. That's why I struggled with it. You know, empowering your team is kind of just something that people say, but what this means is that, you know, allow your team to learn, right? Give them the resources, invest in them in order for them to really thrive with Drupal. You know, just putting them into a situation where, okay, here's a project, go learn Drupal on the fly. It isn't gonna work. The team has to be able to be engaged with one another. And also, they have to have some investment into them so that they can, you know, really learn the platform and be successful. And, you know, make sure that they leverage the community. Avoiding the community is a big problem. The community is really what makes Drupal powerful. It's not the software. It's the community. And as soon as you start working with Drupal, you're a part of the community. It's not this thing that's unattainable and you have to work really hard to join. You know, making a commitment to build a Drupal site. You're a part of the community. You're a part of the communication. And, you know, it allows you to share knowledge. And a lot of people are afraid of this. A lot of people say, well, that's my intellectual property. Why would I want to give that away? And to steal a term from Jeff Eaton, who's a pretty well-known lullabot inside the community, he coined a phrase, a cooperatician. I'm not sure if he stole it from anyone, but I stole it from him. So that's why I'm going there. This is Drupal. The real competition is with proprietary vendors that are attacking open source in general. And this is where Drupal is moving, right? Drew said in his keynote, that's where the opportunity is. Even though we might compete with each other in small areas, we're really... we're more cooperating and we're more sharing ideas so that collectively as a community, you know, we can all grow. There's definitely room for all of us to thrive. You know, seeing where Drupal is going is very exciting. But, you know, when you start to share knowledge, you get a lot of knowledge in return as well. So that's a great, inexpensive way in order to empower your team and get them moving in the Drupal way. And it's something that you shouldn't resist and, you know, working with the community openly and transparently is very, very important. You know, there's some free things that you can do. You can go to conferences, you can go to camps, go to meetups. These are great ways to get your team empowered, you know, make sure that you make it... give them good incentives to go. You know, maybe buy them a drink or something or send them to a camp that might be a little bit far away. But this is where relationships are made. This is where knowledge is gained. This is where your team will thrive and this is where you get the most return from your investments. And then, you know, it's also important to give trainings. Give your knowledge away. This sounds weird, but we do this at Acquia a lot, right? We try to teach people to make ourselves irrelevant, right? Maybe the next, you know, Drupal experts that can thrive and help the community grow. You know, and that's... I think that's really important. When you give trainings, when you start to give your knowledge away, you also become the subject matter in what you're teaching, right? So you get great visibility. You get a lot of business in return. It's a great way to expand your business. Also get people involved or also get people integrated in recruitment. It's a great way to expand. So, you know, Acquia is sending me here. So I do feel obliged to talk about Acquia. So we'll end with this slide. But, you know, what can we do for you to help get through some of these barriers? And one of the things is professional services, right? So we have an organization that's dedicated to providing technical architecture, jump starts, so, you know, intensive week-long trainings in order to get people up and running on Drupal. And also, you know, audits. So one of the things is a pre-site... I'm sorry, a pre-launched site audit where we can actually, you know, go in, view the code, see if it's being adhered to, best practices are being adhered to, and, you know, it's a very valuable tool in order to make sure, you know, what gets out there is something that's going to scale. Enterprise support as well. We talked about an exit strategy. And a lot of times what happens is that a project will be done. There's no negotiation in terms of what's going to happen after. You know, projects inevitably have bugs. There's no perfect project that's impossible. It really is. There's going to be issues. The customer is going to come back afterwards and say, well, you know, you built this, you need to fix this. If they have to pay for it, they're going to be a little bit frustrated. It comes back to expectation management. With Aqua, you can actually leverage enterprise support where, you know, we can take over that part of the business and make it work, so to speak. So it's a nice way to deflect those expectations off of you and onto us. And what we've seen is that the customer then returns back to the original company for future development additional work. It ends up being a nice facilitator for business. And we also offer accelerators, such as Drupal Gardens, Drupal Commons. These are things that are prepackaged solution that allows you to get ready going with Drupal. So it's important to note that a lot of these things are free and you can leverage and you can get up and running as well. One thing that's important is that we offer free training for partners. So we talked a little bit about expertise, right? So let's say you have someone that comes into your organization from, you know, the Java world. If you send them to us, we will train them for a week, for free. We won't charge anything, and we'll send them right back to you. We're putting the investment because we feel really, really strongly that, you know, the importance of Drupal is dependent on the talent and the amount of people that can build good projects. So, you know, that's something that is really important. We'll also do joint proposals. So if you, you know, if this is one of your first Drupal projects you want to get going, we'll either do it side by side, meaning we're out front. You know, it's an aqueous slash company proposal. Or we'll do it behind the scenes that we're not even viewed by the end customer, right? You manage that relationship. You're the point of contact. You know, we'll happily do that. We'll try to provide the aqueous network, which is worth looking out on. There's been a couple of announcements, but these are tools to help you identify what the problems with your sites are and also provide some knowledge in order to, you know, increase your understanding of what Drupal does and, you know, just provides it's a nice facilitator in order to get you going on Drupal and make sure that your clients' projects or your internal projects are successful. So, you know, I think we don't have prepackaged stuff. We really want to converse with you and figure out how we can help you succeed with Drupal. And, you know, with that, I'll end the business pitch and, you know, let's take some questions, have some discussions, and, yeah, we can go from there. Yes. Oh, I'm sorry. I'm sorry. There was some microphone issues. You're going to have a microphone so everybody can hear your questions, so I don't have to repeat it because I'm really bad at that. Cool. So, for a company that maybe has an existing system that's set up in place and they're looking to move to Drupal, if they don't do the research up front and maybe the view is we'll just put our devs against it and then, you know, maybe in two months' time we'll have complete conversion of to the new platform, with sort of viewing this presentation, it kind of makes out that Drupal might be an expensive option to move to in the short run. So, you know, in my opinion the investment would be needed as far as Drupal skills go and perhaps I could go to Acquieta to obtain that, but for some companies that may just think we'll put our IT department against it and we'll try to get something out in five, six months. Is that something you account quite often? Yes. So, you know, a lot of the first projects with that will be problematic because what happens is that you put a time frame together of two months but there's no understanding of the problems that actually determine the scope of that project. Right? So, also, you know, there's best practices, right? How do you achieve that efficiently? With Drupal there's a lot of different ways that you can solve the same problem. So, which one is the right one, right? That's problematic. Drupal and open source. So, you know, I think where you see companies like Jive, right, and Jive is a proprietary community-oriented solution, they give slick demos, they stand stuff up. What ends up happening is that you pay for any additional customization, any additional service. You pay for licensing fees, right? So, the cost up front might not be as much but the maintenance, which is where most of IT cost happens, is back-loaded. And then you're stuck, right? You're vendor locked. With Drupal, you do have to put some investment up front and then the costs tend to tailor off over time. You know, AQUI is not the only solution. You know, I don't want this to be an AQUIA pitch. There's a lot of companies inside of Drupal that talk with each other. This is a great opportunity to talk and to join Birds of the Feather, or BOFs, to talk to people about those transitions. And people are very transparent in terms of what their headaches were, what the problems were, so that, you know, you know what areas you might need to invest in in order to get your developers trained and up and running in order to move to a new system. Okay, thanks. Yes? Sorry. Yes, you just looked that way. That's you. Just a point of clarification. I don't have my glasses on, so I can't see anybody beyond the front row. I just see blobs, so. Hi. I'm coming from a proprietary vendor that's moving from our own CMS to Drupal. And the problem that we seem to be having with a lot of our clients is that we fail to explain the cost in when... You mentioned earlier the whole, there's a module for that, because we come from a proprietary product where we can do pretty much whatever they ask for. It's tricky for us to deliver on budget, well, within budget things which they seem to see Drupal as doing very easily. So it seems like Drupal has this undue unfair like profile of being cheap when in reality it isn't. I was wondering if you had any sort of anecdotal experience of how to handle that matter. Yeah, so, I mean, the big thing is Drupal's not free. I mean, Drupal's free to download, Drupal's free to use. Open source, what you're doing is instead of investing in licensing fees which don't really have a value, you're investing in services in order to improve your product. So I think the big thing with Drupal is that it has a value of innovation. Meaning that, for example, Google Fonts came out and then there was a module that next day. There was no people talking about it. Yes, it wasn't on some roadmap that might not be achieved. You know, I think in your case, I think a lot of times are you working with any other Drupal companies now? Or are you... Well, we've previously used accelerators but in most cases the clients' requirements are just too specific to use something which is comparatively more general like Drupal Garms or something like that. So, yeah and no. Okay, so you're not working with other companies in terms of, I mean, how long have you been using Drupal? About four years. Okay, so when did you make the switch? Well, we're still doing a switch at the moment. We're trying to switch our clients at the right moment. We've switched a few and it's some of the ones that are coming back to us going, that's more expensive than we expected. Where we have the trouble explaining well, that's because modules just don't do what they say they do kind of thing. Yeah, I think that's really important. So whenever we talk about modules we talk about, okay, what is it with a module that you're getting? You're getting something that's free and you're getting something that doesn't have a roadmap necessarily and something that takes effort in order to implement. Not just kind of a plug and play. The benefit is that there's a lot of innovation. With innovation comes a little bit of instability in terms of new code that's out there. I think the advice that I'd say is make sure that tested stuff is used. That's really, really important. Even if there's a module that specifically does what you're looking for if it doesn't have a lot of usage and is under maintained, that'll be a problem. A lot of times you use the stuff that's tested. And just explaining to the customer that yes, okay, here's the reason why you're using Drupal. You're using Drupal because there's no licensing fees so when you're investing money you're investing in improving your application. And also you're not held to a proprietary vendor's roadmap. With that there's going to be work. Open source will get you 75% of the way there. You might have to put some cost up in order to get to the rest of the 25%. But once you do that the maintenance over time will decrease which is really where most of the IT spending happens anyways. Thank you. I'm just... I can hear you, I can't see you, but I can hear you. I'm just wondering what problems you've observed as you have to try and keep your solution up to date as the core and the contributed modules continue to upgrade and how you deal with that. Right. That's a... Drupal innovates very fast and with that it's not on a set roadmap. I think core is on a better roadmap but obviously the contributed modules move pretty quick and have to be updated. I think Drupal does a pretty good job of telling you what needs to be updated and then there's automated tools such as Drush that help facilitate that. And as long as you're not making major changes as long as these are minor point releases generally Drupal works out okay. But what you want to do is you want to make sure that these upgrades are tested in a... staging environment first before going into production. You don't just want to upgrade your modules in production. That's tough to do. And this is an area where expertise comes into play. Again, I hate to do the aquea pitch but I think it's important is that the support understands what the different conflicts are. So they support thousands of applications and they see a lot of the stuff that isn't apparent to everybody. They know that if you upgrade views to 6.14 there's a 6.24 or whatever just hypothetical that there's going to be a conflict with another module. I think that's a problem as well but if you look at proprietary solutions and the cost of upgrading there that's why we see a lot of people coming back to Drupal off of these proprietary solutions because the cost of upgrading is so steep whereas as Drupal it's not free. You do have to do some testing. You do have to do some work but that's one of those hidden costs that you don't want to make hidden. You want to be transparent about it. You want to be upfront about it and as long as people understand why this cost is there and why it benefits them generally they're receptive to that as long as they expect it. We also see projects in Drupal so traditionally we've had kind of like a big brand approach that switch to Drupal and do all the work in 6 to 12 months. I'm increasingly seeing the need for projects that run for several years where you have continuing engagement and you have a phased approach. So you have phased one where you might do as you mentioned. So the right approach meaning long phased projects where small chunks Right. In terms of a website it's really important identifying their business goals. Why is their website there? I think a big example is Twitter. Twitter recently moved to Drupal. It's pretty public why that happened. The reason why they moved to Drupal is because they were having problems monetizing they were trying to figure out how to monetize their product and they were really there's a disconnect between their community. So what they had to do was they had to build a solution, they had to come up with a solution that could be implemented quickly. Everything in Twitter they're Ruby developers. They couldn't do it quickly with Ruby so they had to use Drupal started with Drupal Commons but the reason why they were able to do it is because they were able to do it quickly and they were able to react. So now that they have community engagement now what happens when the community starts engaging? Nobody really knows. The success of a project isn't when it launches the success of the project is how you can adapt one year after you actually figure out how people are going to use your site. So I think with Drupal it allows you to do that because there's free software. There's obviously a cost of implementing that but it's far less than if you have to do a complete customization on top of a proprietary solution. So I think again the value of innovation is really what sells Drupal so communicating that and communicating why that fits the business need of the client is critical. You said that you come from a Zen framework background. I was wondering if you had any tips on how to convince developers but Drupal is a good avenue for them and something to get into if they're from an MVC background. Right. I think a lot of times with developers, myself included is that when you code something it's yours and you understand exactly how it works. There's that familiarity, there's that comfort. With Drupal a lot of times you're giving up some of that comfort. You're relying on what other people have done. From a business standpoint that's really, really important. From a business standpoint it's important that your intellectual property isn't consolidated in one person. It's that you're using contributed solutions and that you're able to tap into the knowledge of others outside of your organization because if somebody leaves and a site that depends on them goes down because they're not there anymore that's a problem for business. For developers, what I like to say with Drupal is that you're coding a lot of trivial things. I was doing a lot of database connections I was doing a lot of queries, that sort of thing. Obviously that product's improving and I actually have a module that integrates with it but regardless I was starting to do a lot of the same things. With Drupal you can really focus on the interesting things. If you leverage the community you're not focusing on mundane tasks like user authentication you're actually working on the interesting stuff. For example, for me it's all about search that's really exciting to me and interesting to me. I don't have to worry about connecting to Solar. Peter Willan in the Apache Solar module does that. Thomas Seidel and Search API connects to all the other stuff. I just worry about focusing on the search interface and it allows me to focus on the interesting things to me. To me that's the best selling point for developers is that they don't have to code the mundane stuff and they can start to code the interesting stuff and they don't have to repeat what they're doing over and over again. Are we good? I appreciate you all coming out.