The answers always begin with questions
I like to start at the beginning. That doesn’t mean the start, but the place where we’re trying to understand, rather than the forge ahead without looking back. I don’t know why. It’s just the way I’ve worked and lived. I like to understand the world around me, go to first principles. In math that meant doing the derivations, outside that meant poking things with sticks and turning over rocks and wandering off the trail. It meant taking apart the clock (and maybe not putting it back together correctly). The act of looking at things to understand, with curiosity, is my grounding. It means I can start so many places new. But also that I need to explore first to move forward.
That means I usually start with questions.
As I was putting together the content for the ‘managing an open source project’ workshop, I knew there’s so much advice or recommendations that are ‘it depends’ that made it hard to get started. But then I thought ‘depends on what?’. And I realized that not only wasn’t I sure, but that likely most projects weren’t sure either. When we’re in the middle, it’s so hard to remember where we began and why.
So, just like everywhere else, I went back to questions. Before we can begin, we must know where to start. As much the what as the who and how and why. And this is the hardest part. Because the vulnerability lies in the questions, where we don’t know. We can’t hide behind the code, or the zoom meetings, or the github stars, or the bugs to solve. These are acts of doing. But sometimes the doing obscures the intent.
The answers are in the questions, and they’re not always the answers we want, because they reflect both the world as it is and the world and the way we want it to be, and in that space we notice the difference, and we have to decide what to tackle and what to let go.
So, if you’re managing an open source project, sometimes it’s good to remember why. Why you started, why now, and what will your why be next. Adam Grant has it right with his ‘start with why’, but sometimes we have to include ‘what’, ‘who’ and ‘how’ to get to ‘why’. So, if you’re looking for questions, here’s a few, some more straightforward than others.
How long has your project been around?
About how many people use your project?
About how many contributors do you have? (however you define contributors)
About how many core project members do you have? (however you define that)
What stage would you describe your project? experimental, stable, sunsetting, something else?
What are you most proud of about this project?
What tasks are users struggling with that your project addresses?
What’s an example of a contribution to your project that you really appreciated?
What is an example of a contribution that was difficult to handle?
What parts of the project do you like working on best?
What parts of the project worry you the most?
What personally is success for you and your relationship with this project? Complete this sentence. In one year, I will be happy if I am spending X amount of time on this project, am excited about Y and not worried about Z.
Here’s the full list of questions in a worksheet.
It’s ok not to know the answers, just start by reading the questions. Let them sit with you and give them space. Take one hour with a cup of tea, or coffee, or sitting outside, with a step back from doing, to be brave and vulnerable and remember why you’re here.