Daniel Stenberg - Uncurled

Daniel Stenberg

Uncurled - everything I know and learned about running and maintaining Open Source projects for three decades.

I have been actively involved in Open Source development since the early 1990s when I discovered the phenomenon of people writing source code they give away freely for others to use and modify under a certain license.

I have started, lead and maintained many projects over several decades, out of which the most known one is probably the cURL project I founded and have been leading since 1998. I have contributed to and participated in many more projects and I have of course used and kept myself up-to-date with a large number of projects in which I did not personally participate.

I first learned to program on the Commodore 64 as a teenager 1985 and after some years I transitioned over to C programming, first on Amiga and then on Unix systems. I released my first source code to the public in the early 1990s - years before the term Open Source was first coined. I have since then spent many hours every week throughout my entire life contributing to Open Source projects, my own and others. I have worked exclusively with Open Source professionally since 2014 for Mozilla and since 2019 for wolfSSL.

Because of my background and life with Open Source and probably a lot because of the relative success some of my projects have had, I frequently get questions about subjects related to maintaining Open Source. How to run a project and what makes them succeed? For a long time I have been collecting lessons from my life with Open Source into a list of advice for fellow Open Source library hackers. This document is my attempt to convert those thoughts and experiences into words.

This document is written with you as the intended reader. You are someone who is interested in Open Source and keen to get started or maybe you already are a maintainer and want to get further insights in how other maintainers go about doing Open Source. You might do Open Source in your spare time or work on it full-time as a paid employee.

I am not suggesting that everything I write in there will be a match for you or a good idea for everyone. One of the best features with Open Source is that there is always more than one way to do things and that everyone is always free to go their own way should they decide to. I give you my take and my advice. You are free to decide what to do with it.

I suppose this is another one of those things we all end up doing: Write a printf() implementation, create an IRC bot, and author a book about Open Source.

/ Daniel Stenberg, April 2022

You find details about the author of this book, Daniel, on his site.

The contents of this book is maintained and updated in its git repository hosted on GitHub.

The canonical URL for this book is https://un.curl.dev. The book is rendered to web format by gitbook.com.

If you find a problem or error in this book, or only want to request additional details or a clarification, submit an issue or propose a change directly with a pull request.

The contents of this book is licensed as .

I will use some of these terms in this book.

The Open Source label was created in February 1998 by a team of individuals who would subsequently create the organization Open Source Initiative that same month.

Open Source is a ten-point definition declaring that if those requirements are all fulfilled, a software component qualifies as Open Source. It should allow free redistribution, modification, derived works, not discriminate against any person or field of endeavor etc.

Proponents of Free Software often underscore that there is a difference between Free Software and Open Source, but in practice, looking at the requirements and the licenses involved, those differences are more distinct in the communities and how they operate rather in how they are defined in text.

Open Source was an effort to create a term that emphasizes the open aspect, as a more commercially friendly phrase and concept than how many people perceived Free Software at the time.

The Free Software movement is oriented around the Free Software Foundation that was created in 1985. Free Software has their four freedoms that decide if a software qualifies. The freedom to run it for any purpose, to study how it works and to change it, to redistribute it and to redistribute modified versions.

Note that there is no mentioning of price or commercial in there. Free is used here as in freedom, not as in price or cost.

Free and Open Source Software (FOSS) is a commonly used acronym meant to include software that qualifies as either Free Software or Open Source.

There are both longer and shorter versions of this being used:

Free, Libre and Open Source Software (FLOSS) is an attempt to emphasize the libre part as in freedom and not price.

Open Source Software (OSS) leaves out the Free Software part but generally it refers to the same group of software, maybe just not as technically correct.

This book is divided into eleven separate sections based on topic, in which I talk about a set of specific Open Source items, questions or concerns.

1. . Stories from half a dozen Open Source projects I have created or joined and spent a significant time and energy in.
2. . Some words and advice about getting started with Open Source.
3. . I have learned something about working with humans after a while.
4. . Lessons and insights about project specific things.
5. . Conclusions about the monetary side of Open Source.
6. . The code is certainly key in a project and there are clues for us there.
7. . A really important area that we must never ignore.
8. . What is it and what does it take to be a project maintainer?
9. . Let me take you with you on a little journey and show how Open Source has developed.
10. . Can you be a successful Open Source maintainer and have a life at the same time?
11. . A collection of interesting questions and feedback that I received over the years.

I have participated deeply and properly in several Open Source projects and in this section I will describe some of those projects. How I got into the projects, some of the specifics of the projects, my position in the project and perhaps something I learned from that particular one.

This is not meant to be an exhaustive or complete list.

Soon after I started a new software developer job in the autumn of 1993, I discovered IRC, Internet Relay Chat. I immediately joined channels (that is what chat rooms are called in IRC speak), socialized online and made friends online with people from around the world.

On IRC, I soon discovered that not all clients were actual users. Some of them were automated programmed robot clients, called bots. All channels I frequented had at least one. One day an IRC friend of mine from Denmark, Bjrn, showed me his embryo of what would become his own Open Source bot. I immediately joined the mission of writing a bot. For the fun, for the education and to be able to make our bot do everything we would like a bot do in the channels we frequented. We called it Dancer from the fact that it served in a Danish channel at first. Dane Serv become Dancer.