 So, my name is Dieter Adriaanssens. I'm an open source developer. I've been part of the PHP admin development team for a few years. And I'm working on some other projects. I will talk about my experience of committing to an open source project or open source projects for 365 days in a row. So, first of all, I'll tell something about myself. I really like statistics. So, the chart you see in the bottom is a project I'm working on now to visualize what's going on in a build process like Travis. The thing in the top is something about the different languages you commit to and sorted per language, per operating, programming language. But the thing this talk is mostly about is about the number of commits I did on GitHub. So, let's get started. Well, I returned from a holiday without taking any laptop, just relaxing, not thinking about developing or doing anything. I've done commit statistics before, so when I returned, I just wanted to do the same thing and I didn't really make a plan, I just thought I'll get started and see how far I'll get. So, just to make sure what this is all about, this means committing to, I had to make at least one commit to an open source project that's hosted on GitHub in public repos, so the private repos don't count. Any type of contribution, so ranging from both commits to, okay, I'm almost lost. And I'm doing this in my free time, so during my day job, I don't work on open source, so in the evenings and during weekends and during holidays, I'm writing software. So, if you want to do this, if you want to do a long streak and commit every day, you need a bit of a plan, you need to be able to do a commit every day. So, basically this depends on the time you have, if you have internet or not, and the kind of infrastructure. By this I mean, are you working at home? Do you have your full development sets or are you on the road and you just have your smartphone or a small laptop with no internet connectivity? So, typically, when you have a lot of time, we get a free afternoon at home. You have your PC at home, you have plenty of time, so you can work on bigger things, like implementing a new feature or trying to figure out why something doesn't work and try to fix it, or work on a bigger project, a bigger feature, try to split it in, I do some investigation, try to split it in smaller tasks that you can work on later on. I found out that if you're traveling and you spend multiple hours on a plane or on a train, you can do some stuff as well. You have plenty of time, you can't go anywhere, but usually you don't have internet. So, I've done quite a bit of refactoring during those times and it's also a great time to improve your unit tests. I just write unit tests, I don't need internet to do this. So, another typical one is a busy day, so you get home from work, you have something. Okay, let's go on. You have limited time, you have something planned for the evening, so you just want to get something quick done, like fixing some coding style, doing a translation. Doing a translation you can also do, just using your smartphone, using a web-based translations of some projects. I also kept a list of small tasks that I knew that would take much time for emergencies, like what I will get to that in a moment. I also noticed that if you take some time to fix coding style and improve code quality and write more tests that your code quality actually improves because. So, I kept going on for 162 days when I talked to a guy called Josh who pledged to do a commit every day for 365 days in a row to an open source project. His idea was to, if you do a commit every day, then it will surely advance open source, so at that time, okay, why not? Let's try it, let's see how far I can get. But until then, I had just been working on open source during, between holidays, so when I went on holiday, I didn't really stop contributing. So, then I had to think about, in the summer, I went on a holiday, so I had to plan to, so I had to, so I went on a holiday and I needed, I took my laptop just to continue my streak. So, it was a climbing trip, so during the day, I was a busy climbing rock and in the evening, we do socializing, you see it by campfire, talk to some people, have dinner. So, I had some small commits, some small tasks set up for that week. I must say it has been a close call in a few days. It was one day I was ill, another day, I almost forgot to do my commit and it was another day I had a technical problem where I couldn't figure out how to get something to work, so at some point, it was five to midnight before I made my commit for that day. So, but in the end, I succeeded. I returned from my holiday and I still had my streak going, so I experienced some difficulties. Busy day at work already mentioned, you have a hard day at work, you get home, you don't want to think about writing software, you just want to relax and do something else. So, that's, then you just have to do that one commit just to get your streak going. Sometimes you have other things planned in the evening, you go straight from work to have dinner and go watch a film or something, then you have to have something lined up as well to do that day. Sometimes you get stuck on a problem you're working on, you start working on a problem and it turns out that the API you're working with is not doing what you expect and then at some point you need to get to sleep and you still haven't committed, so you have to find something to do that day as well. Also find out that you have to commit to master branch of a project, so if you're working on a feature branch, then that commit doesn't count until it's merged into master branch, so if you show that it will get into master, it's not a big problem to merge it later on, but if you're not sure that it will happen, then you have to take that in account when you commit. Traveling can be a bit of a problem as well, I just mentioned my climbing trip. Sometimes it's hard to take your laptop or there's no connectivity and related to that is time zones. So if you're traveling, if you stay in the same time zone, there's no real problem because the day is still the day. But if you go to another time zone, you have to either switch your laptop to that time zone and then I try to remember that you will not miss the day because of the time difference or you keep your laptop in the same time zone, but then you have to remember what time of day it is at home so that you commit in time. So there was one time I was in California and we went for dinner in the evening and then at time until nine o'clock in the evening, I guess to do my commit, so I had to rush back to my hotel to do my final commit for that day. So there were some things that saved my streak. I already mentioned the easy task list. I was doing some translation for a project of a friend of mine that I could regularly do some work on and add some small issues that were easy to fix. So commit time and push time is not the same thing. So I spent some weekends in the forest in France with no internet connectivity, so I did my commits while I was there and when I got home, I pushed them. So the time I committed them counted, another time when I pushed it to the repo. Also find out the thing I did when I was in a weekend in France to do two commits just before and just after midnight they took me 20 minutes to do two commits and I covered 48 hours so I could carry on for the rest of the weekend. And then issues and pull requests counts as a contribution in GitHub. So I tried not to trust on them too much, but I think maybe one or two days of my 365 were actually just an issue that she reported. So let's talk about cheating. It's easy to cheat. So we can just create a bogus commit, open a text file, put some gibberish in it. You can even automate this. You can create a script that just creates that file for you. Even so, you can change the commit time of your commits. So I saw a guy who created a script to make commits 4,000 days in a row and just pushed it and it was there on GitHub. And he had a 2,000-day commit streak and probably spent half an hour making a script or something. So that makes you wonder about the value of a streak. You can easily cheat. You can easily fake it. So you probably ask, did I cheat? Well, maybe I didn't cheat in that way. I didn't use these techniques. I just mentioned that I sometimes used issue to pull requests or file an issue to have my commitment for that day, but I didn't go further than that. So I met some Josh who was mentioned, who started the idea of having a year-long commit streak. I've got to meet him when I was in California. And he told me that he started doing his commits every day for 66 days in a row, and then he went to Burning Man. And on day one of Burning Man, I was in the atmosphere of Burning Man. So it didn't really feel like continuing his streak while he was there. And when he got back, I didn't really want to continue. So for him, it didn't work doing a commit every day. So I talked to some other people. I read some blogs about other people who have been doing a considerable streak. And most of the people said they were relieved it was over. So most of them ended by accident. So they forgot to commit. And then the street number was at zero. So well, it happened. They didn't just, they were glad that it was over. So that started me thinking, so it feels like kind of a burden. I have to continue and do it every day and get yourself. Some days it goes easy. Other days you don't really feel like it. So it started me thinking, this is a good thing to do. So in the end, I pushed on. And I reached my 365-day commit streak. Actually, I went on until my next holiday. So I reached 452 days. So let's get to what I learned from it. So one commit leads to another. So even a small commit like fixing a small typo or doing some code quality changes, you notice something. You see that a comment is wrong or you see that some function can be refactored. So by just looking at your small changes, looking at your code, you see that things can be improved. So the next commit comes easily, actually. And doing one commit a day creates a habit. So after two or three days, the more you get to seven or eight days, then you want to get on. You want to get to 30 days. You want to get to 90 days. And at some point, you are afraid to break the streak. Just want to go on and just keep in mind, OK, if I stop today, then I have to spend two months again to get to the same level. But also, contributing to a project, you should do it because you like it. So if you just try to follow the metric and keep that number going, then you're not going to succeed. Then I notice a similar thing, for instance, in sports where you do some running. It's nice to track your progress just to see how you're improving. But if you start to live for the numbers and you always want to improve and run faster and run longer, then at some points, you will get injuries because you will just focus on the improvement and not on the joy you had for doing the activity. So it's a similar thing with writing software contributing to an open source project. You should do it because you like it and not just to get that number. So will I do it again? I guess not. But it doesn't say that I didn't. It was an interesting experience. It was interesting to see how you have to cope mentally with getting yourself committed every day. There were bad days where it was hard to find the commits to do that day. But in general, I enjoyed my projects. I made some huge progress in the things I was working on. So it was a good thing to keep doing it for a year long. Should you try it? That's up to you. But maybe one year of committing is maybe a bit too long. Maybe do it in shorter stretches. But the most important thing I find is that you should find a balance between doing the work and taking breaks. So taking breaks here is important. So I read a blog about one guy who recommended that the streaks have a github. It's not a good thing. So he worked just during the weeks. And in the weekends, he doesn't do anything. I just relax and enjoy his time with his family. So I recommend just take regular breaks because you'll enjoy writing software. And it would be a pity if you get a burnout just because you keep pushing that metric. So things I do to unwind is just going to nature. You will walk or go on holiday, climb a bit. So that's something you should do as well or do something enjoyable. So I'd like to thank the people I got some inspiration from. And that was all I have to say. So do you have questions? Would you say there have been cases where you would delay a commit or write the code but not commit it yet so that you would have your next day commit more easily? I thought about it, but I never did it. What I did do at some point was I did research before. So when I was going to write a function or implement something, I tried to figure out how to do it and then write the codes. I did write in the code on the day where I actually did a commit. But I did some preparation on the forehand on some cases. How many different projects were you contributing to? Was it one primarily end of a couple of commits to some others, or was it spread out among a bunch of projects? I think it was about five or six. So I was still doing a bit for PHP MATM at that time. I was working on the Android app and I started a new project in the same period. I was doing some translation work for another project and then there were some small projects. I did fix a small bug for or fix a type or something. Hi, do you think that the quality of the code that you write has been affected while trying to maintain a commit streak if it has improved or degraded in quality just because you're trying to maintain a streak? Well, I think it has improved because some days it was easier. I had some statistics running on code quality. So on some days where I just had little time, I went through that list of problems and I tried to fix those. So also when I was on a longer trip, for instance, going on a plane or on train for a few hours, I had time to actually improve some tests. And so if I wouldn't have done that, then I probably would never have gotten to improving the code quality. Other questions? Question. All right, so I just have a final question. What advice do you have for people starting contributing to open source, like let's say students or someone who wasn't contributing to open source at all, how do they get started? That's a good question. Well, I guess most people start, at least I did, contributing to open source by discovering a bug in software they are using. And you notice something or you like a piece of software and then you think, hey, maybe this feature would be nice or this bug, this thing bothers me and then you get into contact with the community of that project and then you find out how they work and then that's at least how I rolled into it just by liking a piece of software and wanting to contribute to make it better and then for the community, I contact the community and they will guide you on what's the best way to start contributing. How about us answer your question? OK, so time's over. Thanks again. OK.