Daniel Stenberg // @bagder

Daniel: I feel a little bit like a lottery winner because it wasn’t really on purpose. It was just maybe a lot of good decisions along the way, but of course, I didn’t know it would end up like this and it wasn’t really... I’ve never really had the really, really long-term vision. Now I estimate that curl runs in roughly 10 billion installations. That’s a lot. That’s like we have like two and a half installations per internet user on the globe.

Brian: That’s Daniel Stenberg, maintainer of curl. And this is The ReadME Podcast, a GitHub podcast that takes a peek behind the curtain at some of the most impactful open source projects and the developers who make them happen. I am bdougie aka Brian Douglas…

Kathy: And I am Kathy Korevek.

Brian: Every episode, Kathy and I invite a maintainer or open source developer into our studio to explore their work, their story, and where the two meet.

Kathy: In this episode, we speak with Daniel who has been maintaining curl for a quarter of a century, witnessing its astronomical growth and allowing it to evolve over time. Simply put, curl is a command line tool for transferring data and its name stands for client url. It works on any platform and because of that, it is used in billions of installations. Daniel works on it full time and despite his many years of commitment to the project, he still finds great inspiration within it and doesn’t really want to be doing anything else. In this conversation, we explore how Daniel first discovered open source, the way he came to maintain curl and how he balances it all.

Daniel is a hero of mine and here he shares his story of first coming into contact with code.

Daniel: My first computer experience was back in the mid ’80s. I had a friend in my class at school who had a Commodore 64. Well I got to know him and visited him many times. You’re youngsters, you don’t remember that, but we had computer magazines with a lot of lines with just data and numbers--number, comma number, comma number, comma number, comma number, you know, pages up and pages down. You had to enter them yourself back then. And then when you ran it, it would be a boring game or something. But I did that in my teens.

Brian: And did that lead to eventually studying programming in school?

Daniel: That led to a very keen interest in computers. So I got myself a computer and then started programming like a maniac in my teens, continued then. So then no, I never studied computers or engineering or anything. I got a job after I did my military service here in Sweden and then I never, as I said, I didn’t have to study. I just got a job and another job and another job, and just went from that.

Kathy: Were those always in computers and programming or did you bounce around?

Daniel: No. Well, my first… I got a job at IBM when I was 20 and then it wasn’t programming, but it was computers. So they were unique systems that needed to set up and configuration when they arrived here and then when they got here, we configured them and they were shipped up to customers. So started at that and learned Unix and stuff like that. But after that, I got into a development job and since then I’ve been a developer.

Brian: What was the year when you transitioned to doing development?

Daniel: That was 1993. A long time ago.

Brian: Yeah, yeah, but still early web. I think once the web got into a lot of our houses at that point.

Daniel: Yeah. Yes. It had started to show up.

Kathy: And then from there, just tinkering around and playing with demos and things like that, how did you get involved with open source?

Daniel: When I started working at IBM in 1991, when I started working to configure those machines and shipping them out to computers, I also soon realized that you could also get tapes with a lot of source code and tools that came with source code. There were a lot of new tools and stuff that--I don’t exactly remember how they got them--but you could actually get them on tape so that some customers actually got them. And then at that time, it dawned on me that there’s a lot of code out there that you could just get it and look at it, compile it, build it and do whatever you want with it and learn from it. And that’s one way I learned C programming at that time.

So I understood and knew about the concept about a lot of free code. It wasn’t called open source, of course that early, but still, a lot of code was there. So I wanted more of that code and the more I learned about it, the more I also wanted to be part of that, sort of, the cool community who could just pump up code for everyone’s benefit.

Brian: I remember that myself, how there was a community around messing with computers. When I was younger, it was the older kids in the neighborhood that would be able to get all the DOS programs and Wolfenstein on the community center computer. They eventually showed us how to run them. We all just used the community center’s computer to practice and play. So I have vivid flashbacks of just looking at those kids, walking around with their floppy drives and teaching us how to run random games. I wondered if Daniel looked up to anyone else that wrote code.

Daniel: I didn’t know anyone. There was just heaps of code that you could get on those tapes and they were a lot of tools. I didn’t know any one of those, I didn’t know anyone who did open source or provided code like that. I just realized that there was an entire universe out there with that kind of people. And I thought that was cool and I wanted to be like that, but I didn’t know anyone, I didn’t know any names or anything. So it was just a revelation to me that it could be like that. So I think it was much later that I actually learned the names of people that are actually famous people that were actually doing a lot of that code.

Kathy: Nice. And then any of those inspire you to keep contributing and go further with open source?

Daniel: Yes, they do. And of course, I want to get inspired by people who do things for everyone that keep on bringing everything forward. And I try then to extract good practices to see what people are doing that I think is good. And try to mimic that when I do open source and learn from what I see in other projects that they do that’s good and try to carry that on. But I also think that I also try to... We have so many bad examples as well in open source that you see people who are leaders that maybe do things in ways that I really disagree with. And I try to use that as a counter example that I know that’s examples of behaviors or patterns that I don’t want to reproduce in projects that I run.

So therefore, I tend to not view people or individuals as heroes because everyone has ups and downs. And I’m sure I’m the same person here, because I’m sure I do things that some might appreciate and other things that isn’t as appreciated. So I try to not idolize any persons for the entire person, but try to extract the good parts and ignore the parts I don’t think is as good.

Brian: Yeah. I wonder if your introduction to open source too as well, it seemed like a natural introduction because you didn’t go to school doing programming, eventually found yourself in a programming role. But at the end of the day, all of these folks are normal folks. These are folks that happen to have these hobbies and build really cool things. And then those cool things eventually get adoption. It’s understandable too as well that a lot of these folks are just really doing cool things and it’s nice to focus on the output, the programs that they’re writing too as well, which I wanted to get into as well. We brought you on to talk about curl, which is a project you’re maintaining today and have been maintaining for quite some time, at least, actually, I don’t even know if I could put a number on it too as well, but do you want to tell us the-

Kathy: More than 20 years.

Brian: Yeah.

Kathy: Pretty impressive.

Daniel: Yeah. It’s actually 23 years now since I released the first version of curl. And then curl was actually a rename of the earlier projects that I also worked with before of course. So I think I’m approaching 25 years counting from the early days.

Kathy: Wow, 25 years on the same project. It was exciting to learn how exactly how curl became what it is today. Like so many projects, the foundations for it were out there and Daniel just wanted to make it better.

Daniel: When I learned about open source in general, and I learned about it, and I started to work on development in general, and I started working on different Unix systems and a lot of network related programming, and I was interested in that, so that was fun. And I did that in my everyday job then. I learned about IRC in those early 1990s. And you could find people online and you could chat in chat rooms or channels as they’re called in IRC. And when doing that, I realized that you could program bots in IRC. So I started that with a friend and we did an IRC bot, open-sourced and we released it and it worked. And we had that in our few chat channels.

And one day I realized that, hey, if you have a bot in an IRC channel, surely it should be able to offer some currency exchange service. Like how much is 100 Swedish crowns in US dollars today? Perhaps we were talking about some products in the channel, the price or whatever. So I realized that, well, how do you do a currency exchange for a bot in an IRC channel? I needed to download currency exchanges from somewhere. Well, they were available over HTTP, so I just needed a little tool to download stuff over HTTP. So I found one, it was called HTTPGet. It was a little bit over 100 lines of code. So I got that and I started fiddling with that and it was almost doing what I wanted. So I started to patch that and then sent back my changes to the author and that’s how it started.

So I continued to modify that until the author didn’t want my changes anymore and told me to maintain it myself, so I took over that project. And after a while, I also found currency rates on other protocols. One Gopher server that offered currency rates and then another FTP server, so I had to add support for those protocols. And then it couldn’t be called HTTPGet anymore, so I changed the name to URL GET. And then after a while, I had users already then. Then I don’t remember exactly why, but I had the support for FTP upload. And then the unit name, URL GET was silly because it wasn’t GET anymore. It was also the other way around, so I renamed it to curl in 1998.

So then at that point, it could speak to an HTTP, FTP, and Gopher and FTP upload and a few other tricks. So that’s how it started. And then in 1998, that was just a few hundred... Well, I think it was 2000 lines of code, a few contributors and a very simple little project. And I of course had no idea where I was going with that. It was just a little tool to download stuff and upload to FTP.

Kathy: That’s cool. So you go from this… I’m going to jump around a little bit and we can go back and forth and in between. But you go from this small 2000-line project that you were just describing to curl, and curl today is so ubiquitous. It’s shipped on so many different operating systems and I don’t know how many developers use it, you probably know. How do you feel about the fact that curl is so ubiquitous today? And are you cautious about shipping updates to it?

Daniel: Well, first of course, it’s a totally amazing feeling to just have that accomplishment for having done that. But at the same time, I feel a little bit like a lottery winner because it wasn’t really on purpose. It was just maybe a lot of good decisions along the way, but of course, I didn’t know it would end up like this and it wasn’t really... I’ve never really had the really, really long-term vision, this is where I want to go in the future, because I didn’t know. I still don’t know. I’m just playing by ear and making decisions day by day. But of course, it’s awesome. And yes, it makes me cautious. Now I estimate that curl runs in roughly 10 billion installations, and that’s a lot. That’s like we have like two and a half installations per internet user on the globe.

And yeah, sure, that’s the responsibility. And that makes me cautious and makes me think about... But not so much for doing upgrades or doing releases because I think that is fairly well, I mean, I’m doing my 200th release next week, so I’ve done releases a few times now. So I think that is cool. I think more of responsibility in how to, for example, speak the protocols, how to behave as a client, or how to be a good citizen on the network and stuff like that. So that I don’t push badness and generally into clients. And also since I then reached this position, I know a lot of people that look at how curl does things? How does curl implement whatever in the protocol stuff? So people are going to look at my implementation and copy that and say, “Well, they did it so we can do it too.”

So I think that’s something I’m cautious about. So I want to make sure that we do it at least reasonably well so that we don’t encourage badness just by people copying and mimicking our ways of doing it. When they do that, and I think it’s fine when they do it, but then I want it to be the good way to do it.

Brian: The responsibility of maintaining a massive project like curl is significant. I can understand why Daniel may feel like he wants to do well by his users. As the ecosystem grows, the use cases evolve as well. Daniel finds a lot of folks dependent on curl as part of their libraries. And with so many people using curl, he believes that a part of his work is to offer support since common issues pop up all the time.

Daniel: When people use libcurl, that’s just an internet transfer engine really, so that someone else will do something that uses libcurl. And, for example, one of the earlier users that is still a very big user is PHP. So when you use PHP and you do file transfers, you very often use curl to do that. So that’s an example where it very quickly becomes a problem for us when someone uses PHP and runs into problems with file transfers. That’s very common. And since it’s a big portion of our users, or I will say that, I mean, when I say 10 billion installations of curl, that’s 9.8 billion installations of libcurl. The command line is such a small part of that. So libcurl is that majority thing, and that is used by people who then depend on curl for their files or data transfer stuff. And that can be anything from a hobbyist up to the really, really big companies doing millions and millions of transfers per second.

Brian: You mentioned, a couple of times I picked up that you used the word “us” and “we.” I’m curious, how big is the team? Who’s contributing to this? How are you managing that?

Daniel: I always try to make sure that it’s not me. It’s not “I.” There’s no “I” in team. But no, it’s actually not my project, it’s not. I’m not Mr. Curl. Well, I can be Mr. Curl because I do more than half of all the commits, but it certainly is a very large amount of people that actually are helping out and have helped out over the years and all the time. So it’s really a “we,” even if I’m maybe the captain and I have the final say in a lot of things, I’m also, well pretty much maybe the architect of a lot of stuff, but there’s a lot of people helping out. So the team, depending on how you define a team… I think we’re about, usually around 12, maybe 14 people per year, who make more than 10 commits to the project.

So it’s not a big team in that regard, but then we have a very long tail of people who are just one-time committers or just drive by, pull request once, and then we never see them again. So we have around, I think maybe 100 first-time committers per year or so. So there’s a lot of that. And of course, I want to make sure that they’re not just a one-time committer. I want to make sure that they’re at least two times, but get them to stick around and help out with more stuff. Because if they’ve been over the threshold to land one change, it’s easy for them to make another one too.

But at the same time, everyone is welcome to help out. I don’t mind if they do it just once either, as long as it helps the project, it’s a good thing. And I’m trying to make it really as a policy, to make sure to give credit where someone else has helped out. I make sure that they get the credit for their changes. And I thank everyone who has helped serve. So that’s what I can pay people with, right? So that they get proper credit for helping when they do.

Kathy: Given the number of people that contribute to curl at various times, I wondered if there are times when Daniel is surprised by the content of the contributions.

Daniel: I would say both yes and no. I think in general, people are actually pretty conservative with what they actually offer. So it’s very rarely that they actually offer something totally crazy that goes completely against everything that curl is or has ever done. So it’s not that people suddenly introduce a Windows system on top of everything or a game. It just doesn’t happen. But I would say that I’m sometimes surprised by the effort that apparently people have done underwraps and suddenly they unveiled one day that’s wow, “I want to do this,” and they unload 4,000 lines of code in one single patch and say, “Here, have a play with this.” That surprises me and I try to discourage people from doing that, of course, because it’s a horrible experience to receive that and work with that.

But I also often find myself in the other end that I’m surprised by also by some people. And this happens actually fairly often that people bring something they want to have in curl, that is a fair feature or a change, and they want to push it and they go 80% and then they vanish and it sits there lingering. “Yeah, that’s an 80% implemented thing. What do I do with this?” And if it’s really good, I could work on it myself, and if I really wanted to and I have the energy. But if I don’t, it’ll just be dropped in a while. It’ll no longer much clean and there’s missing, there’s no tests there and there’s documentation missing and eventually we just close it and it’ll just die. And that happens, I think surprisingly often. And it always surprises me because someone has gone through a lot of effort to bring it to that point. So what makes them stop at that point and not hit all the way? So, yeah.

Kathy: Yeah. Do you have any ways that you tell, is it a lot of people asked for this or is it something you wanted yourself?

Daniel: Yeah. If it’s one of those two, it’s really easy, right? If there’s a lot of people asking for it, then you know that there’s clearly a demand and an interest. If there’s something I want, then I have an interest to push for it. But I of course try to not want things just for my own silly purposes, but those are fairly easy cases. It’s much harder when someone brings in something that is a protocols feature you read about three years ago, and now they say, “Well, we want to do this.” And it’s fairly big and clunky, but they’ve documented it. And there are test cases and, “Is this good? Should we have this or shouldn’t we?” Yeah, there’s no easy way to say yes or no to that. You just have to go with, “Well, yeah, ask some others.” See what the interest is among the community and then just guess, get a feeling.

Kathy: Yeah. Just go from there.

Daniel: Exactly. Yeah. Maybe it’s good. Sure. And I think, we also, in libcurl, we try to never change behavior and not break existing behaviors. So once we have adopted it into the code, we basically will never yank it out. So it’s a pretty big investment too. So if we take it on, we take it on forever basically. That’s also why I want to make sure that the pull requests and the changes are complete before I adopt it. Because it’s also a life lesson that the second I adopt it, I’d say, “Sure we’ll merge it,” and the contributors vanish. And in nine times out of ten, we never see them again. So it’s really, really, now it’s your ball. You have it on your part of the track now. It is so obvious so many times.

Kathy: And you don’t want to feel stuck with it.

Daniel: When I get it, I want it to be good enough so that I can be stuck with it. I don’t want to have something half broken, half decent thing that I have to fix and clean up for a very long time going forward once I take responsibility for it.

Brian: This is going to make for a very bad joke. I used to be a… my role at GitHub is to create tech debt. So I tend to institute a lot of new programs and projects and then hand them off to other teams. So it’s the best part about my job.

Kathy: Maybe I shouldn’t have asked you for all that help with the documentation open source project.

Brian: Yes. Well, I’m happy to get it started, but I’m also happy to hand it off too as well.

Kathy: There’s a lot of responsibility that comes with maintaining a project of curl’s size, but also a need to keep building and growing. Since the team is relatively small, Daniel has built a system to do this while being transparent with all the users who depend on it every day.

Daniel: We have that discussion often in that discussion around, “Should we merge this or not? Is it good enough? Is this a feature we want? Is it done in the way we want it?”

And then recently, during the last two years or so, I’ve actually introduced a new way to do it, play it a little safer by naming or labeling things as experimental. And then with that, I then reserve the right to change behavior and yank it out again, if we don’t want to. So that way we can actually land stuff, just brand it experimental so that nobody will actually rely on it really hard without the warning signs. So that allows us to bring in a few things. And if we really don’t like it, we can take it out again or remodel it if we come up with a better way to do it or stuff like that.

Kathy: And you’re talking about when you actually ship something, it’s labeled as experimental, so that when people are using curl-

Daniel: Yes. Basically we only really ship source code. We don’t actually ship the binaries from the projects so we just ship them marked as experimental in the source code. So that means that someone will actually have to enable it by opting into enabling that particular feature. For example, right now SP3 support in curl is marked experimental. So if you want SP3 support when you build curl, you actually have to enable it. And then you know that it’s yes, you enabled it on your own. You are on your own when you do that, don’t do that in production please. If you do it, you at least know that we told you about it.

Kathy: Okay. So every PR that I ship of Brian’s, I will mark as experimental. Noted.

Daniel: Exactly.

Brian: Fair enough.

Daniel: Warning, warning.

Kathy: Yeah. And then is there like a certain amount of time that passes? Do you accept... you ship it as experimental, when does it become, officially, part of the project?

Daniel: Yeah. The idea I’ve had is that by having them experimental, we will have people that are actually trying them out and reporting bugs and we’ve polished the worst side effects of them and so on. And then when we feel that they’re mature and people are actually, they have some sort of demand for these features, we unmark the experimental and we ship them and maybe it’s switched so that they become opt out instead of opt in or whatever. And then everything is fine and dandy. It doesn’t really work that good in practice, because the harsh reality is that experimental features are rarely ever enabled by users. So they’re actually not used as much. So it doesn’t actually work as good as I want them to, but that’s more of a work in progress.

Brian: While curl is Daniel’s main focus, he did work at Mozilla and left that job in 2018. There’s always a push and pull, between getting a job and doing open source full time. I wanted to know more about the position at Mozilla and ultimately, what made Daniel decide to pivot?

Daniel: When I worked on Mozilla, I worked in the Necko team as it’s called, that’s the networking team. So it handles everything that is HTTP, DNS cookies and sockets and stuff like that, but within Firefox. So that was what I was working with. And I had permission to work a little bit on curl on work hours too, but curl was never a focus for Mozilla at all. So yes, I had permission to work on it, but they didn’t really care about curl.

Brian: So was that-

Daniel: It was a really good sort of CV thing to have when I got the job, of course, because I’ve done this, can I get the job with you?

Brian: Yeah. I guess my next question would have been, so how did you balance these contributions to curl knowing that if you’re less than 12 people who are doing more than 10 commits throughout the year, were you able to maintain the contributions and the project during that time?

Daniel: Well, I worked with curl as a spare time project for 19 years, or 20 years before I started doing it full time. So I have a long time and practice of doing curl in my spare time. And yeah, I’ve spent a lot of spare time hours doing curl. Of course it’s been a challenge, it’s been ups and downs, and depending on my life and what I’ve done for real work in day to day, but sure, it’s been good. It’s been up and down. I think sometimes that has also of course been like a break. And if I’m slow at accepting changes or slow at feedback, it of course slows everything down. In general, I think we’ve had a good run and I don’t think my lack of attention or my limited work hours have been an obstacle or break here. So of course it’s a challenge to run a project like that on your spare time.

Kathy: When did it kind of... Since you’ve been running it--you run it for so long by yourself. When did the project take on a life of its own?

Daniel: Yeah, never. I mean, I still do, I think according to the stats, I’ve done 57% of the commits after 23 years and that’s out of 27, 26,000 commits. So I still do a lot of it. So I’m not sure if it actually has gotten a life of its own, but sometimes I was... Maybe that’s because I haven’t let it. Because I still think it’s that fun, I want to do this myself. So it’s not that I’m in a desperate need for someone else to do a lot more because, as long as this works, and I’m having fun, I don’t mind. It’s good stuff.

Kathy: By doing close to 60% of the commits, Daniel’s role as the captain of the ship is certainly solid. Given how long he’s been working on curl and all that it demands from him, does he ever imagine retiring as captain?

Daniel: I think at some point I can say I won’t be the captain anymore. I fully believe that, but I don’t see it happening anytime soon just because I think this is fun and this is what I want to do. So I don’t think, as long as I want to do it like this, I don’t see myself stepping down from this position. But I think if I wanted to step down now, I think it would work fine. I think someone else or someone, a team would step up and do what’s necessary to continue with stuff. But being done, I think a project like this is never done, because the internet and how we do internet transfers is evolving and changing all the time. So we need to just keep changing curl just to keep up with the internet and how it evolves. So I’m sure that as long as everything keeps changing as they are, we’re going to keep changing curl too.

I think anyone who was doing anything like this, of course there are moments, maybe not when I questioned if curl is the right... but maybe at some times, if I sometimes get a problem or struggle with something, I could just throw my hands in the air and say, “Maybe this is crap, I can never fix this problem.” And get in doubt whether I can do this. And then two minutes later, I figured it out and everything is good again. I think maybe me and curl were more friends, are better friends now than ever, so that we’ve gotten to know each other. I know how to work with it and how to keep my interest at a good level pretty much all the time. A lot of the code has been with me for such a long time and I’ve written a lot of it. It’s really how I can just scroll through any random part of the code and recognize it and I can have a feeling for it. I don’t remember everything, but I can get a sense for what it is. So many times I also have memories from when I wrote the code, I can remember use cases for why stuff is like that. So yeah, I certainly “feel it” like that.

Brian: I’m curious about that change too as well, and the pace of keeping change. So day-to-day, I run a lot of JavaScript. And it’s not a secret that the JavaScript ecosystem turns over every couple of years, where new things become the shiny new thing, and everybody runs to that. But it’s something to say like 23, 24 years of curl existing being dependent on projects like libcurl or libcurl being dependent on curl, that there’s something to say about that consistency. So I’m curious though, of the alternatives to curl. Do you see any of those getting enough adoption that, and I don’t think libcurl’s going to say, “Hey, we’re going to try this new thing or HTTPie.” But do you see future frameworks, future protocols saying, “Hey, we’re going to try this new thing?”

Daniel: Yeah, sure. I’ve never been good at foreseeing what’s going to happen in the future. I was never good at that. I’ve never even tried it, so it just happens like this and I’m taking decisions day by day, but sure, anything can happen tomorrow. I think what actually makes libcurl better and better over the time is exactly consistency, because it’s proven that we can be consistent with our behavior and how to do things. And we can do it for 20 years. Libcurl didn’t exist the first two years, right? So it’s actually, libcurl is two years younger, but we have supported the same API for, forever.

And when it comes to an internet of billions and billions of devices and machines and service and everything, consistency is very, very appreciated and valued. So it’s really hard for someone else. It’s hard for other ecosystems to come up with a good replacement in the short term, because consistency is key and golden and you don’t get consistency by something that you introduce now or tomorrow. And of course we get a lot of competitors and alternatives to curl and libcurl that shows up and goes away again in two years. And that’s been like that all the time, right? But it’s hard for me to say when they become a real contender, when will they replace curl and libcurl? At some point, something will do, I’m sure. But I don’t know when or how it’s going to look like.

Kathy: Ultimately one of the things that has kept curl so successful for so long is reliability. We trust the tools, and the people behind them.

Daniel: You can upgrade curl to the latest and you know that your old scripts, your old programs, they will remain working the same thing because we don’t break things. We don’t break behavior. We don’t break APIs. If we promised behavior before, we will maintain that at a very high cost. But I think that’s consistency and that’s the trust that our users expect, and they know that we can deliver on that. So I think that’s the reason why curl and libcurl are in the positions they are.

Kathy: Oh, one thing we didn’t really touch on, just to jump back to the Mozilla conversation. Why did you leave Mozilla?

Daniel: Well, two things really. First, I felt a little bit stuck as a developer. Not because it’s not a fun thing, because it’s network stuff and I’m interested in that and HTTP and everything that I enjoyed with curl for so long. But Firefox is a big thing, millions and millions of lines of code, and a very complicated… hundreds of threads and objects and C++. And it’s actually a very, very heavy ship to bring forward and to do changes in. And it’s a complicated thing with a lot of bugs and a lot of incoming bugs all the time. It’s actually, I think over time, a pretty stressful situation where it’s really hard to do things, bug fixes or bug reports arrive faster than you’re able to fix them.

And also we had a really hard time for a while there when our development team was decreased significantly. So I jumped ship and I quit before I knew what I wanted to do or how I was going to do it. So I just... I better get rid of this and figure out what I want to do instead.

Kathy: curl has held Daniel’s interest for a quarter of a century. While he was at Mozilla, he found himself somewhat uninspired but curl continues to be the thing he wants to work on, to improve and to engage with. That’s why he ultimately left Mozilla.

Daniel: I could have done something else within Mozilla. So I’m sure I could have found something else to do within Firefox. But first I feel that my area of interest is... not that I wouldn’t want to go totally completely out in a different side of everything, because I’m not really interested in that kind of development and that kind of maybe those languages or problems in those areas. I wouldn’t be interested in them. So I wanted... I’m still interested in networking. I’m still interested in that kind of work, so I wasn’t really prepared to go completely wild. So that’s one reason why I didn’t really see a future, and also my problems with my manager also made me decide that pretty quickly. So it was that.

Boredom is one word I use, exactly. But then I’ve been working with curl for 20 years, so why am I not not bored with that? And I really can’t explain that as good. But when it comes to curl, it’s actually more of a product exactly how I wanted it to be. And I’ve been able to work on it for this long, and I’ve actually refactored it many times and now the internals are very different than they were from the beginning. So I’m actually pretty happy with it. So I’m not actually bored with it. I’m actually more happy with it. And I’m keen on making sure that it actually gets even better and more advanced and more polished going forward. So I’m not bored with it.

Brian: It is wonderful to be able to dedicate yourself to the project you created. Daniel has maintained a project with a handful of contributors year after year. What are the things that he wishes projects would do? What norm would he wish other projects to adopt?

Daniel: Well, I want to be the project that has a really low bar for newcomers and contributors to start doing things. And of course, to do that, everything has to be laid out so that you can figure it out yourself when you do your fork of the project, you do your pull request and you want to submit it. So I want to make sure that everything is there, documented, no weird processes or things, obstacles in the way for doing that. Actually, I know a lot of projects that knee jerk reaction to getting those spell checked pull requests that just changes one word in a comment and say that’s a bad thing, but actually I think that getting those pull requests, it’s actually a good sign that it’s easy to do that or easy enough to do that at least.

And I think that’s the kind of project I want to be. And I think a lot more projects should strive to lower the bar for contributions, because I think as I said before, getting the first contribution from someone, that’s the first step, right? And then you can get the next one. Maybe the next one isn’t just the silly spell check. Maybe the other one is actually fixing the documentation and fixing a test case, or actually improving things or finding, fixing real bugs. So I think lowering the bar for contributions is one of the primary things an open source project should do.

Brian: I’m curious, what’s your thought on the current generation of younger programmers too as well? Because curl’s written in C, a lot of the projects I’ve actually gotten involved in they’re really written in JavaScript. So I’m already a step removed, quite a few steps removed from C. What are your thoughts on the future generations of how we write code and these programmers?

Daniel: Well, first of course, I think that less and less programs are written in C, and I think that’s actually how things are supposed to be. So I think C as a language is of course a diminishing part of everything, but at the same time, I think we’re at an interesting era or period of time. And we’ve been for a while actually, when the amount of software is growing so fast, so that the amount of software in the world is growing probably faster than the amount of engineers that are supposed to take care of all the code. So even if I say that there is less C programming needed, it’s still a very vast amount of C programs that still needs programmers. But there’s also a very vast amount of JavaScript and Rust and Go and all the others. There’s just a lot of everything. So I think there’s going to be a need for developers and engineers in all of these areas, even if some of them are going to grow more than others, but there’s still a lot of everything.

Brian: Yeah. And I even missed a correlation too as well, because you had mentioned libcurl was heavily leveraged by the PHP community. And with curl getting started around 1998, around that time, I believe. Is that the year that you threw out earlier?

Daniel: Yeah.

Brian: Web 2.0, that’s really when I really got involved into programming and getting involved and stuff, and that was PHP. That was Perl. And all the sites that I used, like Myspace and now Facebook and a couple other sites, all leveraged the next generation of languages as well. So basically, in my mind, I’m coming to the correlation and also the epiphany of even now with our Gen Z coders, they’re taking on the next level thing. So perhaps the No-Code Movement maybe becomes a thing, continues to become a thing. I’m here for it, for sure.

Daniel: Yeah. So exactly, so there’s always another layer on top of all the old stuff, but the old stuff doesn’t really just go away because of that, because someone still needs to maintain that and make sure that it works or gets replaced in a sensible way.

Brian: Yeah. And I applaud you and thank you very much for having the interest in continuing down the path of keeping curl moving forward and supporting so much stuff that I do. Every now and then I love just writing a quick curl command into the GitHub API, getting the data I need--or not even data I need, I just want to review some repos, datas, labels, issues. Out of the box, it’s always the first place I test my APIs, is to just quickly run a curl command. That’s my only use case, but I know there’s so many other use cases for curl for sure, so thanks.

Daniel: Right. But it also has become a little bit of that. A lot of people document their APIs by showing the curl command line how to use it, right? So that’s another thing that has been in curl’s favor, the entire growth of rest APIs and stuff like that, and the use of curl to drive those APIs.

Brian: Yeah. Yeah. That’s true. That’s a good point also I missed as well, because yeah, all through the GitHub API, every single one of the reference docs endpoints all have a curl command, and then it has the Octokit command next to it. And so choose whichever way you want to do it, but the beauty of curl is that it’s not specific to my environment or my operating system. I could run that curl command at other places.

Kathy: Daniel is a legend in Open Source and his work has changed the face of the architecture of the internet. What advice does he have?

Daniel: Well, I think it’s hard because it’s of course hard for someone to tell someone, “Yeah, you should just stick with it for a long time and then you will succeed.” But I’d rather look at it from the other side and say that I think one of the reasons why you can succeed with something like curl is by sticking with it and enduring and being. Just keep at it because that’s a way to succeed eventually. Because not a lot of things is an immediate success. Curl certainly wasn’t. I mean, it took years before I even got a fair amount of users. And it doesn’t mean that everyone has to spend years to actually find success, but it certainly... I think getting things quick is not... I mean, succeeding in something sometimes means that you have to stick with it for a while and work on it and really believe in it and just be there and make sure that it actually ends up being that thing you want it to be.

And of course, saying that to someone who thinks... I get that question a lot by people who say that, “Well, how can you stick with one project for so long?” Because someone, a lot of people say that they have to change projects every few months because they get bored otherwise. Sure, and that’s a fair thing, but if you switch projects all the time, maybe no project will ever be good enough to actually hit to any level or succeed at any particular... I mean, reach something. So I think to really get somewhere, I think you need to spend time and effort, and how much? It will of course depend. If you’re a genius, you can do it in a really short time, but most of us aren’t geniuses, we just do things.

Brian: It was great to speak with Daniel Stenberg and have him on the ReadME Podcast. To learn more about Daniel and curl, please visit curl.se.

I am Brian Douglas, and I am a developer advocate here at GitHub.

Kathy: And I am Kathy Korevek, I work in product. The ReadME Podcast is a GitHub podcast that dives into the challenges our guests faced and how they overcame those hurdles. In sharing these stories, we hope to provide a spotlight on what you don’t always see in the lines of code, and what it took to build the technology that inspires us all.

Brian: It’s been really great spending time with you. The ReadME Podcast is part of the ReadME Project at GitHub, a space that amplifies the voices of the developer community: The maintainers, leaders, and teams whose contributions move the world forward every day. Visit GitHub.com/readme to learn more.

Our theme music has been produced on GitHub by Dan Gorelick with Tidal Cycles. Additional music from Rhae Royal and Blue Dot Sessions.

The ReadME Podcast is produced by Sound Made Public for GitHub.

Please subscribe, share, and follow GitHub on Twitter for updates on this podcast and all-things GitHub. Thanks for listening!