The Changelog: Software Development, Open Source - 17 Years of curl (Interview)

Episode Date: May 1, 2015

Daniel Stenberg joined the show to talk about curl and libcurl and how he has spent at least 2 hours every day for the past 17 years working on and maintaining curl. That's over 13k hours! We covered the origins of curl, how he chooses projects to work on, why he has remained so dedicated to curl all these years, the various version control systems curl has used, licensing, and more.

welcome back everyone this is the change log and i'm your host adams d'acobiak this is episode 153 and on today's show we're talking to daniel stenberg daniel is the creator and maintainer of curl deep show today. Huge topic. 17 years of Curl we're going through with Daniel. That's how long he's been doing this. 17 years. Daniel works at Mozilla. He's also an internet protocol geek, as he says himself.

He's an open source person and also a hacker. Now on the show, you'll hear us mention that he's an OG or OH to be more specific for original hacker because he's just been doing this for so long. We had some awesome sponsors for today's show, CodeShip and TopTile. We'll tell you a bit more about TopTile later in the show, but our friends at CodeShip had this cool new feature called wildcard deployments. Now you can get more flexible deployment workflows with wildcard deployment pipelines that trigger if a branch starts with a certain prefix you can use one deployment configuration for multiple branches and automatically deploy that feature release qa branch to the corresponding environments as you've

set up it's super easy Let me break it down for you. When you add a new branch in CodeShip to be deployed to, you can choose whether you're going to specify the exact branch name or if it's a wildcard deployment. And for the latter, you get an option to choose from a dropdown, which is branch starts with, and then you can specify the common part of the branches you want to deploy. So if, for example, you want to deploy all your branches that start with feature slash to a staging environment, for example, you can add this as the branch name and the deployment will be triggered for any of the following branch names. So if you've got feature slash foo, feature slash bar, those will all be automatically pointed and deployed to your staging environment. Super easy to set up.

Love CodeShip. Get started today if you haven't yet already for free with our free plan. It includes 100 builds a month and five private projects. Or use the offer code we have, TheChangeLawPodcast, to get 20% off any plan you choose for three months. Head to CodeShip.com slash TheChangeLaw to get started. And months head to codeship.com slash the change law to get started and now on to the show all right everybody we're back we got daniel stenberg on the line 17 years of curl and more we'll talk about more jared you're on the call what's going on man hey man how are we doing we are excellent daniel how are man? It's good to have you on the call. I'm good. It's a bit late here, but I'm relaxed sitting here, leaning back in my sofa in my living room.

There you go. So you're in Stockholm, or not too far from Stockholm, Sweden, right? Right. Just outside of Stockholm. What time is it there then? It's 10 p.m. 10 p.m. So it's 3 p.m. here. And that's not bad. Small difference. Seven hours.

Yeah. So, Daniel, we, you know, not too long back, you posted this awesome post, 17 years of curl. And for those who are catching up, if you haven't used curl before, maybe you haven't been on the command line enough. But this is a big deal, right? This is 17 years of a tried and true tool that's been a part of Linux forever. And you got this whole history that we thought would be really enjoyable to go down. But before we kick that off, maybe introduce yourself to the audience, those who may not know who you are, where you work at, what you do, what some of your flavors are, and we'll go from there. Sure.

I'm Daniel. I'm in Sweden. I've been working on curl and with curl for a very long time, 17 years. And I basically started that when I didn't, I wasn't really aware of any alternatives. So I picked, I started writing on my own tool and of course it was a small thing back then and only did a little a few protocols and a few things and then it just moved on from there and since then i've been it's been a fun project i've been working on it and expanded it expanded and gotten more users over time, of course. I mean, it's just a little project.

And we've been, I would say, a few core contributors over the years that have kind of stuck with the project and been around for a long time. But it has remained a fairly small project, developer-wise and so on. So it's low-key, no big, I mean, it's not that much of a bureaucracy or big processes or anything. We're just hacking around and improving the stuff that we like. And that's what I've been doing on Curl them for a very long time. And I've been working here in Stockholm, Sweden, as a consultant and doing embedded programming, basically, through my career, mostly.

And just a couple of years ago, actually, more slightly over a year ago, I was looking around for a new gig here in Stockholm, and then I was offered a job for Mozilla. So right now, then, I a job for Mozilla. So right now then I'm employed by Mozilla and I work on Firefox and networking stuff during

the day. So when Ilya Grigorov was on the show, Ilya works at Google and he works, I guess, what does he work at? Does he work on Chrome directly, Jared? Is that where Ilya works at? Works on? He's an internet plumber. That's what I was getting at. His job is to make the internet faster. I'm not sure if that's just on Chrome or what else

it all entails, but sure. Would you say that's a fair assumption of what you might call yourself as well, Daniel? Internet plumber? Maybe. I would rather call like a network hacker or whatever. Ah, that sounds cooler. Because I work on network stacks. I work on Firefox networking stack and I work on curl mostly. I work on a bunch of other projects too,

but those are my kind of two primary projects I work on. This kind of takes us back to 1998. Now I have to admit something, this will share my age a bit, but I graduated in 1997 and you released Curl the spring of 1998. So I was about 18, barely 18. How old were you then? And take us back to spring of 1998, if you can. Yeah. And spring of 1998, I released Curl and I then renamed the former project that I was working on and called it Curl because the project I had been working on before that, I called, originally I called it HTTP Get. And I started that in 1996. And then I added support for FTP as well, and then it supported both HTTP and FTP, and it kind of became odd to call it HTTP GET

when it also could speak FTP. So I renamed the project to URL GET. And then after a while, I added support for uploads as well. So it wasn't a get anymore. It wasn't only get. So URL get turned out to be a weird name. Yeah, that too. So then I renamed it again a third time,

and I called it curl then in 1998. And so since 1998, it's been curl ever since? Yes. So I first got into computers around 2000. And I first got into Linux and the command line in 2003. And Curl is one of those tools for me personally, you know when certain things predate you, it's almost like they always existed. Yeah.

You know, similar to the core utils. You don't even think about who wrote LS and who wrote CD, and I'm sure there's people who know exactly who wrote those things. So, of course, you can man LS and find out. But your program, Curl, is so ubiquitous and was even back when I got started that I didn't even realize for a very long time that it was not just part of, you know, a standard Linux stack when you were writing it, when it was called, you know,

HTTP get and URL get, did you have any clue that it would be deployed so broadly? No, no, no, of course not. It was just, I mean, it was just a small project. I did it for my own sake originally. And then of course, I found out that there were some other guys who also enjoyed it and wanted some features. But, of course, I mean, there's no point in time when you suddenly realize that it's just a constant evolution. So it's just one of these days when I look around and I just suddenly noticed that oh it's getting used all over and so no I never realized it I never intended it it just became like that and I think I mean of course

I think I did a lot of looking back I think I did a lot of correct decisions and perhaps I was also kind of right in time. So it was the right thing in the right time and so on, but it wasn't really on purpose. It just happened. What were some of those right decisions? Well, I would say that I was, the whole HTTP and internet and the web was kind of on the rise at that time

so it made sense to come at that point with a good HTTP tool that could help with a tool that is more low-level HTTP stuff than, for example, Wget which is more

getting stuff and curl is more a tool to do more weird things with HTTP. Do you get like your nemesis? Yeah, at least. I like to give that impression at least. It's more fun to think of it that way, right? Yeah, it is. It's fun to think that the curl person and the Wget people can't get along.

Exactly. I kind of like that image too nice and i also think that i did i think one of the best decisions i did i did early 2001 i think when when we created the the library the lib curl which is kind of the core of curl which then is a way for programs to get to curl abilities programming-wise. Yeah, so the command line tool started off just as a command line tool, and then you said, well, let's make the core of it a C library, and then the command line tool will use libcurl, and then other people can use libcurl, and that was a huge thing. What were some programs or some languages that integrated libcurl. And that was a huge thing. What were some programs or some languages that integrated libcurl throughout the years?

Well, early on, PHP is one of those, really, the first ones. And I think that helped us to get really far because PHP had adopted curl as the default way to do HTTP really early. So it kind of got some widespread adoption early on. And I think that was one of the big ones. It got me really excited when I realized that they wanted to do that. And from that point on, it just kind of spread really wide i don't remember exactly now but but in which order everything but i mean over over the years of course more and more

programs and more and more projects have adopted to use lib curl for for the transfer parts and i would say that today lib curl isl is the bigger part of the curl project because curl, the command line tool, is more like Linux users or command line people. And the number of those are much more limited than the number of programs or projects that would use Libcurl. So it started off HTTP focused, and it's still known for that today. But if you go to the homepage, you find out how many protocols this thing supports. It's kind of mind-numbing.

Dict, which I don't even know what that is. File protocol, FTP, FTPS, Gopher, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMB, SMTP, should I keep going? SMTP, TELNET, TFTP, SSL certificates, HTTP post, PUT,

FTP uploading, HTTP form-based upload, proxies, HTTP2, HTTP2, cookies, user plus password authentication. Man, I'm not done yet. I'm going to stop. This,

I mean, shows what productivity can do over a sustained 17 year time span, right? Nobody thought you'd just be building all of these things in. It's all this stuff in Libcurl.

Yeah. Yeah. What was the, what was the growth of these protocols? Just kind of organic over time and based on people requesting them or people submitting them themselves? How did all this come into it? Most of the features are just kind of creeping in. Like over time, people contribute different patches and have ideas and I wanted to

do things by myself of course so it is mostly organic we're adding things all the time and people are contributing things and then of course we I've had a couple of friendly companies over the years that have actually paid me to spend more work time, more focused time on developing curls. So, for example, I did the SSCP and SFTP pretty much paid sponsorships. And I did a bunch of the others like that. I did the POP3 IMAP,TP support also with the help of companies paying my time to implement this. That's something you hear about a at some point along the way,

you were able to at least financially benefit from the time you put into it. Not so much to get rich off of making Curl, but just so you're not totally giving your time to get nothing back in terms of finances for you or your family or whatever. Right. And it is actually, especially when adding new stuff, that is kind of the easy part to get financing for. Since then, companies who want to do things with Curl, they can easily kind of find room to pay me to do something that it doesn't do already and that they want in their product or whatever. How do you make the decision to put something in there?

Let's say Jared and I wanted to pay to put something in there that was obscure just for us. Do you say yes because you're getting paid? Do you say no? What defines the line there for you? Since I've kind of been fortunate that I haven't been – I've been able to kind of pick my projects. I mean my pay projects, like pretty much cherry-picked them

and only picked those that have matched what I think is fine for the project. I've never agreed to merge anything into the mainline that I think isn't in line with what the project should do. So I've only accepted features and I've only done things to Curl that I think is fine for Curl as a project and whatever the companies that pay me think. So if I've done things that I don't think fits mainline, I haven't merged it to mainline. I've just done it for some company and allowed them to keep it outside of everything. You've also had a whole lot of contributors over the years.

It looks like on your thanks page, there's a massive 1,265 people that have provided code feedback, advice, etc. over the years. That's just an astounding number, right? It's a totally insane number. But it's also a result of me keeping very close track of contributors.

So I'm trying to, since Amini is open source, the only thing I can do to people, the only way I can pay them is by thanking them and showing gratitude and clearly marking and saying thanks. And this, whatever, was done by whoever. And I'm trying to make a really good effort to make sure that I mark everything as reported by or contributed by or written by.

So over the years, of course, I collect a lot of names by people who have helped me out with all sorts of things. Yeah, I was noticing in a comment on your blog, somebody is actually impressed that they found their name in the thank you list, even though they'd only submitted a single bug once, and looked at that as a very minor contribution, and yet you documented that, and you added them to your list, and here they are appreciative of that fact and felt like part of the project even if just a little all these years later. Right and I tried to do that I tried

I'd still try to do that so of course if someone submits a bug report that person's name will end up in the thanks list and of course that might be a bit weird and if I also add someone who who then contributes a very large piece of code or whatever. But on the other hand, I mean, it becomes a really hard thing to draw the line. Who am I to say who's helped or who hasn't helped? Everyone who contributes anything, they actually help the project. So I try to just keep the names and say thanks. And you've seen the adoption. We'll probably talk a little bit more about adoption later, but just thinking about all the work that's gone into

it, all the people that have contributed, of course yourself. If you go to the GitHub, you have thousands and thousands of commits over the years, and I'm not even sure if that backports all the previous history before you switch to Git. And yet you see curl being used on the NASDAQ tower, as you posted to your website as well, which is a nice screen grab of some sort of dump on the NASDAQ screen up there of a curl command going out, which I'm sure they weren't hoping that would go public. I'm not sure what that is, actually.

Yeah, it's like they just printed the source of a script they're running. I'm not sure what that is, actually. Yeah, it's like they just printed the source of a script they're running. I'm not sure what that is either. I actually think it's an ad for that company. Oh, really? That's interesting. So they're showing how hacker they are, or what? Yeah, it's an API. It's a post back to APIallthethings.com with the flag of D and getting a free shirt at Apogee.

So that's advertising there. See, I didn't zoom in. I just looked at it from far away and thought, you know, when people accidentally blue screen in public, I thought it was one of those. Yeah. So it might be on purpose. I, I, I just got that. I just saw the picture. I thought it was fun. That is awesome. That's a cool ad though. I mean, it's the way, you know, sidebar on that,

but, you know, a way to target your audience, right? Like, no one gets that except for someone who understands Curl. Right. Yeah, it's actually a good ad. I thought it was the NASDAQ people messing up, but interesting. Well, it's still cool to see your command line, you know, program, like, blast it up on some big board somewhere.

Which makes me think of all of the, you can go through the list of companies that have used and projects that have used Curl as part of their product and all the people that have benefited over the years from your work. And it makes me think, how much work do you actually have into this thing? 17 years, you got all these contributors,

so obviously you're not the only one committing code. But if you had to think back and say, well, how many man hours do I have in curl? Whether it be coding or maintaining the mailing list or talking to people about bugs and troubleshooting. Could you even estimate that? How many man hours do you think you have into it? Yeah, I can do a rough estimate. Okay, let's hear it. I would say that over the years, I spend almost every day,

I spend about two hours on Curve. Wow. So that makes it around 15 hours a week for about 17 years. Wow. So 15 times 52 times 17, roughly? 13,260? Something like that. Somewhere around there, maybe you take a vacation.

Hopefully you take a vacation. Yeah, sometimes I take vacations, of course. But I've also done periods with more intense. Yeah, that's just the average. 13,260 hours, just based on the estimation. So what keeps you going? There's got to be more. There's got to be something.

We struggle with burnout. We talk about burnout with many people, especially when their project gets to become more successful than they ever planned. And it just becomes too much. How do you sustain it for 17 years? What drives that? I actually have a hard time

to really explain that. I mean, because I know a lot of people who get into the projects and work on them for a while and then drop out after a while. And of course, I have a lot of other projects that I've worked on and I haven't kept up going on those. So no, I think this has just become sort of my baby. I just really like where it's gone, and I like to see it go further, and I like to see it become better, and I want to fix the problems that I get reported and so on. So it just feels like this is kind of the hobby of my life. I'm stuck with this. I really enjoy it.

Do you still enjoy it today? Like you did back when it was first getting going? Oh yeah, I do. I enjoy, I enjoy working on it every day. So, yeah.

And I actually, without mentioning details, like now, for example, I've just today finished a conversation. So I'm going to do full-time curl development now for probably for a couple of months going forward. Yeah.

And I'm, I'm just thrilled about that. So yeah. That's interesting. Congrats on that. That's awesome. So what does full-time curl look like? Like what,

what's on your list of things to get done or to do? Is it, is it a list of bugs that have been driving you crazy or is it new features that, you know, what is it? Right now, it's mostly about getting all my remaining HTTP2 stuff done for curl. Nice.

Since HTTP2 is new and hot and everything, and I've implemented it, HTTP2 supporting curl, and it's there, but it's not completed, and it's not really there API-wise and libcurl-wise the way I want it to be, and the way I think a lot of users want it to be. So, man, just think about maintaining a project of this size, looking at contributors, and letting GitHub crunch your data, it looks like you have 481,000 lines added,

302,000 lines removed. What's the overall size of the code base now, roughly? It's not that terribly big. I think we're around 200k lines of code in the actual project, and there's a lot of tests and infrastructure around it. But the code in the actual tool and the library, it isn't that big a project.

So it doesn't feel unwieldy. It seems like projects as they grow, especially with how many protocols you support, over the years it seems like things tend to get unwieldy. Maybe the big rewrite starts becoming a thought. Have you ever had those kind of issues where you hit a wall and think about a rewrite or a different language and nowadays is it pretty easy to maintain and to add to? Well, of course, there have been some obstacles and points in time

when I've kind of ripped out a lot of junk and redone things internally. But I would say that I've never considered to change language. And of course, that's me being old and grumpy and doing things, coding C. But also, I think that actually a big explanation for curl's success is that it's massively portable. It builds and runs on just everything. That also helps everyone to use it on anything. I mean, I don't mean just Linux and Windows and Mac or whatever,

but every manageable RTOS or weird gaming systems or embedded systems and everything. So I kind of like that. And that's also why I've never considered to change programming language. And when it comes to things like

architectural decisions and how I made things work internally, we've actually been able to change that to a pretty large degree internally over the years without any significant rewrites, just ordinary development and just changing things over time. Let's get a little meta here real quick because I'm noticing that you actually have a link to a changelog on the site for Curl.

What has it been like, I guess, maintaining such a drastically long changelog? It would take me 25, 30 scrolls to scroll this entire changelog. I mean, I guess, is this manual? Since it's such a labor of love anyways and such a legacy project for you, meaning in terms of how important it is to this hobby of your whole life, what is it like to maintain such a long changelog? Well, I'd say that it's – that is part of what you sometimes forget what maintaining a project is. That is everything that isn't code, like the website and just putting things up and maintaining the change log or maintaining things like security, advisories or whatever. It's just making sure that the documentation looks good on the website or whatever.

So yeah, in terms of the specifics around the changelog, I do that not only manually. I have a lot of scripts, but I basically add the chunk for every new release at the time of every new release. So I did a release this Wednesday, and then I added the 7.42.0 details. So I inserted it on this Wednesday.

I'm going to do another release on this coming Wednesday, and then I'm going to add the blurb for the next release then. So it's all about that. And then I have a lot of scripts kind of gathering that information and kind of webifying it. You also have a pretty epic man page. Yes. It's actually kind of insane.

That's one of our problems, that we've added so much features and so much things that it gets hard to find your way around. So it's hard to write documentation when you have so much functionality. What about modularizing? Taking lib curl and breaking it up into smaller bits that maybe are protocol specific or some other arrangement that makes sense and then having a wrapper library that kind of pulls those all in. Have you considered architectural things like that?

I have, but I've never really found the motivation to really go there. So I've tried to ask my audience or users sometimes what users think and what they want from the library in terms of protocols and everything. And it turns out that a lot of users use a lot of protocols. So it's not only that we're supporting all those protocols just in vain, but there seems to be a lot of users using a lot of these protocols. So I'm not sure that it is a benefit for the project or the design to split it up either.

And also, a lot of the protocols are using shared code. So it's not, each single protocol aren't really that separated from the rest of them. Gotcha. This makes me think of another question, which is, how do you talk to your users? I mean, you have, I think you even said a billion users, and probably you don't even know all your users, especially when it's embedded in systems and whatnot. What's your tools and your communication channel

between you and your users? Yeah, it's really crappy. It's not good at all. That's how you really feel. No, but kind of the usual kind of open source problem that I release source code, and then it goes out in the world, and somebody gets the code and builds it

and builds a product and runs with it. And I have no idea who will do it and what will do with it and if they're happy or not. And maybe they'll never come back and ask me anything or say anything, and I wouldn't know about them. Actually, I mean, I have that list on the website called companies, that list, companies that I know about that use curl or lib curling commercial projects. And I would say that the majority of all those companies, I found out that by myself, just by Googling or kind of, I have a friend that find a screenshot somewhere and emails me a picture or whatever. So it's not that users tell me about it. So I don't really have a good channel to talk with most of my users. The ones I talk to, they are the ones who are on the mailing list

or those who ask me questions or those who come to me and have questions or to the project. Yeah, so it's kind of the squeaky wheel gets the oil type of a thing. Yeah, and of course that's a subset of the users and probably a particular subset that aren't all representative of the kind of... Yeah, that's the hard part, right? It's like, is this request serving my users or just this one particular, you know, loud user?

Exactly. Things you got to ask yourself. Yeah, so then I just have to kind of always try to sense that somehow and get a feel for, is this a good idea for the project or just for this user or or whatever but but often it all comes down to who's willing to do the work anyway so if if there's someone who brings code and thinks it's a good idea and it seems to match with a project in kind of conceptual wise and design wise then sure why not then it doesn't really matter if it's that user alone or an entire world as long as

it seems fine with the project. Let's take a pause here. We'll do a quick sponsor break when we come back. Considering the fact that you've been in the game so long with this project, we've got to imagine that you've been through several different version control systems. So we want to talk deeply about

your love-hate for version control systems. So we want to talk deeply about your, your love hate for a vertical control systems over the years. So let's, let's break real quick. We'll come back. We'll talk about that. You've heard me talk about top towel several times in this podcast and top towel is by far the best place to work as a freelance software developer. Well,

they have this term elite engineer, and that defines the kind of software developer that works at TopTile. I had a chance to sit down and talk to Brendan Benesha, the co-founder and COO of TopTile, and I asked him, Brendan, what is an elite engineer? Take a listen.

An elite engineer for us is somebody who satisfies all the technical requirements that you would need in a great developer if you're working at like a Google or Facebook. But then at TopTel, you have to add this extra layer on top of it to make sure that people are mature enough and professional enough to be totally self-directed. And so making sure that they take a tremendous amount of pride in their work and that they're accountable and very, very communicative because in remote freelancing, that's sometimes just as important as being technically competent. All right. If

Brendan got you excited about being an elite engineer at TopTile, head to toptile.com slash developers. That's T-O-P-T-A-L.com slash developers to learn more and tell them the cheese load sent you. All right, Daniel, we're back. Like I said before the break, 17 years at this, you must have been through pretty much every one, and now you're on GitHub, so you're obviously using Git now. You've been using Git for, I think, about a year now, right? Is that right, since you've been on GitHub?

No, it's like four years or three years or whatever. Where have I been at? Four years on GitHub? No, it's like four years or three years or whatever. Where have I been at? Four years on GitHub? Yeah, I think so. I don't remember exactly. We've been through a couple of different version control systems and we've switched to we actually switched to Git pretty late, actually.

So we stayed with CVS for forever. But that kind of also goes back to the fact that we're a small project and we're doing things very simple. We have a linear development, just a single branch basically all the time. So we don't have a lot of requirements on the virtual control system either. So it worked pretty good with CVS too. I mean, Git is way better and way more fancy,

and I really like it. So it's not that I regret it, but that's also an explanation why we could kind of stick with the old for so long. You mentioned... Sorry, go ahead, Jared. I was going to say, you started even back on RCS, which predated CVS,

and then you switched from CVS straight to Git. So you seem to have skipped the subversion time, which a lot of people want CVS subversion Git. You must have liked CVS OK. Speak to the migration process, and if you've been able to maintain your commit history over time, or if you just said, screw it, we're just going to switch. What was the migration between these different systems like? I could mention that I joined the Subversion Project immediately when it started. And I was part of the core contributor team in the Subversion Project for a couple of years. So I have a bunch of commits in that project too.

So I was kind of eager to see a good replacement to CVS back in those days. But you never got curl onto it, huh? No, I didn't. Pretty much for those reasons I mentioned, but it worked out pretty good the way it did. So I never... And then came those distributed version control systems.

I mean, after a couple of years, after Subversion was going, and then I kind of noticed that the distributed approach really seemed to be the way to go. So I kind of just waited out a little bit more and then switched to Git. And then I converted the entire CVS history I had to Git. And that was fairly easy too, also because we had that simple approach to development, mostly in a single branch.

So when I load up your guys' contribution history on GitHub, your 11,347 commits, that's probably going all the way back to the beginning, right? To the beginning of CVS. Or actually, I believe it might even be the beginning of SourceForge. Because we created the SourceForge project page in, I believe, late 99.

So I actually don't remember exactly why, but I don't have the commits before, I believe it's August 99 or something like that so those are the first commits I still have which is a bit unfortunate because I would really want to even know the ones but yeah

So you're happy with Git and I was wondering if you had one thing we've noticed especially I think with Rails specifically when it switched to Git and GitHub, there was a massive influx of contributors at that time. It looks like you have 202 code contributors over the years.

Curious if in the last, I guess it's been four years now, if it's been more than it was in the CVS days, or if it's kind of been the same, or what? I think we're gradually increasing all the time. But also Git, especially in comparison to CVS, it keeps track of authors much better. So it's also kind of a lie, because when we did it in CVS days,

you had to basically write it in the commit comments that you got this patch from whoever. But with Git, it keeps perfect track of who's writing it. So I think it's both. It's easier to keep track of who's providing it, and it's easier for users to contribute using Git. And I would say that it gets even easier when doing

it kind of GitHub style. I mean, with pull requests and even more automated systems. Yeah, and yet on your issues, your GitHub issues, you got 10 open issues, 36 closed. Do you have a different bug tracker

or is your code just incredibly awesome? No, we had a difference. We used the SourceForge bug tracker, and we used that all the way since 99, actually. And we only just very recently decided to stop using that. So we have like 1,400, 1,500 bugs there. But since we're kind of so much in GitHub... That sounds more like it. Yeah. But since we're kind of so much in GitHub. That sounds more like it.

Yeah. But since we switched to GitHub so much now, it's easier to also handle the issues on GitHub, issues, pull requests, and the code on GitHub. Also, the bug tracker on SourceForge isn't that very good either. I was going to say that at least gives you, I mean, having GitHub in comparison to SourceForge

from back in the day, it's got to give you at least, when you talked before about how you talk to your users, it's got to give you at least a better window than you've had before. Yes. SourceForge was really kind of the big thing back in the day, but of course it has kind of gradually kind of faded away somehow. And GitHub is now really where everyone is and where things are happening. So of course it's much better to be in GitHub in comparison to SourceForge, because nowadays everyone has a GitHub account and has presence in GitHub and comparison to SourceForge because nowadays everyone has a GitHub account

and has presence in GitHub and not on SourceForge. So it's also kind of a matter of the least resistance. People are already there, so it's easier for people to contribute when we allow everything on GitHub. This may be an insignificant thing to most people, but I like to have a little fun on projects like yours on GitHub. And I like to go through the page history and I try to hack the URL to

figure out how far back I can go. And I was able to take us back 554 pages, I guess, of commit history. So I don't know what the commit count is per page, maybe like 30 or 40, maybe 25 potentially. I don't know if it commit count is per page, maybe like 30 or 40, maybe 25 potentially. I don't know if it's time-based or not, like how many commits go on each page, but 554 pages of commit history you have.

That's crazy, man. Yeah, there's a lot. The initial commit message was initial revision, December 29th, 1999. And the next one after that was remove junk files. I'm glad you got rid of those junk files. Almost immediately. Yeah, but that was kind of an import into CVS. I guess I imported a lot of junk then, so I had to remove a lot of junk.

So version control has changed over the years. Another thing that's changed, it seems, in the Curl project is your guys' license. Can you take us through the different license variations and maybe some of the reasons for the transitions away from and to other licenses? Yeah, we've kind of transitioned through a lot of licenses. We started out GPL from from the start i believe and i don't

think i paid a lot of attention to licenses then i basically just picked one that i thought a lot of others used or i don't remember exactly what kind of process i had when i picked the license but anyway um after a couple of years i kind of of felt that I'm not really a GPL guy. I'm not convinced that the copyleft idea is a good idea in general, especially not for libraries. And I also got some pressure from users who were kind of saying that they were, I mean, contemplating to use curl in their products, but they couldn't do it because of the GPL and they wanted to have a more liberal license. So, and I kind of, after a couple of years, then I kind of,

yeah, I realized that it might not really be the guy I am. So I changed the license and then, and then we picked the Mozilla public license, the MPL, because I thought that was kind of a middle ground. It's not really cop left, but it's cop left

for the specific files that are included in the project. So it would mean that if you change actual files, you have to provide the source code for those. And I thought it kind of matched more. It was more in line with what I think is reasonable.

But it didn't go very far or long until I realized that it wasn't a good choice either because MPL isn't even considered GPL compliant. So then suddenly I got kind of the reverse problem that people who were using GPL in the projects, they couldn't use Libcurl anymore because it wasn't compliant license-wise. So then I was kind of in another annoying position.

And then for a while I added a license, I added dual licensed. I don't even remember which licenses. What's the license now? Now it's MIT. MIT. Yeah. So you kind of took a windy road

to what is one of the most liberal licenses. Exactly, yeah. What kind of a man you are. Then I dropped that dual license thing and just, yeah, we're going MIT license here completely as liberal as possible. Do whatever you want. Just don't say that you made it. I like that personal identification with't say that you made it. I like that personal identification with the license that you're picking.

You're thinking, I don't think I'm a GPL man. Yeah, I like that too. It's a nice way of thinking about it. And do you think that the MIT, since that change, has helped or hurt? Are you happy with it? I'm happy with it. and I think it's helped.

And I don't think it has hurt us at all. I think I've managed pretty good, and I don't think I've been... I actually don't think we've been... We would have been able to manage a lot better than we have

if we'd have picked another license. I think this license has made it possible for all sorts of companies to adopt and use Libcurl all over. And of course, there's been companies and whoever have used Libcurl and done changes and who never contributed back. But we've been keeping a pretty high development pace over the years. So I know for a fact that a lot of companies, they want to contribute back so that they can follow the development and they don't have to maintain anything on their own or do their own forks or branches or patch sets or whatever.

So I think the LibreLicense has helped companies to not be afraid to use Libcurl. And then in the end, they usually contribute back anyway, if they do any substantial changes. And at the same time, all those, I mean, the GNU projects and everything, those who are then GPL or whoever, they can still use Libcurl perfectly fine, and they are all happy to use it, since it's perfectly free and open source still. You'd mentioned that in the past you've been, I think, I don't know if you use the word bounty or not, but you've been paid to implement certain features

either in a particular branch for a certain company or even if it made it into mainline. But over the years, you've had several employments that have either helped or hurt you maintaining Curl. Can you walk us through some of that and then ultimately bring us to where you're at today at Mozilla in terms of their support for Curl and your work for it? I've been employed by four different companies while working on Curl, I think.

But I've pretty much successfully been able to to not have that influence my work on curl too much so i basically always had curl as my spare time project and done my work stuff separately from curl right so i don't think that has influenced me a lot and then over the years of course when i've got i started working for my own company and when was that like five six years ago then it turned much easier to do contracts for for i mean for money to actually implement features for companies to that one of that so then i've actually i've done a i don't remember how many but perhaps five seven different projects for companies that have paid

me to do things for curl and usually actually those companies they don't want it they don't want it even to be known that they're paying for it. So usually it has never been that obvious to the outside that someone else has paid me to do it. This is an odd question, I guess, to ask, but I've asked this to myself sometimes because I'm self-employed. And Jared, you are too, uh you might like this question but if you it's earlier we got the average out potentially 13 000 plus hours uh that you've invested in this do you think that you made minimum wage for those hours or at least i mean are you the money that you've been able to make as part of taking care of curl or being paid to work on it for a couple hours a day like you are now at mozilla have you been able to at least make minimum wage or well above that do you think

you've been compensated well for for the time that's been invested i guess um i'm not sure i mean partly it is my hobby so i mean you don't really care people are people have hobbies so they don't expect to get paid to have a hobby. I don't mean so that we could justify, oh, you got paid or not. But I think of it like for myself, like the time I invest in something, I just wonder have I at least – am I plus or minus? I'm in the red or am I in the black? And it's not so much to say justified in making money, but just as like, oh, I'm in the red on this one. I didn't make that much.

I just love this thing so much. Yeah, but I just wanted to say that about hobbies since I do it for fun. So it's not really about getting paid for it. But then on the other hand, I think it's been, as I said, it's my big hobby since a lot of years. And I think it has influenced my life and my career and everything I do pretty much.

So where I am today is a lot because of what I've done. So I think in the end, I think it's been really helpful. I mean, I got this since I work for Mozilla now. So it was really, I mean, the hiring process at Mozilla has been a lot of talking about, yeah, I have a lot of code in public and I do know a lot about protocols. And I didn't have to explain have a lot of code in public and I do know a lot about protocols and I didn't have to explain that a lot.

Everything is there. Everything is public. Well, Jerry read the list earlier, so. Yeah, exactly. So I think, for example, then I'm here, I'm working for Mozilla today, a lot thanks to my work with Curl, of course.

So it kind of, it has, what started a long time ago is now at this point. And I would say that, I mean, I've done so much fun and I think I've managed so well in so many areas. So yeah, I would say that I'm definitely a net win with everything of this, taking all those 13,000 hours into account. It's like the ultimate hacker credential. It's like I wrote curl and then they just hire you, right? Yeah, pretty much.

That's funny you say that because I guess it's okay to say it on air. But before we got on the call, we were joking. So before we actually heard everyone's list of this before you heard that i was like dan you're like the you know the og and then we said the the oh for the original hacker because like you know you've been there since essentially the dawn of the internet almost and you've wrote this library that billions of people use so you can't get much more OG or OH than that. Unless you're Linus Torvalds. Tim Berners-Lee. Yeah, Tim Berners-Lee. Yeah, well, of course, you can't think of a lot of people.

There's been a lot that's changed over the years. We talked about the name changing. We talked about your version control systems changing, your license changing. You had four different jobs. If there was anything that stayed the same over the 17-year lifespan of this project, what would that be? I think there's a lot of things that are still the same.

Working open source, you work with people, and I think that people are mostly the same still. So there are, I would say that there are still the same, the same whiners, the same people who are doing things, the same, the same type of criticism and the same type of, so yeah, I think that no matter, no matter what you do and no matter how much success or, or how many users we get in the code project, I don't think there's, it doesn't really change the human mind or the mental state in people.

So there's always that, I shouldn't say always, but I keep getting those annoying emails that I have to kind of resist and really keep back when I respond to them and so on. So that is kind of a... And you know how things can be in open source projects. It can be really rough and you have to have a really thick skin at times because people don't hold back on what they say and write in emails or whatever. But of course, it's also the opposite. So it's a lot of good stuff too.

Well, for those who... Sorry, go ahead. No, no, go ahead. I was going to say, for those who listen to the show, they know we have some awesome closing questions we tail off the call with. But I'm kind of curious what your favorite moment over the last 17 years might have been.

Like, if there's something that just clearly stands out to you as like, that was the day or that was the thing or this is the favorite feature or what in the last 17 years was maybe one of your most favorite moments? I think there's been a lot of good moments, in particular when I realized who have been using curl. Like, wow, suddenly I realized that Facebook uses curl. And then I suddenly realized, wow, that's quite a lot of users or stuff like that. But I especially remember one moment. That is when I saw that the billboard outside somewhere in Silicon Valley,

there was a billboard with the curl command line on. Pretty much like this new one. It was NASDAQ. NASDAQ. Yeah. It was a bunch of years ago when it was an ad for some... I don't remember really what it was. But it was a big freaking curl command line

on a billboard in Silicon Valley. That was a good moment. I think one thing that really resonated with Jim Ryrick, I can't say his name, Ryrick, who's a Ruby developer and one who passed away recently, but it touched a lot of people. One of his favorite things to do was to go to the apple store and fire up a terminal and do man rake um yeah rake

was kind of his bait his baby uh he had many libraries but that was one of his his bigger ones and have his name there of course you you could do man curl as well i wonder you're kind of a Linux hacker. I wonder if being included in different distributions, maybe the one that you use, was a shining moment for you, or if being included in Apple's operating system or anything like that was something that resonated with you. Well, of course.

It's really satisfying and kind of an ego boost thing but but also it's um it's also kind of a i mean as i said they don't tell you about it it wasn't that uh they someone called me and said hey we're using your stuff it's more like suddenly one day someone mentioned it to me oh you know that it's included here. Oh, look, they've been doing it for years. And I had no idea. So in a lot of these cases, I don't know it. Exactly. I don't know it when it happens.

I just realized at some point in time that, oh, they've been doing this for how long they've been doing it. Like the Apple case, for example. I have no idea when I realized Apple was including curl all the time. I have no idea. Sneaky, sneaky Apple. But of course, it's a huge ego boost. And I mean, these days, so many things are network connected. So there are an enormous amount of things that are using curl just to download things.

And these days, there are so many different things like cars or TVs or printers or routers or whatever. And it's fascinating. We have a couple questions for you. I know we shared them earlier. So you may have been thinking about a couple of these, but one favorite we love to ask, and I'm really curious to hear what yours is, but who is your programming hero?

Yeah, I've been thinking about that question. I think it's a good question. I don't know. I would say that the one who immediately came to mind is Richard Stallman. And then because that's kind of one of those original guys who managed to do so much. The guy who made GCC, Emacs, GDB, and a lot of those early days tools that are still around. Even if I would say that he's not possibly my hero these days.

You can say he may not care too much since you switched off the GPL. You probably quit listening right about then. Yeah, he's an interesting character in general, actually. Then I would say that also like people like Linus Torvalds for example is also

someone who managed who has managed to get to a point and do what he likes in a

way with kind of keep integrity and stuff in a very successful way but yeah

I'm impressed by that and I would I would like to get into a position like that but i mean i shouldn't complain i'm in a excellent position myself right now you asked before i didn't mention it but these days and when i'm employed by Mozilla, I'm getting paid to actually work on curl part-time. So I do part-time curl on work hours these days. Well, I would say that Mozilla is pretty interested in security and just the general ability for the internet. So I would say that it's nice to see them to say, yeah, go ahead, Daniel.

Work on curl when you get a chance during your workday. Yeah, it matches with what Mozilla stands for and wants to do. I know that this is using some of your language you've written elsewhere on the curl site or on your own site. You mentioned you got a long list of things to do. You mentioned you got this upcoming two-month span of working full-time. But while you're doing that or maybe in the future when somebody picks up this podcast and listens to it and says, heck, I think Curl's pretty neat. I'd like to hack on some C. Maybe

Daniel's got a little to-do list somewhere. What's a call to arms? What's something that the community listening to this show could pick up and help you on to help Cur curl be a better curl for tomorrow in general for an open source project where all open source projects really not all but most of them are undermanned in terms of people who are actually doing things so so for for me for example i would appreciate if people would just help with bug reports and just help reproduce bug reports or just help try out patches. There's just an endless amount of things that could be done.

Then there's, of course, also this. I have, for example, a to-do list that lists, I believe, like 20, 40, 60 things that we could add to curl if somebody wanted to do it and somebody just spent the time and energy to do it. So there's really, there's both highs and lows depending on what you can do and what you feel for. Let's talk about your open source radar then.

Since this is your labor of love it seems like it might be the only thing you get to play with but if you had a weekend is there any project out there that that's in the open source world that like man if i only didn't have all these bugs for curl to take care of i would totally hack on that this weekend what might that project be or even technology not so much as a project like uh could be vms for better testing you know could be docker for better testing or something like that i'm a library foundation kind of person so whatever i do is usually kind of around those is networking its libraries it's doing things like that so if i would do it i mean if i if i have a weekend off some at some point i don't do a new project i spend time on my existing project but if i would

do a new project i would it would be around networking and doing things improving things that i'm already kind of working on i'm trying most of my things, most of the new things I do, they usually kind of are related to what I'm already doing. So like I started on a speedy library previously to do the speedy protocol and stuff like that, because then I could use that in the existing projects that I do.

So I'm kind of narrow and I kind of, I don't experiment. I don't go very, very far from So I'm kind of narrow and I kind of, I don't experiment. I don't go very, very far from what I'm doing. You got your safe trail and you like to hang out there. Yeah. I kind of, I like my little cozy corner here. So I'm, I don't know that at all. Right. That's good stuff. Well, uh, you know, with such history and such you know og behind you i can't help but just be uh excited to have this conversation with you i know that it's been a long road but it seems like you've been having fun along the way somehow you've stayed motivated

somehow you've stayed uh excited about it and you keep caring for this labor of love you've had your code on billboards and billions of people using it, and you've got some of the most highest accolades with Facebook and many, many other people using your code every day in their projects. It's got to be a good feeling for you to sort of sit back and look at the last 17 years and say, that was time put to good use. Oh, yeah.

When I actually just do that i mean stop stay and and consider all that all those users all those products all those companies using it yeah that that makes it feels really good and as i said before it's an ego boost and of course i I contributed or even had a big part of that. And it's an awesome feeling. But then, yeah, that's about it. And then I go back to do the work. Take a moment, enjoy it, and then you go back to work. I know at the end of your 17-year birthday post, you were like,

have a beer with me, but only have one because we got work work to do and there's bugs to take care of and test. Right. So I know it's been an honor for me and Jared to have you on this call. It definitely was great getting to know you in here about, about all the things you're working on a couple for listeners listening. We've got a couple of shows coming up. We still have to schedule the roots and bedrock show. So if you're interested in WordPress and the

Bedrock way of doing things for WordPress, can't wait to have the conversation, but we haven't put it back on the book yet. However, we do have May 1st scheduled. That's next Friday. We're talking to Steve Newcomb about the famous interface

library framework. Super cool conversation there. We're hoping to see where that's... I'm not really sure where that's fitting, Jared, especially with all this React news. And we talked a little bit about that on that show, I believe. So I'm really curious to see where Steve's sitting with Famous. I'm going to find out next week. Way off the path of Curl, of course.

But nonetheless, still a fun conversation. Daniel, is there anything else that you want to cover before we taper off? I'm good. else that you want to cover before we, before we taper off? I'm good. Anything else you want to say to the audience, you know, where can they find you? Where can they follow you?

Well, everything I do and everything I play with is on my website at daniel.hacks.se, H-A-X-S dot S-E. And I'm back there on Twitter. That's about it. Gotcha. And we'll link that up in the show notes.

So if you're listening to this, head to the show notes, changelog.com. That's right, changelog.com, not the changelog. Jared, we just changed from the changelog.com to changelog.com. How cool is that? We shed a few pounds. We did. You know, three characters. And we're HTTPS now, too.

So we're ready for the future. Totally secure. Now we've got to get HTTP2 rolled out. That's true. and we're HTTPS now too so we're ready for the future totally secure now we gotta get HTTP2 rolled out maybe we can get Daniel offline to help us out any day soon so for those wanting to show notes to this show it's changelog.com

slash 153 because this is episode 153 but Daniel thank you so much for taking the time to talk to us and with that everybody let's say goodbye bye bye see ya I love you.