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.
The author
Daniel Stenberg is a Swedish programmer and the creator of curl, one of the most important open source projects in the world. 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
The book has many sections:
- Introduction, where the author explains the meaning of some fundamental and commonly used terms.
- Experience, where the author tells his personal experience in developing and managing open source projects (such as Dancer, curl, libssh2 and Firefox).
- Start, where to find the basics to start an open source project.
- 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, how to deal with criticism (and insults).
- Project, closely related to the previous section, it continues to investigate and explain the close correlation between people, open source and good neighborly relations.
- 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.
- Source, where Daniel explains how to manage contributions from other developers, documentation written by others and other aspects more strictly related to the code.
- Security, where the author explains the most common problems for creating secure code, and how to deal with bug hunters.
- 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.
- Evolution, or how the world of Open Source has changed in the last three decades.
- Life, how to manage your life and not neglect your family. My wife is very grateful for this chapter.
- 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 quantity of topics covered, there are about seventy pages full of topics, suggestions, ideas and food for thought.
My thoughts
There are some things that made me think and I want to keep a note of.
Sometimes one project leads to another, as for cherries. It is a common aspect in all creative processes. Solving mathematical, computer and logical problems is no different: starting from a particular problem, many other problems are encountered. And often there is no other way than to solve them in order to go 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 that my projects are basically 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 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 more 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, the search for a solution involves asking the person who proposed that solution.
Expect insults. I know it doesn’t make sense, but it is. 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, 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, and to dedicate the time they can to Open Source. 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. There are those who consider women less capable, those who have racist ideas, those who are intolerant towards other religions, and so on. It sucks, but that’s the way it is. Fortunately, there are also many Open Source projects that 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 kind of projects is given by perseverance, by continuing to update the code, by keeping it alive through the various vicissitudes.
Don’t expect money. If a library is well done, and well maintained, and works, then it will be used. And even large industries will use it. But they won’t donate, pay nothing, and often won’t even notify 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, or is not tested, or is not valid, then you can wait before going public. As I said before, life takes precedence, so does the family, and the health of our collaborators, and therefore also of us. 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.
So in closing, I really recommend reading Uncurled.
