This is a frequently asked question: how will I handle the situation if/when I step away from the curl project? What happens if I get run over by a bus go on a permanent holiday tomorrow? What’s the contingency plan?
You would perhaps think that it could affect a few more things that I work on than just curl, but I rarely get questions about any other things or projects. But okay, I have since long accepted that curl is the single thing people are most likely to associate with me.
I’m not leaving
Let me start by saying that I have no plans to leave the curl project any time soon. curl is such a huge part of my life I would not know what to do if I did not spend a large chunk of it thinking about, talking about, blogging about and working on curl development. I am not ruling out that I might step back as a leader of the project in a distant future, but it sure does not feel like it will happen within the nearest decade.
I am far from done yet. curl is not done yet. The Internet has not stopped evolving yet.
Also: the most likely way I will leave the project in a distant future is slowly and in a controlled manner where I can make sure that everyone gets everything they need before I would completely disappear into the shadows.
This is not a solo show
I also want to stress that curl is not a solo mission. We have surpassed 1200 commit authors in total and we average in 25 commit authors every month, with about 10 new committers arriving every month. My share of all commits has been continuously shrinking for many years.
Documented
A healthy and striving open source project should stand on its own legs and not rely on the presence or responses of single contributors. Everything should be documented and explained. How things work in the code, but also how processes work and how decisions are made etc. Someone who arrives at the project, alone in the middle of the night without network access, should be able to figure out everything without having to ask anyone.
I work hard at documenting everything curl as much and as well as possible. My ambition is to have curl stand out as one of the best documented projects/products – no matter what you compare it against.
Distributed responsibilities
If a single maintainer vanishes tomorrow, the project should survive it fine. Redundancy is key and we must make sure that we have a whole team of people with the necessary rights and knowledge to “carry the torch forward”. We invite new maintainers to the team every once in a while so that we are at least a dozen or so that can do things like merging code into the repository or updating the website. Many of those rarely exercise that right, but they have it and they can.
A single maintainer’s sudden absence can certainly be a blow to the project, but it should not be lethal.
My “BDFL role” in curl is not enforced by locking others out. There is a whole team that can do just about everything in the project that I do. When and if they want to.
Accounts
I have logins and credentials to some services that the whole team does not. I use them to upload curl releases, manage the website and similar. My accounts. If I am gone tomorrow, getting into my accounts will offer challenges to those who want to shoulder those responsibilities. I have a few trusted dedicated individuals appointed to hopefully manage that in the unlikely event that ever becomes necessary.
BDFL
(Benevolent Dictator For Life)
I may be a sort of dictator in the project, but I prefer to see myself as a “lead developer” as I hardly ever veto anything and I always encourage discussions and feedback rather than decreeing my opinions or ways of working onto others. I strive to be benevolent. I do not claim to always know the correct or proper way to do things.
When I leave, there is no dedicated prince or appointed heir that will take over after me, royal family style. Sure, someone else in the ranks of existing maintainers might step up and become a new project leader but it could also very well just become a group sharing the load or something else. It is not up to me to decide or control that. It is not decided ahead of time and it will not.
Similarly, I don’t try to carve my vision of curl into some stone tablets to pass on to the next generation. When I am gone, the people who remain will need to drive the ship and have their own visions and ideas. The kids got to do their own choices.
Legacy
I don’t care about how or if people remember me or not. I try my best to do good now and I hope my efforts and work make a net positive to the world. If so, that is good enough for me.
Thanks for looking out for the community and your users! I do still hope that you do not get hit by a bus, though.
That’s always a complicated topic and you seem to have addressed it right. We’re all aging, I know that some users are getting concerned about what they modestly call the bus factor but in fact also relates to the increased risks of heart attacks, strokes, diseases etc that start to be more frequent after 50. And it’s legitimate.
I noticed when answering such questions to some haproxy users that they are often very surprised to see that it’s something critical to the maintainer or bdfl to address. Usually they don’t realize that a project you’ve been working on for 20-30 years is like your kid and you want it to outlive you, so a lot of precautions are taken, like spotting backup people, making sure they’re known, trusted and respected by the community etc. But once it’s explained usually it makes a lot of sense to them and they’re reassured.
I feel more and more (maybe because I’m aging too) that I need to clarify this point. It’s difficult to speak about this because it tends to scare people (“is he talking about this because he’s secretly sick?”) and generally it’s a bit taboo. Backup people that you trust feel uneasy with envisioning the moment they’ll have to take over and don’t want to be perceived as waiting for the throne. I found that combining the explanations of how tools/infrastructure issues are addressed and how other people are ready to catch up is generally sufficient to reassure users. We all know that such a transition is never easy and will definitely have rough edges, but it needs to be openly considered to limit the difficulties, and even repeated so that users don’t get worried anymore by hearing about it over time, till the point it happens and they think “ha! I was right, he was hiding something” but everything ends up smoothly enough.
BTW the part on the doc is very true. I even share with several people an up-to-date release howto (that’s very boring and still too complex for my taste), in part to be sure that missing it cannot be presented by them as an excuse for postponing a release 😉
So thanks Daniel for opening the topic 😉
@willy: good point about age. As Open Source is growing older, more and more of “the old guard” is going to grow old for real and over time more and more of us are going to have to step off the treadmill for health and age reasons.