 Thank you very much. So, hey, hello, WorkCamp. We got the lucky last session. And nice to meet you all. It's been great to be here. We are talking about this concept, essentially. Well, this is one of the concepts we'll talk about. If you're not paying for it, don't base your business model on it. And I said, oh, does that mean, does contributing count as payment? And yes, I got approved for that. So we have experienced open source companies implementing open source software, basing their business around it, who do not fully engage with that software. And I contend that they, therefore, don't get the full benefit out of the open source software that they could. And we're going to talk a little bit about that equation. And at the same time, we're going to talk about developers being frustrated, unable to contribute, and how to unblock that, and include contribution in your daily development workflow. This talk is actually about 40, 45 minutes long. So we're going to try and smash it into 30 minutes now so that we can all get to the closing session. And so that I can get over to Berlin tonight. Right. So hi, I'm Chris. I've been working in the Drupal community for at least five years. I did some migration research on how to get organizations to contribute more to open source software, which led me to Jam, which I wanted to interview. And he ended up interviewing me. And now we're doing this thing together. So it's pretty cool. But a lot of this is based on my research and his personal experience over the past decade and a half in working with open source business. Yeah. Well, I introduced our work at Dees and we'll get to that later on. So I work at a Drupal company called Acquia. I started in 2008 as the 18th employee. There's now about 800 of us around the world. We started out providing services in and around the Drupal platform. What we're doing now, Ronald mentioned in the last session, we are enabling digital business. So we have a personalization tool that runs in a Drupal, in and around a Drupal instance, but the content and the analytics can run on other platforms as well. So we're really moving into this age of screen lists, alternative display or no display, all this other world. Our home routes are Drupal. We do an awful lot of contribution. And so on. I have done dev.acquia.com slash podcast. I've got 250 conversations with people in and around open source up there. I enjoy doing that a lot. I'm pretty active on Twitter. Please get in touch with me anytime. Today, we are going to just make sure that we're all on the same page about, hey, what are those benefits of using open source just so that we have a common ground to have this conversation? Why should you contribute? What is standing in the way of contribution? In some case, how do we unblock you and your companies from contribution? And so I found this quote through another open source person. Edmund Burke said, nobody made a greater mistake than they who did nothing because they could only do a little. Really, any contribution that you can make to open source is worth making because it doesn't really matter how small it is. It's going to make your project better. And therefore, you'll be able to implement things and do that better as well. Our companies, both of our companies, practice what we're preaching and are actively engaged in contribution. Right. So like I said, I work at Decent. We're pretty much an organization that's open source by default. Our handbook is open source. Our business practices are open source. We're currently on a journey to improve the inclusivity and equality within our organization. And every step we take in that aspect is open source. Every source, all the source code we make is by default open source unless prohibited by our clients. And we actually get paid contribution time to our developers. In case you were wondering, yes, we are hiring for pretty much every single role imaginable. We want to be the largest open source specialists in Europe in the next couple of years. So if you're interested in changing jobs, please come and talk to me. I can get you hooked up. My company has 10 full-time employees who work on Drupal Core, a lot of module maintainers. We sponsor a lot of code sprints. We're putting our money where our mouth is, essentially. Let's go on and talk about open source software for a moment. We have these really obvious factors. When you use open source software, you don't have to pay for permission to use it. You get an improved ROI because you're not giving someone else a license. All of this stuff should be fairly obvious, and we know about this. And we can compare a proprietary project to an open source project. And we still do that a lot, pitching against Adobe, pitching against Sitecore, and what have you. Every IT project needs all of these things, and every IT project costs money. So don't tell people this stuff is free. That's pretty obvious. It's a lesson we should have learned. You start to get some differentiators because we can make exactly what we need when we need it. And that means that our projects can be on the cutting edge as fast as we care to develop new features with them. We have thousands of vendors who can compete and cooperate in our ecosystems and being locked into other platforms. You don't always have that. And a big one that used to count a lot in the past. We've seen a lot of these times where you invest in some online system, and then they go belly up, and you're stuck without the data for your business. So at open source, you should be able to organize it in a way that you also keep your data no matter what happens along the way. We have this idea where there is a license fee, but it is a zero amount of currency. And instead of paying for permission to try and see if that proprietary system works for me, I can just pay one of my devs for a week to go and try stuff and build me a minimum viable product, for example. And then every time I spend actual money on open source, I'm spending it on features. I'm spending on making it better. I'm not asking for permission to use the software. So you have a budget model here. Once you've reallocated the money from a license fee into features, you can train people. You can make a better project. What have you for the same budget? So we say, build better. Don't build cheaper. So what is the problem, actually? Why am I here? Why are we here to actually help organizations to contribution? Well, how many of you have ever wanted to contribute or felt blocked somehow? Who felt that I didn't have the knowledge to actually do something? So how many people in the room are developers? Right. OK, awesome. Who's not a developer in the room? What do you do? You're a designer. OK. So you can contribute as well. That's pretty good. So you're all developers. And you've never had a problem contributing? Ever. Oh, we have. OK, so answer the question again. Right. So who has had a problem contributing to something? Who has ever felt blocks in contributing to something? Right. I mean, have you ever doubted your own skills? Have you ever looked at the code some hero of yours has written in the WordPress community and you're like, I don't think I'm allowed to touch that code. I mean, he's awesome. If I say something bad about it, is he going to be like, you know, questions like that, they are blockers. They're blocking you from contributing. And that's one of the reasons I started my research. I've actually been in an organization and I've been asking questions. And talking to a lot of developers over time with different organizations as well. And I've made a map of all the problems they encountered. And there were three things that kept on coming back. Lack of knowledge, lack of time, fear and doubt. And those are the things I've been trying to solve in order for people to actually be able to contribute on their day to day work and make it their own. Which I did by first trying to identify the things that made their fears and their doubts and their lack of time and their lack of knowledge worse. Like the negative catalysts. I found that several people were just afraid to ask their colleagues for help. I mean, they're your colleagues. You should be able to just feel okay about asking them stuff. But a lot of people actually are afraid to admit that they don't know something, right? Then there's the whole combination of being in doubt or a little bit of afraid and not knowing something and you combine those two and then there's a lot of energy to overcome that hurdle and then people are like, yeah, I'll just shy away from this and don't do it. And even if you try to do it, it takes so much time to actually get over it, which brings me to the lack of time issue. Which in itself is compacted by problems like projects that are scoped to narrowly. Things like, am I even allowed to do this? And so on and so on. So I tried to identify things that made those worse. And then I tried to find ways to reduce those catalysts and to make sure that these things, well, were made easier through training and guidance, making time available, defining a definition of done with your projects, whatever. So, contribution seems obvious. Something we need to do. So we know the Drupal community better than we know your community so far. And in our community, there's an awful lot of idealists and people who come from activist backgrounds and political backgrounds and scientific backgrounds and musicians and so on. And there's an awful lot of, yeah, contribution, yeah. You know, it's, yeah, because it's all about us. And it's, because it's the right thing to do. Now, that's a really hard argument to bring to management. And say, we got to contribute, man, because it's the right thing to do, right? That doesn't get very much traction with management. It is, in fact, the right thing to do, but we, these are not business reasons. They don't pay the bills and they don't have any measurable return on investment. So we need to define business reasons to contribute if we want to contribute within our companies and organizations and justify that to management. So, you know, strategic roadblocks are the first thing that I wanna talk about. We have strategic roadblocks, which end up being a lack of vision, a lack of policy, and a lack of support for engaging with open source. And contribution is a part of that. We have, so I'm gonna talk about strategic roadblocks. Imagine I'm coming into your company and I'm talking with your management about, hey, you do open source, let's talk about how you do open source and how you can get more return on investment for your company by engaging with open source. And Chris is gonna come in and talk about operational roadblocks, the things that he mapped out before, fear, doubt, and so on, and how to unblock the developers and make development part of daily operations. So, I just want to shout out to Simon Sinek. He made this model called the Golden Circle. This is an old TED talk that's really worth checking out. Who's familiar with this Golden Circle? Oh, neat. Okay, this is a really neat thought model. Essentially, if you come in as an open source person in your organization, it's like, yeah, we're gonna contribute now. So what are we doing? We're contributing, right? What do we do? Can we contribute? And it's like, we do some contribution and then the management says, why did you contribute? And say, oh, it was the right thing. It was the right thing to do. We gotta pay it forward. Okay, was it effective? We submitted some patches, right? If you start with your what are you doing, you can't measure things and you can't know what your goal is and you can't know if you're moving towards your goal. If you start with your why, why are we doing this? If you determine the why, why are we doing this? We want to engage fully with open source because, dot, dot, dot, there's a bunch of good reasons. Then you can define how that contribution is going to take place. We're gonna talk about some options there. Then from those options, you can do them and you can measurably and demonstrably say whether you are moving your company forward in the direction that you defined in the why. So the idea is there's no getting to a sensible, measurable how from the what, okay? So if you get management on the same page about contribution and they support it, management can create a mandate that says we will fully engage with open source. Talk to the technical part of the company and say we want to engage with open source, here's a budget or not, here are ways that we want to support contribution. Create a policy, the technical side of the house can create a draft policy, management and technical can agree and then we, developers, we can go and contribute at work on work time in ways that support our company over time. So we need to know why we're doing it before we can agree on how to do it and what we're doing on a daily basis. So I'm gonna come in and give that piece of the talk in a minute and Chris is gonna talk about the operational part right now. Right, so I've identified a number of roadblocks. The unclear mandate and policy, the why are we doing this has been a major one. Like I said, lack of knowledge, that's pretty much the how, how do we do, how should we do this? And then you have the lack of procedure, like what are we specifically going to do to make sure that we actually will fulfill the why? And then there's the doubt about scale and the lack of time. And these are roadblocks that can be, of course be very organization specific, right? So in this organization, this was actually the order in where they found most of the problems. For your organization, it might be completely different. Maybe your why is very clear, but there's just a lot of doubt about skills or just lack of time or whatever. However, mapping this out is very easy. All I did was just create a simple questionnaire, send it out to the developers, ask them to actually ask them to answer some questions, like what is blocking you? Are you feeling afraid about stuff? Are you, you know, what is holding you back? And I just got results analyzed it. And like in a week and a half time, I had this list of things that people were feeling blocked by. Pretty easy to do. So back to the real problems in that organization. So this is actually the map I made by actually analyzing those results. I just measured how many answers were given in a certain category, and the more answers were given, I made the bubbles bigger, and then connected the dots. And you can do the same. It's relatively easy to do. Yeah, that's it. So, Dren. Right. So now I come in and I'm gonna do a day-long workshop with your management and we're gonna talk about the why. We're gonna find the why together. So I'm gonna bring you, your management, whoever it is. We're gonna agree about the benefits of using open source and that we really believe in all of that just to make sure that we have that common base. And I'm gonna talk about some specific things. Some of these are, some of these make sense, but they're hard to measure and some of these are easier to measure. I know very intimately the situation of running a company on a day-to-day basis. Operational problems, finding money, billable hours versus non-billable and so on is never simple. I know that some people still do fixed budget projects. Fixed budget, fixed scope is a terrible idea, but I know that people still get up to that. But here, I think the overall tone is to, this is systematic thinking. To systematically do things in this way will produce consistent long-term benefit and this is not really about quick wins. So although there are some things that are pretty clear. So here's a bunch of the topics I'm gonna touch on now. So we could really explore these for hours and sketch them out and put up some formula, but I just wanna touch on a bunch of things really, really quickly now to make sure that we stay within time as well. So this is what I call the boss talk. So look, we're here having this conversation, right? Without contribution, none of this stuff, WordPress, Drupal, Joomla, you know, the Apache project, Node, JS and so on and so on and so on, none of that would exist. In the case of Drupal, our project is plus minus 17 years old and it is the product of millions and millions and millions of hours of coding. So, you know, when we turn on, when we download WordPress, Drupal or what have you, we are benefiting from decades, a decade of best practices from our colleagues, right? So we're benefiting immediately and we really, really need to figure, we owe, this is not a moral story, but we do need to keep in mind how much of a head start we are being given every time we start a project, right? So you've got to own your core competencies. You've got to build expertise in your company because if your devs are better, you will deliver better work, your reputation will grow, you'll sell more things. You'd be kind of stupid not to engage with the product that delivers your core competence. If you're building web applications, right, you should have people who know that code inside and out because they will be able to build better projects and fix stuff when it goes wrong and develop new features when they're needed. You can't just rely on it to be done for you somewhere, okay, so contribution is building expertise in your core competence, you know, building stuff for the web, right? And it just so happens that when you let your developers interact all the time consistently through whatever channels and forums there are in your particular software community, your developers have the chance to interact with the leaders in their field to ask questions and you're getting free training, okay? Every time somebody spends a half an hour on IRC in the Drupal community's case, I don't know where you do it at WordPress on Slack, I think everybody uses Slack now. Every time you spend a half an hour on Slack, right, figuring out an implementation, that's free training, right? And comparing the cost of a half an hour during work hours to fix a problem and move along to sort of stopping productivity for a week and being sent on some formal training course which itself costs money plus the loss of productivity, you have a measurable gain in productivity and a measurable increase in the amount of working time if someone is just doing that in real time. So you get free training simply by interacting with the communities, clearly sending your devs to this sort of an event, doing code sprints and so on. That also helps, it's very important, but you know, when you have a better trained staff, right, your quality and efficiency improve over time and you have a long-term benefit and when you find a problem and you write a patch for that and you submit it so that it gets absorbed and implemented upstream in the project, you have discovered risk and you have outsourced it out of your house. If you build a fix that you keep in-house in your special little in-house code base that you have to track with the main project all the time, you've got maintenance costs, right? And I think it's much better to invest six hours fixing a problem forever than spending, you know, six hours a month on it every time there's an upgrade over five years. So there's a calculable benefit to reducing technical debt in the overall project. If you use mainline well-adopted code plugins, modules and so on within your company and release them to the main repositories, the security teams will look at them, other people will look at them, they will give you back better security. Drupal has a full-time security team, code on Drupal.org is vetted when problems are found and fixed and so on and there's a proper process in place. So you gain security. Now, you could write that quick fix and keep it in-house and that costs money itself but what if somebody just happened to implement it wrong? Okay, and just happened to leave a security hole and nobody in your particular dev team noticed it, not because they're bad, just because there was a problem that they didn't know about and that they didn't recognize. The cost of security risks, okay? The cost of keeping your security in-house, if there's a site outage, if there's a hack, if there's a data breach, okay? Eight years ago, 10 years ago, each Kaspersky website was earning $1,000 a second. All right? Do you want to maintain that security risk in-house? No, right? So open sourcing your stuff, contributing your stuff back to the community, you gain security, that's great for your business. Once you're doing all this stuff, people will notice too. You can build a reputation as a company that will help you sell more projects, do organic marketing through the communities and word of mouth and so on. And one of the biggest factors here is hiring and retention. You know, look at Jenny Wong. Everybody knows Jenny Wong around here and she's awesome and she works for HumanMade and I was having some beers with HumanMade last night and they say, oh yeah, we get tons of CVs where they say, oh, I was talking with Jenny and Jenny said HumanMade was cool and you know, here, can I work with you, right? So being active and contributing to your open source community has all these collateral benefits, right? And we've talked with companies where open source developers have been hired and then they've been taken on, they've been told they're not allowed to contribute anymore. You know, everything stays inside, it's all proprietary and they lose this feeling and then they'll often leave. Turnover is really, really expensive. I was just reading a study today that the cost of a new IT or tech hire in 2014 in the UK was more than 30,000 pounds per roll and each new hire takes 29 weeks on board to the level of productivity that's considered optimal. So instead of forbidding someone to contribute and forbidding them to be part of the culture that they came from as open source developers, you could make them happier, please contribute, please spend your time interacting with the community, please do open source your code because we get more quality and because you'll stay at our company longer and everybody wins. And you could also give them a five or 10 K raise compared to the cost of acquisition of a new employee, that's much, much better. Everything I just said relates to what we call operational contribution. This is contributing to projects that you use at your company in production and all of that makes perfect sense in that context. If you are confident enough as a company to give people contribution time, not tied to current projects, open source developers should go and interact with other projects. All of you should go and check out Drupal 8 because it's super cool, right? You should check out Node, you should figure out how to write in another language. I have a website in Ruby Jekyll, right? Because learning how other projects do things, you as developers get new perspectives that you can bring back to your work projects, learn how to do things in a new way and you can bring incredible value to your company having looked at other things. Yeah, right, yes? Four o'clock, okay. So I talk with management, we talk about open source, we talk about the value delivery that I just talked and each of those has some maps behind it. Writing a patch takes, I don't know with quality testing and everything, let's say writing a patch and submitting it takes four hours. We open source some code to the community, five patches come back from the community that improve our code and we've saved as a company, we've saved the money of 20 hours of developer time at London developer rates, right? There's an actual economic story to be told. So that all sounds pretty convincing. Now let's talk about, so management's given us a mandate to contribute. How do we solve this? Right, so let's fix this. In my experience, while I was doing the research, I was actually trying to implement solutions as well. In my experience, what gave the biggest effect was to start training the people around me, to start training the developers. I had a lot of experience with open source development and the people around me didn't and they were insecure about it. So I ended up just mentoring people, just telling them how they could do it. Whenever somebody found the bug with any project, I was like, why don't you contribute it? Let's just sit down together and do it together. And in that way, I could actually teach people and make people feel more secure about what they were doing. That after a while, they started doing it themselves but they also started helping their colleagues. They were solving the problem themselves after being showed how to do it. And that training and guidance, in this case they had somebody in house me to actually help these people. But it's relatively cheap to find a prominent figure from the community you're in and ask them if they're open for coming in for some paid work and actually spending some time consulting your developers on how to do this. You only have to have them around a couple of days and then the effect will be measurable. So by taking away the knowledge problem, we've taken away quite a big chunk of all the problem space there is. And then comes the change in organization policy, the organizational changes, things that actually can happen in parallel. So while your developers are being trained, management could sit down with, well, some of the lead developers and come to a contribution policy, come to a mandate. And like Jim previously said, agree on why we should contribute as a company, in which ways we want to contribute and what specific actions we want to do to achieve those goals that we've set out. If you're in a company that doesn't do this and it doesn't know that they should actually try to get to a mandate like this, you can always ask, go to your manager, bug him until he actually listens to you and ask him or her specifically for a mandate, for a policy, say we as developers feel and know that it's better to contribute to open source software because it makes us better and it makes our company more profitable. Tell your manager to call us in to do two days of consulting at your company. Okay, you with your selling stuff all the time. We're open source here, right? But I mean, the idea is clear, just ask for what you need. As a developer, at least as a developer, I need open source contribution. I need this interaction to be the best version of me and to stay the best version of me. So wherever I go, I ask for permission to do this and make sure that I can. So now you have proficiency, you have mandate and those two make that you can actually start contributing confidently. You know you're allowed to, you know how to do it. So now you can actually start doing it on a regular basis and before you know it, you're very proficient at it and it starts taking less and less time and you start becoming more and more efficient at it. And you're starting to know the project better as well. So your projects are going more and more efficiently as well. So you're creating all forms of time for you to contribute more and more to open source as part of your data job. And then comes the point of actually integrating it into your contribution workflow. So part of my research was about trying to figure out how development workflows actually work. So I first had to look at the development workflow of a number of companies. And after, well, a couple of months of making very complex processes look very simple, I came up with this. In essence, all development workflows be them open source projects or company workflows come down to we analyze a problem, we develop a solution. One of our colleagues or friends or peers reviews our solution, they either approve it and we can publish it or commit it or whatever you want to call it, or they disapprove and we go back to the analysis phase to fix whatever they said was wrong with it and develop a new solution. So putting them side by side, you see they're essentially the same and then the contribution side of things is really easy. So let's say I'm working on development of a new feature for a client and I'm using some module or some plugin and it's almost there, but I need just a slight alteration to get my use case done. I can create a patch for it and I can just submit that patch to the open source community. I've already analyzed the problem, I've already developed the solution, there we are. I then pass on my solution to my colleague who reviews it and he will also review the patch that is waiting in the project's queue. So now he has also done the work for the client but implicitly also for the project itself. So now the patch has been created and it has been reviewed. So all the maintainers of the project have to do is commit it. This is us sharing our work back to the main project. Right, but what about you need a use case that hasn't been implemented yet, but there is already a patch. Someone has already done the work. Well, we can take that patch, we can use it in our project, but before we use it implicitly, the thing we wanna do first is review that patch to see if it isn't something stupid, if somebody didn't introduce like five or six or seven or 10 security holes in it. But when we come to the conclusion it actually solves the problem and it's actually what we need. We can use it, hand over our project or our solution to our colleague who will review it. And he will implicitly review that code as well. And all he has to do is take that relevant bit of reviewing, post it on the issue queue where the patch originated from, done. Now there's a meaningful contribution and an unblocked issue. And then there's the whole thing of improving on the work of others. The patch was all right but you found a security hole. So you fix the security hole, you upload the new patch and then it goes through the same problem. It goes through the same, you know, the same review and your colleague finds it okay, uploads the review results. There you go. Another patch ready to be committed to the project. And the result is that contribution is now how you work. It is no longer something you need to sell. It's no longer something you need to think about. It's just how you do your day to day job. You'll still have problems. You'll still have time problems because somebody will scope with something wrong. You'll still have, you know, strange, missing requirements. You know, an insufficient definition of done whatever. Day to day problems you already have but contribution won't be one of them. Contribution will just be who you are. And this is not something to talk about with your clients. This is how to run your company better, frankly. So how, so if you agree with my premise with management that contribution can improve your bottom line, save time and resources and you implement workflows like Chris suggests between, you know, internally and externally with this culture of contribution. There are a lot of ways to contribute. Oh, it worked. Okay, that was new today. Thank you. Chris also mapped out every way that we could figure out how to contribute to open source. Please read those. There's going to be a quiz afterwards. Yeah, that's only like four and a half weeks of research. But we identified four methods of contribution that are perceived as particularly important within our community and three more that we know to be effective through our experiences. So talk about the big seven. Well, obviously there is no open source software without the code. So the best way or, you know, the most valued way amongst people is code. It's not my most valued thing though because if you look at open source software projects what they really need at this moment in time is reviews. Is people actually looking at the code and saying, you know what, this actually works. This actually meets the standard. So in my opinion, review should be on the top of the list. But then there's documentation. I mean, all of us have had problems where you install a module and you're like, okay, I've installed it now what? They call them plugins. All right, they call them plugins, sorry. So we've all had that very meaningful contribution to actually improve that documentation. Once you've figured it out, you can just write it down. Even if it's a really quick note, like do this, that, and that, publish it, and now you've documented something, very good. Then there's sponsorship. I mean, there are a lot of very bright people who can be more and more efficient for contributing to stuff. But they just don't have the means to get to a conference and sit with their peers and actually do the face-to-face time which actually makes them extra productive. A sponsorship in that area would really help. But also events like this, I mean, without the sponsors, we wouldn't be here. We wouldn't be having this talk. Or like your company pays one of the developers to work a day a week on an open source project. Right, yeah. Yeah, they pay me to be here. And then there's the whole organizing of events. I mean, people need to be able to do that. Companies can do that as well. Local meetups, very important. But also design, for the one designer in the audience, a lot of open source projects lack proper design. They just need help on that end and designers can actually start doing it. I mean, there isn't some consensus that needs to be reached. It's just somebody just needs to step in and do it. And nine times out of 10, people will just be happy that somebody did it. And then there's the whole evangelizing. I mean, just talking to people about open source and the importance of it and the roles it can play in our lives. There's very important things to do. Right, and evangelizing also includes creating and sustaining our community. Community doesn't happen without us writing blog posts and doing podcasts and having beers together. And that all counts towards evangelizing. I explained to our lovely transcription crew yesterday what open source is and how it works. And they got more insight into how that works. And they seem to be very excited about the ideas of like they could make the software that they work with so much better if they were only allowed to mess with it like we do. So there are a lot of moments to talk about what we do in regular life. We talked about why using open source, we talked about a very, very high level, a business case for contribution. We talked about things that block companies and developers from doing it. And we talked about unblocking that and some ways to go and contribute effectively. Thank you so much for having us. We're finishing within one minute of time, not bad. Yes, it's been really, really great. I'm really, really happy to meet the WordPress community for real. Finally, you can find both of us online fairly easily. Thank you. Thank you. Thank you so much, Jam and Chris. We have about five minutes to head over to closing remarks and you have a flame catch? I do. But if you guys have some quick questions, you could either sort of make him late or contact him up there. Well, I've got some time to...