 So thanks for coming to the panel session today. My name's Brian House. I'm Vice President of Marketing at Acquia. And this panel today is called From the Frontlines, Victories and Battlewounds from Building Global Developer Communities. So I'm actually really excited and proud to have three great companies and three great individuals who agreed to participate on the panel. So first is Jeremy Johnson, developer advocate from LinkedIn. Second is Amy Piazza, product development for X.com, part of eBay, and Michael Shaver, who's a web manager for Intel and their open source technology center. So very excited to have a panel and to hear about what they're doing and their lessons learned building developer communities. Now what we're gonna do, the way we're gonna handle this today is, so we'll do, each of the panels will come up and walk through a couple slides just to give you some context for what they're doing with Drupal and the developer communities they've built and how they're working. Then we'll have some moderated Q and A, so we have some questions I'm gonna ask the panelists. We'll go through those, and then we'll open it up for you guys, so hopefully as during the slides and the discussion, some questions will pop up, so I encourage you to do that. And if you wanna tweet your questions in, you can do that as well. I'll do my best to moderate Twitter while we do this. So without further ado, let's jump in. Jeremy, you're up first, so why don't you talk about LinkedIn? How are you guys using Drupal? Thanks, so as you said, my name is Jeremy Johnstone. I'm a developer advocate at LinkedIn. LinkedIn is, as most of you probably already know, is one of the largest, or actually is the largest professional social network on the web, with over 150 million users. A little bit of background about me, so the kind of relevant here. To number one, I've been with LinkedIn for almost a year now, started in April of last year. I've actually, the slide is a little bit accurate. I've been using Drupal as a user capacity for quite some time. But as a developer and somebody who's actually been supporting and maintaining a Drupal site has been about two years now, I started my background in PHP in 1999. I've been a fairly heavy contributor to PHP, specifically, especially during my Yahoo days and before my Yahoo days. And I've developed a large number of websites. Some of the smaller websites have done, for example, is like Hotscripts.com, if any of you ever remember that site. I was actually the developer who developed that. It was running at the time, basically in the range of millions of page views per month. All the way up to sites as big as Yahoo, a madras book, which is doing, at the time when we rewrote the entire site and did it in PHP, it was doing between 200 and 300 million page views per day at that time. And all of that was based on a PHP-based website there. I'm also the co-founder of an organization called Random Hacks of Kindness. Random Hacks of Kindness is basically a developer community where we bring people together to help solve some of the world's challenges. Specifically, we started off in disaster response efforts, but we've now branched out into doing environmental impact and then just humanitarian aid projects in general. And basically, developing or organizing hack day events so that way people can come together and help build solutions for the NGOs and the other needy people of the world that don't necessarily always have the technical expertise to do that. And incidentally, also, it is a Drupal-based site as well. So a little bit about how LinkedIn is actually using Drupal. We actually use Drupal in a number of different capacities, but my specific thing that I want to be talking about today from perspective is for our developer community. So if you've ever been to developer.linkedin.com, you'll see that this is our front page here of our site, standard Drupal deployment on Drupal 7. We actually leverage quite a few different modules and different pieces of the Drupal community. So for example here, you see a documentation page from our documentation. Basically, you can see that we're using the books. We're bringing in some of the content on the side here. We use views fairly heavily. We use a lot of different things. We've also developed some custom features and modules for Drupal. For example, this code highlighting section right here. I looked all around for trying to find something that allowed us to be able to show case code highlights that are in multiple languages, but they're all like the same block of code. Couldn't really find anything that addressed that need. So we actually developed something like that in an open source to back to the community, which you can see at the bottom of that screenshot. We also make use of the advanced forms module. We have a very active community with tons of posts every day, as you can see here. This was a screenshot from yesterday and there's an extensive number of posts that are happening on our forums. And then here's one example where you can see where we're using the views in our showcases that allow you to be able to see, pull in different pieces of content and make it easy for editors to be able to update it, but at the same time, being able to have a nice cohesive look and feel to it. Hi there, I'm Amy Piazza. I do a managed development team at x.commerce, which is a new branch of eBay Inc. Focused on a commerce operating system. And our portal is x.com, so it's actually running on Drupal 7. We recently migrated to Drupal 7 from proprietary software. At the end of 2011, we kind of finished that project off and we've been running since then on Drupal. I have a little bit of history with Drupal. We also brought it in-house at AOL. I ran the developer network at AOL for a while. That ended with about 1.3 million users and I think right now with x.com, we're at about 300,000 on Drupal plus some additional properties that we're looking at. I'm all about bringing Drupal to the enterprise environment. I know sometimes that's good and sometimes it not. So the way we use Drupal on x.com, it's essentially a developer network. We represent the developer network in the developer experience for eBay Inc. So all of those properties that live under eBay are at some point focused on x.com. That includes PayPal, eBay itself, x.comers, which is the new one, Magento, Milo and Wear right now. We have other entities like StubHub and rent.com that'll eventually get there. On the site, we do standard developer network things like SDKs, code samples, documentation, sandbox environments, all of those lovely things. We also have a developer directory which is a partnership with Odesk. We have certification programs for various PayPal APIs and products. We've got a Riley writing articles for us. Those are all featured on the site. We also have the standard forums, blogs, support and evangelism or outreach. We did partner with Acquia but we currently maintain everything in-house. So, you know, here's some concepts about why developers are on x.com, why they matter to us. It's an open system right now and we're trying to kind of make our mark in that environment. We're working on some common open standards in terms of commerce. We rely pretty heavily on developers to contribute back to the system, back to the environment and the ecosystem. And we're looking forward to growing the whole site and kind of expanding the whole developer network. So, my name is Mike Shaver and I work in the open source technology center at Intel. The open source technology center has been around for a long time and it's grown quite a bit. But the primary focus around it has been Linux enabling, especially on the Intel platforms, obviously. So, a little bit about me first, that I've been working with Drupal for over six years before I got to the Open Source Technology Center and then been working with Drupal exclusively for all of our sites at the Open Source Technology Center as well. So, the kind of projects that we are involved in at the group that I work in can range from everything from contributing to the kernel to WebKit, smaller projects that we maintain like Conman and Clutter, Yachta, which is an embedded project. And then some larger projects where we partner with other larger companies like Amigo and Tizen. And pretty much all of these, except for some that are sort of like, we're just sort of contributing to on the side, need developer communities. The range of size of these are quite a bit. We have a lot that are very small and primarily function as the external face of the project, a place where we have documentation and some general information, some downloads usually around the project. And then all the way up to some larger projects that use a lot more, that get a lot more people involved in contributing in certain ways. We haven't used forums very much in our projects. We tend to use mailing lists for all the collaboration around communication like that. But just about everything else that you can think of that a community would need, SDK, downloads, documentation, all that kind of stuff lives on these sites. We also, for the Amigo project, ran both of our large conference conferences with the Cod distribution. And that was very successful. We were able to customize it quite a bit. And it was very good. And then we also use open atrium for some internal collaboration as well. So we use Drupal in a lot of different ways. Comes in handy many places. Excellent, thank you for each, providing some context. So now what we're gonna do is just do, I have to raise some questions that we're gonna walk through. So I wanna do that. So if you want, you can tweet questions to using the hashtag I'm following it up here. Otherwise we'll have you come up to the mic, but I'll be happy to do it either way. So let's kick this off. First, the first question I wanna ask is, each of you is, what were the factors that led to your decision to select Drupal? So each of your orgs are a little bit different. So why don't we talk a little bit about how you came to that decision? So Amy, you've done this at two different organizations. Why don't you take the lead? Can you hear me? So we did a pretty extensive analysis of Drupal in a variety of other enterprise software pieces we did something called a LAM analysis. It's essentially a qualitative and quantitative way to get to a decision for technology. We looked at things like speed, stability, security, all of the functionality, like community management, content management, obviously, ease of administration, collaborative tools, all of these sorts of things as well as time to market. How quickly could we develop for this? How quickly could we make changes and iterations? All of those kind of came into the analysis and you come up with a score and Drupal won by heads and tails. So it was pretty easy. So at LinkedIn, the decision was actually made before I joined for us to move over to Drupal, but a lot of the things that went into that key decision-making factor for us was basically, number one, it being an open source product, but yet at the same time having a very vibrant community that both as a volunteer basis and then also with professional support companies that are out there. So if we ran into issues, we would be able to get the support that we needed and both for pay and not for pay situations there. Another thing that went into our decision-making process was previously the platform that we were on, one of the reasons why we chose that was because it was a Java-based product. And so subsequently because of the fact that LinkedIn is a very Java heavy company, we thought that that would actually make a lot of sense to stay on the same thing. Well, we since learned that those requirements kind of changed and so we were looking for something that basically any ops person would be able to easily come in and be able to support and one of the benefits of a PHP-based solution is that basically almost every ops person out there can go and manage a PHP stack and be able to understand how to set up Apache, understand how to set up PHP and get things going. And then also another factor that played into our decision was being able to find all of the different features that we needed and then, but yet if we couldn't find a specific feature having a very extensive developer hook system and modularization system so that way we could go in and do the things we needed to do custom, but yet do it very easily. Cool. Well, Intel's quite large and our group is just a part of that, but being the open source technology center, it was obvious that we needed to find an open source solution. Most of Intel uses Microsoft for most of their product stuff and websites. So, but it just was clearly the winner from our perspective from the customization and the community perspective. So, you know, talk a little bit about Intel given that it is such a Microsoft heavy shop. I mean, obviously in your group, because you're open source, I mean, do you have pressures from other parts of the organization about open source conceptually or? I mean, Intel has a long history of contributing. I mean, we're one of the largest, I think second largest contributor to the kernel and to other projects as well. But yeah, it sometimes can be challenging just because the IT group can be entrenched, but you know, I think they give us wide latitude. Cool. So let's talk about the learning process for the development teams. I mean, you talked to Jeremy that you guys are a Java based shop. So when you made that switch where there was you or the people, other people within LinkedIn, you know, what was that process like? Would you go through from a training perspective, how much of a change was it? So in the case of that, basically our developer relations team, which I'm part of, is one who actually maintains the Drupal site there. So it necessarily wasn't necessarily an issue with moving Java developers over to that. But at the same time, there were, being like, I'm one of the primary people that actually supports and develops for our Drupal site. Being a longtime PHP user, I was very set in my ways of how I did things in PHP. And so subsequently, when you're coming in to a system like Drupal, sometimes things can be a little bit harder initially just because of the fact that you have a set way of doing things. And so subsequently, because of that, there's a bit of a learning curve. Whereas if you're coming in fresh and not necessarily having set processes for how you did stuff in the past, you can have a much easier time. And the way I liken that to what I'm talking to some of my developer friends is that Drupal in a way is kind of like the rails, so to speak, of the PHP CMS community. And that there's a right way to do just about every task. It's usually well documented, but finding out what that one right way to do that task can sometimes be a bit of a hurdle. The other thing that I would say is that a lot of the documentation that's out there and a lot of the tutorials and hands-on guides and things like this were written from Drupal 6. Drupal 6 was probably the landmark success so far to speak of the Drupal community. And so there was a whole bunch of content written about it. Drupal 7, there is enough difference where you kind of have to make sure that the documentation that you're reading or the tutorials that you're looking at, you're actually making sure that you're still following best practice. And so a lot of the things have not necessarily been updated, so you just gotta be careful and cognizant of that. And then furthermore, I would say, as with any open source product, you can't punt that responsibility of making sure that things are secure, things are done the right way and stuff like this. When you're using third party modules, you gotta make sure that you're looking over that and taking ownership and responsibility for making sure that what you're deploying is actually of a stable and quality nature. Excellent. I know, Amy, you talked a little bit about how you had a mix of both Drupal and non-Drupal developers. I mean, how has this impacted your organization from the development side? I think there's a little bit of a learning curve whenever there's a new technology, right? We went with documentation, we actually used DrupalizeMe for some training. I think the ramp up and everything like that was probably shorter than some other enterprise stuff. I think it's been pretty good. They're actually here, they can probably tell you more about it. Excellent. Talk about migrations. I know, at least Jeremy for you and Amy for you, migrations was, you guys moved over from proprietary systems from a developer community, social content perspective. What was that process like? What was some of the lessons learned or things you could share around that? Amy, do you wanna go first? So we actually had a pretty complex migration. We actually had a three to four part migration. One was, we actually had two from a Jive system, two different Jive systems, different versions. One from a homegrown CMS, and then the last one was from an internal PayPal system. So we had a wide variety of data structures, data types to move and kind of get everything together along with users. You know, we kind of morphed along the way and some of the challenges that we faced were creating a common framework and getting all of that lined up and having the foresight to understand what was coming at us again so that we could adjust and adapt as we went along. Well Jeremy, you wanna talk about your experience? So the CMS system that we were coming from that was Java based was something called Jive. So if any of you have heard about that, that's what we were using. Some of the challenges that we ran into was, number one was getting the content out of Jive. They actually have a fairly extensive API system but pulling out some of the content was not necessarily the easiest thing to do. We thankfully were able to use a XML output format that they had and then using one of the Drupal modules for import, we were able to pull in content syndication and pull it in through that mechanism. But one of the things that we learned kind of along the process of testing things was that the import-export process isn't perfect. And one of the things especially that you'll run into is that, especially in the case of with Jive, Jive went in and added a lot of custom markup and specific CSS style tags and things like this on a lot of the content. So when that gets imported into Drupal side, if you just do a straight import straight across, you're not necessarily, you're gonna have extra markup in your documents that, in your pages that is not necessarily relevant or needed anymore. And so subsequently, things may render just a little bit off or things may have a bloated markup. So you're gonna have to go in and hand finesse a lot of that content to be prepared for that. One of the other things that we learned, especially the hard way too, is no matter how many times you've went in and tested your import process, tested two more times. We ran into a couple issues where we thought we had everything absolutely perfect and then we go in on the day of the actual migrations, we were scrambling and had to go in and make a couple of fixes. So just be prepared that no matter how many times you think you ran over it, you probably haven't ran enough time so your process. Interesting. Now what about training for content contributors and people that use these sites and they're participating, whether it's interacting in the forums in some cases or providing information up there. I mean, what sort of things did you have to do in that site, Michael? Do you wanna take that one? It's been a pretty easy transition for most people and not everyone, but in general, the content forums and stuff are pretty straightforward. And I think it sometimes is difficult for people that are used to working in documents and that's kind of a jump for a few people, but in general, people make the transition pretty easily. So I mean, we don't do a lot of training specifically except for just getting the sites out there in front of people and allowing them to use it. That's usually enough. Yeah, I mean, one of the things that we hear, I know along the lines, when people are evaluating Drupal for these types of applications is, they see the sexy demo from a jive or they see something in the, like, oh, Drupal, we always hear about the authoring experience in that. So have you had any pushback from the authors or the people that use it on a daily basis or regular basis? Do you have people that are in it every day? Yeah, I mean, the people that are in it every day get more used to it. I think it could be better and even some of the stuff that's happening here at the conference and coming, leading up to the conference about the content creation form improvements and stuff are all gonna help. So I think in general, the great thing about Drupal is that it's moving fast and so it'll only get better, I think, but we don't really have a lot of issues with it currently even. Okay, Jeremy, do you wanna add to that? I guess one of the things that I would add to that is is that it kind of really speaks to the power and the awesomeness of Drupal in a way that, in our case, even our marketing and PR people and others who have dug in, now mind you, a lot of those are, at least they do have a technical slam, but not a single one of them that's had to have any specialized training. All of them have been able to go in and write content and immediately dig right in and do things. On your second kind of question that you posed to Mike, that would be one area that I feel like we may have lost a little bit, but it hasn't been a pain point. In Jive, Jive actually has a really nice feature that allows you to, for example, when you're posting a comment or you're updating a documentation page, it's very easy to go and find related content and be able to link to that directly from inside their content editor. That's one of those things that, I'm sure there's probably a Drupal module and I just haven't went and found it yet, but at the same time out of the box, Jive did a little bit better, but in general, I would say that it's extremely easy to get going with Drupal and we've had zero pain points from any of our content authors. Yeah, it's interesting, I was at a conference a few weeks ago and it was a CMS conference, but they're like, oh, we come in, and one of the other vendors is we come in and we'll train you on what you should be using a CMS for, and then we'll do training, walk you through requirement gathering, and then we'll build it for you and then we'll do you training on how to use it. And I was like, wait a minute, this is all the training I want. Can I use it? If I can use this, I want to be able to use your CMS. The expectations have shifted so much for content contributors. It's interesting, I just don't think people have much patience for that level of training just to use an application, use a system. This also ties into maybe a segue into mobile. How do you guys think about mobile for your developer communities, both for people that are contributing content or the people that are interacting on the communities? Michael, do you want to take the lead on that? It hasn't been the highest priority for certainly for our sites, but it's certainly becoming greater importance for us. And I think it's just a matter of being able to develop it in a way that allows for mobile interaction. And it's pretty easy to do in Drupal in general. I mean, it's mainly on the design side that you really have to consider. I mean, there's some improvements, I think, going into the administration side, but I'm not so sure that too many administrators are going to be administering their site on a mobile device. So I think it's more on the content creation and the viewing side that it's working out well. I know one of the things that you mentioned when we talked was some of the for your mobile developer communities, they're actually wanting to get access to their reference documentation and things on the device while they're debugging it or working building out. So some of the newer projects that we're working on are mobile OS systems. And so you're going to have developers are going to be kind of testing on live devices and are going to want to maybe jump over to see documentation really quickly. So that will be nice, I think, as well. Nice. All right, Amy, do you want to talk about sort of what you guys are doing in XCOM? We're kind of in the same boat where it hasn't been the top priority. I think it's becoming table stakes now. So it's something that we definitely have to address. My plan is to simply address it with the responsive design and take it from that approach. Interesting. Anything, Jeremy, you want to add? So I guess the point that I would add to that is that, and I kind of want to separate two facets of the discussion here. So number one, mobile is extremely important to LinkedIn as a company and it's also extremely important to our developer community. So having mobile access to our APIs and our platform and SDKs is something that's very important. But at the same time, I would say that accessing our website, our developer website specifically on a mobile device itself hasn't necessarily been a high priority. And a lot of that has to do with the fact that the people who are coming to our website based off of all of the analytics that we've done, they're sitting at their desktop computer and they're coding. So when you're sitting coding, you're going to have a web browser available to you and subsequently you're going to be able to pull up in that web browser and look at the documentation, interact in the forums and things like this. So while our website does work on mobile devices, specifically like an iPad, it's absolutely great experience. It doesn't necessarily translate as well down to an iPhone type or smaller screen sizes. And so subsequently it's not been a priority for us just because of the fact that most people, you can't code from your iPhone. So well, I guess you could, but most people don't. And so subsequently because you're not doing that, it's not been our primary focus. Okay, cool. So let's stick with you, Jeremy. Talk about real life best practices when implementing Drupal. The pitfalls or things to avoid. There's one thing that you know now that you wish you knew when you started off this effort. What would that be? I guess one of the things that I would say is that be very careful when you're using third party modules. There's a lot of really good modules out there, but there's also a lot of really bad modules at the same time. And popularity does not necessarily equate to a module being of a specific quality or not. And one of the things that I think part of the reason for that is that the Drupal community makes it extremely easy for somebody to contribute a module to the community. And so subsequently because there's almost zero barrier to entry, there's gonna be a wide range of different things that are published out there. And some of them are well maintained, some of them are not. And one of the things that I do wanna applaud the Drupal community on is that unlike other communities, for example, WordPress, where they kinda hide some of the issues, they hide this and they hide that from what's going on, Drupal makes it very obvious on the front page. You can see when the last commit happened on it. You can see how many bug reports there are and things like this. So it's very easy to identify what are the better modules in that respect. Two of the modules that I specifically wanted to kind of spotlight and that we had lessons learned on was that the Comet Notify plugin. It's a great plugin and allows people to be able to go in and be able to subscribe to comments that are posted. So in the case of like a forums module, if you wanted to know when somebody else is replying, you could subsequently subscribe. The issue that we ran into with that module is, is that it was very specifically designed in such a way that it didn't actually make as much sense. So if you subscribed on one post on a thread, you probably, and then when you post it again, you probably didn't wanna subscribe again so you would get duplicate emails. Well, because of that, because of the way the module was architected, every time you post in that thread, you could be resubscribing and get multiple emails. So that was a concern that we had to go in and do. Another one was the CDN module. The CDN module for Drupal 7, pretty much most of all of the CDN modules all stopped their development and they all pushed everybody towards the one that's called CDN. Unfortunately, due to a bug that was in the CDN module, you had to go in, like you couldn't actually use this in Drupal 7 because it didn't support the public colon slash slash URLs. And so subsequently, it didn't work. Furthermore, if you fix that problem in the code, which I do wanna take time to note that there is, the bug tracking system is an excellent resource. So make sure that any of the modules that you're using review the bug tracking system because there's tons of, almost every issue that we have found, somebody else had already posted, and in most cases, it had already posted a patch to fix it in the bug system, whether it had been rolled back into the code base or not. So that's an excellent resource for you. But in the case of this, once you fix that problem, then if you're an HTTPS site, there was another bug in the module where it didn't work for HTTPS. And the interesting thing about this module is it was extremely feature rich. It had pretty much everything you could ever want in a CDN module. And subsequently, there was about 3,000 lines of code. Well, when I went in and spilled it down to find exactly what we needed out of that whole module is nine lines of code. So in this case here, we decided, instead of running into these perpetual issues and module that hadn't been well maintained over the last year, we just took the nine lines of code that we needed that were relevant and made our own module and then subsequently use that. So be prepared and aware that that might be a step that you need to do. Furthermore, I would kind of say that, like I already kind of touched on this, but be cognizant of the fact that just because you're using open source, you still have to take ownership for making sure that security, you're staying up to date and things like this. The Drupal community is really good about publicizing when there's a security fixes and making sure that you're aware of it. But you need to dedicate time to making sure that you do stay up to date and making sure that you're staying on top of those. The general rule of thumb that I always like to use is plan on using about an hour a week to maintaining and keeping your site live. And that doesn't mean that you have to do an hour's worth of work, but making sure that you're staying current on what's going on in the community, knowing where the community is going is gonna set you up for success in the long run. Especially like paying attention to, even though Drupal 8 isn't released and out there in the field yet for production use, making sure that you know where Drupal 8 is headed, making sure that that aligns with that, with your goals and your initiatives, because otherwise it could catch you off guard and subsequently you have to maintain and support that. So Amy, why don't you go next and talk a little bit about what you wish you knew back then when you started? Oh, there's probably a ton of stuff that falls into that category. I think as we rolled out our project, there's plenty of things that have come up and I think we're still uncovering a lot of stuff. You know, I think taking ownership of the modules that you install is a good thing. You definitely do some vetting behind the modules before you roll them out. Bug tracker's awesome. Just take a look around and make sure everything's good and solid before you go forward with it. Michael, do you wanna add anything? One of the things that we have learned over the course of the years is that a lot of our, we have a lot of sites and a lot of the stuff is pretty repeatable and so we're really, you know, driving towards the distribution kind of model and kind of the features or apps where we can reuse them so we generalize them sometimes, add some settings so that they can be customized for a site but are basically the same code base and that's been really useful because that way, you know, it just shortens our development time considerably for an individual site. Excellent. Talk about change management, you know, or team structures for successfully implementing Drupal. You know, you talked a little bit about your guys are going on the solution route, I know this, you had some pretty strong opinions here. Maybe why don't you kick us off, Amy? So x.com is kind of in a tricky situation from a corporate website perspective. We have a ton of stakeholders. Pretty much anybody and everybody in the company has a stake in this site. All the products go out, you know, we're in the go-to-market plan for everybody and as we were rolling out Drupal and as we were redesigning this site and redeploying it, we restructured the team considerably, we had a large enterprise Java-based team overseas, offshore. We restructured the team into a much smaller team onshore, all based in San Jose with a mixture of skills, you know, we really kind of spread out the skills so that we had people who were really good at CSS and had people who were Drupal experts and had people who were learning. And I think the structure is working out really well right now. Excellent. Jeremy, anything you want to add? So one of the things that I think that has made us extremely successful in this area so far is we spent a lot of time when we were initially doing the Drupal deployment to go in and set up a lot of the groundwork and infrastructure pieces ahead of time. And that was one of the things that made it very easy for us to roll out new changes and things like this. Some of those entailed, for example, a Git-based deployment process that allows us to be able to roll out new fixes into the field. Other things were automated backups. So for example, besides just the nightly backups that everybody naturally normally runs, we also made it to where, for example, every time we did a new deployment to the site, it would automatically back up the entire code base as well as the database. So that way, even if you'd forgot or something like this. And that also facilitates easy rollback. So that way, after, say, for example, something pushed out in the field and there's something wrong, we could run one command from the shell and be able to roll back to the exact state where it was, even if there had been migrations or other things that had happened to update the database. And then finally, was making sure that you had a consistent approach to being able to bring in the site up and down. Basically, if you are just depending on the maintenance page, well, when you're pushing code, you can't depend on the fact that the maintenance page is actually gonna be live. So we configured on our load balancers a way to be able to, when we're doing a push deployment process, that none of the traffic even hits to the web servers at all. And it says that the site is in maintenance and that we're actually doing that push process. Excellent, excellent. Let's talk about roadblocks. What do you do when Drupal doesn't meet your needs, your community? Developer communities usually have a lot of different pieces of it, wikis or something we talked about, some of those others. What do you do when you hit one of those roadblocks? Michael, do you wanna take the start? Yeah, a lot of the developers in our group have worked with other tools and so Drupal wasn't always the best answer in the case of a site that has a lot of developers and needs a good wiki. We usually go with midi wiki. Just because of the way that they're used to working and the ease of that application for wiki content. And we find that with some other applications as well. So it really comes down to, is there a tool that is good enough to use and then if not, then we can look at Drupal and if it doesn't exist in Drupal, then we can build it. So it kinda goes down that line. Usually we start with does the functionality exist in Drupal and can we leverage that to begin with and if not, then we look elsewhere. Do you wanna go to Jeremy? So I would probably echo the same things that Mike just said but an additional, so what we kinda ran into issues wasn't necessarily on the wiki side of things but is in our forums. So we have a very vibrant community that's posting a lot of posts and they're asking a lot of specific questions and stuff like this and because we segregate out our forums based off of different respective parts of our API. So in our case, for example, our REST forums are separate from our plugins forums and so subsequently, as you probably well know in any forum, people post in the wrong forums, they post on existing threads and things like this and so one of the pain points that we've kinda ran into is that the forums, while it's a pretty good and it has a good solid foundation, it's not the same thing as a full featured forum package like for example, if you've ever used V-Bolten or things like this, so the administration capabilities and things like this are a little bit lacking. I would say that it hasn't necessarily been a roadblock for us but it's kind of some one of the things where we wish it was better and so subsequently, like Mike said, it's one of those areas where we're gonna probably invest some time and effort in going in and enhancing advanced forums and making super enhanced or advanced forums to be able to better support some of those administration features that we're looking for. Excellent, thanks. Amy, do you wanna talk about a few things? Sure, I think we take the same approach, check it out, see if it's out there, if we can leverage what's there, if not build it. One of the things that we're tracking right now is technical documentation and we're having a really kind of difficult time combining all of these different formats of technical documentation into something that's reasonably presentable on the site and we don't exactly have a solution yet, we're kind of exploring our options right now, so. Okay. You know, just a reminder, if you do wanna submit a question via Twitter, you can, we'll move to some of those as well here. There's a question actually that came in from Dan. Amy, you mentioned the LAM analysis when you did your sort of selection process. Can you talk a little bit more about what that is, explain it, maybe provide references that other people might be able to use that framework for? Sure, it's actually, if you do a search for it, it's L with three As and an M. And it was actually created by one of our chief architects, Jeremy Carrier. It's actually a pretty easy way to make a technology decision. You essentially, you define what good is and you have a quality tree. So you kind of define all of those things that you're looking for in a good product. And then there's a whole formulation that goes with it where you give ratings and values to each of those qualities and you end up with a score. And it's a really easy way to actually come to a conclusion in a quick way. Interesting. What about commons, Drupal commons is a distribution for community sites. Did anyone look at commons, evaluate that? Sort of what role did that play in your process? And Jeremy, do you wanna talk or does anybody have a, okay? We actually did start by looking at commons. And by the time we got through all of the things that we actually needed, we realized that it was the Drupal six versus Drupal seven. Did it make sense? Were we gonna use enough of commons to stay off of seven? And it just didn't match up. So we ended up with essentially a partial commons on Drupal seven, so a lot of the bundled pieces. I gotcha. But not all of it. Anybody happy to take questions from the audience if you guys wanna come to the mic, all right? Hey, thanks. I'm Ryan, workonopenii.org. And we're an energy sharing platform that's considering building a community and developer community is a big place we'd like to start. We have a lot of APIs and different things like that. So I'm wondering how do you incentivize building a community? So I think like for LinkedIn, well, the developers there are really interested in building something for LinkedIn, I imagine. But for an energy information platform, how do you draw those developers? How do you keep them there? How do you say this is the best place to be for finding energy data sets around the world and user APIs, et cetera, et cetera? So how do you drive community participation? Build it and they will come, right? Right. So as you pointed out, people already know about LinkedIn. So they're coming there and they're actually wanting specifically to integrate with the LinkedIn platform. So that part of that has already been, that hurdle's been a little bit overcome. I would say that one of the biggest things is making sure that people feel a part of the community and making them feel like they are being able to contribute back. So I know personally from the communities that I've been involved in prior to working at LinkedIn, specifically, especially before I joined Yahoo, was the communities that I took part in was the ones that I actually felt like I had a contribution and I could do something there. So whether that was maybe helping improve the documentation, maybe that was going in and smoothing code samples or tutorials, maybe that was answering questions in the forums. So making sure that there's avenues where I can feel like I'm doing some kind of impact. And then also getting recognition for the impact that I am having. So if you can figure out ways to be able to spotlight members of the community that are, they are doing a lot. I think that you're gonna be a lot more successful in that regard. Then as far as driving traffic, I mean, it's a standard process you would to drive traffic towards any of the sites, is making sure that people know about you and that's gonna be relevant to, you know, every site's gonna have a different mechanism for doing that. But the general broad goal is just making sure that you're out there talking about it and making sure that other people who are writing content that's related to your site, making sure that they know about it and they're linking to it. I mean, I think a lot of it is just the ease and the findability of the information and is it easy to post in content? Is there a lot of hurdles that they have to jump through? And all that stuff I think contributes quite a bit to the participation rate. I mean, I think there are other ways as well, but I think those are the pretty key areas. I think engagement is something that all of us kind of are challenged with at any given time. You know, we actually are spending a lot of time on reputation building and being able to showcase people on how their contributions are affecting the community in a very visual sort of way. And I think that, I think it remains to be proven, but I think it's a good step in the right direction. Anybody else have any questions that they wanna ask at the mic? All right. Hi, I'm Ben. When I work at CGI in Canada, I manage the Drupal team where we build large scale infrastructure for banks and things like that. And one of our bigger challenges we often have is everything around deployment, whether it's content staging, whether it's deploying new sites, whether it's the general deployment mechanisms is always a more or less a custom solution for each client. I was wondering how you guys generally handle that. Do you do content staging? Have you looked into the Eager project, for example, for helping rolling out sites faster? Or can you talk a bit about your strategy around that? So as you mentioned, I think it is gonna be very specific to the type of environment that you're working in. So in our case, all of our infrastructure at the moment at least is hosted on joint smart machines. That's something we're gonna probably bring back in house and be doing on our own infrastructure. But so a lot of the process around that was very specific to like how we were set up in our environment. I would say that we definitely do have a staging environment. We also have developer environments. So one of the things that I set up was going in and using something called Vagrant, which allows you to quickly set up a developer environment that's reproducible. And so because we had the backups that were automatically being done, every time we did a code deployment, it made it very easy to just be able to go and grab one of those tar balls and then use that to build the developer environment so that we had exactly what was in the production environment for your testing. I would say that there is a number of different projects that are out there in different stages of maturity that kind of make that process a little bit easier. And then, but we just, it didn't necessarily fit our specific needs. One thing that I do wanna kind of plug here on the AQUIA side, AQUIA does have a solution where that we were interested in but didn't necessarily work for us was being able to have like development staging and production environments and then being able to easily like one button push migrate stuff that had happened in your development environment to the staging and then up to the production environment. And it sounds extremely interesting and I would love to explore that a little bit more but it just didn't fit linked in specific needs. Anybody else, anything else they wanna add? Yeah, I think I would echo that as well. It can be difficult in there. It usually does come down to some kind of a custom solution but I do think that some of the hosted solutions like the AQUIA and Pantheon have some interesting concepts around them and may work for your needs. It didn't work exactly for our needs because of the requirements of so many other services attached to these sites and so that became a little bit difficult. Someday that might get resolved. Go ahead. Okay. So I'm wondering what's the best way to support a hackathon and to build your development community from going to hack events, helping people get data, APIs, et cetera from those events. Do you have any thoughts on that? So I don't have a direct response from that from a LinkedIn perspective but based on my background with Random Hacks of Kindness I can give a lot of insight there. So basically Random Hacks of Kindness is about developing hack day events and then one of the challenges that we've had with Random Hacks of Kindness is bringing that continuity between events and so that way just because you're at a 24 hour hack date it doesn't stop there. There's still ongoing things that go on especially because our nature of the hacks that we're doing with Random Hacks of Kindness is trying to build sustainable solutions for disaster response in the now environmental impacts in other areas. So basically you can't just stop at that point and so that's why in the case with Rock we are leaning on Drupal and being able to build out a drivable community where people can interact and be able to stay up to date on what those specific hacks are. So again it's very much intended by your specific audience but in our case there it was being able to make sure that all the projects that were worked on are being spotlighted up on the website that there is a way for people to be able to find out who was working on these projects find out what the current status of those projects are and then also being able to get involved and contribute back specifically. That was all things that were have been very successful for Rock. All right, go ahead. So I work for Jaspersoft and we are currently in the middle of a migration of our community site Jasperforge.org and one of the things that has come up and we're still undecided about is user points or user karma. Thinking about either going with a model like Stack Exchange or Stack Overflow or I was just wondering if any of you had experience or thoughts around user karma or user points. Amy, you talked a little bit about that, right? Yeah, we're actually in a partnership with Badgeville to create a whole framework for that. You know, there's a bunch of facets to that. It's user points, there's user badges, there's profiles, there's levels, expertise, all of those things that all kind of roll into you know, a karma or whatever you want to call it. It's kind of a cool thing. I think I said earlier, I think it remains to be proven for us in particular. I think it's proven elsewhere. You don't think of it, but that little badge next to your name is pretty powerful when you get those and it kind of sinks into your mentality and you start working towards things more often. Yeah, I know just even intuitively when I use forums, customer support forums or whatever, those are the kinds of things I'm looking for before I go read the answers. You know, I know Symantec has a customer support community built in Drupal called Connect and that's a big piece of that experience. I don't know, do you guys, anybody else have anything they want to add on this side? I would say that it's something that we agree is very important. It's something we're investigating at LinkedIn. So in our case, you know, for example, with a profile that you mentioned there, we pull in through a single sign-on solution, we pull in all of the existing LinkedIn profile, but one of the things that I think would be a very interesting is not only having the badging specifically on the LinkedIn developer website, so when you're seeing so many of the forums, you can see like what the reputation score is and how good a quality of responses the community thinks that they have or how many responses in general that they made, but then also being able to have that badging show up potentially on LinkedIn.com. So whenever somebody's viewing your public profile, they can see, oh, this is an active developer in our community. So it's things that we're exploring, but right now we just don't have a established solution in place for. We've looked into it with a couple of our projects as well, but we never really have gone down that road. So I think maybe someday, but it gets complicated, I think that's the thing. There's a lot of data points and the value of those data points is different and it's kind of subjective a little bit, so you have to be kind of careful. Go ahead. Thanks for letting me monopolize questions here. I have a lot of good, or I have a lot of questions for you guys, so. All right, Awkward Commons, I think of kind of as a huge vacuous warehouse when you first install it, there's like 10 different features at least, forums, blogs, whatever. How do you start that with a community without them feeling like they're in this universe that has three people in it? Like what tools do you start with first? Do you start with forums? Do you start with blogs? Do you give the community everything and just say have fun and see what happens? Do you build up through organic groups? What are some strategies around that? Just in general, like how much, how big is the menu when you first start, right? Yeah, we usually start pretty modestly with blogs and stuff just because, and then build that over time. But usually it's some social interaction stuff like blogs and then it's a lot of content and then the content starts to drive people and then you add additional functionality over time. But yeah, you don't wanna necessarily launch with an empty site. I guess I would echo those same points is, is that you need to make sure that you have enough content to keep the people interested in coming back. And you also don't wanna overwhelm them with a lot of different places that they need to go to until you have that established community. So I would say like focus on, whether you're gonna do the blog, focus on maybe you're gonna have like static content, things like this. And then also in the forums, if you can go in and get like a closed community, like for example, your immediate peer group or something like this to go and start discussions. So that way, whenever you do officially launch, then you don't see like a completely dead forums. I know that from a lot of the communities that I've been involved in in the past, if the site is completely barren and there's no activity on it at all, it's gonna be a lot less likely that I'm gonna come back and check those forums because it's just, I don't necessarily see that content. So trying to get some of that initial content there is gonna be very helpful to you I think. Yeah, you definitely wanna see stuff. Something as simple as an FAQ is often helpful to someone who's new in exploring a new product or a new offering. An empty site is never a good thing. Cool. Well, I think we're out of time here. So I wanna thank our panelists for taking the time out of their busy DrupalCon schedule to come and participate here. So let's give a hand for the panelists. I wanna thank you all for coming and also encourage you to take the survey, provide feedback on the sessions. Obviously that's very important for everyone. So I encourage you to do that as well. But thanks everyone.