 Hi, everyone. I'm very excited to be here. Today, I want to talk to you about how to get them to commit. And by them, I really mean developers. And by commit, I mean GitHub commits or any version control commits, essentially contributing to open source. My name is Alana. I live here. I have a quick intro here. So my name is Alana. I'm a founder of a company called Holographic, which is a digital batch board and platform for developers. I used to lead developer-tooled partnerships at GitHub Education, namely working on the GitHub Student Developer Pack, scaling it to 2 million users. Over the last couple of years, I've been a developer relation strategist. So helping companies win the hearts of their users really and improving the experience of the people who are using their tools or within those organizations. And all throughout, I am an engineer. I still code less and less these days, but I make that work. So what we'll go through today is one. What motivates organizations to do open source software? We kind of have an entire event really dedicated to this. I won't spend too much time there, but we'll go over it. Then we'll compare that to what motivates developers to write code and commit to open source. We'll go through the title of talk, which is how to make them commit, and some of the challenges that come with it. So this is probably best started with just talking about organizations. Why do they commit to open source? Why do banking platforms decide to open source part of their software, or why they also contribute to other projects that they're using, et cetera? What are their motivations? So again, you know this better than I do, but really, there are three key reasons. One is security and regulation. So the more code we have published out in the open, the more people are developing it. More people and more programs are dependent on it. The quicker bug surface, the quicker security patches are implemented, because it affects so many people. And regulation also. It's important that there is transparency in services that are especially dealing with such sensitive information and sensitive data. Secondly is customer experience. Or let's say end user experience. We want everything that we do to be snappy and quick. And that's why it's important to follow best practices, not just from FinTech software, but also from everywhere, beginning with APIs, ending with cloud native and computing. So if we can pull software from other industries, take inspiration there, make some contributions there, we can all just improve the end user and the customer experience for everybody. And thirdly, speed to market. And what I mean by speed to market really is more so developer productivity. So how quickly developers can ship those, whether it's security patches or improvements in customer experience. But to understand developer productivity or what causes it, really we can just rename it to developer experience. So ultimately, when organizations commit to open source or contribute to open source, I'm going to try and stop using the word commit. They are, whether they know it or not, improving developer experience, if done right. So developer experience, taking away a little bit, just taking a bird's eye view of everything in software development, developer experience describes how developers feel while using or working on your product, whether that be developers internally, or developers using a particular developer tool. And developers are the most productive when they use tools and not only satisfy the technical requirements, just get the job done. I'm sure that mainframe computing also in the way to get the job done. But it also fits their pace and their needs. And so what that results in is folks just really loving the product and recommending it to other people. And so more developers, more contributors get brought into a project. And so that's kind of like a never ending cycle almost that if it's started, it's really beneficial for the project and it's beneficial really for everybody. Now, why do developers come into open source? It's pretty clear why organizations do it, namely especially the first two reasons are the easiest to understand. It's security, it's compliance, it's customer experience. We want the developers to be more productive. But what actually motivates developers? Because as amazing it is to build compliant software and care about the end users, there's something a bit more to it. And this is really the key to understand what drives people to write code for other projects. So what makes the developer profession as a whole unique compared to other professions and jobs out there? Well, one thing is that they need to constantly learn new stuff. If you are a carpenter, you don't need to constantly learn about the new tools that are coming out because there aren't just coming out that many. Maybe there are, but I don't think there are as many as there are new frameworks, new open source projects, new best practices, new API specifications, new types of computing even coming out all the time. And so developers must constantly learn new programming languages, frameworks, and best practices. Back in the day, but this is not even that long ago. Like 10 years ago, you would have been fine with jQuery. Now, if you don't know at least a couple of these, that's not going to fly. You might have a job, and I'm sure it will, but you have to know what they are. I mean thinking about things like Kubernetes. In 2014, it was only open source then. Now, we've got not one event, but two Kubecons a year. Lots of developers go there. Second thing is they need to be able to prove that their work is good, their work is reliable, it's potentially better than others. So that is to be trusted at work. That is to be trusted with new jobs. That is to be trusted with promotions, et cetera. And so that's what's also pretty special about developers. And thirdly, they need to and they want to constantly be aware of new opportunities. And that's opportunities to learn that new stuff, to apply that new stuff, to build other things, for opportunities to assess their own work and kind of see where they fit, and also just to get better jobs, really. So taking in mind the organization, whether that's an organization open sourcing a project or the project themselves, we can, and so the goals of organizations and the goals essentially of developers, we can form a hypothesis that looks at something like this. If we show developers that we care about their goals, they will care about ours. If we provide them with the opportunity that the opportunities that they're seeking, really, then we can get some of their buy-in. And this can be applied to lots of things. So there's a famous quote by Billy Brandt, if I'm selling to you, I speak your language. If I'm buying, then listen to you don't reckon. For us, it looks more like than listen to you don't reckon, but not important. So how do we make developers commit? Or how do we, in a nicer way, said, how do we provide better value to developers that they see value in being an open source? One, as is pretty clear from the Billy Brandt quote, speak their language. And this has to do with messaging. Messaging and communications, what you say on your GitHub repositories, so open source repositories, what you say on any landing pages, how you present yourself in guest blog posts, how you present yourself to developers, even in job ads, really, because they can read it really well when it's not exactly for them, but only really benefits the organization. So show your developers, your contributors, what's in it for them. Developers don't always care about software that makes banking more efficient. That's a goal that's very hard to relate to. Even if banks are doing it for the community, that's another thing. I think a lot of companies, this is like, a lot of companies touch the word community or call their users community. And then it's like, yeah, we're doing better for the world. No, no. We can see right through it. But developers do care about new software or improving software if it helps them spend less time looking at clunky codes and just more time on building cool stuff and solving problems and helping them achieve the goals that we spoke about before. So just as a couple of examples, this is an API testing tool. But I just wanted to bring your attention to the tagline and the title and subtitle there, which is build APIs together over 20 million developers use Postman, et cetera, et cetera. Postman does have some open source tooling. Postman itself is not open source. But something in that language helps folks understand what's in it for them. OK, let's say if that was a tagline for an open source tool. I can also improve the lives of other developers who are like me. When it comes to writing product descriptions within GitHub Repos or elsewhere, what developers care about, what they're contributing to potentially, is less about what impact it has on the business. Every company, whether it be developer tool or project or anything, exists out there to solve the problems of another dev tool to get you to market quicker to what are some of the other buzzwords. Oh, yeah, yeah. Basically use this tool so that you can focus on building instead of dealing with that other tool. It's all the same. If you clearly outlight features, then developers can clearly see or they can estimate the impact and the pain points that they're potentially contributing to solving. This is a Goldman Sachs project. I just quite like the description that's very straight to the point. Make it simple to get developers their first results. So in the case of committing to open source software, this is making their first pull requests for their first contribution as easy as possible. Committing to open source, I keep saying committing, but really it's contributing. I'm just going to, the developers are just not going to trust me anymore, but contributing to open source is a really scary thing unless you've been involved from pretty much early on. Somehow maybe someone roped you into a hackathon or your company was open sourcing something and you were just kind of there. Yeah, I have to do this. It's not easy to just decide to get into it. So the easier you make it, the quicker folks can see the results of their work, the better. I'm using an example as a JavaScript function called alert just to illustrate the perfectness of what quick time to hello world means. The reason why alert hello world is so perfect, it's not because it's just a few characters. It's because you immediately get the result on your screen of what that function does. That's why it's so perfect. You get your first results visually immediately. So of course, getting developers involved in whatever small tasks is great. And you can do that through requesting, for example, or highlighting help required for documentation or maybe just with some, let's say, documentation website work. But there are other ways to get involved and involve developers that gets them to their first contribution quicker. One is an event called Hacktoberfest. Happens every October organized by Digital Ocean. Companies can sign up. Projects can sign up. Essentially anyone who's owning or maintaining open source projects. And then Hacktoberfest is basically this massive festival of developers just seeing what issues or tickets need to be solved. And they know they won't be judged because there's also 100,000 others doing it. So this is a really, really fun event. Another one is, I mean, there are more, but Google Summer of Code. I think it used to be for students. It's no longer just for students. But if you have an open source project, you can submit it to Google and Google and yourselves kind of handle. It's almost like an internship slash apprenticeship. So developers get help. You also get folks to contribute. Just some good programs to look at. And they have both expanded a lot in the last few years. Thirdly, I've mentioned GitHub several times. But if you have an open source project, leverage GitHub is literally for open source. Number one is housekeeping. By that I mean just general appearance of the GitHub repo. So your GitHub repo for a project is your landing page. And it helps developers assess their impact upon committing. Don't think that's very correct English. But it helps them assess what impact their contributions might have, right? It's a lot nicer or it's more compelling to contribute to something that you feel others will recognize for your contributions and lots of other developers will use, like what impact you potentially have. So that's one thing. And then the second one is leveraging the features to help developers guide themselves. So it comes with tons of issue templates, request templates. You can automatically assign reviewers. Don't want to get too much into details. There are guides how to do this online, essentially. But that just gets developers into a funnel and it creates less room for error and frustration and shows them what to do. And it's nice because it's friendly, friendly to folks to show how to do things. A project that I really like to use as an example is Backstage. It's a cloud-native project that is open sourced by Spotify. The project itself is essentially a dashboard that you can install. And you can see all of your environment, all of your applications, where they hosted what languages that they written, et cetera. So you have that single view of what you have. But the reason I like Backstage is because they have a really well-organized GitHub repo that's very friendly for contributors. So the project is clearly defined what it does. There's a screenshot. There are certain badges that show that it's active, so developers might be able to get help if they need help. And it shows that it has impact. Spotify is not really mentioned, I think, in this repo, in the website it is. But through other things, you can see that, oh, this is cool. So this is impactful. These are some of the issue templates. So issues, if you're unfamiliar with GitHub, it's kind of like ticket. Yes. And so you can have a bunch of templates that help developers make contribution. And then also on the right-hand side there, you can see a bunch of tags, as well as releases imply that there is some regularity there. So it just looks like a good project to contribute to. I appreciate that this is a pretty big one at this stage, but there's no reason why other projects should not do that. For is reward developers. And that is to never lose focus on developers' intrinsic motivations to commit. So a thank you goes a long way. Being told that your work is helping others kind of motivates you to continue. You can then very clearly see your impact, right? If project maintainers recognize you. Meaningful swag goes an even longer way. So celebrate the developers' achievements and make them feel like an insider. Maybe give them a special sticker or rewards in other ways. And thirdly, going back to those developer goals that we spoke to before, help them gain recognition, not just within your project, but also for themselves. Like, it's very, let's say, a little unrealistic to expect that folks after a single contribution or just by using your product will immediately become super fans and part of your community. But if you show that your developers, that you are part of their journey, that you are part of the communities that they're in, not the other way around, there's a higher chance of it. It's just the one with stickers. I don't think there are any ones, but from events. But with the stickers, yeah, I'll have to go back. But going back to that recognition again, so how can you recognize developers? This is also a problem that I often, or challenge, that I often face when I work with debt tool companies is that, OK, we maybe get some contributions, whether internally or externally. So how do we make sure that that continues happening? And, OK, we need to recognize them, sure, somehow. What do we do now? So things like tagging developers and release notes. Using language such as contributors instead of community makes people feel like they themselves are part of this, if that makes sense. They feel more recognized. They feel as if it's specifically them that helped the project and ultimately helped other folks and improve the developer experience for everybody. Invitations to events and conferences, whether it doesn't necessarily have to be, OK, come talk about our project to other folks. It can simply be, it would be great to meet you in person. Let's hang out. We're going to sponsor your ticket to go to places. You can always tweet and blog about them. Whether a life hack, it's not really a life hack, but something that I like to use is, when you tag developers and release notes and you also publish those release notes as a blog post or as part of a blog post and newsletter and also a tweet, while the broader audience of users might not always see it, the open rate for things like newsletters can be pretty low. But they themselves will feel really recognized and just nice, someone is thanking you for your work and things that you're important, which in turn helps them to be more confident and appeals to their goals of being able to stand out and do a good job. You can also, and I will go to this in a second, mention folks within, I mean, I said GitHub, but can also be GitLab or really any other platform, but just keeping a list of authors, so folks who contributed to the project and made it happen. And I don't mean just external contributors, but also folks within your company. This is also something to note. I just simply talk into them. I think it goes a long way, right? This is just an example of an author's file. It's a HCPI project, API, a testing tool for CLI. So everything is kind of clear. We create symbiotic relationships in organizations and users, and everyone is living in harmony and peace and we have these events every day and there are tons of people and I'm getting very distracted here, but what makes it so tough and why what I've described as the ideal scenario, but it doesn't always work immediately. Well, one is time, right, to build a culture within your organization, to change developer perceptions, especially as we're talking about fintech software, where it's a bit harder to relate how that impacts your life to go on and build applications, let's say as a side project, and create developer buy-in. So developer programs take a while to build and see first results off, which leads me to the next point. What results are we looking for? It's not only hard to measure success, is also we don't really understand what success means. Yes, it could be companies adopting the software, it could be folks speaking about the project, folks starring the project could be dependents. There are lots of different, these sort of vanity metrics and ways to measure success, but given that it takes time and it's not guaranteed and it's not easy, justifying resources to hire someone or to put more emphasis into getting your developers to contribute to other open source projects or open sourcing your own. Justifying resources is hard, especially if you have investors, let's say, who are looking for a very quick and measurable return and high growth rates. And then thirdly, it's skill, scarcity. So we're lucky enough, I think, in this room and in this conference in general, or in this forum, rather, we have folks who do have an understanding about why open source is important and developer experience, et cetera. But generally, it is quite difficult to find people to lead the projects. Normally, they need to be quite technical, but also community managers. I think this is the time where it's okay to say community manager. So yeah, that's me. Let's connect, Twitter or LinkedIn is probably best. Open to any questions? Correct. So I think in that case then the problem would be how to increase developer productivity as general developer happiness. I think, as you mentioned, the same things apply. So instead of an external-facing library having good or dedicated people who lead internal documentation, who lead onboarding processes. Onboarding, first impressions matter so much. So having, carving out time for that and then having that duty. Recognition, I mean, money is always nice. I'm just being very honest in terms of that. Cool. And yeah, internal employee reward programs. That's potentially the right way. And making sure that folks are working on things that they enjoy. Because with open source, then the thing about open source really and external contributors is you kind of pick and choose what you want to do. Internally, you don't necessarily get that. So that can be solved through either, well, I know what Google does is 20% folks can dedicate on to contributing to other open source projects, let's say, right? Like, yes, they might be in our source, but let's say 20% of the time can be spent on something else. Or have an open policy offer to switch teams, potentially. I know that's, again, the ideal case scenario, but yeah. Yeah. Sorry, I think you were first. So it depends on, I guess what you're specifically look, like what type of open source project is it? If it's something that you've just, for example, open sourced or you're considering open sourcing or just not very known, that's something that I see as quite a good opportunity for someone who doesn't necessarily have that open source experience to come in and make a name for themselves, right? So in that case, I would look for someone who's a strong developer but doesn't necessarily have open source experience, ideally someone internal, someone who takes initiative. I think that's really important because there's a lot of, even if you are a contributor, not a maintainer, there's still a decent amount of program managerant and prioritization and just some extent product. So someone who, even though is a strong engineer, has some experience with those bits as well. If the CIS, let's say, yeah, it's, I mean, just going back to my student days, quite a few folks who went to hackathons ended up being in open source and generally folks who are doing weekend projects or small sort of projects go to their blog, I think and see what types of things they write about if it's how they made a computer over the weekend, like Raspberry Pi and stuff. That's a tinker, that's someone who does it, because it's fun, interesting. Not sure that helps, but yes, you had a question. Yeah, so are organizations that allow them to commit if they're willing to, especially like big organizations? So this is all good, like organizations, maybe recognizing this depth of, are you influenced by organizations or not? This is a really great question. Well, I mean, that conversation needs to start, right? And I think, I mean, yeah, it's hard. One potential argument, and again, this is just top of my head, what I'm going to think of right now, is look at how much open source they are or you're using within your organization that you're basically not putting anything back to and really just highlight the pain points of it. I get that, yeah, we can catch up on this later. I think this is a really interesting challenge. That conversation needs to happen, it's just the angles are hard. I last one, not sure how much time I have, yeah. I mean, I'm a big believer in not forcing people what they don't want to do. I think some people are great engineers while they might not be excellent, let's see. Their focus is just not on that. So in that case, I mean, a lot of the maintainers just kind of grow into that role because it's necessary and they see what's best for the community. But I would say that generally, the same sort of framework applies. Recognize those contributions is important, especially with documentation writing. Oftentimes it's like an afterthought. It's like, oh, have you documented your code? Okay, we publish any documentation as long as it exists, someone can use it. Recognize is a very important work, assign an owner and also, yeah, titles. Like there's no, you can call folks contributors and maintainers, I mean, this is maybe a bit of a stretch, but you can have core contributors. You can create potentially other titles that makes folks feel important and their work feel important, even if it is not always fun. I think we're out of time. Don't wanna take up anymore, but yeah. Thank you.