00:00:19.840
hello all right i like to walk um no thank you it's a huge honor to be
00:00:24.880
here today i've never been to singapore before so this is my my first chance to visit
00:00:30.400
my wife and i are planning on sticking around this weekend and exploring a little bit so we would love any any
00:00:36.079
recommendations so i'm a developer at github i work on ruby javascript
00:00:41.920
and kind of whatever else needs done to to work on product features uh most recently i finished a project
00:00:48.719
kind of revamping github wikis a little bit i don't know if you've used them recently they've gotten a bit better
00:00:55.840
and then right now the project i'm working on is actually uh upgrading us from rails 2-3 to 3
00:01:02.239
which is like five years late so but we're close we're close
00:01:07.520
we'll be on we'll be on get on rails three soon and then three one three two and four before too long so
00:01:14.720
anyway that's what i've been working on um you can find me online as beekeepers
00:01:20.240
both on twitter and github i'm not a garden gnome despite what that suggests but uh if you have any
00:01:27.360
questions throughout this or want to get in touch feel feel free to tweet at me we'll probably have some time for for
00:01:32.400
questions at the end but if we don't get to them i promise i will reply on twitter
00:01:39.680
so about seven years ago my wife and i bought a house and we planted our first
00:01:46.079
vegetable garden uh it was in our backyard it was small not very ambitious we had no idea what we were doing
00:01:52.960
but we kind of wanted to experiment with it uh each year we've kind of continued to
00:01:58.719
do this and continued to expand this is actually the a picture from like the second or third year that we did it we
00:02:03.759
built some nice boxes um started kind of scaling things up and over the years
00:02:09.440
i've realized that what i like about software development what i like about the software development process is not the
00:02:16.319
engineering side i'm actually not a very good engineer but i really like the gardening side
00:02:22.400
see software really isn't like this like pre-defined prefabricated product that
00:02:27.520
goes through this like nice clean process and comes out at the end it's really more of an organic process like
00:02:32.879
you your job is to to create the right conditions for this thing to thrive and then as it grows make small adjustments
00:02:40.000
and try and shape it into something that eventually hopefully produces fruit
00:02:46.000
and ideally with that fruit then you you have seeds that you can then go on and plant in other products and use them in
00:02:51.920
other ways and so uh i've been thinking a lot about this the last year or so
00:02:58.640
um and and specifically as it relates to open source because i mean gardening alone is awesome you get you get all of
00:03:05.360
these things you get a nice fruit that you get to eat yourself but it's even better if you can share it with other people
00:03:12.239
especially if you can share the harvest so at github over the years we've
00:03:17.440
actually done quite a bit of open source and i would say if we're honest about it lately we
00:03:24.239
haven't been that good at it you know we're still on rails 2-3 which means that we can't participate in
00:03:31.040
making rails itself better we have some projects that we haven't haven't been the best caretakers of
00:03:36.480
so at the beginning of this year i kind of made it one of my personal goals this is something we need to get better at this is something i want to do better at
00:03:42.159
myself and this is something i want github to be better at so i've kind of set out on
00:03:47.680
this journey this last year and i want to talk today about some of the lessons that my love for
00:03:54.080
gardening has been teaching me about maintaining open source and so today we'll kind of walk through
00:04:00.000
the process of gardening as that relates to maintaining an open source project and kind of ultimately my goal is to
00:04:06.239
convince all of you to go out and start your own gardens to go out and release open source and learn
00:04:12.480
what this process looks like so before i do before we dive into this process i want
00:04:18.959
to talk a little bit about my experience my first open source contribution was in
00:04:24.000
2006 shortly after i had started using ruby and rails
00:04:29.919
and recently well over the years i've contributed to whatever projects gems and stuff that i
00:04:35.199
was using but i've never really been involved in a large open source project i've submitted some patches to rails
00:04:40.400
here and there but never you know been extremely involved recently
00:04:45.759
my probably most well-known project is dot n it's just a really simple thing that will
00:04:51.919
load up configuration files into the environment when your app bootstraps it's not very complicated
00:04:58.000
in the past i was the maintainer of delayed job for a long time i didn't originally write it it was written by
00:05:03.360
tobias luetke from shopify but at the point at which we went from rails one to two when two started
00:05:09.600
supporting gems he didn't really have any interest in maintaining it so i gemified it and then supported it for
00:05:14.720
several years uh after that i worked on a project that probably nobody's ever heard of called q
00:05:21.520
which is kind of an abstraction of of these database queue idea where you can swap out back ends
00:05:27.440
my first gem ever was called tinder it was a campfire api before campfire actually had an api it would just do
00:05:33.120
screen scraping my only uh non-ruby project that i've
00:05:39.600
kind of actively worked on is called rosie it's basically factory girl for javascript and then recently my kind of
00:05:46.320
pet project has been this github notifications client because i hate email and get a lot of
00:05:51.600
github notifications and i'm trying to figure out a better way to manage them so this is where i'm coming from i mean
00:05:57.520
none of these projects as you can see are huge none of these are rails you know they're not it's not ruby
00:06:03.440
these are all really small projects actually and so i would say you know if i had to
00:06:08.800
judge myself as an open source contributor i would say i'm average i'm not prolific i'm not a beginner i'm
00:06:15.039
somewhere kind of in in the middle and i say that basically to convince you that this is something that all of you
00:06:21.120
can do uh so we talked about large open source
00:06:27.199
projects i would actually argue that something like rails is actually more like farming it's not gardening
00:06:33.120
it's at a much bigger scale than that or you know certain projects
00:06:38.960
might be a little bit more like land management where you're just trying to make sure that things don't fall apart and burn down
00:06:45.039
but you don't necessarily have control over the process so specifically today i'm talking about gardening i'm talking
00:06:50.720
about these smaller projects that we all use in and out on our apps every day
00:06:58.080
so before we dive into this a little bit more i do need to give some some credit to steve klabnik he posted this great
00:07:04.160
article on how to be an open source gardener i would highly recommend you go read it uh his was his was at the
00:07:09.680
perspective though of diving into one of these really large apps um he got involved in rails started kind of
00:07:16.560
tending kind of some of the issues and and so anyway it's a great perspective i would definitely recommend
00:07:22.880
reading it but i want to clarify that this is not actually the perspective that i'm coming from i'm talking about smaller gardens than
00:07:29.599
this so before we dive into this i just kind of want to get an idea of where you're
00:07:36.319
all at show of hands how many people right now maintain an open source project like you are the maintainer or
00:07:43.280
one of them all right excellent keep your hands up how many
00:07:48.400
people have committed contributed in some form to an open source project
00:07:54.400
even more all right excellent thank you
00:07:59.599
so before you dive into any gardening project you need somewhat of a plan it doesn't have to be perfect
00:08:04.960
but a plan will at least help you kind of avoid some common mistakes and when you start that out i think the
00:08:11.039
important question to ask is why am i doing this what are my motivations i think there's some myths about open
00:08:17.360
source and what it will gain you you know some people think oh if i just put this out somebody else will write
00:08:22.560
the code for me somebody else will do the work and if you if any of you that have maintained open source i've experienced
00:08:28.560
this you know that's not usually the case most small projects hardly ever see a real contribution
00:08:35.760
but ultimately i mean our goal has to be to produce fruit right we want to make our projects better we want to
00:08:42.719
create things that other people can use we're all driven by this desire to
00:08:48.000
create things but i think there has to be something else that sustains us and that and that
00:08:54.720
is this this ultimate goal to produce a better product the second question we need to ask
00:09:00.800
ourselves when we're getting involved in open source is how much time can you dedicate to this
00:09:06.640
because it takes a lot more time than you think it should and the weird thing about it is
00:09:12.399
uh so there's large large open source projects seem to be the ones that you would expect to take up more time and
00:09:18.000
they do take a lot of time um and they're hard because so many people care about them but open smaller
00:09:23.120
projects are kind of the opposite they're hard because nobody cares about them um you're the only one and so you have to spend all of your time tending
00:09:29.519
it so that's that's the planning phase just ask yourself some simple questions
00:09:37.440
now we're ready to actually dig in and start doing some of the work when you're ready to release it there are a few things that we can do to
00:09:43.519
create the right conditions for this project to flourish and in gardening we call this cultivation you're preparing the dirt
00:09:50.240
you're fertilizing it so that the project can actually take root
00:09:57.120
so for an open source project you want to make it as easy as possible for people to contribute and use your
00:10:02.880
project any small barrier to that any small hurdle could be enough to discourage
00:10:09.680
somebody from actually contributing so let's talk about what some of those things are
00:10:14.800
the first one seems obvious or silly but pick a good name
00:10:19.839
the name of your project can actually make or break it and so what makes a good name
00:10:25.440
this is not a complete list but these are kind of the things that i've been that will run through my head as i'm
00:10:31.040
getting ready to release something first it has to be searchable if it's really generic it's hard for people to find it
00:10:37.600
it needs to be memorable so those two are kind of at odds if you want something to be searchable you need
00:10:42.720
it to be unique but you also don't want to be so unique that nobody can remember what it is
00:10:47.760
and then you need to be suggestive like what it needs to suggest somewhat of what this project actually does it can be
00:10:54.640
completely unrelated and then on the the not side it can be too boring
00:11:00.880
or again it'll be hard to find people won't care about it it can't be too weird it'll be hard it'll be hard to
00:11:05.920
remember and also not too trendy like if anyone wrote a rails plug-in back in the day there was the axe as whatever trend
00:11:13.519
and now nobody writes plugins named acts as whatever so be careful that your name will actually
00:11:19.920
last for a while so as an example of this i mentioned my project called q
00:11:26.240
i think in terms of the the quality of code it's probably one of the projects i'm most proud of
00:11:33.040
but nobody's ever heard of it nobody's ever used it because they can't find it um it's really hard to search for
00:11:38.880
and people can't even really pronounce it they're like cue you quick huh um
00:11:44.560
so when i was showing this to a friend initially uh i was trying to explain it to him and i'm like you know it's just oh my gosh
00:11:51.360
it's a better background cue that's all it is so i came up with this idea like oh i should have called it omg bbq
00:12:00.000
so i'm going to rename it i claimed that name on rubygems recently so that nobody else could steal it
00:12:06.959
but we'll get ready for the marketing push soon but i think this is a good example of a name like it's kind of fun
00:12:12.240
it's playful it's not too weird because we all know what it means at least somewhat depending on cultural barriers
00:12:18.800
but i think this is a good example the next thing we need to do is write
00:12:24.560
documentation tj talked about this a little bit ago if you want people to use your code or if you want your project to
00:12:30.560
thrive you need people to use your code and if you want them to use it they have to be able to figure out how and that's
00:12:36.320
docs so docs are not as fun they're not as sexy they're you know it's not as interesting as actually writing the
00:12:42.240
project but it's still extremely important and a little bit of documentation can go
00:12:47.519
a long way so probably the most important part is the
00:12:52.959
readme at least if you're putting your project on github this is the thing that takes center stage and so i want to talk briefly about what
00:12:59.600
makes a good readme because i think that this is probably the most important part of your documentation
00:13:05.360
so first we have a one line description this is just a project that was on the github trending page recently
00:13:11.519
so i completely picked it at random simply that it was like the second thing on there
00:13:16.560
so you have to have a quick one-line description tell people what the heck this thing does and why they should care um it should be clear it should be
00:13:23.040
concise should have some of the key words that people are looking for but not so long that they get bored
00:13:29.440
while they're reading it that's what the second line's for a little bit longer explanation um this
00:13:34.800
project chose to just do a sentence or two some of my projects i've done like a couple paragraphs to explain the
00:13:40.399
motivation behind it or why it's different than some existing thing that's out there
00:13:48.079
um after that we need to tell people how to actually install it again this depends on the project if it's a ruby gem just
00:13:54.800
say gem install the gem name or add this to your your gem file if it's something else so this is a
00:14:00.560
javascript library they say hey just include this in your in the header of your page but showing people how to install it is
00:14:07.279
an important next step we need to then tell people how to use it and this should probably be the longest
00:14:13.600
section in your readme it should kind of outline all of the the different options um
00:14:19.440
you know give an overview of of the way different ways that people can actually use the project
00:14:26.079
and then finally all the way down at the bottom you tell people how to contribute
00:14:31.199
because the goal is that you know the first time somebody comes to your project they're going to start at the top of that readme but over time they're
00:14:37.040
going to they're going to work their way down right eventually they'll install it eventually they'll use it
00:14:42.160
and the only way that your project is going to thrive then is if you can help them become a contributor
00:14:47.360
so at the bottom include that information how do i get the source code how do i run the tests um how should i submit a pull request do
00:14:54.000
you want pull requests or would you rather you know me email you a patch i don't do people still do that i don't
00:14:59.600
know maybe not but tell people how to contribute
00:15:04.959
um if you want some examples of goodreadmes i said i went to the trending page i would recommend starting
00:15:10.480
there i've found that most the projects that show up there are there because they've done this one
00:15:15.600
thing well they've documented their their code in a way that that has engaged people
00:15:21.600
so look at those examples uh next i'm not gonna spend a lot of
00:15:27.040
time on this because this is something i don't care a lot about but it is important you have to choose a license uh if you don't have a license on your
00:15:33.360
project then the assumption is that it is copyrighted by you and nobody else has permission to use it
00:15:38.720
but there's also like weird legality things there that i don't understand um but i'll basically just choose a
00:15:44.320
license um if you need help with that choosethelicense.com is a pretty helpful site that will kind of walk you through
00:15:51.680
the like couple basic ones so start there
00:15:58.160
then lastly for preparing your project you need to just simply follow
00:16:03.519
conventions of other projects if you want people to contribute then they need it's helpful if you can have them do it
00:16:09.600
in a way that they're already familiar with um so if it's a ruby app follow ruby conventions if you know have an app
00:16:16.639
directory if it's rails have a lib directory if it's a gem have your tests mirror your app um or
00:16:22.880
your lib files which seems kind of silly but then it is actually really helpful
00:16:27.920
people can easily dive in um you know have a gem file have a rake file whatever it is those conventions
00:16:34.320
are there for a reason but mostly it's easier for people to dive in but if you're going to make changes to
00:16:40.480
your project now is the time to do it because nobody has seen it yet
00:16:47.440
so the next step in tending this open source garden is we need now need to sow it
00:16:54.000
and i think that this is probably what we imagine as we imagine kind of this glorious open source life we imagine that this is the
00:17:00.560
main part of it right but this is actually the easiest part
00:17:05.679
this is simply taking everything that you've already done and just putting it out there there's not a lot of work involved in
00:17:11.280
this the only the only work required at this step is that now you have to talk about what
00:17:16.559
you just did and i know for many of us that's hard we're not very good at advertising the things that we do
00:17:22.720
but you need to you need to advertise it say hey i created this thing here's why it's important here's why it's good here's why i think you should use it
00:17:29.280
i found it helpful to blog about it so i just have blog opensoul.org so here
00:17:34.480
was my blog post about dot end when i released it and it was just a couple paragraphs as you can see here's why i
00:17:40.799
did it here's why i think it's important it doesn't have to be slimy it doesn't have to be
00:17:46.559
uh you know deceptive uh as long as it's coming out of a place that's that's genuine people really appreciate it
00:17:54.240
uh and then after you've blogged about it put it on social media i know that this seems like a silly game
00:17:59.919
of trying to like get your thing on the top of hacker news or whatever but i think it actually makes a huge difference so so tweet about it you know
00:18:07.120
some projects if they make sense have a twitter account that helps people follow it
00:18:12.720
but but talk about it so everything we've done up to this
00:18:18.000
point is really the fun and easy part we created the project uh we got it ready
00:18:23.039
uh we released it and now is when the work actually begins and this is the part that i think most
00:18:28.640
of us don't think about when we're thinking about open source everything that wants to grow needs
00:18:35.919
watered and it needs it consistently so without water plants in the garden
00:18:41.520
will go dormant an attempt to survive drought the leaves will curl up and they'll eventually die
00:18:47.600
if you don't water them so our projects are the same way we need
00:18:53.440
to consistently water them and consistency is is the important part
00:18:58.559
in gardening they recommend that you water your plants every morning in the morning before it gets too hot
00:19:04.640
this gives the plants time to draw up the water before the heat of the day
00:19:11.280
but if you do it at night there's a chance that there could be like disease anyway but i found that this is actually really helpful advice for open source
00:19:17.679
that if you try and form a habit of not maybe not every day but most mornings just wake up
00:19:23.919
check in on your project has there been any issues have there been any conversations try and keep moving the
00:19:29.280
ball forward on several of those things
00:19:37.280
part of that is then also setting a guide for what it looks like to contribute to your project and i found
00:19:42.960
it really helpful to follow your own contribution guidelines so if you tell people hey if you find a bug
00:19:49.280
open an issue for it if you want to submit a fix create a pull request do that yourself um it seems kind of
00:19:55.840
silly this is this is a pull request i made to myself on my github notifications app notice
00:20:01.440
that nobody even commented on it by the time i committed it i'll usually like open a pull request and then let it set
00:20:07.120
a day or two and then i'll merge it if there's no discussion again it feels really weird it feels
00:20:12.559
like you're talking to yourself but i think it's really helpful for people watching the project to see what it looks like to contribute
00:20:20.240
it also gives them an opportunity to jump into the conversation if they want to
00:20:25.600
and that's where you have to start trying to invite them in again like it's really hard to get
00:20:30.880
people engaged but there's often these opportunities where you can just say hey
00:20:36.640
uh i see you commented on this thing i i you know or you created this issue about
00:20:41.679
something that should should be made better would you be interested in submitting a pull request i'll do that almost on almost every
00:20:47.760
issue that's open on a project anymore i'll ask them if they'd be willing to investigate it and a lot of times they
00:20:53.600
are sometimes they're not but if i hadn't asked they wouldn't have had that opportunity to participate
00:21:03.679
we also have to always be hospitable on our projects and sometimes this gets really hard uh
00:21:09.039
but by the time you see a contribution the author has usually spent a couple hours either getting familiar with your
00:21:15.679
project or investigating the bug or the issue or figuring out how to build the new
00:21:20.799
feature and so whether their contribution is
00:21:25.919
something that you want or not you have to be hospitable to them you have to be courteous
00:21:30.960
you know some of these some of these contribute some of these contributors are extremely ambitious um but maybe their contribution doesn't
00:21:37.840
quite meet your standards so you have to tell them that you have to give them that feedback say hey i really liked
00:21:42.880
this i usually start out by by thanking them for their time and their energy say thank you for giving for working on this
00:21:50.240
and then i start to give feedback and and usually it's in the form of questions if i just tell them hey this is not good
00:21:55.919
this is not good i asked them say hey could this break in the future would maybe it makes sense to have a test for
00:22:02.000
this or what do you think about this other thing somehow engage them in a way that
00:22:07.679
brings them into the conversation even more when you're patient and courteous with
00:22:13.919
with contributors it'll eventually start to snowball they'll do that to other people that are participating in the conversation
00:22:20.159
um and they'll also do that back to you now there's there's times too where even
00:22:26.559
after this feedback cycle like things still don't quite meet your standards um and i kind of i liken this to like
00:22:33.600
our every once in a while our niece will come over and try and help us when when we're gardening um you know and she'll like start
00:22:38.960
digging something and obviously she has no idea what she's doing she's doing it horribly wrong but i still need to honor
00:22:44.480
that she's interested in that and that she's she's putting some amount of effort into it and so and the same thing with open
00:22:50.320
source you know if somebody has made their best attempt to try and contribute
00:22:55.440
sometimes sometimes you just need to merge it even though it might not be the same merge their pull request and then come back and fix it up later
00:23:05.919
and then most importantly with with this gardening metaphor is you have to give it time
00:23:11.200
um and an open source project is no different as soon as you plant the seeds in the ground it seems like nothing's happening
00:23:17.440
you'll spend weeks maybe even month or more and see no progress but as long as you
00:23:22.640
can keep doing it consistently eventually you'll start to see to see things grow
00:23:32.480
so as your as your project starts to grow there's actually countless forces that are trying to destroy it
00:23:38.480
and it's up to you to defend against them so in gardening you'll actually take in you'll cover the soil with mulch
00:23:45.039
so either wood chips or or grass or something but the idea is that you're trying to protect the plants
00:23:52.000
and the soil from these forces so it could be weather it could be weeds
00:23:58.080
it could be erosion so we have to we had to figure out how to protect our project
00:24:04.640
the first thing we need to do is only add features that you want to maintain and this is probably one of the hardest
00:24:10.720
things with maintaining a project as soon as you have somebody interested they'll submit a pull request and you're like excellent
00:24:17.360
and then you realize that it's not something that you're remotely interested in um even though they think
00:24:23.200
it's extremely important they'll you know they might kind of go back and forth with you and say oh this is what i think it should be
00:24:28.640
if it's not something that you want to maintain then you simply should not merge it
00:24:34.000
this has been a probably one of the more painful parts for me in open source is you know somebody will submit
00:24:40.640
a pull request for a mongood adapter to queue and it's like well that's great but i don't want to maintain a mongood
00:24:46.720
adapter because i don't use mongood and you don't want me to maintain a mongolian adapter
00:24:55.200
tests are extremely important in this process as people are submitting contributions you need to know that the things that
00:25:01.440
they're submitting actually work um and and so having an existing test suite will give an example of how people
00:25:08.240
um how people should contribute not only does it give you confidence but
00:25:13.279
it also gives confidence to the people submitting these things so travis ci
00:25:19.679
is incredible if you haven't used it i would recommend it on every single open source project but the great thing
00:25:25.279
is they submit they open up a new pull request the tests will run and they'll know right away and you'll know whether
00:25:31.279
their contribution is is passing or not
00:25:36.320
and now the hardest part don't feed the trolls
00:25:41.679
there's going to be people that will not be happy with your project no matter what you may be the nicest person in the
00:25:48.240
world to them and they will still be extremely upset try not to engage with them i mean say
00:25:54.640
thank you be be courteous as you would to any of your other participants but do not try and aggravate them
00:26:02.240
tj earlier was talking about the the hearts thing i tried that with one contributor that was not very happy i
00:26:08.240
kept posting hearts and eventually i got an email from him that said just stop posting hearts i don't love you i was
00:26:13.600
just like oh so i actually went back and took the hearts out and i think i replaced it with like i like you or something like
00:26:20.640
that i don't know he didn't appreciate it so i learned not to feed the trolls
00:26:30.080
as your project grows eventually though you're going to mess up some of those things we just talked about you know mulching is not enough
00:26:38.080
there's going to be weeds that are going to start to grow there's going to be mistakes that you made and so we have to prune
00:26:45.600
you have to remove features that have either
00:26:51.200
kind of gotten unwieldy gotten out of hands or things that kind of evolved into something that you don't want to
00:26:56.640
actually take care of so so remove any of those features that you don't want to maintain that slipped
00:27:02.480
in there i found it helpful to split them into separate repositories so like
00:27:09.039
the queue project that i talked about um if somebody submits an adapter that i don't want to maintain i'll just say oh
00:27:14.880
well you can publish it as your own um and just name it you know cue dash adapter name
00:27:20.559
and then other people can use it there's a nice plug-in api but i don't have to worry about maintaining it anymore
00:27:27.440
one one recent example of this i was on dot n when i when i started working on dot m
00:27:33.279
the intention the entire time was to have it be development only because in production there's better ways to set environment variables
00:27:40.399
but development it's pain in the butt you've got to like either set them on your machine and then they conflict with
00:27:45.520
other projects or figure out some other way to do it but anyway over time people like oh well
00:27:50.880
here's a capistrano support for it so that when i deploy it'll automatically copy over my config
00:27:56.240
variables people wanted multiple environments and it got to the point where it's like wait a second this isn't what the project was
00:28:01.760
originally intended for so pull request 95 on this repo
00:28:07.600
was the one that split out all of the deployment all the multiple environment stuff to a separate gem now
00:28:14.320
somebody else can maintain that and people that want that can add it but i don't have to worry about it being part of the core
00:28:22.480
so the important part with this use semantic versioning we'll first use versioning in general in
00:28:28.480
your app i'm really excited about the the ruby core changes actually kind of switching to more semantic
00:28:33.760
versioning-ish scheme but so semantic versioning is this idea where each of these the places
00:28:40.320
in this this number are significant you have the patch number which is basically bug fixes
00:28:47.919
you increment that anytime there's a bug fix and only a bug fix maybe sometimes like a minor feature but
00:28:54.320
yeah mostly bug fixes the second one is minor backward
00:29:00.080
compatible functionality so whenever you add new features to it you'll bump that and then finally the third one is any
00:29:06.640
incompatible api changes so to show what that might look like
00:29:12.480
if you wanted to remove a feature you would deprecate it in a minor version and then come back later and remove it
00:29:17.600
in a major version so the ruby code for that say here's one you know 1.x.x of our project
00:29:24.240
you just simply add a conditional inline it's like if you're using this future this feature you know print out a
00:29:29.679
warning statement um this just you know this feature will be removed in whatever next version
00:29:35.360
um and then also it's helpful if you if you include caller zero or whatever
00:29:40.399
caller line will will show the line of their code that is calling it that way they know when they see those in their
00:29:46.720
tests or in continuous integration they know where it's coming from
00:29:52.640
as you're doing this it's really helpful to keep a change log uh so here's the change log from dot n
00:29:58.320
uh and basically all it is is it's changelog.md in the repo and i just highlight major changes
00:30:05.039
that people will care about they could go i keep a link to the full change log that's actually the the list
00:30:11.360
of commits but i think it's helpful as as the maintainer to roll those up and highlight here's the features that
00:30:17.200
you'll actually care about
00:30:22.240
so then the whole point of all of this is to get a harvest
00:30:27.360
uh and that's not to mean work at harvest like tj um no i'm just all right that was lame
00:30:33.600
it's not as funny as aaron's joke i'm sorry it's not as funny as aaron um no but the whole point of this
00:30:40.320
process is to make your product better right it's the main reason we do it
00:30:46.080
there's also the like you know altruism trying to help other people make their product better
00:30:52.000
but this is this is the point of doing it at the point at which it stops producing a harvest
00:30:57.360
you need to ask yourself some questions first does it make sense for me to keep
00:31:02.399
working on this i've had a lot of projects over the years that i worked on while i was actively using them and then at some
00:31:08.240
point i stopped a delayed job was one of them i haven't used it in several years and so it didn't make sense for me to
00:31:13.519
keep working on it and so give it away when it stops being fun find somebody that does care about
00:31:19.200
it and that's willing to take it over the only caveat to that is don't do that
00:31:25.440
if your product still depends on it this is something that we've we've learned the hard way at github we've
00:31:32.000
given away several projects in the past that we thought we were done with and it turned out our product depended
00:31:37.519
on them one example is is actually the project i just got done working on was github wikis
00:31:43.360
and wikis are powered by this library called gollum which about two years ago there was some
00:31:48.399
people that were submitting some amazing contributions were really active on it and so we gave them commit access and
00:31:54.000
release access they did a bunch of great work the problem is we didn't keep up with it
00:31:59.600
um and two years later now gollum itself had evolved to a point where we can't use it anymore
00:32:06.320
and that's i mean that's good i think gollum's gotten better but we were not we did not kind of a
00:32:11.600
whole uphold our end of that bargain so be careful when you do give it away
00:32:17.679
that either the person has your interests in mind or that you keep a communication channel open with them
00:32:25.279
you also need to clearly state the project status if you don't find somebody to hand it off to then let other people know that is no
00:32:31.600
longer maintained the lesson that we learned this project on was grit grit is the
00:32:38.000
library that we use to talk to git from ruby and for i'm since the
00:32:43.200
beginning this has been to the to the outside world the thing we were using except that we've been actually working
00:32:48.640
on not using it anymore we've been working on libgit2 and some bindings to these native c libraries but we didn't
00:32:55.039
tell anybody that so recently i submitted a pull request
00:33:00.320
to grit that just updates the change log or excuse me updates to read me
00:33:06.000
i don't know if you can read that but it basically just says grid is no longer maintained github's working on moving
00:33:11.039
off of it and you know we're not we're not accepting contributions anymore and then i just went through and closed
00:33:16.799
the like 200 and some open pull requests and issues with a link to that and said hey sorry
00:33:22.399
we're not working on this anymore if somebody wanted to pick up a fork of it they definitely could
00:33:29.200
so all of these basically come down to us learning from some of our mistakes
00:33:34.320
and this is actually an extremely important part of gardening and maintaining open source i think a lot of us are afraid to get
00:33:40.399
into it because you know maybe our code's not good enough maybe we're not very good at maintaining these things
00:33:46.159
but it's all a learning process and the only way to get better at it is to actually practice it
00:33:53.039
so earlier this year i actually tweeted for the record i am terrible open source
00:33:58.320
maintainer and a couple people like hit me up on this and they're like really like i've
00:34:03.679
seen you doing a bunch of stuff that doesn't seem consistent but i think for me personally like it's it's not it's something i don't feel
00:34:09.839
like i'm good enough at and so i've been trying to to work really intentionally at it
00:34:15.040
but the best part about this is there's not like a world's best gardener there's not a world's best open source
00:34:20.800
maintainer you just have to be good enough to produce a harvest you have to be good enough to make your project fit your
00:34:27.040
needs and so i think that's kind of the redeeming factor in this that there is no
00:34:32.839
perfect so you know we just need to keep practicing we need to keep getting better at this
00:34:39.200
one favor i ask of you is if you see an abandoned github open source project
00:34:44.560
please ping me because i want to know i want to be a better caretaker of that
00:34:49.679
or explicitly say hey we're not using this anymore
00:34:54.800
thank you very much
00:35:23.520
you
