 Welcome, everybody. So this is a session I put together basically to, I guess, scratch an itch. It's primarily kind of targeted at, I guess you'd say, larger organizations, so governments, nonprofits, libraries, museums, those kinds of larger organizations which are starting to embrace open source in quite a big way. So let me just click it. Yeah, so I just wanted to say, for those people who are here, I know there's quite a lot of representatives from universities and government here today. So I just wanted to say, first of all, welcome. It's great to see governments and universities and these larger institutions starting to participate in the Drupal community. So thank you. I think it actually strengthens our community having you here. And thanks for, if you're here in this room, thanks for coming along to this session. But for those who aren't in those organizations, I think there's a few things in here that you'll get a lot out of as well. So Drupal South is essentially about sharing ideas. And I wanted to share my ideas about how you could best work with open source in your organization. So who am I to tell you how to run it? I've never really worked in government or a large enterprise or an institution. But I wanted to share my experience from working in the private sector for a web agency who's been working with open source for quite a number of years and how I can share that experience and maybe you can benefit from that. So this is my background. Been with co-founder of Previous Next, which has been running for about seven years. One of the co-creators of AGOV and obviously deeply involved in Drupal, so I'm the top 50 core contributor to Drupal and also working a lot with the team behind GovCMS. But we are in the middle of a paradigm shift if you're not aware already. But what does that actually mean? And I think the way I see it is that some of the ways that we've been working over the last few years is we're changing. We're changing the way that we're actually working. And partly due to this, so it's a few years old now, but I think that actually was one big change in the direction of how, especially, governments work. And one of the key things in that circular were Australian government must consider open source software. It must be given fair consideration. And also, this is one of the key things that I wanted to focus on today, which is essentially government agents will need to actively participate and contribute back where appropriate. So I think that's a big change. But what is driving this change? What was the reason that open source, in general, is actually being adopted and why is it being needed? Well, there's a few things. Essentially, the users are driving this change. They want more digital services. They want more open data. They want it on any device, and they actually want it pretty quickly. And I think this has been difficult for larger institutions to be able to accommodate that rapid change and the breadth and depth of the digital services they're actually providing. Obviously, internet usage is going up. And according to my calculations, we'll hit 150% internet usage in the next 10 years, which is interesting. And even more so, mobile devices are going up. I mean, this is just from last year. But the percentage of users using mobile is going up. So essentially, on any device, so we need to be able to build sites that accommodate that and that obviously requires renewed investment in online technologies. But how do we accommodate it? How are we able to do that? Well, we can look at how the private sector does it. We can look at how the smaller agencies do it. Some of those things are around being agile, using agile processes, lean methodologies, continuous delivery, and essentially continuous process improvement. Well, how can we do it with Drupal, basically? So I mean, we're a Drupal conference, so I want to focus on that a little bit. How do we do it with Drupal? So some of the features of Drupal that will help with this is, essentially, we're working with a framework, which is very agile. And by that, I mean, contributed modules for Drupal get released very, very quickly into the world. So if you're working with proprietary software or your own in-house software, it's very hard to actually respond when new technologies come out or new features or new services come out. So for example, things like Google Capture, they release a new way of actually doing Capture, which was much improved on how they used to do it. That required a new API. There was a module for that within hours of that API being released. That's quite a rapid turnaround. And that is common with a lot of Drupal features. Modules are released very, very quickly after a service is available. It's also extensible. So by that, I mean, you're not tied into what Drupal Core provides. You've got this massive community out there of contributed modules. And if there's something that doesn't actually meet your needs, you can go and build it yourself. So you can extend it. You can make changes to it quite easily. And you can actually customize existing behavior quite easily. So it's very flexible and rapid in terms of how quickly you can get features out. So what's the paradigm shift? So I think the way I would summarize this paradigm shift is essentially what we're moving from is the role of being a consumer to the role of being a producer. So essentially, we are consumers, obviously, in a lot of ways. So if you're on Facebook, you're using Facebook. But what I mean really in this context is instead of consuming CMS software, so instead of consuming a proprietary concept management system, how do we actually participate a little bit more and give back? So a consumer of this sort of software would essentially just sit back, wait for software releases to come, wait for bug fixes to come. If they're doing coding, they would do that potentially in-house, privately. They'd build up their own functionality. They may do things in a custom way that's not done in other organizations. And they're not necessarily going out there and collaborating with other people. They don't really care about that. They're mainly focused on what they're doing internally. But what producers do are they're actually doing the opposite. They're sharing the code, they're collaborating, they're participating, and they're engaging in the community. So they're giving back into the community. And I'll talk a bit why that's actually important. So when you're sharing code, essentially, what it means is that it needs to be high quality. It needs to be well-tested, well-documented, well-supported, so maintained. And it actually provides a lot of transparency into what's going on because people can read the code, right? But with commercial software, essentially, you don't have any of that control. You're locked into release cycles. You don't have any control of any priorities in what features actually get released. There's often large support fees and restrictions on what kind of support you can get. And essentially, you've got vendor lock-in. Obviously, commercial software often has a support model around it, so service level agreements and priority tickets. But this isn't necessarily exclusive to commercial software. You can get that with Drupal, for example. OK, so this is the key. How do we actually make the most of working with open-source software? So I'm just going to take you a few things to consider. So first of all, quality. So just as an example, if you're contributing to Drupal, these are some of the criteria that you actually need to have to submit a patch to Drupal.org. So obviously, you've got to follow coding standards. It's got to be accessible, so that's a key gate in terms of the feature that you're adding. It's got to be secure, so it'll be reviewed for security. It's got to be performant. It's got to have tests. So all the code that you provide needs to actually have tests. And of course, it's got to be peer reviewed. So the process of contributing to Drupal.org is that it needs to get through to a RTBC state, which is essentially reviewed and tested by the community. So people actually have to put their eyes on it, look through it, and comment. And often, you'll go through these feedback loops where you'll get comments, and then you go make changes. And it could be 50 patches long when you've actually finally get one that's actually accepted. But I think one of the things that you need to consider as well is that the real power of open source software is co-creation. So it's technical innovation that actually is happening with open source software. So we're not only getting well tested code, we're actually getting new ways of doing things or innovative ways of doing things. And I guess this question is, if you are maintaining all your own in-house code, how you can support it yourself? So how many people do you have in your organization that actually understand that code and can actually fix bugs in it or fix security issues? What kind of audits are you doing? So are you doing accessibility reviews of your code? Security accessibility performance reviews? And are you following best practices? So do you have standards around the code? Do you have commenting standards? Do you have just these simple things like code style standards? But so by pushing code into the public domain, you're enforcing this on your own code. So I'm just going to talk a little bit about process. And I know that most of you would have heard of these concepts before, but this is something I think that is very important when it comes to working with Drupal in particular. So the key is really just around trying to adopt a startup culture. There's been talk about this in government and other institutions as well. How do you actually work as a startup would in those organizations? And a few of the key things around process and just around things like concepts like minimum viable product. So who's familiar with Scrum in here? Yep, most people. So one of the key things of Scrum, which I find really important, is that there needs to be lots of communication. So by that, it favors communication over documentation, large upfront specification documentation, because it realizes that in order to be agile and be able to react quickly and actually build a valuable product, you've actually got to be having direct communication with the business owners, the people who own that domain of knowledge in order to be able to deliver what they want. Its features are short iterations. So we've got short feedback loops in terms of delivering products and lots and lots of testing. So because we're not doing upfront specifications, we need to be doing automated testing on all the work that we do, so we have confidence that it's actually meeting quality standards. And as I said, early feedback and also frequent releases. So we're not doing these kind of big six months, 12 months, two, three year projects where no one actually gets to see it until the very end. And they say that's not actually what we want. And also minimum viable products. So this ties into the whole release early and release often concept. So this is a graphic which I thought was really appropriate. So it doesn't mean that you're kind of delivering half-baked products along the way or half-baked site. You're delivering the core functionality first, and then you're extending and enhancing it as you go along. So at every point, you actually got something that people can find useful and actually like. So I think the key message around this is don't try to gold plate features. Start thinking about how can I just achieve the core functionality of what I need. And then release it out there, get feedback on it. That could be released internally. So outside your core team. Release it, get feedback, and then use that to help you prioritize what are the next features are. Because you can be guaranteed that your priorities are going to actually change once you've got feedback. You can't be making assumptions around what people will find valuable until they actually get to see it. And it helps you actually reduce wasting time on unwanted features. So you might think that this feature is really fantastic. And by the time you actually deliver it, people are like, well, actually, we don't need that. Which does happen. So build a team. So a lot of organizations are actually hiring internal developers. They're trying to skill them up. They're working with partners or consultants like previousnext, like us. How do you actually make that team succeed? So the first thing I think you need to do is actually what's actually going to be motivating your developers. And I'm talking about developers this could equally apply to. To anyone in your team. But I guess the key to working with open sources try to understand what's going to be their key motivation. So these are some of the things that actually developers are motivated by. So first is altruism. So that's basically, especially in the case of Drupal. So they may be contributing to software because they understand that it will be used by nonprofits. For example, they can have a software they can download. It has a very low cost and a paying license fees. They get a lot for very little. And I think there's a good example of this altruism when I was in 2010. I think it was DrupalCon. Could have been Portland. There was an earthquake in Haiti. And on the sprint day, we were all there. People were working on Drupal core. And a table basically sat down and said, let's build a site that can be used by people who are looking for accommodation in Haiti. And they can basically put up, like, I've got spare accommodation and people who are looking for accommodation could find that. And they could match up and essentially find housing for these people. And I think that was a real important kind of light bulb moment for me because I realized that a lot of people who were working or who were there at the DrupalCon were doing it because they wanted to make the idea of a public good. They wanted to improve the life of others. And they can do that by building software. There's also a key motivator, which is essentially around just being part of a community. So being involved in a network of like-minded people and trying to build something together. And I think a key one is essentially people being motivated by recognition. So Drupal, there's lots of kind of different ways that especially in Drupal, working in Drupal core that people actually get recognition. And I think yesterday Angie in her keynote was talking about, now she highlighted some people. So she went and showed their profile. She was talking about how many commits they have. So she was saying, okay, this person has more than 150 commits. So these are the key, and they're not great metrics, but there's some key points that you need to recognize that people are motivated by the kind of recognition that they will get within a community, especially with open source developers. So a number of commits, what working groups are involved in, what teams they're part of, whether they're a maintainer of a module in Drupal core, are all key drivers for people to actually be motivated in the work that they do. And actually Drupal.org is putting a lot of effort now into trying to improve the recognition, not just of individuals, but of organizations that are actually contributing to Drupal.org. So there's a lot of work coming out pretty soon where you'll be able to say, I worked on this bug. I fixed this. Who do I wanna attribute this work to? And you can actually choose whether it's yourself or whether it's an organization that actually participates. So people start building up profiles of your company or your institution to be able to say, well, this company's actually backing contributions to Drupal.org and then build up your profile. And the last one really is just around creative expression. So if there are a lot of people, if they're open source developers, they might be working on whatever they have to do on a day-to-day basis. It might not let them actually do the things they really wanna do. So they wanna be able to go and build something in a really cool way or using new tool. Often it's a really good motivator for them if they can contribute in a way that lets them kind of express their creativity. So how do you actually keep open source developers' skills up? So this is very different, I think, to how you would traditionally send people off to training courses. If you're working with Microsoft or some software where it's very kind of very, there's a curriculum for doing certain training courses. The best way, I think, to train developers in open source is actually get them to start contributing. Get them to write patches that will have to look at all the APIs that are working under the hood to be able to actually understand what's going on to be able to fix patches. And open source contributions are a massive, a massive way for them to actually improve their skills. They'll get feedback on their work. If any of you saw Lee Rowland's session yesterday, he was talking about his kind of process of learning, going through doing Drupal core contributions. He was actually learning all the time. He said his skills had grown like 10-fold from his time actually participating. And that's not like being a genius and just being someone who's skilled and, I mean, even though he is, it's more about like his participation. He was persistent and he went back. He got feedback and he kept going. And I think that is the key, it's the participation part there that was able to raise his skill levels. And I think that's really important when you're building your own teams to think about how can I keep their skills relevant? How can I build up the team and improve their skills? Speaking at events is another one. You might be aware, like when you actually speak at events you actually have to know what you're talking about. So that's a good driver for people to actually get up and talk confidently about a topic that they're passionate about or they're interested in. And it also helps their communication skills and the ability to go out and spread the knowledge of what they do. And a key one, as I said, is just participating in the community. So being involved in discussions, coming along to these sort of events and engaging with the community. Yeah, so what are the outcomes? So if you are involved in open source contributions, so you learn the latest technologies. We'll build a stronger community so the Drupal community will benefit from your participation. We'll get different ideas coming in that we might not understand. So if Drupal South was essentially just all developers all sitting around talking about the latest cool technology would miss out on insights of what it is that different organizations actually need. We had a great keynote this morning, I thought, which it's not often that you get the perspective of user experience and design. And it's really refreshing, I think, especially as a developer to actually go, right, yeah, this is another kind of thing that we all need to be considering. So I think that cross-pollination of ideas and getting input from different organizations and different institutions actually really helps strengthen the community, gives us a better understanding of what's happening. I think that one of the key things I mentioned before is actually building a reputation. So this applies specifically to Drupal developers. So I was on a panel in DrupalCon Austin which was basically just Drupal shops. There was a bunch from the US and from Europe and I was representing Australia. But it was all talking about how we actually recruit and how we actually find developers. It was really interesting to discover that we all had a similar process and it was all around looking at that particular developer's online contributions. So we would look at what have they been doing on GitHub? Have they presented any sessions? What modules are they writing for Drupal Core? How well are they maintaining the issue queues of the modules they maintain? So it's all around their reputation and that's all available online. You can see what people's contributions are. And that is a huge, that's way more valuable than just saying, yes, I've completed these courses and I've got this level and I've done these kinds of projects because you can actually see what their work is in practice. Okay, so how do we actually make the shift if we're trying to move to a model where we're actually embracing open source and trying to work with the communities? How do we actually make that shift? I think in terms of your organization, one of the key things is actually just be very clear about what your vision is. What's our goal for working with these technologies? What are the values of the organization that we want to be instilling in the team? So challenge some of the underlined truths. By these, I mean, there's lots of assumptions there. Open source isn't safe. We shouldn't be sharing any code with the outside world because it'll expose us to vulnerabilities. People will be able to see our code and work out how to hack us. So challenge those assumptions. Like, okay, well, what's the truth about that? What's the reality about those assumptions? And often the reality is that it's actually much more secure to actually have your code peer reviewed by thousands of people as opposed to the five people that might be in your development team that may not be experts in security. Try to skill up your aligned team members. And by that, I mean, work with people who share your core values. Are they aligned in terms of their core values? Try to skill those people up. And in order to be unified as a team and cohesive as a team, it really requires lots of communication. So that is communication from different levels of the business talking to each other so you don't have segregation and there's teams off here doing their own thing that don't really understand why they're doing it. Yeah, so basically be clear about the core values and belief. Encourage team participation in that as well. So it doesn't have to come on high. What, you know, discovery about what your core values are and what your beliefs are. Encourage participation in that. You know, you essentially, by getting participation, you're guaranteed to get more buy-in from the team who share that vision. And actually provide a roadmap for how we're actually going to implement this change. So we're talking about an organization saying, okay, we're rolling out Drupal. This is the goal that we want to actually achieve. This is the outcome. How do we actually get there? So you need to be able to provide a kind of action plan for actually how you plan on doing that. It's not good enough to have just the vision without a way to actually action that. And this is, I mean, might be controversial, but try to build your team around those core values. So often you'll have people who are experts. So they may be, especially in, I guess, a relatively small community like Drupal. It's a big community, but, you know, often if you go out and you say, okay, we're just going to hire all the experts that we can. That's actually can be detrimental to the team. If they don't share the core values of your team, they are unaligned with that. So sometimes it's better to actually remove those people out of the team, not have them disrupting your team. It's much better to actually have more junior team members who are aligned with you and skill them up. And that way you'll actually build a much more unified team, a lot more cohesive team. And another key point is that your team members may not be necessarily all in the same location as you. So previous next, we're very distributed. We have people in Queensland, Canberra, Sydney, and two different offices of people in Melbourne. So it's not necessarily all about having to have people sitting at the desk and watching them nine to five to make sure that they're doing their job. Your best team members might not be sitting right next to you. Communicate. So as I said before, often in a traditional project, I talked a bit about scrump, in a traditional kind of waterfall project, you'll essentially have one team do IA in design and they'll just chuck it over the fence and go, here you go, go implement that. You need to basically have a unified team where you're talking through all of those problem-solving decisions with the user experience team, with the developers, with the business owners who actually understand the problem that they're trying to solve. So that you're actually working very collaboratively. And that is direct communication between the product owners and the team members. We're essentially trying to solve the problem together. And communication through wireframes alone is not enough. And this is a key feature of agile. So not only does it strengthen your team and build up a stronger team of open-source developers, it's actually part of the process as well. So, and this is probably the key message I want to give away is essentially, your key to success with an open-source team is essentially to engage with the community. So attend Drupal South, which some of you have done. Collaborate with the community. Get involved in discussions. So it was great to see yesterday there was a bof for Drupal in universities. And we had people from different universities who hadn't really ever spoken to each other. And we sat in a room and we actually talked through common problems that we're trying to face. And it wasn't a technical talk, it was really just sitting there saying, okay, what's the problem space that we have? How do we actually share these problems? And I think that's the power. And essentially being engaged in the community is that you can actually try to help each other to solve the same problems. I mean, a lot of the time, you may be competitors, but you're essentially working in the same problem space. You are looking at the same technology solutions. There's a lot to be gained out of sharing knowledge and what you're doing and learning from others. Yeah, so get involved in the open-source software itself. So if you find a bug, don't just kind of fix it in your local fork of that code. Submit a patch up to Drupal.org, explain what the problem is that you had. Provide a patch if you can. So basically fix the problem and share it. So part of the process of what we do when we're building and when we build Agave is essentially we never have any bug fixes that don't exist on Drupal.org. You find a bug and it could be an accessibility issue with the module. The first thing you do is you post a patch up on Drupal.org so that other people can start participating in that discussion. It might be that you made some assumptions about what that module did and your assumptions are wrong, but by the point of actually posting a patch up there, you're gaining that knowledge and you're understanding what the issues are. Share your knowledge, so talk at sessions, provide information about what you're doing, which I know a lot of organizations are doing, and share your code. I don't know whether everyone's heard of Pay It Forward, but the idea is that essentially try to contribute more than you actually get back. So try to over-contribute rather than just assume that other people are gonna be providing you with all the tools that you need and you're just gonna consume them basically. Yeah, so that's my key message for the take-home message for today is engage and yeah, thank you. I've got some time for questions if anyone's got questions. Any questions? Yes, Pam. Besides going to conferences like this one, what are some other ways people can engage with their local community? Thanks for asking, Pam. So look, there are local meetups and there's Drupal meetups in every city. I know that South Australia, there's not specifically like a Drupal meetup, but there is like an open source meetup where you can go and talk about open source and Drupal. And one of the key things that we're finding as well is not the server just sticking to the Drupal community. So in Sydney, for example, there's JavaScript meetups, there's PHP meetups, there's CSS meetups. So it's not about just participating in just one community or the Drupal community. You really gain a lot from actually participating in lots of different communities and sharing that knowledge across them. Thanks, everyone.