Test, test, test, one, two, three, thank you. All right, while waiting for the last few stragglers to come in, we'll go through some of the formalities. For those of you who don't know me, my name is Brendan Forster. I come from all the way over in Australia. I do some open source stuff, and I also work at GitHub. If other people were to describe what I do,

they would probably be wrong. Yeah, it's a Microsoft guy, don't worry about it. But I do product work for GitHub around the Windows side and also technical stuff, and also a bit of open source on the side. How I got involved with open source was actually, Google Code was the first one I was using for open source. Now I came over to CodePlex and then Bitbucket

and then GitHub. So in terms of all these source code hosting platforms, I've kind of gone through them all. But what was really interesting, there were two sort of projects that I was working on that gave me a lot of stories, and so that's what we're gonna cover off in this talk. First one is Code 52. In the summer, Australian summer of 2012, Andrew Tobin and Paul Jenkins,

they wrote me into doing this thing, and it sounded like a simple idea at the time. That is, let's build something every week, do an open source project, get people involved with it. But then we realized we had to do it next week and the week after that and the week after that. And while we got a lot of people involved with this stuff, we ended up being the core team and kind of still doing a lot of the logistics

and cat herding. And so we got through about four months worth of projects before we just kind of went, yep, that's enough, we gotta stop. But it was an absolutely fantastic learning experience in terms of how open source projects get put together and how to encourage people to participate. The other one that I'm involved with is something that's, GitHub's running around Octokit. So Octokit is kind of our code name

for our API libraries, and so there's a Objective-C and the Ruby libraries, and I look after one of the .net libraries. And so this is nice because I get to do something similar. I get to encourage people to participate in this project, and when they quite often tell us it's their first pull request, I go, yes, excellent, we're getting more people involved.

And there's various things like we get to play around with them and have gifts and just, yeah, encourage the community to get more involved. And the cool thing about Octokit.net is that we're up to 42 contributors already that have submitted pull requests that we've merged in, and there's a few people down here that are contributors. Thanks for coming and filling out the seats. And Octokit was also in the community recently

around strong naming. 170 comments about strong naming, that was amazing. Eventually we actually decided we were gonna use strong naming despite lots of people in the community saying, no, you shouldn't do it. Yeah, that was pretty hilarious. All right, a couple of disclaimers about this talk.

These are my opinions. Obviously there's lots of people in the open source community that have differing opinions, and that's perfectly fine. Oops, let me get the differing. Oh, it doesn't, here we go. So yeah, lots of opinions. Don't take my word as gospel truth, but ultimately I've got some stories to tell and we're gonna have some fun. And the other one is to be aware of people who are prophesizing the one true open source faith.

How Linus Torvald's baby and they work in a certain way. The projects I work on work in a very different way. There are lots of ways out there to do open source. And lots of people tell me that they don't ever have time for doing open source, like they've got families, they've got kids, you know, all that stuff. But the first tip that I'll give you is to read other people's code.

There's all these places like my employer, which have code out there over on various projects. Go read them. Yeah, I'm biased, I'm at GitHub. But one of the cool things that GitHub did recently was this thing called a showcase. And so we put out various open source projects around various categories. So if you're passionate about, for example, game programming, there's various categories around that

where you can go and explore projects. Easy ways to kind of find interesting projects to go and read. Some projects that I'm reading at the moment. Reactive Coco, that's a port of reactive extensions over to the Coco library. We have Mac team at GitHub that use that stuff. Actually, they built it out and they use that for their apps. Fake, I hope Forky is around this week

because I'd love to catch up with him. That's F sharp library for doing build scripts rather than using command files or PowerShell or all that. And K runtime. David Fowler's little baby around doing a lighter version of the CLR. I'm reading these things at the moment, kind of racking my head around all that stuff. I highly recommend that you guys do the same.

So you guys are reading code but you're not sure how to contribute. You don't need to be on the core team to deliver a lot of value to projects. I'm gonna show you some stuff that you can help out with. All right, let me tell you a little secret. I have a terrible reputation on Stack Overflow. I, yeah, that doesn't mean you shouldn't go there. I know lots of people who are.

Yo, Guru is like Mr. Skeet. But that's where the action is in terms of people asking questions. Yo, you can see on there that I have some tags that I follow and I look at. But ultimately, that's where the action is in terms of supporting projects. So if you use something and you know enough about it, drop in the Stack Overflow and answer people's questions.

Issue trackers. If you're more familiar with a project and how it works, you could cruise their issue tracker because obviously there's, once you get to a certain point, you need to reach the core team to deal with something. This is the Chromium issue tracker. I found myself in there a couple weeks ago looking at a issue with, yeah, opening links. Couldn't actually find something

so I ended up circumventing it and go straight to a contributor. Mailing lists. I don't like mailing lists at all. Who still uses mailing lists for browsing work? Anyone? One, two, three, cool. So rather than that, I like discussion forums. This is the Ember forums for basically just open-ended discussions.

I don't like mailing lists because they all use email and I don't like email either. But in particular, there's a sort of pattern that comes up with mailing lists and you'll have people who just have a lot of time to just answer things on email discussions,

answer threads in the email. Answer threads in the mailing lists and you'll see that the time that you invest in the mailing list becomes sort of just a time sink, essentially. So you have people who are super passionate about things and you have people who just don't care and ultimately they all trend towards those people who care and the people who are sort of moderates, they just kind of step back.

Whereas I like discussion forums because they're a lot easier to kind of dive into and they're a lot less intimidating for new people. Donations. We all remember OpenSSL and that lovely little vulnerability around being able to scrape memory off a machine. Yeah, that was a project that had two core contributors and ultimately everyone on the internet was using it but no one was donating to it.

I hope we've learned something from that because just recently, a few hours ago, they published a new security advisory. It's a bit more nuanced than the one that was there a couple of months ago but ultimately these things are still happening and we need to kind of improve these projects that are core to internet infrastructure and make sure that things are secure.

If you're not technical, if you've got like a graphics sort of background, design is one of the ways you can contribute to projects and even if it's something as simple as an icon. James, hello, I can see you're up there as number two on the list. An icon for a project actually is rather useful.

Oh, and there's Damien's as well on the next line. And documentation. Developers hate writing documentation. I don't like writing documentation but if you use something and you can kind of at least contribute some words to it, we'll be all the better but let's say you're a bit more hardcore than that. Steve Kladnik a couple of weeks ago

put up this blog post around being an open source gardener. He was talking about how he was working on the Rails project and he spent a whole weekend reading up on these issues. So the scenario is that he was looking at contributing to Rails. He wasn't familiar with it all so he started with the issue tracker. Inside that sort of issue tracker, he kind of read through every issue

over the course of a weekend. Didn't comment on any but just kind of got familiar with what the project was doing and then kind of took a step back and then he kind of worked through issue by issue, stuff that he could kind of close out, stuff that he could comment on and stuff that he could actually point people to other resources. And so over the course of a couple of months, I think it was after all this,

he got to the point where he was kind of doing curation on open source project. Again, you guys probably do open source projects and so you kind of know about this sort of mojo but there's definitely sort of an easy way for things to atrophy and sort of fall away and die and I've got projects which have done that as well and it sucks but yeah, you definitely need work to maintain the stuff but we're all human in the end and even me, I do need some sleep.

Other ways that other people can contribute to stuff, just share the load. So you're probably thinking, that sounds all straightforward. I'm just gonna dive in right now and so you go open up your favorite text editor and you have a mental blank. I don't know what I want to build. I know I want to do something.

You kind of just get stuck in this loop and then you flip the table and say, I don't know, I'm stuck. I don't know what stuff to work on. My next tip would be to scratch your own itch. Find something that, a problem that you've got to face and then try and solve that problem. Don't think of solving all the world's problems or building the greatest framework ever.

Start with something small. So I'll tell you about something small that I've worked on a couple of years ago. It was around testing asynchronous code. There were a couple of projects I was working on as part of the Code 52 stuff with various people and we go through this process of arguing about stuff, coming to an agreement and then basically hugging it out and then we go on to the next project

and we repeat the whole process again. I think it was about number three scenario that came up where I just kind of went and stopped, said, no, no, no, no. We've got to kind of pull the stuff out to a library to make the stuff simple. And so AssertiX was born. A friend from Microsoft had some Assert extensions already bought in, so I kind of proposed

to add the stuff around testing task-parallel library projects at the same time. I actually pulled it into an internal project a couple of months ago because I was hitting that same problem again and everything was hunky-dory. So if you have useful code that you know is lying around, think about contributing it up, publishing it up,

writing up some details around how to use it and see if you can make the world a better place. But I will warn you, if you do the stuff at work time, check your contracts because there might be stipulations around code that you've done at work or out of work and whether you can actually publish it because generally some companies will say the IP that you make at work is owned by them.

But you might be not quite so keen on publishing up your code. You might believe it's terrible code. Yes, we've all written terrible code. I have, you know, it's just the natural part of life. There's something about open source developers that kind of, they grow a thick skin, I think, and they kind of get to this point where they're just like, yes, all right, I can put the stuff out there,

you know, critics be damned. This is a screenshot from a blog post that Scott Bellware wrote around sort of adoption of technology. You have like the people who are, you know, ahead of the curve in the early adopters and then there's like this gap that sort of teams or companies need to jump to pick up a new technology. I see this and I think this is probably the good model of sort of open source participation

because we have, there's a number that someone quoted me, 20 million developers out there. At GitHub, there are six million users. So like there is obviously this big curve that's behind the scenes of people who aren't on open source, might not be aware of open source, might not be participating in open source, like there's, you know, it's not in the majority yet.

The other thing about open source is that it is intimidating, you know, putting yourself out there for all the critics to see. Some people aren't a fan of that. A couple of patterns that I've seen around sort of users, not users, contributors in open source space is the imposter syndrome, the feeling that you can't do something

because you feel like you'll be caught out as a fraud as soon as you do it. I felt this when I started at GitHub because I was actually a little anecdote. We were at a party and there was a band up there and someone told me that they were actually GitHub employees and I'm like, these awesome people I know are actually also awesome musicians, like I can't play a guitar to save myself and they were up there playing like a real band.

But of course there are some benefits to contributing to open source projects and throwing yourself out there. This is a commit where I was fighting with JGIT and someone decided to drop in on it and just say, best commit message ever. Little things like that kind of make the whole experience better, but ultimately you do have to throw yourself out there and it is intimidating.

There's nothing else that I can really suggest aside from summing up some courage and jumping in. The other sort of bias that I wanted to call out was self-selection bias. I'm someone who is male, late 20s, white, speaks English. That's kind of like the stereotypical developer that's out there. Imagine if you're not sort of in that mold.

Imagine that you're female, middle age, doesn't speak English as a primary language. Kind of fitting into that culture is a lot more harder to do. You have to kind of, again, sum up courage. But there are things that give me hope about this. The fact that there are some things

that have come up recently around sort of changing attitudes in industry and in open source projects. The one that I'll bring up was around LibUV. So back in November last year, excuse me, there was a contribution to some docs to clean up the places where they'd used a sort of a gendered pronoun.

This was actually quickly rejected and the internet noticed. The internet decided to pile on. 225 comments later I believe it's still going but the fact is that they had a lot of back and forth and internal infighting around whether this thing should be accepted and ultimately it was just some words. Why not just change it and move on? Not so long ago Django had something similar come up

I'm not gonna comment on, I actually don't care about the terminology that's there but enough people cared about that there were 700 and something comments over the space of five weeks. But they ended up taking it. They changed it and they, you don't agree? Yeah. So they took it, they changed it, they upped.

Again, this is about documentation. Not actually changing code here, they're changing docs. But then after that something interesting came up. Other pull requests came in to sort of change things in certain ways. There was even one there that, we'll come to that one in a second. Someone saw this as an opportunity to kind of push things more forward and improve more documentation around things

to make it more inclusive. There were also some hilarious ones in there. Change the project name, bring in Batman and Robin to describe things. But this is again, this is all about documentation. And I just saw this as a big exercise in bike shedding because all this effort was being spent on things that weren't moving the project forward. Yes, it was about being more inclusive but again, lots of effort was spent

and not really improving things. So we have those extreme cases of the internet piling on. Let's say you actually want to have a go at participating in a project. My advice is to kind of just lurk, essentially. Lots of things, they're all done in the public because public and open source go hand in hand.

Take time out to watch for things like personalities in a project, how these teams communicate. Do they have sort of any in-jokes? They probably do. Other things to look for is, do they have rules around how to challenge, how to turn the rules? Yeah, sorry, that probably should have been

like learn the ropes. Like contributors, how do you get started? How do you submit a patch? How do you work through things? Of course, where is this project going? Maybe it's done, maybe people just quibbling over stuff. There's things on the roadmap that you might be able to contribute to then it becomes a lot easier. But quite often there are big personalities in the open source space and if you don't feel like you can fit in, that's fine.

No, maybe try something else out, maybe start off something else yourself. Yeah. This is gonna be fun. So everyone who works in sort of open source, they will have stories like this where things have been bounced back. I'm just using an example here from Octokit. There's a task that comes up. You want to take it and work on it.

You then submit some code and you wait. You wait, you wait, you wait, you wait and then some clown rocks up and just closes it. That is not collaboration, that is just throwing things over the wall and maybe something gets thrown back in your face. So let me tell you about my first pull request.

If you've never heard of this site, it's just called firstpr.me from a colleague, Andrew Nesbitt, and I forget the other chap's name, but sorry. My first pull request was to SignalR. I was experimenting with the internals and what I wanted to do was add in AutoFact support. I went back and forth with David and in the end, he closed off the pull request.

I actually completely forgot about this until I found that site. Yeah, we moved it over to somewhere else, but yeah, my first PR on SignalR was rejected. I guess the more you do open source, the more you kind of get this feeling of you're not your code. Don't be so attached to the stuff that you're working on when someone says I don't like it, it's wrong sort of stuff.

But hopefully maintainers will kind of work through things to improve it and get it to a point where then it can be merged in or you kind of get a good reason why it's not merged in. Again, doing things like that, that's not cool, but it does happen out there. I'm gonna pick on some friends of mine. First one is Rob Connery.

You probably know him from previous NDC OSLOs. He runs a project called Biggy, which is a sort of a database, a flat file database for doing .NET development. And he had someone submit a pull request. This was around specifically adding in tests for JSON, generated data, all seemed hunky-dory, but the more I read into the actual pull request itself,

the more I kind of was a bit concerned. The tests were hosted on Dropbox. They had various sort of prioritizations for tests. There were things that there were just kind of weird. So Rob wrote up this epic reply. I'll give you a summary of it. But he said a lot of things in this reply. He was reminded of some tests being removed.

He suggested things around how to basically restructure the tests. He wanted the test to be done locally. But then he included some stuff that was kind of not really related to the pull request. He was just saying, could you open this stuff up earlier? Not really relevant to the situation. So were you there?

He also said, would you be, if you can kind of take on this feedback and update it, we can do this in a different pull request. He was expecting the guy to reply. But then he closed the pull request. So there was some sort of mixed messages in there and a lot of sort of details around what's going on. How could, let's say our friend Rob have done things better.

So for maintainers of projects, the things that you're working on, don't keep them in your head. Actually write them down somewhere so that actually other people can see what's going on. Discussions are easy to derail because it's the internet. If you can keep things focused, that helps everyone kind of stay sane. And, excuse me,

don't write novels in email threads. It's so easy to do. But try and keep things as succinct as possible. Again, I'm gonna get on to that in the next point. And for contributors in particular, be clear with what you're working on. If you've got an issue to work on, drop a comment and say, I wanna dive into this.

How do I get started? Pull requests, this is something in particular we've noticed with doing stuff at GitHub is, the sooner you can open up a pull request, the sooner you can get feedback. So even if it's partially done, open it up and let people see what's going on with your code. If you've got a big task that you're working on, break it down with some steps

to say I'm working on this area here, this area here, this, this, this, this, this, so that anyone can see how close you are to being feature complete. And Checklist is something that we use a lot in GitHub for tracking progress. Again, like a list, just kind of work through these tasks so that other people can see. Here's a good example of something I was working on recently. Basically, I had a number of tasks to do,

set up a checklist, worked through it, and was ready to go. I think I got merged in. Anyway, just kind of give people visibility on what you're working on, and on the maintainer side, give them, other people, a plan to work on so they can contribute. The other guy I'm gonna pick on is a colleague of mine, Paul Betts. He works in a project called Reactive UI,

and it got a pull request around coding style. Paul gets this a lot, because he has a certain style, and the guy was talking about, well, he was aware that the issue was a very religious argument around .NET developers, and he said, if you can close this, well, you are welcome to close this immediately, and then he goes off to talk about interfaces in the .NET framework,

which Reactive UI wasn't following, and Paul left this comment as part of the close. He basically grabbed up a bunch of GIFs, dropped them in there, and then closed it. Like, that's Paul's style. The other guy might not have enjoyed it, but hopefully Paul gave him some entertainment as well as closing it, which leads into my next point. Words are hard. So when you're in a open source sort of scenario,

most of the stuff is done over text. It's easy to lose context with text, and it's easy to assume things, and it's easy to derail discussions, particularly when people who don't have English as a first language will then translate. Mistranslations are easy to happen.

It's, yeah, everything's hard. So you can have conversations that spiral out of control until you have this sort of the famous words, take it offline. I've heard that so many times as a consultant. It's silly. But everyone has sort of a writing style, and the more I've done sort of GitHub and GitHub-related work, I've kind of got more aware of my style.

So I'm gonna give you an example of my style. This was a one-line fix for a project around the build scripts. So rather than sort of just leave no comments, I decided to explain what was going on, how I'd messed up, and throw in a GIF for good measure. Like, I was, that's kind of, people who know me will know that I will happily mock myself, and that's no different to what I was doing.

Another thing that the GitHub guys use a lot internally is emoji. It's a silly little thing, but after being there for almost a year, I can't live without emoji. We have our own little internal lingo around communications. You know, I start off the day by dropping into the chat room and sending in a wave emoji to say hi.

Like, you could say hi, but we kind of drop it in to say a picture. If you agree with something, you could do a thumbs up. We also use okay, and to say goodbye at the end of the day, peace out. We have these little lingo that we kind of just grow up. Code-related stuff, we use lipstick to kind of indicate that this change is sort of like a refactoring rather than actually changing any behavior.

Cactus is a warning to don't touch this code yet. It's not ready. And of course, fire is for deleting code because deleting code is awesome. GIFs, again, we do use a lot. This is someone who shall remain nameless. Was merging in someone's code, dropped in a GIF with a thumbs up, and yeah, Daft Punk.

But of course, words quite often will turn around. This was something that happened last Christmas. I was playing around with Script CS, and I was grumpy. I was at the point where things were just breaking, and rather than actually submit an issue, I just got on Twitter. I CC'd in all the maintainers, I gave them a screenshot,

and yeah, I was just basically grumpy as. Thankfully, this one turned out because Glenn, one of the maintainers, wanted an excuse to get back into some Script CS, so he pointed me to the issue tracker where he chatted back and forth around what should happen, and I think he'd fixed it up in about 24 hours, which is insane but not so surprising for Glenn.

This example here from Tather Motti. He was looking at a pull request that had been sitting there for a while, and someone jumped up and got angry. This was his reply. In particular, he just wanted to remind everyone in their discussion that people in open source come from all walks of life, and of course, everyone has their own,

their first open source PR, so just be constructive, be positive, work with the guy. Great way to disarm that discussion. Legal stuff. Code that, I'm just gonna use that as an example. So this is a gist from a colleague. He was writing a read-write-a-lock.

Yes, it was, in Objective C. He actually put a code header up to indicate the legal details. The gist that I put up yesterday for something else, I realized, did not have a header. If you don't put a header on a code file, the ownership of that code is actually to the guy who wrote it, so you're not allowed to use it unless you get their permission. Most developers don't really understand

the copyright stuff aside from yo, this is a license. Like, how you are allowed to use code that's out there on the internet is very, very important, and of course, everyone's probably seen this in copyright sort of software. It's just a note to say, go and read the damn license, because it's really important. So I'm gonna tell you a little anecdote. The libgit2 project, which is sort of a Microsoft

and GitHub sort of co-sponsored project, is licensed in GPLv2. There's a C-sharp wrapper on top of that, which is actually MIT licensed. Now, these two are sort of incompatible, things that are licensed under GPL. If you consume them, you sort of have to adopt the same license, but how did these people get away with using the MIT license?

Well, it's a shortcut, which I'll explain in a second, but the GPL2 was licensed under, sorry, the libgit2 project was licensed under GPL2 with a linker exception. Now, what the hell does this linker exception mean? It's these little words in the file. You can link to the compiled version of the project,

or yo, take the source code and use the license. So the libgit2 project is GPLv2, but it's also permissive for those who just want to use the bits. So yeah, get to know the license of the projects that are out there. If there's stuff you're using already and you don't know the license, just go and check. Typically, MIT, BSD, Apache licenses,

they're fairly permissive and open with what you need to work with, but just go and check, please. All right, friction. So, lots of people will happily put code out there that does something, and they will assume that everyone knows how to set it up. They know what things they need to build,

what things they need to test with. They just assume that people will figure it out for themselves. I say no, I say that's terrible. I say you should make it as easy as possible for me to hack on your stuff. So things like I consider friction are, oh, I have a certain version of Visual Studio.

Is it 2010, is it 2012, is it 2013? I don't know. So my challenge to you guys who work on stuff is to take a fresh dev environment and test out a project. Doesn't even have to be yours. Take some time to kind of see how easy it is for someone else to work on this project. Are there additional tools that are necessary? Are there config files, configuration values

that are missing? Does stuff just not work? An example of that I did recently was for XUnit. I saw that they were on GitHub. I pulled down the repo. I went to build it, and it would fail the build because the package was missing. So I basically raised an issue to say, where is this mystery package? They said, oh, it's over on this new feed.

I turned that into a NuGet config, pushed up a pull request, and actually got merged in, but it was rebased off to a different commit. That was a little thing that I could do to make it easier for people to get started with XUnit. I did something similar with AutoFac. Their docs were in this old HTML format. I turned it into Markdown so that people could just get started with it.

Little things like that kind of make everyone's life easy. Ah, passion. So as someone who has done a lot of open source projects, this guy, Zach Holman, he sent out this tweet a while ago. I kept it favorited. Open source is totally a love-hate thing.

You either, yeah, you live to see yourself die a happy guy or you just get jaded. That sucks. There should be a, ultimately, everyone should be happy. That's one of the ideals I've got. But I'm gonna tell you about a couple of projects where I've kind of just completely lost the passion on and how this thing happened and ultimately I haven't gone back to them yet but what I might do.

So the first one is Squirrel. So we had this grand idea to replace click once with our own sort of update, sort of install experience built on Wix. The, I got through to, we had a goal of 1.0 of doing all this stuff and I got through to 0.8 where we started documenting the extensibility points.

And then I hit this KB article that I needed. So we're in .NET 4 and to do .NET 4 in async await, you need a specific KB to be installed. There is no way for you to be able to install this KB without having to restart the user's machine, which is a not great experience. I wanted to kind of work around this one.

I ended up going back to the guys at Microsoft and they just said, sorry, yeah. So I was at this point where I had an installer that was not a great experience. Yes, it did most of the stuff and I just kind of lost the urge to kind of keep pushing this thing on. So back in January, I wrote up a lovely markdown file of this is the headaches that I'm dealing with, this is what I'm gonna suggest to do

and ultimately I got a lot of positive feedback around doing it. But then my priorities changed internally and so I didn't get enough time to spend on it. I do feel really sad about not coming back to it. But yeah, that's I guess how things go. The other project came out of, I was up for MVP summit and there was some guy who said, documentation in .NET projects is terrible.

So I had this burst of inspiration, thank you James, and started hacking on this little thing called Scribble. The goal for this one here is to kind of make the documentation easy to work on. Actually, I gotta show you something. It was just PowerShell scripts plugged into NuGet, you install it in your project and then you kind of generate docs inside your IDE.

What I wanted to do with this project here was on build, refresh your docs. If you had code snippets, you could pull them into the project, pull them into the documentation. But the problem was that there wasn't any hooks that were available to do this. So I was left with throwing away the PowerShell and NuGet stuff and rewriting it as a VSIX. If you've ever done VSIX, you'll know that it's not for the faint of heart.

And I got to this point where I just said, yeah, no, I'm not doing this. Some people have kind of pulled in various bits and pieces for other things, but at the moment, it's just sitting there. Someone that was asking me the last time I gave this talk, what's a good example of kind of wrapping up a project? Announcing that yes, I'm done.

Thanks for all the fish and off you go. Jeremy Miller had actually just wrapped up his development on FUBMVC at that time and I said, yeah, that's the one that I've got. The cool things that he did, well, classy things, let's call that, was that he gave enough notice. He was working on some tasks and he said, after I've done these tasks, it's gonna be 2.0 and then that's it. And so he also gave reasons about why

he believed he was, why he was giving that stuff up. And yeah, it was a rather impressive way. I've got the link to that in the slide notes. I'll publish that up later. But yeah, so you kind of just gotta be honest with yourself to say that's enough. I'm going to kind of call it there.

The, before I'd done open source work, I really hadn't thought about this distinction between done versus dead. I'm building out stuff for what I need. Other people are using this stuff for what they need. There's gonna be some sort of impasse between nine pass impedance mismatch. So you'll see discussions like this.

The contributor says, it does what I need to do. I consider it done. The other people will turn around and just say, I want to support new features, blah, blah, blah, blah. An interesting example of this is Underscore. So Underscore had some sort of changes. They wanted to sort of target performance. Someone else wanted to come in and support browser compatibility.

They got to the point where Lodash came in and basically forked the project to kind of go in a different direction. People are gonna kind of go back and forth about this stuff, but ultimately they don't have to agree. If you've got enough motivation and interest around going in a different direction, just do it. But the fact that it does, it's nice to have one source of truth for these projects, but quite often that won't be the case.

The other sort of side of this stuff is when projects just are abandoned. They can't get the maintainer to come in and look at stuff. Thankfully things like GitHub will let you kind of fork off a project super easily, and you'll quite often have projects that get abandoned.

A blog post from Felix Geisendorf came up a while ago around this thing called a poor request hack. He mentioned this radical concept of when someone submits a poor request that gets merged in, give them commit access. At the time, this was my reaction because I thought this guy's on drugs. Why would you open it up to basically be a free-for-all?

But it's a bit more nuanced than that. You've got people who are contributing stuff to your project. Why not empower them to keep doing that stuff? I've seen this. I've actually done this on a couple of projects in a second, but you have these people who are competent enough to get code in. Why not just let them do it? So one of these projects, I inherited a WTF UI application

after the original maintainer didn't want to take it over, but at the time I was doing web development, and I was just like, I have no time or passion to maintain this stuff, but there were a few people in there who were commenting on poor requests, so I fired them off an email, and I said, to thank you guys for all the hard work that you've done in my absence,

I'm giving you guys push rights for the project. I just said, I'm around if you guys want to have questions. Ping me on Skype if you've got stuff, and then I just kind of stepped back. So these three guys, Alex, Dennis, and Jan, they now run the thing. They have done a number of releases since. If you saw Hansmann's project that he just launched,

that's using maps metro. The last thing I actually contributed to that project was some nice documentation. So again, it's all coming full cycle. You were on the core, let's write some docs, that's it. Sadly, I actually get pulled into this stuff a fair bit, and I just had to tell Hansmann, the last time this came up,

to mention that these guys here work on the project, give them credit instead of me. So I'm running really early, and I hear the party's going on now. But yeah, so my ethos around this stuff is that we just need to be nicer, we need to be more constructive, we need to be more inclusive. Lots of people can do open source work. We should be doing more open source work, because it's a more interesting model.

Yeah, questions. I have Tim Tams, Australia's favorite sandwich. GitHub, not sandwich. My brain's gone, I'm sorry. Australia's favorite, biscuits. Some GitHub stickers, SuperScribe stickers as well.

Yeah, thanks for your time. Go enjoy the party.