 How's everybody going for day one of Drupal South? Yeah, see some good sessions? Yeah, yeah, cool. Awesome. Well, my name's Nick, and I'm from Previous Next, and I'm also from Skipper, a hosting platform. And I'm here to introduce our keynote speaker. But before I do that, I just want to quickly tell you a little bit about the platform. I'm going to take up too much at your time. And also tell you about a bof that we're having a little bit later on. So anyway, so I just want to tell you what Skipper is. And it's our scalable hosting platform. It's built on Kubernetes. It's all from the command line. And it's all about maximizing developer workflows. So if you want a hosting platform that works right at the command line and right where you operate as a developer, come have a chat with me. And we have a bof just at 2 o'clock. And we're going to talk about if you're interested in Skipper, if you're interested in Kubernetes, containers, come have a chat with us. So we're really keen. Awesome. And yeah, if you can't make it, don't worry. We have people in these bright red shirts. Turns out a few of us kind of are synced up in color schemes. But yeah, Skipper, red shirts, couple of lads over there. Go see them. But yeah, let's introduce the keynote speaker. So today, we have Michelle Manoring. She's a developer community manager at GitHub. Yeah, and just chatting with her before, it's crazy. Multifaceted. I mean, the whole community manager is just the tip of the iceberg. While researching Michelle, I found out that she wears many crowns. She's not only a hackathon queen who's run more than 70 hackathons, but she's also an eSports queen, a streamer, journalists, and also co-founder of Rain Scooters, which yeah, looks super, super cool. Yeah, I'm going to get in trouble if I buy one. So today, Michelle will be talking to us about collaboration and how developers and non-developers can work better together on open source. So if everybody could stand up and give a warm welcome to Michelle. Thanks so much for that awesome introduction. I'm not from Skipper, even though I am wearing red. I kind of realized that today, I was like, oh, I kind of like blend in with all the Skipper people. That is the scooter, but that is not my presentation. Give me one second. It is supposed to be on the screen. There we go. Awesome. So as Nick mentioned, I'm the developer community manager at GitHub. Really, really excited to be here. I'm based in Melbourne and yeah, cool to be in Hobart. Thanks for turning on the nice weather for us too, which is awesome. That is my GitHub handle, Mish Manors. It is also my Twitter handle. So if you are tweeting today, feel free to tag me and I will probably more than likely retweet you, which is awesome. I usually start off telling you all a little bit about myself, which I really hate doing. And so I'm really glad that Nick has done nearly all of it for you. So I don't have to really talk about myself, but yeah, I've done over 70 hackathons, run a few companies and yeah, have a lot of fun while doing it, which is awesome. Right, today, we're going to be talking about collaboration, teamwork and open source. So before we get into all that, we're gonna talk about where collaboration actually sits within this whole ecosystem. So most of you here have probably heard of DevOps, yes? Yeah, good, cool, awesome. So you had a few DevOps talks today and there's a couple tomorrow as well. Now DevOps is this term that's been thrown around by lots of innovative tech companies these days, like GitHub, like IBM Cloud, like Google, like so many others. And what DevOps is, is it's as much about the tools and techniques and platforms as it is about culture and processes. So for DevOps, there's four key areas to DevOps. Now I mentioned you have a few DevOps talks there and most of them are around the security side of it. There's also workflows and automation and continuous improvement. Now we're not gonna talk about these other three aspects of DevOps today, today we're gonna talk about the first part, which is collaboration. And the reason why I wanna talk about this is because this is an area I'm super passionate about, but also without collaboration, these other three areas of DevOps just simply don't work. So this is where we're gonna start today. It's really exciting. Now collaboration is nothing new. Yeah, people have collaborated for a very long time. We do it across our industries, we do it across cultures, we do it in many aspects of our daily lives. But what's become increasingly more important and increasingly more seen today is that collaboration within the tech field and within technology companies has become much, much more important. And the reasons for this is the way that we code today, the way that we work today, the types of things people want is much more personalized, it's more tailored, people expect a lot more. And so if we don't collaborate across an entire industry, we don't actually build really good products, services, platforms or features that people really need. So collaboration is really important. And at the forefront of all this collaboration is teamwork. Now I don't know if any of you have seen this acronym before, but it's mean team, so together everyone achieves more. You've probably heard of the other ones like, teamwork makes the dream work and all those types of things. So a team is really, really important. And teams are important, not just in the industry, but we see them across our whole areas of life. So who plays sport here? A few sports people in the room, cool. Most of the sports you play, unless you're playing tennis or something, are all team-based sports. And within those teams, you have roles that each of your team feels. Some people are better at, if it's cricket, some people are better at bowling. Other people are better at batting. Some people, what we call the utility and they're kind of like half good at everything and not really good at one specific thing. But if everyone within the team works together really well, you have something that actually works properly at the end. So if it's a sport, you've probably all seen within your own lives, even at the professional sporting level, that a mediocre team with really good teamwork and collaboration will nearly always beat the really good team that has really poor teamwork, right? And you've probably seen this in your work too. That if we work together, we're probably as a team and if we call upon the best skills of all our team members and everyone plays their roles, we usually come out with something better at the end, right? That's nothing new. And something that I found out quite recently is this is a quote from our CEO, Nat from GitHub. And he says, coding is also a team sport. So like in a team, like cricket or basketball, we all have our specific roles and positions and the skills that we're good at. Same in coding as well. We have a specific role that we want to fill or we have specific skills that if we combine and work together as a team, we come up with something really, really cool at the end. Now, Nick mentioned the hackathon queen. I've done lots of hackathons. So I like to try and build hackathons into my talks because it's cool. So who's been to a hackathon before? Oh, yeah, about half here nearly. So those people have been probably seeing this, right? The hacker, the hustler, the hipster, yeah? Yep, some people are nodding, like, yeah, yeah, yeah. So when I do hackathons, I often talk about, you know, this first stage of the hackathon where you kind of like all rock up in the room, you're like, yeah, we're here to do stuff and it's gonna be cool and then you're like, great, I don't have a team yet and this is awesome. So right, let's start the hackathon. We get people to make their teams. But before I go off and tell people, you know, off you go, make your teams and do stuff, before they do that, I always talk to them about these three key areas of a hackathon team. That if you don't have these three areas of your team, you're just not gonna achieve, you're not gonna have a holistic team. So for these three different roles and positions, we don't know what they are. So the first one's a hacker, a chicota, you're a developer, you're techie, you have your hustler, which is your kind of like business person, manager, kind of like, you know, pushes everyone along. Then you have your hipster, which is like your design person, your human experience as type person. So for hackathons, I'm like, you should always have these three roles filled in some way, shape or form. Even if you're doing a very technical hackathon and the whole idea of it is at the end that you build a product, it is still useful to have these other two teams to help you build a more rounded product. And I've seen it in hackathons where you go and you can tell the teams that are like, they're all a group of hackers, as soon as it starts, like bang, the clock goes and all sit down and they start building stuff. And I'm like, come over as my mentor, I'm like, hey guys, what you building? Like, what are we gonna do for this hackathon? They're like, oh, we don't know, we just started coding. This is great. And I was like, okay, cool, but obviously you've got to build something at all. I rock up and I'm like, so guys, you know, cool challenges this week, this is cool. What do you think you're gonna build or what kind of problem do you wanna solve? What kind of solution do you wanna come up with it? And their answer is often, I don't really care what we do, but it has to have VR in it. And I was like, why does it have to have VR in it? I don't know, we just worked on this really cool VR solution and it's gonna go into whatever we do. I'm like, okay, well, just make sure that it actually is useful, right? And then if you go to obviously a team with all just like, business-y people, they're all flattened over who's gonna be the leader and the driver of whatever they're doing. Then you go to the design team, they're sitting, making cool, pretty pictures, and you're like, cool, what are you gonna do? They're like, I don't know, we just wanna make people feel good and make everything great. And I was like, this is good. And individually, you're like, okay, I can see where all the skills are winding up, but if they all actually work together, then you have something that comes out really well at the end. You have a product that works. You have a driver and a manager who's making sure it's all working. You have a really nice design of the product, but ultimately you've actually built something that's useful. So yes, the VR stuff, if you can build something that's cool, it's cool, but stuff that's more useful is always gonna win out. The old days of hackathons were like, oh, we just build cool tech for the sake of building cool tech. Yeah, it's cool, but there's not much of a use for it. So hackathons now, the ones that build cool tech that actually have a use is gonna win out every time. So instead of having these three groups all off on their own, we want them all working together and awesome. And then we have a dream team and then some magic happens and it's all awesome. They go on to build the best product and they win the hackathon and they build a billion dollar company and they'll leave the day jobs and happy days. Yes, it does happen sometimes, but only if people work together and that's what we really want people to do. Not just in hackathons, but in your teams and across your organizations as well. And what I will say really quickly before I jump on to the next part too, is that these three roles don't necessarily have to be all the same person. So often you'll see the person, as I said before, the utility who can do a bit of everything. Like me, I kind of cover a bit of all those roles, but nothing really specific. So what you want though is you wanna make sure these roles are filled, even if they're not all by the same person, but as long as you've got them covered, you make for a really, really good team who can basically execute anything. You can solve pretty much any problem. Now, if we look at across an organization, that becomes even more important. So I've chosen four here because obviously there's not just three teams within an organization, there's a lot more. Obviously I'd fill up the entire slide if I tried to add everyone onto here. But what we really want is like, teams working across the organization. So it's not just about hackers and hipsters and hustlers working together anymore within their own team, it's about working across the whole organization. And the reason we want this to happen is so we can build really good products, really good services and really good platforms for our customers. So like I said before, like if you go into a hackathon and the people, the code is start coding, the design people start drawing, the business people start arguing. Within an organization, if everyone comes together, the marketing department can start working with IT and with sales and with management. And so instead of the business people going off in a room by themselves and talking about what they're gonna do and the biggest thing they're gonna build next and then going and giving it to the IT department and the developers and go, here's what you build and developers go, but that's just not useful. We can do so much better or, people just aren't like a left out of the process these days. So if you're working across the whole organization, the developers are into the systems and the processes and the ideas from the start. And the marketing people have a say in what's happening, the business people have a say in what's happening. Everyone working together, you get something that is a lot better at the end. And there's some examples of this. So there's one particular company and they noticed they had a big problem between their different teams. People didn't quite wanna talk to one another but also there was a disconnect in what the developers were building, what the marketing team was marketing and what the sales people was actually selling. So they went, how do we fix this? How do we get the teams to work better together? So what they did is they sent their developers out with their marketing team for a whole week and was like, right developers, you're going out with the marketing team and you're gonna shadow them and you're gonna see what they do for the whole week. And the developers are like, okay, that's kind of cool. We don't have to be on the tools all week, get out and do things. And they were there and they're watching the marketing team or the sales team seeing what they do and they're like, why do you do that? Or why do when you talk to someone, go put all their stuff in a CRI and it takes forever and then it seems like nothing comes out at the end. Marketing team like, well, that's just how it's done. That's how it's always been done. The developers are like, I can fix that, built something in a day and then, boof, their revenue and their engagement goes up. That was great. The marketer saw that was brilliant and the developers were like, yes, we built something that's actually useful. And then the next week, they flipped over. Marketing sales team went and sat down the developers while they were on the tools and were like, oh, this is how you do stuff. Like, I had no idea that this is like the skills you have and the capabilities we have. And so what this company saw happen after this little trial period is that they started collaborating and talking together much better. And from that, better products are built. And that's the whole idea of collaboration is actually getting people to build better products because at the end of the day, someone is gonna be using your product. And you want people to be using that product to use it well, to use it good and to be the best experience that they can possibly have. And you can't do that if you've only got one team working on it or one set of skills. What's really important to note too here is that part of the reason we want different teams working across the organization is for diversity. Now you've probably heard the word diversity a lot, and you know, we need more diversity in our businesses. We need more diversity in this. We need more speakers here and people doing that. Diversity isn't just about gender. It's not just about having more women speak at things or having more women in an organization or having more non-gender people within an organization. Diversity is about diversity of every aspect of what you're doing. So it's about diversity of the teams, different teams working together. It's about diversity of where the people are from, about their skill sets, their backgrounds, their beliefs, their upbringing, their age. All these different things will help give and provide the different types of experiences so you can build products that actually help the whole of civilization. Because you're not building a product just for one specific person most of the time. You're building products for a whole range of people to use and you can't build products for a whole range of people if you're not using the skills and expertise of a whole range of people. For example, if I sit 50 lawyers in a room together and these 50 lawyers are all 50-year-old males, they all went to the same school, they all grew up in the same suburb, they all live in the same suburb, they all have the same pay grades, they have the same life circumstances, they have basically everything the same. If I give them a problem, what do you think's gonna happen? Probably gonna get 50 of the same or similar solutions to that problem. But if I change some of the things, some of the aspects within that room, if I mix it up and we have men and women, we have different genders, we have different people from all different backgrounds and we give them the same problem, we're gonna come up with 50 very, very different problems because they're all drawing on their expertise. So that is what we want. So what we really want is we want these teams and organizations to work together across the entire organization to build better products, and that's what it's about. Now often in today's society, we have something sitting in the middle here to help these teams collaborate and work better together. One of those is GitHub, yes, I'm from GitHub, so we're gonna talk about GitHub a little bit, but there's a whole bunch of other things that can sit in the middle here to help teams work together and collaborate better together. Things like Slack and Zoom and all these other programs and platforms that you're probably already using with your teams. And what's really important to note is that these don't just help teams work across organizations, they help teams work across time zones, across different situations, and they help teams work across different skill sets as well. And that's what's really important is finding those platforms and those tools to help you. So we're gonna go into a little bit now of just a few of the little features that GitHub has that can help developers and non-developers work better together and help people work better together across an organization. And what I'm gonna say too before I start this is this is the way that we within GitHub work. So we've got, I think it's over 70% now of our workforce is remote. The way we work and the way we talk about how we work is the way our entire company works. Every single person within GitHub uses GitHub. Doesn't matter if they're in the finance team or legal team or the marketing team, obviously the developers use it, but we all use it to work together and to collaborate better together. So just a brief recap then of just GitHub for those who haven't seen up. These numbers are actually out of date now because I think there's over 41 million. But basically we've got a lot of developers on the platform and there's a lot of repositories, a lot of open source hosted on the platform which is really exciting. So I just wanna briefly touch on just some of the features that we have that allow people to collaborate better. I'm gonna call them all out first and then we're only gonna focus on a couple of them because we don't have time but also you know a lot of them anyway. So one of those is code review. Developers in the room, I think most of us are developers, yeah. You guys all know code review. So obviously we have code review that allows you to see different pieces of code side by side, allows you to collaborate with others much better and fix all your conflicts and things like that. We also have a lot of integrations. So if you haven't seen, we have a marketplace that people have built and contributed to and there's a whole bunch of integrations like literally hundreds of integrations for GitHub for everything from Slack to Google to Docker to like everything. So we've got that as well. It helped teams collaborate better. Team management, a lot of you are probably running teams or organizations within GitHub. So obviously you can manage the way that they work. You can choose who are your reviewers, who are your editors, who are just your viewers and all those kinds of things. So team management is really important. And obviously, you know, you can host all your code on GitHub too. So yay for that. Now the couple we're gonna focus on here for collaborating on GitHub is project management is really important and documentation. These are two things that people don't necessarily think about when we talk about GitHub. They just think, oh yeah, that's like code hosting platform. Well that's that open source thing and I'm not a developer so I'm not even gonna go there. It's like, well, hang on, we actually have these really cool things that allow developers and non-developers to work better together. And then for the final stage of the talk, we're gonna go on and talk about social coding and open source, which is really exciting. So who has seen the project management boards that we have on GitHub? Few people? Who uses all the types of things? You know, there's a whole bunch of them. You don't have to, you know, Jira, you know, we love Atlassian, especially being an Australian company. I love Atlassian, they're great. But there's a whole lot of different tools and things out there for project management. And GitHub has just one of those. So this is what a project management board looks like. You can create this in any repo and you can use it to create columns, you can create, you can add in issues there, you can assign tasks to people, you can add labels and all these other kind of things. And what I really like about the project management board is that you don't actually need to know any coding to be able to use the project management board, as we say in some of the other platforms as well. This makes it really easy for managers and non-developers to get on to the platform and see what the developers are doing. You know, here we can see, oh yeah, there's some issues that need to be tracked. There's some things that need to be tracked out and there's some fixes. So if I'm a manager and I go in, I can see where all my developers are at and working on, I can go in, I can comment on it. I can add different labels on Twitter, you know, comment on bits and pieces, something like, oh, I don't understand this, this was a non-developer, but can you guys keep me up to date on this, whatever happens to me? So there's a whole bunch of different things. And what I really like about it too is you can make it really, really simple if you want. So this one's just got a few different pull requests in there, as well as just cards. So the first one there on the backlog is literally just a tag that someone's just typed in and just left it there. And what's cool is you can see that all those little, you know, the blue markers and things, they're just links to issues. So you can add your issues onto the project board as well and your comments and your pull requests and it'll add like a little snapshot of what it looks like. So it makes it really, really easy for someone to sit back and understand what's happening with your project, which I think is really cool. And again, this is a way that all our people within GitHub work as well. You can also make your project boards really, really in depth and crazy. So these ones are all links to issues and comments and pull requests within the project. And you can see it adds a snapshot to every single one. And you can see all the labels and things there, which means I can stand back here and look at this and go, yeah, I know exactly what is happening in the project. And I think this is really, really key for collaborating and for developers and non-developers to work together. Because often what happens is developers like, yeah, yeah, we've got our tools, we've got this, we've got that, and then project managers want them to go and use another tool to report on how they're going. A, that's a waste of time. And B, why do that? Because you can all get on the same platform. Bring the project managers into your platform as well. It doesn't have to be GitHub. But whatever kind of platform you're working with as developers, get your non-developers in there as well. The other thing we have, which a lot of people don't remember or realize is we have documentation hosted within GitHub. So I was chatting with someone out in the lobby before and they're like, yeah, I love GitHub pages because I can just go in and start writing documents and GitHub. And I was like, yeah, exactly. That's what's good about it. So you know that when you build a piece of software or launch a project, there's a whole bunch of different pieces of documentation that need to go alongside that project. Everything from readme's, to help guides, to licenses, all those other kind of things. Now why have your copy team go and write something or your managers go and write something and give it to you to upload as a developer? Why can't they write it in the same platform as you? Which you can do as part of documentation. And the other really cool thing about having documentation within the platform is that your documents, your help guides, your readme's, your licenses, all those kind of things, they can receive the same kind of love and attention as your code. They're also bound by the same rules. So if you're using Teams or whatever and organization, you've probably got a bunch of rules set up for your account that says, you know, if I need to push this or send that out that these things got to be ticked off first, you don't have your documentation doing that as well. So rather than having it sit somewhere else and go, oh yeah, we've got to make sure that all the, we've got all our tick boxes and everything's working fine and then we're going to upload it into there and oh no, the copywriters have actually changed it all again. I'm going to go back in and fix it all up. You can all do it in one place now, which is really, really cool. And this is the way we work and it works so well and it means that there's a lot of transparency across an organization. And this is another problem with the way a lot of people have been working over centuries is there's not a lot of transparency within an organization on what happens in each different departments. This allows a lot of transparency. People know where everything is at and everyone's accountable for something. All right, so we're going to go into the final part of my presentation, which is social coding and open source. So obviously one of the main features of GitHub is you can show off your awesome profile. It's basically like your CV, which is pretty cool. People have created all the funky things to change your contributions and stuff to look like Pac-Man, like one guy made this 3D one. So you can, I don't know why you want to see your contributions in 3D, but it's, people are like, why did you show it? I was like, because I can. Like somebody built this because I could. This is what I love about open source as well. People just do stuff because they can. So this is really cool too. And so one of the main parts of this whole social coding aspect that has come about in the last probably five to 10 years is that people really want to show off what they're doing online. People don't just contribute to open source because it's a cool thing to do. It is a cool thing to do. And we'll get into that a little bit too. But they show it off too, because they want to show that they're actually doing cool things. You know, this is a really, really good way to build your CVR as well. So with open source, I'm assuming you guys all know what open source here is, considering triple is open source. So open source is essentially products, software, platforms, things that are all free. And the reason they're free is because people like yourselves get on and contribute to it. And what I like about open source isn't only is it free, it's free to contribute to. So if you were sitting there going, hey, this stuff sounds cool. You can literally just go and do it like that cool social coding, put your contributions in 3D thing. But some people say to me, look, Misha, I like this open source stuff. But if it's all free and it's all cool, like why would people want to do it? Why would people want to give up all their software for free? But also why would people want to work on it if they're not getting paid for it? I was like, that is a great question that I can answer all that for you. So there's a whole bunch of reasons why people want to do open source. First reason, people want to learn. People contribute to open source because it helps them learn from others, from themselves. How many people here run into a problem and you go and Google the answer? Yep, pretty much. Obviously, if you're doing more stuff like this, you know, I was on the other day doing something, I ran into a problem and I was like, oh gosh, how do I do that? Just go and Google it, you learn by doing. The other reason you learn through open source is because a lot of companies pay their developers or allow their developers to spend a percentage of their time working on open source. So not only are you learning, contributing to open source, but other people are, you know, some of the best developers in the world are as well. And by you contributing to open source, you're able to learn off of those developers as well. For example, a lot of people don't realize that Microsoft is the biggest contributor to open source in the world, which means yes, lots of people are contributing to Microsoft's open source, but a lot of Microsoft employees are contributing there too. And so if you're contributing to those projects, you're learning from Microsoft employees, which is pretty cool. The other reason why people contribute to open source is that they contribute too. So you get like, you know, nice fancy contribution charts. So you can launch new projects and so you can build your projects. Some people don't necessarily have the time, the money or the resources to launch or send something really, really cool. So one of my friends had this really cool idea for a project and he's like, well, but I've got no one to work on it, I've got no money, I've barely got any time. So he just started doing it on open source. You enlist the help of all those developers who are on open source platforms. You know, we put up the number before, was it like 40 to 41 million developers? By having your project open source, you're enlisting the help of essentially 41 million developers. So that's pretty cool. So you can imagine the kind of skills and stuff they would have to be able to contribute to your projects. To launch a project as well. If you want to launch something, it's a great way to do it on open source. Another way is to build. Some people have already got a project or something that they've been using internally and it's up to a certain point and it's pretty good, but they're like, it could be a lot better. So they go and open source it from there so they can build upon that project. And it's a really, really good way to build up and to make it available to everyone. Another reason why I contribute to open source is to join a community, just like Drupal South, right? You're all here because you want to join a community because you want to contribute, because you want to be part of the community and by joining a community, you get all those things that come along with the community. The networks, the contacts, the free food. Was it free? It was free, free food. Apparently free drinks tonight too. So all these things that come along with the community is one of the reasons why people contribute to open source. Next one is to contribute your skills. Now call it karma or call it, everything goes around in a circle, whatever you want to call it. Lots of people like to contribute their skills to open source because they feel like they've learned so much from the community, or they've learned so much from their university and they feel like they're in a privileged position and it's a way for them to contribute back to society, to developers. And I think that's really special. Finally, I want us to build a better world. Some of our world's pressing challenges and problems we face have been solved through open source. By open sourcing problems and challenges, we're able to come up with ideas and solutions. That as I mentioned before, hit a global community because you've got so many people from all over the world contributing to a particular product, you're able to build something that really, really matters to people. How many people have heard of the fact that this year was the very first time in history, we as a human race were able to produce the first image of a black hole? Did a few people know about that? Yeah. How cool is that? 26,000 people worked on that project, building virtual telescopes and contributing their time, their resources, their employees, and they were able to produce this image that furthers science and scientific advancement. Like, how cool is that? Like, no other time in history have been really able to say this. One final thing I will say is another reason why people contribute to open source is because now on GitHub, who's heard of the sponsors program? Who are people? No, so now you can actually get paid for your open source. So stuff like Patreon and there's a whole bunch of other ones where people set up their sites so people can pay money to them. You can do that directly on GitHub now. So if you have an open source project, you can apply to be in the sponsors program, which means the button that goes on your profile, people can go to your profile straightaway, click Sponsors Person, they can give you money. One of the reasons I love that so much is because lots of people like to, you know, be part of the open source community. They love to download stuff. We know that within the open source community, there's a kind of like an ethical thing that if you use open source, you kind of contribute back to that. Now, one of the slight problems with that is that not everyone can contribute their time and resources, they just don't have the time. They just don't have the time to contribute their skills. So this is another way for people to be able to contribute their money. And I believe it's still running. Yeah, for the first 12 months of the sponsors program, I believe GitHub slash Microsoft is matching dollar for dollar for every sponsor. So you can go on and it's pretty cool. So you can actually be financially supported now to do open source, which I think is amazing. So that's pretty cool. Now, one of the things I really like about open source and all these things that we've just talked about here, like why you do open source, the collaboration around open source, developers and non-developers working together, all these concepts don't just work in an open source world. They also work within enterprise and across an organization as I was saying before. And this is what we call it inner source. A few people have heard of inner source before? I think it's a few people. So inner source is essentially all the things that I've just talked about, the collaboration, working together, the systems and tools and dev ops and all that kind of thing. It's about using that not just for open source projects but using that internally for your own projects and for your own organizations. And the reason you do that is the reason I keep hammering on this entire dog is by improving the quality of your software and improving the output of it, making a better product or a better platform, better service, because if you can do that, you're gonna be way ahead of the rest of your competitors, which is great. So all these things I've talked about, developers working together with non-developers, creating more diverse ecosystems and environments to work together with, working more on open source and contributing, some of you are there going, yeah, this is cool, I like this stuff, you know? Awesome. And I've done this before and talks to him, like, yeah, I love what the person's saying about the things and the stuff and I wanna go do things. And you kind of sit there going, yeah, but where do I start? Like, it's got blank slate in front of me and I don't know what to do. I have an answer for you. First thing, again, I'm the hackathon queen, so I just get to hackathon. They're super fun. I saw probably like 50% of the people in there in the room put their hands up for a hackathon. Get to one, they are so much fun. Drag your non-developer friends along to them as well. I think there's, no, I don't think, I know that no matter what hackathon you go to or what you do, if you're a non-developer or you drag your non-developer friends along, that there is always something you can contribute, always. And that's the same for open source as well. Open source isn't just about contributing your development skills. We're always looking for, well, not we, as in the Royal We, everyone, the open source community, is always looking for more business leaders and project managers. So whatever skills you have, I can guarantee you they will help at a hackathon. If you don't want to get to a hackathon, get your company to run one. They're a really, really great way to increase that collaboration across an organization. Some of the most successful organizations around the world run hackathons regularly. REA, Car Sales, Google Ventures, you name it, they all do it. Next thing is to learn more. I don't know why that, there we go. So there's a guide online, literally opensource.guide, which shows you a whole lot of information about where to start with open source if you've never contributed before, what to do, what to look for. And then if you have done open source before, if you're a maintainer, it's got a whole bunch of things around what to do with your maintainer. Some of the best practices for open source, how to do all these other things. So it's a really, really good guide. Next one is learn more. I love learning more. And it's always a good way to continually update your skills. And one of those ways is our learning lab. In true open source fashion, our learning lab is open sourced. So there's a whole bunch of courses on there, not just built by GitHub, but built by a whole bunch of other people. And this will help you, and also your non-developer friends, to get started and to upskill with GitHub. So if you like these ideas and you want your non-developer friends to get into coding and all that kind of stuff, or maybe not coding, but helping out in projects and that, the learning labs are a really, really good way to start, or a good place to start. They will teach you everything from how to comment on an issue, to tagging someone, to adding labels, all the way through to conflict resolutions on your code, if this is what you want to learn about. A whole bunch of stuff around GitHub actions and automation, and so there's just so much on the learning lab. So it's a really good place to start if you're new, but also there's heaps of ways to upskill on there as well. And then finally, just contribute. Get out there and do stuff. There are literally hundreds of millions of open source projects by some of the biggest companies in the world. And my best advice for you is if you haven't contributed to open source and you want to, is start somewhere where you're passionate. Start somewhere where there's an area of interest. So if you're into astrophysics, why not start with NASA? If you like SWIFT development, go on there. Jump on SWIFT development and see what you want to do. Don't just do something because your friends are doing it, or because it looks like the most popular or everyone else is doing it. Do something that you're really interested in and passionate about, and you really can't go wrong. So that's pretty much it for my talk. I hope you enjoyed it. If you want to follow me, I'm like literally every social media platform known to man, Mish Manors, and I hope you enjoy the talk and thank you all for listening. Thank you, Michelle. And we do have a little open source projects called Drupal that you can also contribute to. Yup. And wow. Also, I figured out recently too that there's actually like a credit system for Drupal. So yeah, so if you're contributing to open source and the Drupal community, you can actually credit your employer or your contractor and like a whole bunch of other people. So it's really cool. We had a great hackathon, which we called a Drupal sprint yesterday and thank you for everyone that came to that. So thank you so much, Michelle. We've got a little token of appreciation for you. Oh, thank you. Michelle has taken her own time to come and talk to us today. And also thanks to our sponsor Skipper for funding her travel here. We hope you enjoyed the rest of the event. You are gonna be staying around. So by all means, go and have a chat to Michelle through the event. I also have stickers too. She's got stickers. If you wanna come find me, I'm around for the next couple of days. Now I've got a bit of a laundry list. Yes. So you're welcome. I will take a seat. Thank you all.