I better not touch anything anymore.
Okay, nine minutes off.
Okay, cool.
Hi.
Technical stuff.
Right.
Let's start this.
I am Daniel.
I work on curl all day.
I work for Wolfers & Sells.
I do curl stuff all day.
I am going to talk a lot about curl.
I always talk a lot about curl, but today as well.
I don't think I am going to present a lot of new things here.
You are going to hear me reproduce and repeat the things you already know.
But cliches are cliches for a reason.
I am going to just let you know that some of them are actually true.
At least from my point of view.
I work on curl since a long time.
It runs in a few things these days.
You can actually probably not walk very far without using curl knowingly or not.
It is in a lot of different devices, things, services.
Since a few years back on more than one planet as well.
Right?
A favorite slide of mine.
Anita, squeeze it in.
I am sorry.
A few years ago I also got this gold medal from the Swedish king here for my work on curl.
And actually...
But not a single gold medal since then.
It is kind of a disappointment.
But anyway, these days we estimate there is roughly 20 billion installations of curl.
Quite a few.
We don't actually know that it is 20 billion.
It is roughly open source, we don't know.
But definitely there cannot be that many other open source programs in general.
Software anywhere that runs in many more instances.
I am pretty sure.
Pretty decent thing, I think.
But you know, everything really didn't start out like that.
It has been taking quite a while.
Because in my project, our project Curl stuff...
We of course started somewhere.
And it was a long and sort of an effort.
And a long journey from something that was really not very good until what it is today.
Which could possibly be good.
So in November 1996, it's a long time ago, I turned 26.
Fun.
So I started with a little project.
It was more like that.
Very silly toy.
160 lines of code.
Just a few screen folds.
And what do you do with that?
You start with playing with it, it makes it something.
You start fiddling with it.
And you know, start small.
Do what you want to do.
Give it a lot of time and have fun.
That's how you start an open source project.
You have a niche, you start scratching.
And as long as it is fun, why not work on it?
And in my case, I worked on it for about two years.
I actually recalled it Curl then in 1998.
So it started with another name.
But that's a long story.
Anyway, two years later, December 1998, what an awesome success.
300 downloads of my software.
I have this screenshot from the website that I had back then.
Because I think it's a cool reminder that actually getting 300 downloads of your software is pretty cool.
That's way more than all your friends.
All those who just did it because they know you.
Actually started to reach out.
And that's cool.
It is cool with 300 downloads, even compared to 20 billion today.
And I also want to emphasize that this was two years later, right?
Two years later, 300 downloads.
Yay, a good one somewhere.
I mean, in 20 years, we could have 3000.
So yeah, keep working at it.
And finding your goal or you find a project to work on, of course, it's a good thing, right?
It's fun and work on it.
And maybe, sure, you want to make it easy for others to help.
But you can be sure that, I mean, the world is drowning in open source projects and good ideas, right?
It's not a problem to find good ideas.
It's not a problem to find open source projects.
But how do you actually get anyone else interested in your little project?
Because you think it's fun and interesting and serves a purpose.
Probably not.
Probably you're just going to have to realize that it's you and your project for a while until it's proven to be something.
So as long as it's fun, why not keep at it, right?
And spend the time because it's not going to be an immediate success.
Very few things are an immediate success.
So yeah, spend time on it.
People often ask me what I've done in Curl mostly.
But I think what I'm mostly done on Curl is spend time, right?
1996, I started this.
And also learn to use the time.
I told you, I was 26 years when I started this.
I didn't have any kids.
I've had kids since then and they have grown up pretty big since then too.
And all of that, we're all having lives, families, other things than just open source, right?
But how do you actually get time to spend on your projects?
In many cases, you maybe need to do a little less of something else or a little bit less sleep or whatever.
In my case, I sort of, yeah, maybe if you really want to spend time,
as I say, you need to spend time on your project to get somewhere,
maybe you have to do a little bit less of something else, right?
And people actually sometimes don't believe me when I say that I never ever play computer games, right?
That's just, that's an easy thing to rip out of your life and save hours
and spend that on your open source project instead.
I mean, you can cut down on sleep as well.
And I do that to Firmum, but that has its downsides as well.
Just accept the fact that for long periods of time, you might just be the only person, right?
You, of course, you make it easy for anyone to contribute and you know,
load the bars and accept pull requests and everything, but, you know,
there are many open source projects out there and we're all competing with the same developers, right?
And all those developers, they also play computer games.
They watch TV, they have families, they have other priorities in life before your open source project.
But I can spend time on my project. I can control at least to some degree what I spend time on.
So sure, just accept the fact that, yeah, yeah, yeah, I make pull requests in my own project, right?
I put them up there, someone can comment on them, someone might review them, but if they don't,
I go ahead and much and continue with the next one.
Because in the end, it doesn't really matter. Looking back at your project,
you don't care if I started my project 10 years ago, 15 years ago, or two years ago,
as long as the project is good, it's there, it fulfills the purpose.
So in a way, time doesn't really matter in the end.
And of course, reaching somewhere, accomplishing something with your project,
there is really no silver bullet here. There is just engineering.
And there's just open source stuff that we all know how to do. We've all been doing for a long time.
There is just hard work and keeping at it. And of course, having fun.
Because if you're not having fun when doing it, you probably won't endure.
So in the code project, right, it started in 1996.
Number of lines of code is basically zero.
So I actually started a project with someone else's code, so I didn't write those first 160 lines of code.
And then I became a maintainer a few months later. And then we started the journeys.
And then we, so now we're at 160k something.
And yes, a fascinating linear growth too. Kind of unbelievable.
So yeah, I'm just saying that keeping at it, things might develop.
And making sure that others can contribute is of course, crucially important.
And that's why it's open source. We want to enable others to contribute,
even if in many times maybe they don't, but there's still that opportunity, right, and availability.
And if you're doing things right and you happen to be accepted by others, maybe someone will contribute.
And now everyone is looking at that bump in 2005 and thinks, what happened?
And it's quite boring. I actually just went back and sort of filled in names that I have missed out from the list before.
So I just went back, so it's actually not supposed to be there.
But it's my script count number of names in the list.
So over time you might get a lot of help if you're successful enough.
But success is obviously not given, right? There are a lot of open source projects.
I mean, and they're adding every day, right? So there are hundreds of thousands.
Just look at GitHub or whatever. We're drowning in open source projects.
And yeah, it's certainly not a guarantee that whatever we do is a success and going to be popular or anything.
But if you don't give it enough time, if you don't spend your efforts and really make sure,
I get a lot of questions or people say, yeah, yeah, I spend a lot of time on my 47 projects.
I did them for several months and nobody used it.
So sure, if you don't spend enough time, if you don't polish it enough,
maybe it doesn't stick out among all the others, right?
So maybe you actually have to spend more time to get somewhere.
And it needs to be fun. But whatever you do and whatever anyone does,
there will be times when you're sort of, when you just run into something that wasn't supposed to happen,
like a security problems or whatever. And it's bound to happen to anyone who's doing software,
maybe more to some than less to others. But still, everyone is doing mistakes.
It doesn't matter how long we're doing this or how much we have done it.
As long as we keep developing, we keep changing things.
There will be mistakes and mistakes will lead to security problems every once in a while.
In Curl, it looks like this. The green ones are bars.
When we fix security problems, the red ones are when we introduce them because I tracked them down.
So of course, we introduced them before we fixed them.
But anyway, I'm just meaning that, yeah, we work really hard, of course,
to make sure that we don't introduce bugs, we don't introduce security problems,
but can be sure that they will creep in anyway because it's tough.
And you all know that, right?
Nothing new here.
But what do you do? You just own your mistakes because they are going to happen
and try to learn from them, which I think is really, really hard, right?
Because every time you get a security problem, it feels like,
this is a one-off, we should never have done this stupid thing.
But try to learn from it, adapt, move on, add more tests,
and make sure that we at least don't reproduce the exact same problem again in the future.
And yeah, I've done that still several times actually, it's kind of stupid.
Yeah. And keep having fun because if it's not fun, it's not going to,
you're not going to spend all that time on it.
And no one else is going to do it either.
And of course, everyone makes mistakes.
And it's really a matter of how you handle the mistakes.
It's not sort of the amount of mistakes or how critical they are,
but how you take care of them, how you take care of the people who actually made the mistakes.
In my case, it's easy to take care of the people because almost all of them were my mistakes.
And there's no denying that it's sort of soul-crushing
when you have your software in 20 billion installations
and you have one of these things that you know can end up really, really bad for the users.
Yes, that can make it a little bit harder to go to sleep at night.
But yeah, again, we all do mistakes.
We try to learn from them and move on, right?
And in our case, in pretty much everyone's case, we just have to do what we can do, right?
Engineering, we write readable code.
You should be able to understand the code in any language.
Whenever you read code, it should be understandable.
If you can't understand the code, it's the wrong code, right?
And you document everything clearly a lot.
And another thing with working stuff, or working stuff for a long time,
is that you have a long time to write the documentation as well, ideally, right?
And a lot of tests too, because the more time, the more tests.
And you analyze your code, of course, you threw every tool at it
and make sure that the tools, they don't complain on your code.
And then when you have sort of fulfilled all these steps,
yeah, you know, it's pretty decent and you can throw fuzzing at it.
And in our case, I also like to offer bug bounty as well,
because I'm fortunate enough to have someone who pays for it.
So we offer a lot of money to people who can point out the security problems.
And yes, then you get a lot of bogus crap as well, sort of, yeah, there's a security problem.
But still, also get a lot of quality people spending a lot of time and effort
actually trying to find security flaws.
So in my experience, this works really well.
It's a pretty cheap way to get a lot of help to find your most stupid mistakes.
But, okay, there might be other people involved in open source sometimes.
You're not alone all the time.
And really, over time, you learn that it's code is easy, right?
Code is easy, you can just debug it, try it again, write a new algorithm,
but the people, they are never easy.
People are sort of what the challenges are.
And the longer you work in an open source project, the more you maintain,
you know that the challenges, what you need to sort of,
what you face on a day-to-day basis is the problems with communicating
and talking to people from different areas of life, cultures, languages and everything.
And you can be sure that they are going to be less-to-friendly at times.
So over time, we do less and less coding and more and more interfacing with humans
and other things as a maintainer of some stuff, right?
And, right, so negative feedback is sort of the default.
It's a little bit depressing, but you know, as long as things work, sure,
20 billion installations, no one says a single word, sort of, yeah, it works, cool.
And someone finds a little bug somewhere and you can be sure that that is what you are told about,
especially if it appears stupid or silly or something, because then someone is very upset
that surely it should have worked since a long time ago.
You've been working on this for so much.
So that is, of course, and I know you all know this, that's the default.
You basically never hear when things are good, because that's the default.
Everyone assumes everything is good all the time.
When something is bad, you get told about it.
So people often ask me what the difference is in curl back in the days with 2,000 lines of code
with 300 users compared today with 20 billion installations.
There's really no difference, because in the little development community, people raise their bugs,
they complain, they have problems.
All the ones that are successful, they shut up, they are somewhere else.
So it doesn't really look different today.
And a lot of lessons in what you do when you realize over time that contributors rarely stick around.
In curl, I have lowered the bars and the friction for new contributors, I think, a lot.
So we get a lot of contributors even fixing a spelling error or typos in a comment somewhere.
People contribute that.
And I think any contribution is a good contribution.
It doesn't really matter if you fix a typo that makes it hard to read.
Yes, it's an improvement.
So I accept it, but do the contributors stick around?
Out of all, I mean, today we have, I think, 1,240 authors who have written code commits in curl.
That's an amazing number of people.
Over 65% of them did it once and never again.
So, and I don't think I'm unique in that, and I don't think it's special.
I think it's more like that's how people work, right?
They show up, they find a problem, they submit it, and they move on to something else.
Because it's not their primary interest in helping my project, they just found a problem and fixed it and moved on.
And sure, it's okay for them, it's okay for me too, but just the realization that most people who show up,
they will show up there a few times maybe if you're lucky and then never again.
And maybe every once in a while, of course, you get a new contributor who will actually stick around for a long time and contribute a lot.
And you will be happy for those.
And of course, I mean, there actually is the reverse too, right?
There are a lot of newcomers.
And I've never heard of, you never saw this person before in your life, and they show up suddenly one day with an amazing patch showing that they understand everything.
And you can sort of be amazed that someone just shows up on your doorstep one day and have a perfect understanding of your architecture and design style and code style and everything.
So suddenly, open source is open and ready for surprises in every direction.
And that's part of the fun, right?
Less fun is perhaps that sometimes when being a little bit public about things, things can go in the other direction.
So I actually never really...
So this email from, well, soon three years ago, was actually the first one that sort of hit me.
Hit me like this.
Yeah, so my email address is in the current license.
And the current license then appear in a lot of products.
And this person quite clearly had been attacked in some way and saw some traces of curl in some leftovers somewhere.
And that was obviously my fault.
He had lost his family's life and job and everything.
Completely confused person, but it was all my fault.
That was tough.
But, okay, open source, this fun thing with open source, open source, the term was coined in 1998, right?
Exactly the same.
Actually the month before I started renamed it to curl.
So it's sort of open source and curl.
And it's been hand in hand going for a while and still just 25 years, right?
Before we did open source before we called it open source too, right?
Because we still worked exactly the same way.
We just didn't use the term then because then mostly we talked about free software, but it was a little bit more confusion than what it actually was.
But anyway, so today is much easier to do open source because everyone knows about open source.
If you approach a developer today working in any field, people actually know what open source is.
Back in 1998 or 96, no one knew about open source in general.
It was just a niche click of weirdos.
And today everyone is using open source, right?
There's not a single project, single user, single developer anyway who doesn't use open source at least to some extent willingly or not.
It's just going to be there.
And we're all going to work with open source in ways that we suddenly did not 25 years ago.
And we all, I mean, there's so, so many more contributors to open source today than before, right?
There are literally millions and millions of possible contributors today.
Back in 1998, there were not millions and millions of contributors.
In 1998, the total internet population was, I think, estimated to like 40 million.
That's basically the amount of open source developers today, right?
And of course, we're many, many more maintainers of open source today than we ever were before.
So there's also a lot of equals among us, right?
We all know, I can talk to you like today, we who maintain open source and you are all a lot of open source maintainers.
I don't have to even pretend.
So there's a lot of good things.
So it's of course also much easier and much better place to do open source today than ever before.
And I think it's going to be much easier and better going forward as well because all of this is just going to improve.
We're just going to do more open source and it's way, way easier to do open source today too, thanks to infrastructure, tooling, funding, whatever.
But I think we're into in for a bright future.
But anyway, I've done this and worked on a single project for so long and people ask me then, don't you ever get bored?
The same project for 27, 28 years, yes.
And of course, I get bored.
Everyone gets bored every once in a while, right?
Lack of motivation.
How fun is it to work on the same thing all the time?
Of course, the motivation comes and goes.
That goes for everyone.
And that's just natural part of life, right?
Whatever you do, there will be periods in your life when you don't feel the same sort of, yes, it's going to be great to work on this documentation today again.
Sometimes you just have to, you know, do something else, spend more time with your family.
In my case, I like to sort of move around, do something silly and some less important part of the code or do a slight less curl for a while.
I've just come to realize that lack of motivation is just a natural thing.
It's just sort of an endless cycle.
Sometimes you come in and then come back and it doesn't really matter as long as you sort of let it play out and maintain your overload.
One of these things is very commonly brought up, right?
If you're being that single person and you feel that a lot of users are depending on your work, maybe you sometimes work a little more than you should.
And I think this is a real problem and it's a real, it can affect us for real.
But it is important to separate you from your project, of course.
I'm not sure I manage that always, but I do try.
And there's a little this of, you know, if your code run in a lot of places, can you really ever be sure when you release a version that is not going to sort of bring down half the internet?
I don't know.
I think you just come to, you have to deal with it.
In my case, I think I'm actually pretty good with this because I feel that we have enough tests, enough eyeballs, enough people involved that crossing my fingers.
It might not happen too often at least.
So I think it works really well.
That's from my case at least.
But I want to emphasize and I think this is true for many people that the thing about imposter syndrome, it doesn't really ever go away.
It doesn't matter if you have those 20 billion installations, you can still experience periods of that.
Did I, did I, do I even know this sort of who am I to tell them how things work?
I mean, come on, this protocol doesn't actually work like this.
But what one of my skills, I think when it comes to doing open source is just make sure to use the time slots you get.
I have that a lot, you know, you have a family, you have a life, you have friends, but sometimes you have 20 minutes for yourself.
Can you spend those 20 minutes on your open source project?
I've become very good at it, which makes me very good at, you know, if I get 20 minutes here and 20 minutes there, that's actually 40 minutes.
And I'm not complaining about, yeah, I need an hour to get prepared first because then I would never do anything at all.
And I don't split my attention between all, a lot of sort of many other tiny things.
Sure, I do a lot of other projects as well, but I give them much less attention.
And again, time might feel important sometimes, but it really doesn't.
In most cases, it doesn't matter if you're done today or tomorrow or next week or the week after that.
Who cares, right?
Sure, it's not in this release, you're going to do another release soon again anyway.
And down the line, it didn't matter if you were done last week or next week.
So, let it take some more time.
And of course, I'm a true believer in release early, release often, so that everyone has a chance to get your latest code as soon as possible,
because it just makes maintaining and everything easier and contributors have a much easier time to actually work on your latest code better.
Yeah, so reduce contributor fiction to get people to help out better and have fun.
Of course, we need to just remember that we're all different.
I can stand here and say how I work, but I'm sure that you all have sort of objections and say, yeah, it doesn't work for me.
It doesn't work for my case because I mean, spare time, as I'm talking about spare time working on open source,
you can of course, in my case, I work on open source work hours and spare time hours, that sort of maximize.
But working on anything, spare time is of course a luxury, right?
If you're working on something on your spare time, maybe someone else in your family is doing, you know, the laundry or cooking or taking care of the kids or whatever.
So of course, that's a luxury. If you have that position, it's a luxury. I don't deny that.
So in many cases, you don't have that luxury. And of course, then it's much harder.
And there's of course an unequal privilege here, right?
If you're rich enough to do this, you can do this.
If you have to work two works and take care of the rest of your extended family, maybe you can't do this.
Yeah, just have to be aware that of course it's a luxury. We're all different. We're all unique.
And of course, what is success? I consider 300 downloads a success in 1998.
We all have a different way to measure success, right?
So we don't have to have 20 billion installations.
It's fine if all your friends are happy with your tool and you can just have fun. That's also success.
In my case, I have mentioned already my email address in the Curl license.
This gives me an excellent opportunity to learn about people's agonists in life.
Like if they don't know how to install their GPS in their car, they email me and ask me.
And you can imagine the amount of anger in this user.
He couldn't install the GPS. He's been scrolling through that open source license screen in his car.
Found an email. I'm going to email this person.
So I get a lot of car questions.
So then you learn, yeah, Sean, so my email is apparently in a lot of cars and people have problems with cars.
So I have no idea.
But not only cars, actually.
So I can learn about other things too.
And usually my way, this is the best way I have to actually learn about where people are using Curl.
So wow.
So I have to Google.
Often I don't even understand the question. I have to Google it. What are you talking about?
Oh, great. Are they using Curl too?
It's confusing.
I sort of stopped replying to them because...
You know, the first... She asked me when I started.
You want to help out? You want to be friendly? Someone ask you questions?
Obviously completely lost.
No, sir. This is how it works. I just wrote a little component.
No, no, no, no. That's not how it works. Just ask your friends and help me fix this car now.
So I have this example. This is a great one. It's a little bit convoluted, but I'll explain.
I got an email from a woman. She said her Instagram account was hacked.
So what are you asking me about that?
Sad for you. Okay.
But she showed me the proof that I'm involved.
Instagram? My name.
Now I should just head over and talk to the guys and tell them to help her with her account that had been hacked.
And I told her, cool. They're using Curl. That's in my code, right?
And try to explain the concept of open source. I never talked to these persons.
I didn't know the use, Carl. For me, it was like a revelation.
Cool. Instagram, right? That's like a billion installs suddenly.
She didn't really see it the same way.
Now, she emailed me back. She found my name again in her phone.
Exhibit two.
But it cannot be a coincidence.
Your name cannot be twice in my phone.
For any good reason, right?
So she threatened to contact them and tell me that I'm an Instagram and Spotify hacking.
I don't know if she did actually.
So maybe they don't know this yet.
No, I'm exposing myself.
So when I work on this stuff, I just, what I'm trying to say here is I'm not special.
I didn't do anything genius like I've just been working on this a long time.
I just had an idea. I think it's fun. So this is what I do.
And I think this is sort of the best you can do.
And I wanted a tool to do the internet transfer.
It does look a little bit more these days than it did from the beginning.
And I endured. I kept going at it because I didn't know anything else and didn't know better.
I think it's fun. And keep polishing.
If you spend a lot of time on something, it can actually become pretty good.
And make it possible for others to contribute if they want to.
And you can just hope and wish that they will contribute.
In my case, they did to a pretty hard degree.
And this is really the most fun I can imagine.
Yes, I'm living the dream. I work on my spare time project full time and getting paid for it.
What else can you ask?
So, is that easy? I think you can do it too.
And pretty much that's sort of what I wanted to tell you.
I've written about these things a little bit before in this book-like thing
if you wanted to read more about my thoughts on this topic.
So, thank you. I'm done.
APPLAUSE
I think we have a few minutes for questions.
If you have a question, raise your arm and someone will run with it.
There's a question.
The mic will come flying.
Hi, thanks for the talk.
I have a question regarding...
You mentioned that you have lots of contributors nowadays.
And how do you deal with their PRs, basically?
I was wondering two questions.
One is how nitpicky you are and how you...
Basically, based on your experience, how nitpicky can you be
without discouraging people from contributing?
Like being overly pedantic on comments and stuff like that?
I'm having a little bit of a hard time to hear your question.
So, it's regarding how nitpicky you are in your PR reviews.
So, how pedantic you can be
not to discourage people from contributing to such an important piece of software?
So, do you tend to just let things through or are you very strict?
And you still get lots of contributors, even though you're strict in your reviews.
Because I guess when you get a diverse set of contributors,
it can happen that lots of people have different coding styles
and different levels of detail that they go into, code comments and stuff.
I don't think I have any sort of general rule there.
I try to...
Sometimes, I think there are contributors who are clearly,
maybe newcomers struggling with the language or the culture or everything.
And of course, I try to be a little bit more welcoming,
maybe more forgiving and helping out.
But it depends also a little bit about load and everything.
Usually people, no matter culture, language, anything,
people understand code and following code styles
and making sure the test case works and everything like that.
So, usually I don't have to consider that to any greater amount.
Okay, that's interesting.
Most people are developers. They understand this from the beginning.
The other bit of question was regarding... similar, but regarding documentation.
So, have you found that...
Documentation is roughly the same.
Documentation in the code comments.
So, if you've seen that being over-documented,
has that helped you or are you not doing it?
Because when you get such a...
Over-documented, that's a rare thing.
Well, over already means it's too much.
But when you know... you could go overboard and you could...
You can, but in my experience that is very rare and sure.
I mean, we can have a discussion.
Sure, you mentioned this as a comment,
but then below the code is exactly the same thing.
Assign A to 2.
No, yeah, of course.
Maybe you don't have to say that in a comment,
and then we just had a discussion.
So, of course.
But I think that's very rare, actually.
Usually it's in the other direction.
Maybe you could explain a little comment here why this is happening,
and not just have a huge blob of code.
Right, right.
I guess what I'm referring to is when you have such a long story in your software,
and you want to leave traces of some design choices
and why some things were implemented some way rather than the other,
because other people, especially contributors who are one-time contributors,
are not going to have enough context.
So, I'm just asking regarding your style.
Do you try to leave traces of context like this was done this way because of this reason?
That reason, please do not change it, blah, blah, blah, stuff like that.
Sometimes, but it's hard to leave traces of sort of to leave it for history
because things change.
So, leaving traces like that also just risks that you leave traces of your former design
or former decisions that maybe were not enlightened enough.
So, I don't make a concerned effort to do that
because everything is in git anyway.
We can always go back and look at the history if we want to.
Was there any question left or should I shut up?
I have a couple of questions.
One is how much time you were spending on the project before being able to work on it?
Sorry, can you repeat it a little louder?
Yeah, sorry. How much time you were spending on the project before you were working on it full-time?
I have a long-standing tradition in my family that I spend every night on curl.
So, when the rest of the family goes to bed, I stay for another two hours working on curl.
So, I've done that since 1996 basically.
That's two hours every day, every week, every month, every year for 27 years.
Now I've just added my full-time work as well.
So, now it's just instead of two hours per day, it's now 10 hours for work days.
Do you delegate maintenance?
Sorry, again.
Do you delegate maintenance?
So, do you have many...
Do you delegate maintenance of your project to someone else and how many...
Or you maintain everything yourself?
Because there's much maintenance overhead.
Well, I'm the lead developer here.
I'm not the sole maintainer.
We're a whole team. There's a lot of people, apart from me, who can merge code and who does.
I just think I do the bulk part of it because I'm the only one who works on it full-time.
I do it much more than they, but if I would stay in a conference the whole weekend,
someone else can still merge code while I'm away or if I'm just absent.
So, there's a whole team actually.
You