Uncurled — Everything About Open Source | by Samuele | Aug, 2022

Delving into many truths of the open source world

Photo by Luke Southern on Unsplash

Today I want to talk about Uncurled (everything I know and learned about running and maintaining Open Source projects for three decades) by Daniel Stenberg. This is an ebook that contains anecdotes, tips, and considerations on how to manage and maintain an open source project.

Daniel Stenberg is a Swedish programmer and the creator of Curl, one of the world’s most important open source projects. In his ebook, he tells the story that led to this project well, and also its evolutions. Since the book is free, I recommend reading the Experience: Curl chapter directly from his pen.

The book has many sections:

  1. Introduction, where the author explains the meaning of some fundamental and commonly used terms.
  2. Experience, where the author tells his personal experience in developing and managing open source projects (such as Dancer, Curl, libssh2 and Firefox).
  3. Start, where to find the basics to start an open source project.
  4. People, perhaps the most complicated (for me). It explains how to manage and maintain a group of people, how to behave in some common situations, and how to deal with criticism (and insults).
  5. Project, closely related to the previous section. It continues to investigate and explain the close correlation between people, open source, and good neighborly relations.
  6. Money, or how to self-finance an open source project. Or, in another way, don’t quit your daily job hoping that open source will pay you the rent.
  7. Source, where Daniel explains how to manage contributions from other developers, documentation written by others, and other aspects more strictly related to the code.
  8. Security, where the author explains the most common problems for creating secure code and how to deal with bug hunters.
  9. Maintainer, another very interesting section in which the necessary tasks to maintain an open source project are addressed. And, consequently, the responsibilities of a maintainer. Spoiler: there are many more things to do than what one expects.
  10. Evolution, or how the open source world has changed in the last three decades.
  11. Life, how to manage your life and not neglect your family. My wife is very grateful for this chapter.
  12. Emails, a collection of emails Daniel has received over the years. Why, when your email appears in the credit of a car, do you want to not be responsible for the whole car?

As you can see from the number of topics covered, there are about seventy pages full of topics, suggestions, ideas, and food for thought.

Photo by Mitchell Hartley on Unsplash

Some things made me think, and I want to keep a note of them.

Sometimes one project leads to another, as for cherries. It is a common aspect of all creative processes. Solving mathematical, computer, and logical problems is no different: many other problems are encountered starting from a particular problem. And often, there is no other way than to solve them by going back to the original one. I think it is one of the most beautiful aspects of programming. And even more frustrating.

Perfect is the enemy of the good, and sometimes the good is enough. Indeed, sometimes even the mediocre is good for solving a problem. And even if a problem is a problem, a solution is a solution. And it is often best to start with a solution and then change it if necessary.

Open source often means solo work. I don’t know why, but it struck me. Yes, I know my projects are all the result of my work. And as much as I insist on leaving them open source, well, it’s more of a lone cowboy job than a team job. Finding out that this is the norm has somehow reassured me. And somehow scared me too.

Complaints make more noise than compliments. And this, alas, is true in almost all fields. When you curate an open source project, or anything else for free, it is filled with the voices of those who complain rather than those who thank. It is understandable: those who use one of my libraries want a solution. If all goes smoothly, there is no reason to wonder why. If something is wrong, searching for a solution involves asking the person who proposed that solution.

Expect insults. I know it doesn’t make sense, but it is true. The only thing to do is to stay calm and not respond in kind. Maybe wait a day before answering, and do it with peace of mind. And if that doesn’t work, lengthen the response times a little at a time until the conversation drops. There is no open source project worth ruining your day.

People go and come. It applies to those who insult; it also applies to those who give a hand. Each of us has our own life, our own problems, and our own priorities. Any contribution is welcome. And even those who are unable or unwilling to contribute are welcome. That’s okay, and there’s no problem.

Life takes precedence. Your own life and that of your collaborators. Everyone has the right to live their own lives and to dedicate the time they can to an open source project. No one has the right to judge, or to argue, the way someone else spends their time on the project. It is about donated time and voluntary work.

There are prejudices. Even in the open source community, there are prejudices. Some consider women less capable; some have racist ideas; some are intolerant towards other religions, and so on. It sucks, but that’s the way it is. Fortunately, many open source projects are active against these prejudices. And, personally, I find they are the ones where you can breathe the best air.

The success of an open source project is given by time. It doesn’t matter how many people use a given program or library. Success in this project is given by perseverance, updating the code, and keeping it alive through the various vicissitudes.

Don’t expect money. If a library is well done, well maintained, and works, it will be used. And even large industries will use it. But they won’t donate or pay anything, and they often won’t even notify you that the library has been used. That’s how open source works, and there’s not much to do.

All changes can wait. If a change is not ready, is not tested, or is not valid, then you can wait before going public. As I said before, life takes precedence. So does the developer, their family, and the health of our collaborators. Nothing bad happens if an update comes out a little later than usual.

Things change. So is the open source world. With today’s tools, it is much easier and cheaper to manage open source code. Just think of GitHub. Maybe we are living in the golden years of open source. Or maybe the future will be even better.

Thanks for reading.

I highly recommend that you read Uncurled.

News Credit

%d bloggers like this: