 Alright, so this talk is called Ask Not What Open Source Can Do For You, but What You Can Do For Open Source. My name is Jeff Walpole, I'm the CEO at Phase Two, and I'm going to be hopefully providing a variety of perspectives for people who are interested in how to make an open source argument inside an enterprise, but also how to get more out of an open source community. So I'm going to talk a lot about engagement and participation in this talk. So the first kind of major theme I have is sort of the value of engagement. The first place to start is understanding how do we value the engagement of an organization in the enterprise. So here's an interesting quote and I did a lot of research for this talk and I tried to focus not just on Drupal but at open source technologies and also at companies that you would recognize, right? I think a lot of us sort of tend to think of the companies that we work with here in the Drupal space and know the names and those are the people that we think are doing the most open source work, but when you really go out you look at Silicon Valley, Facebook, LinkedIn, Google, Apple, those are the companies who really power open source contribution and so this was interesting. This is a quote from the actual, I almost said phase 2, from the Facebook blog in 2006 and it's actually talking about the value of open source to Facebook and if you guys read anything in the sort of the open source media, Matt Essay who is a huge open source advocate and writer, writes for, I think he writes for ZDNet now, but he's been the CEO and CTO and CMO of a lot of marketing companies. This year he named Facebook as the most open source company in the world and that's because so much of what they do is contributed back to open source and so much of what they value in their code base comes from open source, it's a two way street and it's pretty interesting because you tend to think of this as being not in the Silicon Valley space but it really is. I want to talk a lot about the promise of open source engagement for enterprises and when I say enterprises, I'm talking about large organizations, either a Fortune 1000 government organization, a large education system, somebody who's got a significant amount of size and scale to apply to the problem of developing software and that's not because I don't care about small and medium sized businesses or smaller nonprofits or community organizations, I do and I think they get a lot out of open source but the arguments for why they use it and how they use it are entirely different, right? So what I want to talk about today is not about the choice between using open source and not using open source, I think that argument has been won by the open source community and Drupal is a great example of that. The companies that Drees put up today, you can see, you know, we've got significant argument to be made that using open source is better than commercial proprietary solutions in many areas and content management is certainly one of the leading areas. What I want to talk about today though is actually a different take on that. I want to talk about the ways that organizations actually find to increase their engagement and participation in open source communities and so that distinction is an important one. I'll talk a little bit more about that in a minute. So there was a great study, one of the things I read the other day is the Linux Foundation came out with a study in which they tried to value the value of the Linux code base, right, which is a massive code base that's been developed in the open source world out in the open for many, many years and it's had many large contributors on the enterprise side and of course it's had, you know, tens of thousands of individual contributors as well. They value the code base of Linux at $5 billion, which is a shocking number and it's an interesting study and I recommend you download it and look at it, but it goes to demonstrate sort of, we're at this point now where it's not a question of whether that code or that software functionality could or should be used as open source. If it's $5 billion and all the code that's gone into it, how could it be anything else, right? I mean, who else is going to contribute $5 billion to an operating system at this point, right? And so it's an interesting idea to think about the fact that we've actually gone so far that we really are over the edge into open source is now a dominating force in software development that no one can take back and I think the value of it's well-proved. So when I talked about the difference between using, participating, contributing, I'm using a bunch of different words and I actually have a distinct definition for each of them. So using to me is choosing to use open source software instead of commercial alternatives, right? And Drupal's just one example, you know, Apache is a great example, right? Choosing to use Apache or Linux or anything else in the LAMP stack and there's, you know, literally dozens of examples. That's different than participating. What you guys are doing here today by being a Drupal con, whether you're sponsors or speakers or just here to listen and meet people, that's a participating effort in the community, right? And there's a distinction between using the software and participating in the community. And for me participating in the community is going to meetups or speaking at meetups, going to conferences, online engagement, getting into the issue queues, talking to people, working in groups. Those types of things, it's a two-way sort of participatory social activity. And then the third category here is contributing. And contributing is perhaps the most discussed but the least understood form of engagement in open source, right? It's actually adding to the code base itself, either fixing bugs, you're submitting patches, you're contributing software functionality enhancements or documentation, right? And so it's this act of actually giving. And then, of course, there's this interesting hybrid or this interesting overlap of financial patronage that occurs in open source as well. And financial patronage is both a form of contributing like donations, grants, things like that. But it's also a form of participating, sponsoring this conference, right? Sponsoring a code sprint. Those are ways to pay for a participating activity, right? So financial patronage is this sort of reoccurring theme that I'm going to bring up a couple times because it is also where enterprise meets open source. Open source needs enterprises to be able to have the financial resources and capital to deploy that into these communities to help them thrive. So those are all examples of what I talk about. I would say the general box just going around all this for today is engagement, right? So I think of this as engagement and I think of all of these as components of an engagement strategy. There isn't one strategy. It's made up of all these things. So there are organizations out there and in many cases I think it's perfectly fine for an organization to use open source but not be a larger participant in either the community or the project, right? And there's many examples of where that happens and not everybody can get involved, not every enterprise can get involved in every single project, open source project that they use, right? You know, how many of you contribute to Drupal, for instance, right? Now, how many of you contribute to the Apache project, right? Or the Linux project, or the MySQL project, right? So there's an infinite amount of open source code out there that you could contribute to, but there's a finite amount of time. And so people in organizations are making these decisions as to which projects contribute the most value to them and at a given point in time. Clearly, people that come choose to come to DrupalCon find Drupal to be one of those projects, right? So when you don't do that, when you just use software, it's not always bad, but what it sometimes leads to is you not being able to realize the full gain of that value, right? So you might get, go download Drupal and actually see some of the benefits of Drupal's CMS, but you might be missing out on a lot of the ways that you can work with the Drupal community or gain knowledge or experience through participation in the project itself. So for one second, I will talk about why leading enterprises are using open source and I really just do mean using the open source code now. And the reason I bring it up is like I said earlier, it's not that small and medium-sized businesses or educational institutions or community organizations aren't using it, but they have a different priority set, right? You see these bullets a lot. It's like, why do people use open source, right? And I think if you put three or five or six bullets up there, they'd probably all be right. The question is when you're an enterprise, which of these matter more to you? And so what you'll notice is cost effectiveness is at the bottom, right? And it's not because enterprises don't value cost as a determining criteria, they do, but they're also in a competitive nature more interested in things like speed to market, maximum flexibility of the code base, outsourced innovation and development that they can get from the community, and of course cost effectiveness, but it's not really the same equation. They have a different set of priorities that they bring to bear. So now let's move on to why they're actually participating. And I think in a lot of cases, you know, one of the things that you really don't see a lot is an argument for why participating. You see an argument for why using, you see an argument for why contributing, but in the middles is participating. Like why do we all come to Drupalcon? Like why are we here, right? Sure, the swag and the t-shirts and the stickers are awesome, right? And so are the parties, but like what's the value to an enterprise to be participating in this? And so I think that's kind of the open question. So the number one thing I've heard and I did, as I said, a lot of interviews, I talk to a lot of companies and I'll tell you a little bit about who they are in a minute, but the number one thing I hear over and over again is talent, right? It's the most common reason that people participate in the community. And the reason is it's not, it's, you know, it's kind of natural, right? This is a social engagement. Social engagements tend to be about connecting one person to another. And so the primary thing you'll hear is recruiting, right? If you talk to a big business that's here, you'll ask them like, hey, why are you in Drupalcon? And the answers are going to generally revolve around something to do with people. Talent is the number one thing. They're looking for great developers to hire, right? Or they're looking for project managers to have experience in this space or designers that have to design for this platform. But there's also a second component here and certainly my company and other companies that have been recruiting from this community and working this community for a long time know that you also have to retain great talent, right? It's not enough to just go hire them. You actually have to retain them. And the way that good developers in particular are retained in this kind of a space is you provide, you provide great environments for them, right? And those environments are places in which they're empowered and enabled to contribute. If that's something that motivates people, you have to be able to appeal to those interests, right? And that's sort of the irony of this whole thing is that talent is acquired in the open in an open source community, right? But you also have to put your best people out there and show their talent off, making them attractive to someone else. So there's an irony, right? Which is sort of like the openness that gets potentially someone getting poached or taken from your company. So it's an interesting sort of dichotomy that we live in. We're all in the open and it's all out there for good or for bad, right? And then the other piece of this is purpose, right? If I went to hire a great developer out here in the exhibit hall today and I walked up and I said, hey, we're one of the biggest companies in the world. We make a ton of money come work for us. They'd be like, I don't care, right? But if I said, hey, you know, we're one of the largest pharmaceutical companies in the world solving cancer treatment, right? Or we're developing cancer drugs or something. And your open source code is contributing to the success of that. That's a totally different thing, right? That's an intrinsic motivator for them. They see how what they do every day can contribute to a larger purpose, right? And that kind of connection can happen in open source. We literally have opportunities to see out in the open where our code can contribute to a greater good. And it doesn't have to be curing cancer. It could be, you know, world peace or world hunger or any of those other small things that most of us like to pretend we're working on every day. So, yeah, so, I mean, for me, everything comes back to office space eventually if you've seen the movie. And if you haven't, then I don't know why you'd come to DrupalCon, but that's just a whole separate issue. But, you know, I think another, this is an interesting quote. This is from the co-founder of GitHub. And of course, they're a huge open source company and their whole model is based upon that. But one of the things I really liked about what he talked about is the job interview process because it reminded me a lot of what happens at phase two. It's really cool when you don't have to ask for a code sample or, you know, the old show me a writing sample, right? Well, if someone's an open source developer or a contributor, it's all there. All their mistakes, everything they've done, they're good thinking, they're good interactions. The issue queues are littered with their behavior, how they interact with other people, how they treat other people. It's all there. It's all part of the public record. It's a fantastic interview and recruiting tool, right? So it's just an interesting way to think about how that openness begets better information for an employer. The other aspect of this is learning, right? When you flip it around, you think about, well, why do you send your people to a Drupal conference or something like that? One of the things that's really interesting as you learn is you talk to people in IT departments and development organizations inside large enterprises and they say that one of the ways that they learned how to do some of the things they did is by participating in open source. So they actually get things like software development practices. They brought Agilin from being involved in projects like this or they brought in Git because their developers learned how to use Git on the Drupal project. Or they learned something about DevOps by coming here and learning about cloud deployment practices or continuous integration or automation or something like that. So you get this sort of set of learning that you couldn't get elsewhere and you're giving your developers and your technical staff a chance to learn new skills, right? It's a very cost-effective way to do training. It's much cheaper than, you know, a master's degree in software engineering or sending someone out for a $3,000, $5,000 course that's very detailed, right? It's a more broad-based education. It's a lot cheaper. And then there is this technology transfer component, too, that happens whether we realize it or not. Like, by coming to these conferences and participating online in open source communities, your team is gaining exposure to new technologies that they may or may not admit came from there, but that's where they learned that cool new JavaScript framework, right? They got it from engaging in an open source project where it was introduced, right? They didn't just Google, you know, cool JavaScript framework, right? Somebody showed them that. They learned that. They saw it in a code base somewhere, right? And that's an important part of how this works. And then, of course, you're also most, especially if you're a technology company, but even if you're not, your technology and your technology thinking is then working back into the community. It's a two-way technology transfer, right? If you're a CDN company, a bunch of CDN companies here, right? Like, your participation in the community makes everyone else aware of that CDN, and in some ways, you're probably adding hooks and connections to that code into the project that you're working on and vice versa. And so that exchange is incredibly important. And then the other part that's really interesting is that you also get to see how other people are innovating certain problems, right? You get to witness innovation in R&D in an open chamber. And for an enterprise that has very limited resources, you might not have the ability to do research and development or innovation around a certain piece of functionality, but if you can watch someone else do it for free, that's pretty powerful, right? And it really helps you get the most out of your money there. So let's talk a little bit about why enterprises are contributing to open-source projects, right? We all think of this as contribution and just the term itself sounds like an altruistic activity. You do it because they tell you it's the right thing to do, particularly in communities like this. And the truth is that while individuals may get individual satisfaction from doing it, or people may feel good that they've done it, there are actually very tangible reasons why enterprises should be doing this from a business perspective as well. And those are motives that are driving them which are not necessarily bad. They could be considered ulterior, but they're still good for the project. So one of the most important things is wisdom of the crowd, right? So if there is a common problem that is out there that is not necessarily something that your organization needs to solve, but is something you need to get through, you can use the wisdom of the crowd to solve that problem for you. So there's this integration that other people are gonna need. Why not watch as someone else innovates the solution to that and you get to piggyback on it? You get to stand on the shoulders of giants, right? Too often in closed organizations, large enterprises, too much money goes to developing common problems that other people are outside solving for you. And that's a very expensive proposition if you can leverage what's already been done. The other one that's related to that is what I call force multiplier, right? And force multiplier is an example of when, you know, you might have a small team of developers capable of building a certain amount of code for you, but if you're capable of contributing that code to a community and empowering people to build on that code, you're actually extending your development capability by allowing people out there to write code for you. And there are dozens, well, not dozens, there's hundreds or thousands of examples of where this has been a successful acceleration strategy for enterprises. And you have to be savvy to do it and it requires that participation in the community. You can't just put it out there and have it happen. But when it does work, it's a flywheel that creates a lot of energy for your organization. And so, you know, the thing I like to think about is you're literally, when you put it out there and you're working with people in the right way, you're literally inviting people to test, repair, improve, maintain, and document your code along with you. And you're not paying them. Think about it for a minute, right? It's super important, like, to imagine that you're getting free work there, right? There's something in it for them and there's something in it for you and it's a mutual exchange. It's not a bad thing. You're not taking advantage of anyone. But there are people that will extend and carry that forward. And as much as people who are used to this model think of that as just natural, there are people in enterprises, particularly in financial areas or in higher levels of executive functions that might not realize that that capability is available to them if they make a small investment in participating in a community. So, this is another quote from Tom Preston Warner as well. He's also, sorry, he wrote this post called Open Source Almost Everything and I thought it was really great. It gave me a lot of the insights around some of these things, but this one was, like, in a good example, like, I mean, at GitHub, you know, because they have this great platform, it's really easy for them to do this. They have a technology called Risque and they just put it out and they said, he said they had 115 different developers outside the company who were literally just extending this functionality on a regular basis. And all they're doing is just sort of shepherding them a little bit. They're just 115 people off writing code for them. Unbelievable, right? I talked to a friend of mine, Denny's Cooper, who's open source lead at PayPal. I did some interviews with her about how PayPal does this. And again, these are big technology companies, right? We're not talking small fries here. These guys have released, you know, dozens of frameworks. They do a lot in Node.js and they've released some selenium-based testing frameworks and some of the functionality that they use, like, to get photos off credit cards and repayment entries and stuff like that. So this was actually a project that they put out called Release the Kraken, which I thought was clever. So we put it in here. So there's another interesting phenomenon that goes behind the scenes. And this is something, and I actually interviewed Dries for this presentation. We talked quite a bit about, you know, maybe below the surface what's really happening, right? And when you really get into a community, you realize one of the things that I thought was most interesting is when you really get to know the people inside of a community like Drupal, the smart enterprises are actually figuring out how they can use those people to gain control and influence over the direction of something that they care about, right? So some of the examples that Dries put up this morning, you know, whether it's the pattern lab, you know, component-based architecture, you know, component-based design or trying to think what his other initiatives were. Okay, I'm drawing a blank. But initiatives like that, right? If you are an enterprise, a very large enterprise that has a vested interest in the success of one of those things, you actually can pull strings within the community by knowing people and asking them to move, remove blockers from issue queues, working with them to contribute patches and then tapping them on the shoulder and saying, hey, it's me, can you commit my patch, right? That stuff happens every day, right? It's not bad, it's good. It's ways that the social interaction, the social network of the community actually moves people to the front of the queue. It clears blockers and it gets priority things done. And if you're an enterprise and you understand what your priorities are and how to get them there, it's a really awesome way to make sure that stuff is getting done for you. There's also sort of an almost nefarious strategy that's out there and I just wanted to mention it just because I think it's kind of interesting. And some of you read a little while ago, Tesla open sourced a lot of the code that they used to power their electric cars, right? And people are like, why on earth would they do that, right? And part of the reason, at least the stated reason, was that they're not really competing with other electric car companies, right? They're competing with gas company or, sorry, what do we call the other ones? Fuel. Oil internal combustion. Thank you. They're competing with internal combustion engines, right? But also what's really interesting is they know that they're so far along and they're more advanced and more sophisticated software that they're not open sourcing that the sort of rank and file software can just get dumped out there and let other people work with it and maintain it. They kind of lose a competitive edge, but there's no electric car company that isn't going to have that basic stuff anyway. What they're really doing is standardizing their way of doing it while they're moving on and working on the more advanced functionality that is actually a competitive differentiator, right? And I like to think of it as the open source equivalent of price dumping, right? So they're just literally taking this big piece and saying, here's all the commodity stuff. You guys maintain it in the community with us. It's our stuff, but we'll give it away. We'll be over here writing the really advanced stuff, right? And so that's actually a strategy, believe it or not, that Apple, Amazon, Google, Netflix, a lot of these companies do this to each other in open source. And it's not bad. Everybody benefits, but they also get the advantage of sort of distracting the competition a little bit. And then, of course, there's the age-old sort of marketing and brand awareness. Like I said earlier about the individual, the same thing applies to the enterprise. So everything that you do, everything that you contribute, the patches, the thinking, the writing of the code, the documentation, it's all public. And when it's out there public, it's good for your brand, right? If you're doing a good job. Now, conversely, you can backfire if you're doing a bad job. But if you're doing a good job, then you can actually send a signal to everyone that you are someone who cares about open source, you do great things in technology, and everyone, it's evidence. It's proof that you're innovating and doing cool stuff. And that's actually really powerful as a brand motivator. It's good for getting business. The perfect example is the Drupal shops, right? Drupal shops and people here in this space. Everybody relies on this. Last year on Drupal.org, they changed the algorithm of how the marketplace was sorted so that the shops that were making the most contributions would rise to the top. So we sort of created a leaderboard, like to game and incentivize contribution, right? That sort of interplay between contribution and brand awareness is fascinating, and it works really well in open source. So, you know, the other thing, and I thought this was a good quote, this is the VP of Systems and Engineering or at least used to be at Netflix. And he was talking a little bit about the signal that it sends to your current potential customers. Like, if you're willing to invest in open source, like, you're definitely willing to invest in them, right? Because you see this sort of technology investment that's very public and very, you know, altruistic on the surface, and it's a very important message to your customer base. Like, you are a company that has this thinking for the future, your setting plans, your putting frameworks in place, and potentially you're willing to do the same thing with them. What that has to do with seals, I don't know, but I got some help from our designers. So, let's talk a little bit about how enterprises engage, right? So, there are some general patterns, and as I said before, I think what you're going to find is that, you know, your unique combination of these is really important. So, one kind of stance is like low participation. And there's organizations out there who just kind of hang back. There's a monitor and learn approach. They're reading, they're engaging. Maybe they have Drupal.org accounts in our world or something like that, but they're just listening. They're taking it in. There's other ones who are proxying through a partner. So, they understand that contributing and having involvement in the community is important, but they don't necessarily have the resources to do that themselves. So, they're working with a partner like a Phase 2 or AQUIA plays this role for a lot of people where they become sort of a proxy for contributions and for issue queue wrangling and things like that. It's a perfectly valid strategy to hire a vendor to help you with that. And there's like more high participation models. And some of those include like self-representation. So, you have a few key people on your team that are very visible involved in the community and those become your go-to people. You channel everything for Drupal or for Eclipse or something through a few key people, right? And then the last one is just the most rare is the full integration, which is you literally have a very visible presence. You're probably sponsoring events yourself. You're hiring from the community. You're interacting with the community. You're contributing to the community. You're like all in, everything in. And in order to do that, you have to see a significant gain strategically from the value of that piece of software. And again, I want to emphasize like every enterprise can't interact with every open source project that they work with. It's just not feasible. They have to pick and choose the ones and the strategies that make the most sense for them. So there's also some sort of more advanced techniques and these are like, one thing is like shared development models. There's been some really interesting work around this. Like you'll see industry consortiums form around key things where everybody in that industry all needs the same thing. So like a lot of people in the hosting industry are really involved in an open stack, right? It's like Rackspace, Red Hat, people like that and they're all pushing for the same thing. You also have models where they have like group or pooled leverage, right? And Acre created a program here in the Drupal community which is no longer active called Large-Scale Drupal, LSD. And that was focused on, again, gaining common requirements from a bunch of enterprises to try to figure out if you could push a set of functionality all at one time that a bunch of people needed. And of course you have distributions as well. There's plenty of examples in the community of distributions where a bunch of people are working on the same problem set and I could take the bait and talk about that for days. But here's a really interesting one. I just wanted to point it out. There's also the trend called Inner Source. And Inner Source is this sort of dog-fooding scenario in which the processes of open source are brought inside an enterprise so that the enterprise actually works internally within their own development as if they're an open source project, right? And then PayPal is actually one step further and then they open source to their Inner Source, if that makes sense. So they brought a way of developing software internal in-house and then they took the documentation and the methodology around that and then they open sourced it and they put it out there for anyone else to use. So it's this sort of cyclical pattern of openness that's kind of interesting. And of course there's good old money, right? Financial patronage is always welcome and you think you'd be hard-pressed to find an open source community that doesn't benefit from that and the models go everything from sponsorships to grants. Google Summer of Code is a great example. I can't remember the exact number I read but in my research they said over the years that they've been doing Google Summer of Code it's like 115 million lines of open source code have been written. And of course everyone will just chuckle and say that doesn't equal quality, right? The old SLOC problem. But I think it's an important distinction to understand that you can put a little money behind creating a lot of good and open source. There are examples of sprints, right? So right now there's a talk going on in another room about the module acceleration program which is a move to push the next set of really important D8 modules faster and do sprints and find actually sponsor and hire some of the contributors behind those. So these are all ways to put money at the problem and of course money doesn't solve everything but it certainly creates a lot of wiggle room for people to develop code in this model. So I wanted to tell just kind of a brief vignette and this will be kind of quick because of time but I was like going through this mental exercise it's like how do I explain this? If I'm like talking to someone from an enterprise like how do I explain how I think they should engage with the community or how they should participate that's different than the way they do now. So I was thinking of like a tale of two companies, right? You have like one company called UseCorp, right? And they're like, maybe they're both these companies that are seeking to do a Drupal project. Let's just imagine they're both same timeline, same goals, maybe they're direct competitors, right? And UseCorp has got this idea that they want to use the cost advantages in the quick time to market of Drupal but they don't know a lot about the product. They've researched it, they've maybe read some industry reports but they've never used it. They have no direct experience, right? And EngageCom is, you know, they want to use Drupal to increase speed to market. They hope to gain a lot from community innovation. They also have no direct experience. But they've chosen to engage the community and leverage all that it offers and I just wanted to kind of walk through how do those two experiences differ? Same software, same kinds of companies, same circumstances, right? And will it result in the same type of thing? So, you know, at the business case level, you know, UseCorp goes out, they go to management, they say, hey, we got this great thing, we're going to do Drupal. They postulate an ROI of 400% on the project based upon some exaggerated case studies that they've read in the public sphere. They've talked to industry angelists but those people have never really implemented the technology and they take those claims at face value and they say, hey, we're going to 400% return on this project, right? Now, meanwhile, EngageCom has talked to a lot of trusted sources within the community. They've been to DrupalCon, they've been to Drupal Meetups, they've talked to people who've done very similar implementations and they've learned some benchmarks from them, right? And they also know from talking to those people that what they're asking for is extensive customization and as a result, they've chosen a more conservative return on investment of 200%, right? So as they go into vendor selection, UseCorps knows that they need a vendor that's used this technology and has experience with it but they kind of just rely on the fact that this company's done this before and they don't look a lot at participation or involvement in the community as a key factor. Meanwhile, EngageCom wants people who are actually recognized in the community and the project for their involvement and they're very concerned about getting a team on their side that they can demonstrate the ROI goals but also they want to engage the community experts, the individuals out there that they've met to help them shepherd this project along. So at Project Initiation, UseCorps, they work with their vendor, they spec out features, they treat it more like a product because they really don't understand that unique framework aspect of Drupal. They create a project plan that's based largely upon guesswork and it doesn't recognize some of the pitfalls and best practices from the community because they just haven't talked to people. Meanwhile, EngageCom has Project Sherpas. They literally have people out there that they've engaged that they think are going to be able to carry them through this project and give them advice in key areas. They start attending local meetups, they bring questions, they even plan talks of their own, right? They practice sharing their own knowledge back with people and they've engaged their vendor for some additional training so that they can get a team up to speed in addition to just building the project. I swear I'm not going to go through every stage of a project. So at Project Execution, UseCorps running a little late, right? The requested functionality is non-standard from Drupal and because these custom requirements are something that they have no experience coding, they're actually writing custom modules when they don't need to be. And so the vendor that they have is never developed in this way and their estimates are off base and these guys are really starting to slip behind. But in the EngageCom model, they've modified a lot of their requested functionality to adhere to some of the best practices. So they've understood what worked in the community and they've changed their approach as a result. They don't have locked-in requirements. And they've started with the distribution and best practices modules. So they're not writing a lot of custom code and they're not starting from the ground up. And as a result, their project is on time and it is on budget. At Project Completion, UseCorps is getting close to launch but they're really frustrated by the amount of testing, issue resolution, defects, problems that they're surfacing. And they don't really have a great way to get around it. They're vendors working very hard to patch it, but they're writing a lot of workarounds. They're working with custom modules now and they're hacks and they're just trying to get the thing live. And they know they're going to have to come back and fix things but they're in a scramble to meet their deadline. At EngageCom, the team is very calm as they approach launch. They understand what it's going to take to get live and they're really focused just on the user experience. They have the time to polish. They're not stuck on trying to get the core functionality to work. The launch goes very smoothly and the team has basically an advisory and a transition team in place at launch so they already know how they're going to carry the thing forward. And they've got additional work lined up from their vendor who's prepared to step in and help them if they stumble in any way. So as it goes into the final stages of this, there is a transition and a maintenance period that occurs, right? But UseCorps isn't ready to inherit the system that they have. They've commissioned and built a system that they truly don't understand. They have to argue with their vendor over warranty issues. They don't feel prepared to take the system over and so as a result, they're aggressively positioning with their vendor to try to keep them on to do work longer, right? The system continues to be plagued by misuse and over-customization, workarounds, hacks. And their ROI at this point has fallen very short, right? And they don't even have the concept of total cost of ownership at this point. There is no life beyond this project. They just want to get live. They blame Drupal. They blame the vendor. They blame themselves. Everybody's miserable, right? And EngageCom, they understand what they have to work with. They understand where that system needs a little more love post-launch and they have a team, both in-house and with their partners that's ready to continue that trajectory. They have met their very reasonable ROI and they're already starting to look at the total cost of this product. What is it going to cost in a three- or five-year life cycle? They're looking ahead. They understand that they have something now that they're committed to, that they're going to be using. And they bark immediately upon post-launch improvements and enhancements that will continue throughout the life of that system. So what's the lesson? Don't be used core, right? They suck. And I realize that's sort of a long, belabored example, but these things happen. And what happens is on every single project, we want to do the right thing. We want to be open source, but we don't really value and understand the ways in which not being that can start to drag us down. It makes us late. We don't see our return on investment. We're not in a good position to take over a system. We don't understand where things went wrong, why there are bugs, why it's non-standard, why it's difficult to maintain, why there isn't documentation. These things happen in little, slow cuts along the way. It's like a thousand, death by a thousand paper cuts, right? And it happens along the way. And it all starts with that posturing towards being open in your approach to doing it and finding other people in the community who are willing to help you instead of going out in a closed and proprietary manner. So those are really the keys from that lesson. So the last segment I just want to talk about a little bit is valuing open source in the enterprise. So I've given you a lot of reasons why enterprises use open source, why they participate in open source, why they contribute to open source, but how do they value it? Because at the end of the day, it's all about being able to understand if you can place a value to working in a certain way. And you have to be able to demonstrate that. In big companies and enterprises, it's all about making a case for why that is better than the alternative. It's a very rational set of thoughts. So this is a good quote. This one came from Google. So this is one of the communications managers for their open source projects, and they said Google's mission is to make the internet more available to as many people as possible. I think I've heard it worded more eloquently before. But if ambitious projects like Android and Chrome have given users more access, that's certainly in line with their goals. So they're making connections between their mission and the reasons that they do open source. And the more you can do that as a business, the more the purpose seeps into the way that you contribute when you work with the community. So when you look at enterprises that have been successful in open source models, you see a lot of things emerging, but that commitment usually starts at the C-suite, right? You have to get the CTOs and the CIOs to be able to champion for the use of open source. It has to start at the top. Otherwise, you're going to be fighting all the way up. And you want to make a business case based upon total cost of ownership, not return on investment. And I'll talk about that in a little more detail in a minute. These are people who leverage the openness of community information, and that's not necessarily just kind of an altruistic thing. They literally get free training, free information, free best practices, free pitfalls to avoid by listening and coming to conferences, reading the blogs, doing things like that. These are not things that proprietary software companies tend to put out in great volumes, right? They control the information about what that software does or doesn't do well. This is open. And then they're also committed to tailoring their approach to the nuances of the way that that works. So like I talked about in the use corp in the engage-com situation, if you understand that there's been ten implementations done in similar industries or around similar solutions as yours, you know who those people are, you can talk to them directly and you ask them, why did this not go right or what didn't go right? Why didn't it work? But people always end up telling you as they go, you know, I thought like, you know, let's take a publisher. We used to work with publishers all the time. Every single publisher says, customizing the workflow is absolutely critical to the way that, you know, this magazine publishes their content, right? They all say it, right? Guess what? They don't have money on it and none of them ever use their damn workflow, right? And if they just went out and listened to learn that and said, okay, we're just going to accept a standard workflow that works with the workbench module in Drupal, right? We'll let you customize a few states, a few transitions and some notifications. But don't write anything custom. Don't go off the rails. Don't do this. Don't do that. You know, could you save 10, 20% of the project? How much of the time and focus went towards this thing that somebody thought was unique and they're talking to other people who have implemented the same thing? So there's a lot of value in appreciating and understanding which parts of your project are truly unique, right? And of course, at the end of the day, the ones that are successful are always prepared to put their own resources in capital towards the project's success. So there are haters out there, right? Clearly, there are people in enterprises that are difficult to deal with. And while the CIOs and the CTOs might understand the value of this stuff, you are going to have to confront other groups. Marketing, for instance, they typically require a much stronger understanding of what that product is going to accomplish for their goals, right? They're less concerned with how it's built, which is what it sounds like when we talk about open source, and more concerned with what will be built, right? And so that conversation has to change to maybe the features, the innovation aspects, the wisdom of the crowd, those other arguments, not the cost arguments. Procurement requires a stronger understanding of how open source differs from buying a product. They're going to compare everything to the model of purchasing a product, right? And so you have to find a way to place the value of a more nuanced set of flexible software into those terms for them to make them see the value. Finance is going to immediately look for that ROI, and you have to change the thinking from ROI to total cost of ownership. And again, I swear I have a slide on that. And then, of course, there's legal. There are pains in the asses. Man, aren't they pains in the asses? No, I'm just kidding. Legal are an incredibly important part of it, but if you're in an enterprise, you have to understand that you are interacting in a world in which your intellectual property, your trademarks, your secrets, those things do need to be protected, right? And you have to make them feel comfortable that your use and engagement in an open source community is not endangering intellectual property. And that's a very serious thing when you think about GPL. You know, GPL is the licensing model that Drupal has done under, and it is a very promiscuous open source software license, right? It allows people who, when anything interacts with GPL, it allows that to flow down, and in essence, open source things you don't want to. So there's valid concern, but it's not the same thing when you're in an enterprise. So these are some of the ways that you have to put these different arguments and these different beliefs and ideas to test with these different groups because none of them are going to see the problem the same way. It's not just financial, and it's not just how the software gets written. So some of the ways that leading enterprises that I've talked to measure success. On the quantitative side, it's important for immediate success. Return on investment says I'm going to spend X, and I'm going to get Y back, right? That's a return on investment calculation. It's the simplest form. It works really well for an initial project, right? We're going to spend zero on licensing fees. We're going to spend half a million dollars on vendor fees. We're going to spend $100,000 on hosting fees, $50,000 on training fees, and in the end, we think we'll get a value that's greater than whatever I just created. $150,000, right? What's baked into that is in essence an argument of efficiency, right? What's really hard to say is using this over that will be 10 times more efficient. You have to find metrics and ways to quantify the efficiency of working in open source versus working in proprietary models. That's another important component. On the qualitative side, there's innovation, and we talked a bit about that. It's by far the most important aspect for a competitive industry. If you're one of these Silicon Valley companies, as I was talking about, a technology industry company, or something like that, innovation and your ability to get innovation from open source is probably one of the most valuable things that you can take away from it. One of the best cases and arguments that you can make to justify your participation. There's also the softer side, there's a lot of people in culture. It's hard to quantify, right? But when you realize how difficult and how hard talent is to come by, if you're an enterprise, there are probably already metrics in place on what it costs to recruit someone or what it costs to retain someone or how high they're expecting their attrition rate to be or not to be. There are probably metrics out there that you can support and piggyback on that are already part of the HR world or the people world in an enterprise. When you drop all that down, the uber metric for open source is total cost of ownership. So total cost of ownership takes all these things to consideration, right? It looks at the long life cycle of a system and it says, when we implement this thing, it's a two or three or four or five year life cycle, right? And over the course of that time, there's going to be all these tangible and intangible benefits that go into why we made this platform decision, right? It's a longer view and the longer view includes that retention and that recruitment and that training. It also includes all the innovative aspects that you forego. It includes the number of people you did or didn't have to hire to support this versus an alternative. And it also incorporates that initial ROI. So total cost of ownership is the uber metric for open source engagement in an enterprise. If you have people in your organization at the top executive levels that are willing to give you the benefit of the doubt for the long view, the platform, the three to five years, this is the way to make the case. There are so many things that bake into this that are more important than just the initial return on investment. So I did talk quite a bit about total cost of ownership and if anyone has any questions about that or send me an email. So I have some recommendations for enterprise participation. I just kind of want to walk through and then I'll stop and do some questions. The way I talked about it earlier is like, I think there is a unique strategy for every enterprise. You're going to pick and choose from a lot of these tactics, from a lot of these approaches and you're going to develop something that's unique to you for the specific platform that you're dealing with. But there are levels and I see it as a progression. So there are progressions. I see it as a series of almost like levels or platforms that you move through. And the way I would approach it, if I were on the other side and I were a large enterprise, if I was the CTO or CIO of some enterprise and knowing what I know over the years that we've worked in open source, I would advise that people progress logically through these things and see it as an investment. As you move through the first level, you do some of these things and if you're seeing value, if you're seeing that it's contributing to that total cost of ownership, then you double down and you do more and you do more and do more. It's not like everybody has to roll in day one, roll out the red carpet, get a booth, print some t-shirts and send your whole team here and say, hey, we're all in on Drupal. You move this way over a period of time and you see if it's reciprocating that value. The first thing I think is those low cost and free learning resources, people totally undervalue how cheap and easy it is to get good training materials through an open source project. Even our paid materials are cheap. Even if you buy a subscription to Drupalize Me or you go, every talk is being videotaped. I don't know, every time. Is this being videotaped? Oh crap, I hope not. Every video taped these talks. They're available for free. It's an amazingly great resource. The next thing is really understanding those true platform pitfalls like I talked about. Go out and find me the five biggest scenarios in which Adobe Enterprise Manager has failed in the last year. Google that. Versus going out and being able to talk very candidly to people in your same industry about how they've used Drupal unsuccessfully. It's an incredibly powerful resource available to you. And then there's hiring consultants who have deep expertise in the project and the community can help you make informed recommendations. It's a super important part of the process is to understand who out there whether it's an individual or it's a large shop or it's an implementer or frankly you could just be the trust. But you can find consultants who are willing to shepherd you through the process. I called it Project Sherpas. People who will carry you through the community in that process and literally show you the way. The second level is you kind of graduated with some intermediate strategies. I talked about starting from a foundation. Use the best modules, distributions, approaches, architectures. Don't figure out how to make these things in Drupal because they've already done that. Take advantage of that. The Sherpas, the community guides to help you find the best practices I already talked about. Leveraging community innovation I think the next step is really understanding what are the things out there that you think you can get from the project that you yourself don't want to necessarily build but you can monitor and see how someone else is progressing on the key things for yourselves. You get to that third level in advance level, right? That's where you probably want to start building your own experts. That's where you maybe recruit some people from the community for yourself. You're making targeted contributions. You're picking areas where your contribution can actually get into the project and be successful. Maybe you're even advancing the point where you know some of the strings that you can pull. You know some of the people and the key contacts that can help your contribution or the code that are relevant to you, right? You're advancing up that sort of value chain that way. At the very top, like the sort of expert strategies, the things that I really only recommend when you get up there is maybe picking an area of this community where thought leadership and ownership of key modules is something that's good for you, for brand awareness, for knowledge, for competitive reasons, and kind of planting your flag in the corner of the universe. Getting ahead of the roadmap and by using that deep knowledge to understand where the project is headed, like listening to Dries' talk today and saying, hey, those are things that are going to be good for us in Drupal in three years, right? Internet of things. Now that I know that the roadmap is going that way, I know that he wants to use Alexa to create content types or whatever, then now I can actually understand how maybe I can work that into what I'm doing with this product. And then the last thing is getting your own agenda into the roadmap, right? So that's where you're really developing a team that can influence the direction of the project itself. Maybe they're core contributors. Maybe you're hiring core contributors and they're actually changing things in a way that's beneficial to you, or maybe you're just making major contributions and those contributions are influencing that. But you're actually getting in there and you're moving the direction, you're serving your own agenda, and those are sort of the levels, right? You start at that level. You start at the basics and you move your way along. And in each stage, if you're working with a CIO or a CTO or somebody who's championing this project, you're demonstrating to them the return on investment and the total cost of ownership in the long run for your investment in each stage as you progress, right? So I want to thank some of the people that helped, just some of the names of some of the companies I talked to and interviewed. I read a lot of articles and I talked to a lot of people and they certainly don't have the total base of knowledge here, but once again, getting out there and learning what's worked for other people is probably one of the best practices you can get out of this community and one of the reasons why personally I enjoy giving these talks because I learned so much by just interviewing these people and trying to figure out what works for you. How did this even come about? Like, hey, Pfizer, why do you have 42 people that are contributing to the Drupal project and you see why do you have a booth at DrupalCon, right? I mean, these are really interesting conversations to have with people and I encourage you to do some of that communication yourself. So with that, I guess I have a few minutes for Q&A, not long, but I could probably take one or two questions. Do we have the next... Are you the next speaker? Probably need to let somebody get set up. I've got a question for you, Jeff. Yes, sir. What was your first contribution to Drupal? It doesn't have to be code because I'm not a developer. Damn, I don't know, Frank, what do you think? Yeah, running the DC Drupal Meetup, yeah. So it's probably like 2009 or something like that, maybe? Oh, yeah, no, sorry, 2007. I'm way off, yeah. Thanks, everyone.