 Okay, so let's get started. Thank you everyone for coming. This is the Drupal distributions leveraging open source solutions session. It just rolls right off the tip of the tongue. And we've got some real leaders today in the area of Drupal distributions and I'm gonna let them introduce themselves but first I wanna just talk about the topic of distributions a little bit and provide some background. So what are Drupal distributions and why are they important, right? So there's a lot of different ways to think about Drupal distributions. There are technical explanations, there's kind of a business-need explanation and the way that I like to think about them is that when you install Drupal Core you get a tool for building websites which is really powerful but it's still a tool for building a website or a web application. So if you want a tool, if you want a purpose-built solution you've still gotta go ahead and configure and set things up so it's not really ready to go. A Drupal distribution is powered by Drupal Core but it is purpose-built for a particular purpose. So once you install a Drupal distribution you've got an application that's ready to manage your conference or your intranet or your publishing site. And so you can look at them as an accelerator to site building so they make it quicker to build a site and you can also look at distributions as kind of independent from Drupal in the sense that while they happen to be powered by Drupal they have a specific purpose and they provide value out of the box. So a little bit of history about distributions, distributions actually go way back in Drupal as early as 2006 and certainly there was discussion earlier but there's a blog post that's often referenced by Dries where he referred to distributions as the future of Drupal and he said, Drupal 5, the upcoming Drupal release will have better support for Drupal distributions. Now this is true and of course Drupal 7 is the current core version of Drupal. We're talking about Drupal 8, that post was done at the time of Drupal 4.7. So quite a while ago and there were improvements in Drupal 5 for distributions but really it's taken a while for distributions to become more mature. A couple key milestones in the maturity of distributions that we should mention are in 2009 the features in Drushmake projects were created and so those are two really fundamental tools for technical components for building distributions and then only recently this month full distribution packaging on Drupal.org was made possible and so what that means basically is that previously you could develop a distribution on Drupal.org but there were a lot of limitations around what kind of distributions could be downloaded from Drupal.org so if you had patches to modules or if you had third party libraries like jQuery UI you couldn't make that packaged distribution available for download on Drupal.org and so people had to host them separately or even package them separately which was added some complexity to the process of building distributions. So it's kind of taken a while for us to get to where we are today and really there's still a bright future ahead for Drupal distributions. I do want to highlight that last step because this is really one of the biggest milestones towards distributions, the packaging enhancements that were completed recently. These were funded by the companies you see here, a couple represented today in the panel and it's really easy to complain and say oh I wish Drupal.org was better, doesn't do distributions the way I need it to so I'm just gonna kind of complain but a lot of folks worked on this and in particular these companies stepped up to sponsor so that was really great so thanks to everybody who sponsored that initiative and helped work on it. Yeah, little applause, right? Moving distributions forward for everybody and for some reason the slide appears again. So the bottom line there is that it's taken a long time for distros to mature and they're still maturing. So now in reverse alphabetical order by a company name I will let the panelists introduce themselves. We're very organized today. Reverse alphabet. Starting with phase two technology. In case you didn't have that off the top of your head. I didn't know if we were going by last name because that would be also me. Yet, so there's two folks here from phase two and I'll let Karen introduce herself. My name's Jeff Walpole and the CEO of phase two and our company maintains currently four major distributions. Open Public, Open Publish, Open Atrium and Managing News. So those are the four that we're actively involved in and we've been doing Drupal distributions for over three years now. We launched Open Publish at Drupalcon DC in 2009. So we've been through the rocky road of doing it one way and coming back and doing it a different way and we actually have had quite a bit of experience on our technical team with that. So I think I'll let Karen introduce herself in her role because it's important here too. Okay, how's that? Oh, there we go. I'm Karen Borcher and I'm the Director of Products at phase two. So my job is to manage the roadmaps and teams who are developing and building these products as well as the community management aspect of what we do in helping to get more documentation, training, videos, and help around the distributions. So managing kind of the whole ecosystem of the distribution, not just the technical build. And that's part of our commitment as a company with the distributions is just not to build them and put them out there, but to try to look at the support around them more holistically. So that's my job. And then level 10. My name's Tommy Kraken, I'm the Director of level 10 and we maintain a distribution called Open Enterprise and we actually launched it underneath a different name, kind of a convoluted name called Iside Essentials back in just before DC. And kind of it's been an interesting, through the four revisions, kind of an interesting winding road that I think just been through a lot of the same things. My name is Mike Shaver and I work at the Intel open source technology center. And so I'm actually, we don't do a distribution, we just use them for a lot of the open source projects that we, our developers are participating in. So we have experience with using Cod for a number of conference sites as well as OpenHRM for some of our internal collaboration. And then we've been looking at other ones as well, just for other uses. And AQUIA starts with an A, so we're at the end of the alphabet. My name is Mark O'Brien, I'm the Vice President and General Manager for Distributions at AQUIA. And my history actually is very competitive against proprietary solutions with the open source space. I'm still active with a project called Open Proge and there's about, they compete against a Microsoft project and I think it's kind of a pattern about going against the open source via these of the proprietary vendors. And Open Proge was downloaded about 125,000 times last month. And so there's many proof points out there, Drupal being another one. And the expectations for me with distributions is to have that same kind of effect in the marketplace. But with AQUIA, everyone probably knows has commons and Cod and I will let Ezra continue on with the intro. Sure, so I'm Ezra Barnett-Gildes game and I'm the technical lead for the distribution team within AQUIA. I'm also the project maintainer for the conference organizing distribution and the commons distribution of Drupal for conferences and external community websites. And I'm looking forward to talking to all the panelists today. I think this is gonna be a good conversation. So let's get started. The first question that we've got here is how do distributions get started, right? Do they come from client work? Is there some seed funding or is there just kind of a magical community initiative when people get together and build them? So I guess I'll start out with Karen. Do you wanna start that one? Sure. The answer is really that all three of those things can start a distribution. At phase two, Jeff can actually talk more about how our distributions were started with client work. But a lot of our work at phase two is in specific verticals, specifically in the online publishing vertical and in the government vertical. So we've built a lot of expertise which is really at the heart of a distribution is expertise in the module choice and the configurations and what's needed specifically for a site for a specific group of users. And so a lot has come from client work. Their open atrium is not one that we built. It's one that was built by Development Seed and was done some with client work and then also some with grant funding actually through the Knight Foundation. And then there are also community initiatives that start some of them too. But Jeff, do you wanna talk anymore about how ours got started? Yeah, so as Karen said, I mean we built open public and open publish with work we'd done in the industry sector. So open public, we'd done work at the White House and House of Representatives and we tried to pull some of the government specific things that were developed therein. And with open publish, we actually got a contract from Thompson Reuters who had developed a technology called Calais, which is a semantic metadata processing and they were looking for a way to integrate that into Drupal and we did that and then we released that as part of the distribution. So I guess we have done a little bit of both and then Karen mentioned the Development Seed story with regards to open atrium. So I think there's a lot about probably four or five different ways that these things get built and I guess I'll let one of these guys talk about, I mean, awkward would be another example of how it's done. It's a really interesting question. I think that long term for a sustainable distribution, you have to have an ability for the maintainer to monetize that and the monetization of that could be your domain expertise. In my role at Acquia, a lot of people come to me with their distribution ideas and just over the last couple of days, there's been some really interesting ones including things like urban planning and real estate, et cetera. But the core base of that is that those organizations have domain expertise there so they're looking to monetize it and obviously add value through that. At Acquia, we've basically done all three. I mean, we've done the seed funding, we do a lot of client work with our professional services to augment that but I think the key one is the third that's listed up there and that's community involvement. I think for all of us, Drupal in general, but distributions in particular, we've got to get much more community involvement across the board, across all distributions to really see these things take off. One, I guess, one comment I would have is that anyone really can build their own distribution and it's just a matter of if you think there's a need for something that replicates more than once, essentially. So I think it's more about your use case and trying to define the exact sort of place where that needs to happen within your organization. I mean, I think the way we came to it is a little bit of a common theme that we learned to start doing Drupal back in 2008 and we're trying to figure out what are the modules supposed to use, how are we supposed to put this together, we're building a lot of, we've built a lot of corporate sites, marketing sites, things along those lines and it was a way for us to sort of codify our standards instead of documenting we codified it into and in the beginning it was just a database dump and a bunch of modules and I said, hey, why don't we actually turn this into a distribution which was insanely hard back in those days and then eventually features came along and then apps and things like that to make it easier but it really just kind of came out of trying to be more efficient for our clients and starting to codify that. Yeah, and to just jump in there on specifically the conference organizing distribution it's interesting because I would say it was primarily funded by client work through historically through the company GVS which is now part of Acquia but initially it started out, well the Drupal 6 version I should say started out here in Denver for Drupal Camp Colorado and there was a community effort to build that site in a way that contributed features back towards the distribution and that kind of provided a base for some other folks but in particular GVS to then go out and sell consulting work essentially that resulted in contributions and so at first cod wasn't particularly feature rich but then we added the schedule view and other features that are now key parts of the distribution so at the same time some company funding went into moving some of those things along often if you contribute code back from a client project you kind of need 10% more time to just button it up and get it into a state that it's really generalized and ready for community contribution so definitely agree that having all three of those is a solid way to build a distribution which brings us to our next question how do you measure the success of your distributions this is a tough one and yeah it looks like Mark is eager to answer oh Mark is eager to pass the microphone to someone else I see this was actually a running joke before we all got on here so I was handing it to Karen but since I have it yeah exactly that's actually a really tough question because it really varies based on the distribution and based on the intent of that distribution I know that the maintainer of ELMS for instance is out here and that's an e-learning management system that is for Penn State so success for them is obviously deployment internally at Penn State and success there for commons and COD for instance internally at Acquia we measure success a number of ways and we track the downloads we track the growth we also we tag in salesforce.com and so that we can tell from a monetary standpoint what the growth is there as well so that is that that's one way but also there's contributions from the community and I think that that's that whole theme of community involvement again so the number of commits from the community the activity on the community and the forums those kinds of things are it's almost like the canary in a coal mine if that dries up you know that's you got some work to do so I think all of those together it's both from a community side and also from an activity side anyone else want to? So we see I really like the term accelerator for distributions it's a really good word for it one of the I think one of the ways when you are thinking about how you measure success for your distributions you have to figure out first what success means for you and I think you know for us in distributions there's two things that our distributions do for us they lower the cost of acquisition of our customers for a sales perspective and a marketing perspective they bring us people because they people see that we are experts in this space because of that distribution and because of what we've built and what's powered by that distribution so that's one way and then another way is it lowers the cost of our execution and that's you know what Tom was saying is it helps us lower that so those are the you know one of the ways that we look at our distributions and whether they are successful is it's bringing us people and taking you know is it less time and less energy for us to go out and convince people to build their sites for them and is it making us more efficient does it take over does it take care of the first you know 100 hours of a project 200 hours of project 1,000 hours of a project how much time does it save you and how much money does it therefore save you and how does it accelerate your projects right either from a sales perspective or from an operational perspective since we do a lot of this in-house with our team and I guess in theory I pay for it I can tell you that you really do need to put some kind of a return on investment look at total cost of ownership of these things because building them is one thing maintaining them can also be very expensive there's an enormous amount of responsibility in the community around doing this and since we've not just doubled down but quadrupled down at this point we're spending last year we spent about a million dollars I was a 1.03 or something like that I almost threw up when I saw it but it was done consciously for a number of reasons and for us a lot of the return is yeah it's in acquisition of customers it's in sales it's in marketing but it's also a way to provide our developers a release from the day to day of building heavy deadline-driven websites so it's a nice way to get them involved in the community to help them build their own contributions their own personal brand and also get to do something other than their project work so the problem and my point I guess in measuring it is these are very intangible things and they're very difficult to put a price on and when you're trying to recruit and retain a high quality workforce in this subset of the market here you have to think about some value there as well and we're looking and right now and Karen has been charged with it but we're looking at ways of monetizing or not monetizing but really quantifying all of that so that we can actually have a measurable return on investment and we know when we put an hour into open public we know exactly what we get back as a company but right now that you can really only do it from a sales perspective I think there's a lot more benefits than just sales and marketing you know it's kind of interesting some of the same things that Jess talking about is really there's kind of three vectors that I think we look at when you say the success when you start these projects it's really we're a bunch of developers it's our art we want to make something really cool and you don't always get to do that with your clients so you've got kind of this time and then there's the altruism side it's really kind of neat when people come up to you and say hey I built this really cool thing I used your tool in fact we went around looking at some of the things we're seeing like these wedding sites coming up and some really cool stuff that's being built but then eventually you start to realize that okay well the art part of it and the altruism part is great when you get started there's this really heavy maintenance cost and so eventually you got to figure out some way of making it financially viable and we're sort of trying to figure that out ourselves as we go along yeah and so very related to that long-term maintenance is getting contributions to a distribution from outside the company that's the main sort of sponsor or funder of that distribution so have folks on the panel had success in encouraging those outside distributions and what are your secrets to getting people to contribute hot potato microphone up here no kidding well this is actually something that really challenged us to be really honest with you I'm not gonna sugarcoat it and say we've done a perfect job of this because we haven't we actually got almost into a place where we were a little bit closed in the way that we were developing our distributions we didn't make it very easy to contribute to we didn't we had a very internal theme and that was really difficult to sub theme so it was very hard to contribute themes and sub themes it was hard to contribute to the modules or really be involved in the builds of it and it wasn't very easy at that point because distributions weren't on Drupal.org and the issue queues weren't there it was really hard also to it was really hard to manage that process and we really got into a place where we became very reactive to the community and not proactive and if anybody heard Ryan from Commerce Guys yesterday talk about how they got started with commerce and the way that they encourage community contribution with commerce it's a much more proactive method and they're very very involved in getting people in now we've taken once you know when we rebuilt on D7 when we started now that everything's kind of moving to Drupal.org and we've got every issue queues there and everything's there we're starting to see a lot more contribution we put a full-time community manager on just to work on this just to work on getting people involved and contributing to and developing with the distributions we ramped up our documentation and training information just a huge amount all in an effort to really get more people involved and more people working on the project we've seen a lot of success with that with the apps and app server module with level 10 and media current and some other companies really coming in so we're starting to see the fruits of that labor but we really had to make a shift from being reactive to proactive in that department and that's something that's a lesson we learned from the early days of distribution building. Yeah. I just want to tag on one very important point Karen made there is some of that has to do with people it has to do with reaching out to people and sort of being a company versus part of the community and all that but there's some very real differences in the way distributions used to be built versus the way they're starting to be built and should be built now and that has to do with the packaging of them and how heavy they are as a tool when we built stuff on Open Publish for instance on Drupal 6 it was a very large set of modules there's a lot of custom stuff there was really no way anyone could make contributions to it other than just send us patches and so now what we're doing is we're pushing it all back on Drupal.org and you can take an issue for your distribution and move it back in the issue queue to the actual module and the distros themselves are getting lighter so there's less stuff in the distribution it's more of a smaller core and then the third thing is using something like apps or features to provide more flexible extensions to these things so that people could actually contribute in an app or modify an app and then have that not even need to be in the download because the apps module will allow you to actually pull that stuff in when you're doing installation so you don't have to roll a whole new release anymore just to get updated functionality and that's a huge change in the way these things are being built so I think maybe Tom has more on that too Well I mean definitely the in fact we pretty much had abandoned our distribution back before features came along and then even features it really wasn't as flexible as we wanted and apps has really gotten into where we were really hoping years ago but I guess you know getting back to the original conversation we're just starting to get into community involvement one of the things that we're actually using our distribution a lot for is teaching we do a lot of work with the Dallas Drupal user group we do a lot of beginner stuff and so I think doing things like having app sprints and sort of teaching people best practices and seeing hey if you guys come up with some good stuff coming back we've had several people come up to us at this conference and ask about getting things on our app on our app server and so forth so we're kind of new at doing it anybody else have a comment? Okay so I actually would like to talk a bit about both comments and Cod was always developed on Drupal.org Commons historically was developed on GitHub and so shortly after I joined I started an initiative to move the development of comments to Drupal.org and that started around last summer so around August of 2011 and so what we've got here is a graph of issue queue activity for Commons and what you can see here is the number of users commenting filing new issues and then what's really key here is the total number of non-Aquia attachments so Drupal.org uses a patch workflow and what I've done in this graph is subtracted the Aquia team patches and so what you're seeing in the yellowish orangish line is which is probably not very distinguishable on this projector is this one here is patches filed by people outside of Aquia and so what you can see is as soon as we move development to Drupal.org essentially right after that there's a huge spike in the number of outside patches and I think that that's pretty straightforward it's not really surprising Drupal.org has a set of conventions around contributing code through the patch workflow through the issue queue and so GitHub is an amazing system it's transformed the way we work on software but it's not really the standard way of working on Drupal specific software so once we adopted that convention we saw a really big increase in outside participation and this goes through February and as you can see the number of unique users so this is not the number of comments the number of unique users commenting in the issue queue has only increased so that was a huge benefit for us and for everybody using the comments distribution on an architectural note one thing that I think is pretty successful as an approach is to and this is sort of related to apps is that you want as many of the components for your distribution outside of that project and living as independent projects as possible so the conference organizing distribution uses a module called UC sign up to integrate to provide the smooth checkout workflow that integrates Uberkarts e-commerce functionality with the sign up modules attendee management functionality and this is a graph of usage statistics comparing the conference organizing distribution with UC sign up and what you can see here is that UC sign up has over double the number of reported site installs and the benefit of that to Cod is that that's twice as many developers twice as many sites theoretically contributing patches towards UC sign up which still benefit Cod and so by taking those components those key components out of your distribution where possible building them in a way that's generalizable and not specific to your distribution you increase the potential audience of people who can contribute and so of course not shown in this graph is Uberkart which has an install base of something like 10,000 sites and so of course there's even more folks contributing to Uberkart and all of those enhancements to Uberkart come back and benefit Cod so the real message here that I take away from that is as much as you can get those components out of your distribution as much as possible so our next question brings us to some exciting news in the Drupal world as you may have heard recently phase two and treehouse agency recently merged two leading Drupal shops and so two questions related to that first of all congratulations and second of all two questions that you can sort of answer together or separately as you like first of all how will this merger impact the work on distributions that phase two is doing and then secondly it seems that there are some different technical architectural preferences that the two companies have in some areas like boxes and bean and things like that so how do you reconcile those I mean do you use them both where they're best appropriate or you get to try to standardize on those approaches or have you thought about that yet? No we haven't thought about anything at all no this was just a spur of the moment decision seriously this is a really hard question but I think a really important one for us and frankly for me personally I think one of the things that I had mentioned earlier is when you really trying to get the best people in this space from a development perspective having innovative projects they can work on is critical because smart people don't rest on their duff they need things to do and so product innovation was a natural part of how we got good people and how we kept those people happy, excited, interested, involved and all that and I think it also was the same thing at Treehouse they have a lot of contributors and people who innovated a lot of modules so the question becomes how do we pull those things together in a way that makes sense and we've got very real examples we work with something called boxes they work with something called beans they do similar things there's a bunch of... Could you put the beans in a box? Yeah, we're gonna come up with a can of beans Yeah, there you go So we have a very interesting challenge in our hands and one of the ways that we're approaching this merger is we're saying, okay can we really actually get the best stuff from both companies to prevail and so what we've done is we've looked at things that will actually challenge us and one of them is this distribution question how are we building distributions how are we monetizing distributions and we're gonna throw that challenge to the combined team and we're gonna say as part of integration the way you will integrate is not by trying to learn what each other does but to invent a new way to do things together and so part of the way we'll probably do that is we'll throw all the modules, all the distros all the contributions up on a board and say, okay, which of these pieces fit together which of these pieces don't fit anymore which of these pieces do we wanna rework and completely open it up and not try to just make them work on our products and make our guys work on their modules because something we've learned and we learned this last year when we brought in open atrium we took on features and context and spaces and all these modules we learned it's really hard to work on someone else's code even if you have great developers so what we want is this to be a joint effort we want everybody to feel like they have ownership in this instead of just saying, okay, now you're on our stuff so that's the philosophy we have and the specifics of how we're gonna do it is probably a whole lot of closed door developer on developer intergalactic Olympics of the mind type stuff so also a cage match sounds like a great start got boxing gloves do you wanna add anything? Nope Thank you so the next question is for Mike so Mike could you talk a bit about how Intel the open technology center has used cod and open atrium I know a little bit about this or a bunch about this because I had the pleasure of working with Mike on a lot of enhancements to both Mike is awesome, so tell us Mike well we got involved with cod around the Migo project which is an open source mobile OS that our group in the open source technology center was working on and it was a developer community and they needed a conference site so we got involved in cod to roll out two separate conference sites for two separate events and in general the experience was great I mean I think what you find a lot of times with distributions is that they're not always exactly what you want but that there are a lot of ways to customize them some distributions seem to make that a little bit easier than others I think open atrium is a good example of the ability for a lot of the customizations to happen kind of through the configuration that they've already set up within the distribution itself whereas other ones you might have to actually do a little more on the coding side so you have to have some people that are experienced with Drupal but in both cases I think there's ways to do customization which is a big benefit for us because we always find that that's a necessity let me talk a little bit about open atrium and our customizations there because I think that was pretty important so we wanted to extend open atrium in a couple ways and the way it's built was kind of the foundation for a lot of the modern ways of building features and so it took a little bit of a learning curve to get some of the customizations in there but once we did that and we hired Ezra and Ben to do some of that work as well as Trellin did a feature for us as well and it's amazing because the integration once they're set up is just like it's another application within the distribution itself it doesn't seem like it's pigeonholed in there at all it's really integrated well and that was really a big benefit of us because when you work with people that these are your end users that are using these systems and they're used to, some are used to stuff that's not so great some of them are used to stuff that's a lot better in terms of using other software you need to raise the expectation and make sure that you're providing a good experience for them all around so it's really important that that integration is tight and well done and so we found that with OpenHRM and with COD as well we had really great experience with the organization especially around the managing of sessions having the way COD is built right now which is with all the DrupalCon events is that there's voting for sessions but our model didn't quite fit that so we had built some customizations around allowing just a small committee of people to vote on sessions and then that would be ranked by a certain criteria and then that was the way that they actually picked sessions so that was a great example of like okay it didn't quite work right out of the box the way we wanted it but there was this other way to do it and it wasn't very difficult to sort of implement this so great thanks and would you say that that level of kind of seamless customization is what led you to choose these distributions over something like a closed proprietary hosted service? Yeah, definitely and especially around the conference stuff the design aspect was very difficult to do in any of the hosted services or anything like that so and then having experience with Drupal made sense to have it in that platform to begin with. Got it, thanks. So we discussed apps a little bit earlier and I wanna open the conversation about apps actually with a quote from Karen, surprise quote. So the quote is you need only whisper the words app store at a pub in Croydon to start a full geek on geek brawl about monetization in Drupal and its potential ill effects on the open source community. So obviously this is a... Obviously she had a brawl in Croydon. Yeah, it got ugly. But it is a complex issue because Drupal is a free software project and when we start people hear app they might think app store and think about selling code and so there's a lot of issues that come into the sale of code. There's also the idea of decentralization so Drupal is a project that really values centralization around Drupal.org so a lot of work went into for example adding Git support to Drupal.org to help curtail the number of projects that were moving out to GitHub so that there would be one canonical place where you would always be able to find a Drupal project where the security team could pay attention to that project and issue security advisories or you have a standardized issue queue similarly with the distribution packaging was another effort to centralize on Drupal.org. So one might look at apps and app servers and say hey what's up with this decentralization? And so I'm wondering if you see apps and app servers as a way, as kind of an experimental area that might eventually move back to Drupal.org or maybe a mix of being on Drupal.org and on company specific hosted services. So I guess that's like 15 questions but if you'd like to answer any of them that would be great. I'll pass that to Tom since. Yeah, the whole app store issues is kind of interesting. We really look at it as it's just a great way to package and deliver things to the 99% of people out there who are not developers. To this point we haven't done anything to commercialize any of our apps and it's just a great way of delivering things to us right now. One of the things that we have done is actually almost all of our apps, I think we've got a couple we still need to clean up on this, but most of our apps we actually release on Drupal.org also. And so you can install them from Drupal.org, you just don't get all the automation of the installation. And of course, it helps to have the issue queue there and to be able to move stuff around. So there's a lot of benefits to all these things being on Drupal.org. The other thing that's kind of interesting is originally when we looked at apps, oh this is gonna be this great huge thing and there's gonna be millions of apps and so forth and actually what I'm starting to kind of feel is almost a better approach and really it's the approach that phase two's taken is absolutely a little bit more around your distribution. And it's almost kind of nice to have less choice. I mean we've got thousands and thousands of modules out there and it confuses people. And so, but if apps go on Drupal.org, which would be great if it does, we'll move over onto that. Kind of whatever makes sense there, cool. Yeah, so just to touch on something Tom said I think is important from an architectural perspective is apps, a lot of times in fact in every instance that I know of with our code, the app itself, the actual module lives on Drupal.org as an open source module. The apps module itself just does packaging and delivery of that. And so even with the app server, the code itself, it's grabbing in real time from Drupal.org. So there is no forking or any extra sort of hosting of these modules off site. All you're doing is hosting the infrastructure through which the module or feature gets wrapped and then delivered into the distribution. And that's why I think it's not inconsistent with moving off the Drupal.org if you keep that mantra. And so I think one of the things that we did around this when we saw that this confusion around app stores and apps was occurring is we actually worked with some people at Acquia, Moche and Robert Douglas and some others to develop essentially an open app standard that would attempt to head off the concerns of commercialization and not sticking with the open source mantra and all that. So we developed essentially an ethical checklist if you will. And so I'll let Karen talk about that a little bit. Right, so apps came around to solve a specific technical problem and then it created a specific small firestorm after that. And the technical problem we were trying to solve and I actually think it really solves it rather beautifully is we wanted to keep the distributions much smaller and we wanted to make it, but we wanted to make optional functionality easy to install in the distribution. It was a very specific problem. We wanted to bring open public. When we were building it, we wanted it to just be just super, super lightweight, really easy to install, very performant and we wanted to be able to be able, we knew that a state government or a local government and a federal agency would not have the same functionality needs, would need different things and we wanted it to be easy for them to install those and go with it. And that's why we built the module. The open app standard was necessary once we realized that, well, if I want an app for, say, constant contact or something in my open publish distribution and I go to constant contact and say, hey, I'd really love it if you could build a Drupal module and we'll make it into an app for open publish. And they say, oh, really? Cause somebody else just asked me to build a Drupal app for their Drupal distribution or their different store and theirs isn't the same way. It's a different way. And then all of a sudden these companies and integrations, people that we really want to make it easy to work with Drupal are having to build these a whole bunch of different ways for a whole bunch of different kinds of app stores. On the other hand, we didn't want there to be like one major monster app store to rule them all and scare the crap out of everybody. So what we said is, let's just come up with a standard. Let's come up with a standard way of building these that means that there may be some actual interoperability. Some apps might actually work in other people's distributions, hooray. And if not, at least we're building them the same way and we're going to people once and saying, build this app and it could potentially work in different distributions and we can do this one way. So a bunch of us got together last summer and built an open app standard on Drupal.org. It's our groups at Drupal.org, there's a group for it. It's a really active group now. There's a lot of people talking about it and if that's of interest, we try to encourage people to have less pub brawls and more talk on Drupal.org. It's great to see collaboration around that standard, yeah. Okay, just to show of hands, how many people would like to ask a question at the end of the session? Okay, so we do have some questions. So let's do one more official question and see where we are in terms of time. So what are you most excited about in terms of distributions over the next six months or two years or as far into the future as you think you can see? Well, since I've got the mic, six months, two years, framing it in those time frames and extending past actually I think is more appropriate because I think, you know, Dries did a blog many years ago talking about how distros can make a difference and in the marketplace and it's really something that as the distributions mature and the group that's up here now all have very relevant distributions for the market. So the whole open source movement has moved into the corporate mainstream. So you can go to a CIO now and actually they may look open source first. Having a distribution that hits a vertical market and let's call it a solution for this purpose and with the community software being commons, for instance, if someone's looking at social business software and there's a handful of proprietary vendors out there, it's good for Drupal and it's good for commons to be in that mix. The same CIO is not going to look at Drupal alone without the solution that fits that use case. There are many, many use cases for commons, for instance, where the door is open for Drupal and they decide to build it themselves, but Drupal still wins. So I think the excitement that I would see going forward is the maturing of the application of the solutions and maybe the maturing of the application market as well, the apps market. But the more that these become mature and I'll focus on commons, it's really causing problems for the proprietary vendors and by getting in there, it just opens up a broad opportunity for Drupal in general. And a lot of things I get excited about, some of the same things that Mark's talking about. Drupal, if you're a developer and you've gone through the learning curve is awesome. It's this great erector set, but most of the world doesn't want an erector set. In fact, a lot of times we've lost deals because someone was looking for a calendar and they're like, oh, I'm gonna just go with this thing that already is a calendar, not something that has to be morphed to turn into a calendar. And the thing that I get really excited, and particularly around the app's part of it, I mean, to me it's kind of hard to break apart apps and distributions, is that we now can build these purpose-driven projects where people get what they want, but they still can break it apart and have all the great flexibility of Drupal. There's a great article that, actually the Blue Drop Awards, they had on one of their blog posts that I forget who it was, it was a magazine that said that another CMS had won the CMS war because they were really good at tailoring what they do to bloggers. And that's the one problem is we're tailored to developers and developers are actually a very small part of the world. And so that's where I get really excited. I think we're gonna see these distributions really opening up new markets. We already have, I mean, with a lot of your guy's stuff. I think I'll say that I'm excited to hear that more of the distribution infrastructure is gonna go to Drupal.org and there'll be more community participation around that. Because once you invest in a distribution and your users are using it actively, it really becomes a critical part of your business or your group or whatever. So having the ability to participate more to push the distribution along to make sure that it's not gonna be abandoned is really important and you feel like you're a little bit more part of that project. Yeah, I would add one thing that's always discussed in the context of this and that's figuring out some of the really interesting business models around these things too. So there's lots of people out there doing SaaS versions of these things. There's people out there providing support, training, design customizations, custom themes, apps, all these different things. They all represent new marketplace opportunities that are potentially interesting for both people who are contributing to them as well as the people that have maintained them. So we're really excited about that and it's gonna be probably the big topic I think for the next year or so around distributions. Well, because you haven't had enough colorful analogies for me today, I'll tell you the one that is the best way I can describe why I'm excited about distributions for the next two years. I kind of think of distributions as a, I think distributions are in a place right now where they are finally about to be a great thing in the community as open source projects and then about to be part of something bigger than that. I think that my job as a director of products has really been really the director of distributions and I think going, taking that step from distribution to product is something that's coming in this space. And my colorful analogy for it is that I kind of think of distributions as holding a handful of toothpaste and it's, it works, it does something really good. It does exactly what you need it to do but nobody wants to buy a handful of toothpaste. There is really hard to do that. It's really hard to sell a handful of toothpaste. It can be the best toothpaste in the world but nobody's gonna buy your handful of toothpaste. So the other things around it, the, you know, the tube of toothpaste and the tools with it and the things, that's what makes it truly a product. That's, those are the things that you can wrap around a distribution to make true web applications and to make real products in this space. Products that let people do really amazing things with these distributions and products that power, make Drupal power really big things on the web and I think, I think we're just getting to the point where we're seeing that. We're just getting to the point where we're seeing distributions mature enough, get enough contribution from the community to really start to step out and be the cornerstone of really great products. And that's what I'm excited about. That's a great way to think about it. If you just bought a handful of toothpaste, by the way, you can get a refund at registration. Okay, so let's take some questions from the audience. I know a number of folks had some questions. I wanna make sure we make time for that. Is that mic on over there? You guys have obviously been involved in some really successful distributions but I was wondering if you guys have any experience with, maybe you guys put some resources into a distribution that never got off the ground or did you decided not to do and any lessons that you guys would have about that as far as somebody thinking about doing a distribution. What did you learn from maybe say quote unquote a failed project? Yeah, so this is my pure moment of total honesty which will probably, I will regret later. So we have a fifth distribution. I don't like to talk about it much. It's called Tatler. And Tatler is actually really, really cool. It is the number one requested distribution that we have. It has been downloaded an enormous number of times. And it does something really cool. It does topic monitoring on the web for things that you put in and it uses semantic algorithms to kind of bring in information. It creates feeds and brings in all this information in a Twitter like interface. You can look at all these things. Well, we learned a couple of things in the process. In fact, we hired Karen when she pointed out that it was flawed on a number of levels. One, the technology, it just wasn't, it was a terrible fit for Drupal, PHP and Cron. It just bringing in that many feeds, that many mentions and deduping and dealing with feed integration was a very difficult problem to put out as a distribution. If you have a server and you know how to do all this system administration stuff and you really understand performance and things like that, then you could run this thing. But if you just open source it as a distribution and you hand it out to any marketing guy on the web who wants to market stuff for his clients, they don't have the technical sophistication to maintain something like that. Huge mistake for us because it looks so cool, but it's so hard for people to administer. That doesn't make a good distribution, I think, to Tom's point. Second thing was there are so many commercial alternatives out there that do a better job. And we did it our best that we could do for free in Drupal and put it out there. But all at the same time, these products were all the rage. You got Radiant 6 and there was one called Viral Heat that you could go do a SaaS version of it for 15 bucks a month. Or you could download our free distribution, spend twice that in hosting, never be able to configure and manage it, and be frustrated with the results you were getting and yell at us even though it was free. So both the business model and the technology were flawed. We have not decommissioned it because it's a contributed thing. We want people to see what Drupal is capable of doing, but it was a bad choice for a distribution. Thanks for that answer. Is that good? Yeah, go ahead. Two questions here. One, will the distributions hosted on D.O. go through the same security evaluations that contributed modules and themes currently do? And then also, based distributions with apps connected as an a la carte approach, this means the standard of the distribution is broke. So how do you deal with support and maintenance long term in that approach? Sure, so I'd like to answer the first part. I think it's actually not accurate to say that contributed projects are monitored. It would be more accurate to say that, I think that there's a sense sometimes that the Drupal security team is actively patrolling, Drupal can trip and looking at code. And in fact, they don't do that. The way that it works is that people report security issues. I think that my understanding, and we have some security team members in the audience of the way that it will work, is that distributions will follow that same model so that if a distribution is packaged on Drupal.org and is available for download on Drupal.org and it has an official release, so same policy is for contributed modules, not an alpha, not an RC, but an official release. And a security issue is discovered. It'll be reported to the security team and a security advisor will be issued according to the same policy that applies to other projects. Is that correct? Okay, so that's now a fact. So... With the nod of the head. We just made it a fact right in front of your eyes. Okay, and so the next question, let me see if I can summarize it and let me know if I've got this wrong. Is distribution maintenance broken when apps are sort of not shipped with the distribution? I guess I would sort of ask, what do you see as being broken about that model? Yeah, I think, and so the point that was made was that you know, it's new that you can add something to an existing distribution and if anyone wants to weigh in, that's cool. The way I think about that is that in a lot of ways apps are new, but in a lot of ways they're also not very new, right? Like right now there's nothing preventing me from you know, releasing my app on Drupal.org as its own project as people are doing now and not having an app server. And so the added step of making those apps more accessible and perhaps more discoverable than they would be without an app server, I don't really see that as that dramatic shift in architecture. But let's see what the panelists think about that. Yeah, there's a few concerns around it, but in general it's not that much different than just upgrading a module or upgrading features. Yeah, you normally have a lot more dependencies and so sometimes those dependencies could break things. The way we kind of see apps being used is that you either have kind of the hobbyists that are going to install them on their Bluehost site and the live site and so forth and hopefully they back up their database. The more enterprise side of things and we rarely see apps breaking things, but they do just like modules do sometimes. On the enterprise side, you're gonna deploy these things on your local machine, you're gonna deploy them on your dev environment before ever pushing them up. So far there hasn't been too much of an issue, but just because there's so many dependencies with other modules is a little bit more likelihood than with a regular module. All right, next question. This is great for starters, so thank you guys. Could you speak it to the mic just so the folks at home can hear you? Yeah, I really have to speak to the mic there. Okay, hey everyone, could you post the slides from this because I recently went through and basically, I mean, I run a distribution, I went through and abstracted a lot of the code into more of the approach of hey, there's just a lot of modules and we happened to assemble them back into one package. Could you post those slides because it took me a while to convince my boss why I needed to do that and that one example with the graph with the UC is exactly what I've talked about and it had no statistical evidence personally to do. Yeah, and I'm actually planning to do a blog post with those statistics as well. So we'll post the slides, there'll be a session video and then I'll write a blog post that includes some of that information. Awesome, glad you found that useful. So one minor thing for the audience, I've noticed a lot of people actually treating their own sites as distributions, which I think can help you get into that type of mindset of just how to develop it. It's a little overhead, but long-term, you've got to spend all the same thing for other people, it helps. But two questions for you guys. From the security perspective, I think it's interesting, but as you abstract the stuff, so then there should be security announcements about those individual projects, but your distribution is probably going to point to a specific version of those modules. So should you be waiting for the distribution to flag a security release or should you be looking at the individual projects flagging security releases and upgrading? Because I've heard there's some potential issues involved. Yeah, I think that's probably, so let me start to answer that question and then we can continue to answer that question outside the panel, because I think it really depends on a per-site basis. In general, security advisories can be issued when in fact, not every site that uses a particular project is affected. So sometimes there are a set of conditions that have to be met on a site for a particular vulnerability to be exploitable. And so if your site doesn't happen to have that set of configuration, you're not actually affected. I would say, I would refer you to the issue queue for the relevant distribution to get the best answer about that distribution. And I think we should probably let, we just have a couple more minutes. So those were great questions, thank you. Hi, my name's Dustin Boger. I'm a webmaster for a group out of California, the Delta Stewardship Council, and we've embraced distributions on a couple different levels. One, we have a conference that we put on. We've used Cod, we're developing that right now. And two, we're looking forward to Open Atrium to use that as our internet. Question I have, I guess, is for Jeff and Karen. What's the future migration process or timeline for moving Open Atrium to seven? Because we really don't want to have to do that on our own, we wanna wait for it to come. So I was wondering what the timeline might be on that. Sorry, I feel like we're out of time. Yeah, we're out of time. No, I'm gonna just address that. I'm really glad you asked that question. For us, it's very important. And we do have some information publicly available in terms of a roadmap. There's also a BoF occurring. Yeah, I'll be going to that one. One o'clock and we'll talk about that specific issue. I just wanna say in general, it Open Atrium is a great product on D6 and it works really well. And so running right into doing seven or something like that never seemed to be really a pressing issue. It's something that people want because their developers have moved on to seven. They've moved on to seven. And so we're aware of that and we're gonna address that and we wanna do that. But in the spirit of the other stuff we've talked about, we really want that to be a community effort. And we're very much going to hold our ground this time and we're going to challenge the community to contribute time and potentially money to making that happen. Because just rebuilding Open Atrium on Drupal 7 as a phase two project is a non-starter. It would cost us hundreds of thousands of dollars and I just can no longer imagine a world in which we put everything out there for free and nobody helps us contribute anything back to it. It doesn't make any sense and it's against the spirit of this project. And we are going to have BOFs. We're gonna have public discussion. We're going to call people and email people directly and say, what do you want to do in the migration to D7? We've started that process with customers who are using it and we'll do the same with developers. So we really do expect that it will be a community effort. So do you wanna- Michael, if you get a chance, I'd love to talk to you afterwards about your customizations to Khan. Yeah, and the other thing is we'll probably be putting together kind of a core group of Atrium developers, of people that are really interested in guiding it. Part of it, of course, is the fact that it would be a very, very big build for one group to do, but part of it also is that Atrium is used in such different ways. It's used as an internet, it's used as a project management tool, it's used as a portal. It's really used in just amazing different ways. We don't want to be the only ones guiding the roadmap for that product. When we are happy to be leaders on that project, we're happy to take the responsibility for it and those kinds of things, but we really want the architecture and the vision for it to come from the people that are building it in such different and interesting ways. So it's really key to the strategy on Atrium and it's the only way that Atrium will move forward. Do you wanna reference for that roadmap, please? Yeah, oh, sorry. If you go to community.openatrium.com, there's a blog post in a new group called, there's a new group on it called Developers that is for people who are developers who are interested in working on the next version of OpenATrium. And it's on, there's a blog post that is from our technical lead, Patrick Settle, that kind of defines our early vision for it and that's what we're gonna discuss in the boff this afternoon and then in the continuing weeks to come. Okay, great, thank you very much. Thank you. Well, thanks so much to our panelists. This was a really great conversation. Thanks for the questions. Please fill out the session survey and let us know what you thought so that we can improve this for the next time. Thanks. And there's some distribution boffs this afternoon. I know that Commons and Cod are having boffs and I heard they're gonna be awesome.