They can never remember which Glen —
fiddich or livet
But they know it’s one of those,
and that when Maria’s order comes in
that’s for me.
Maybe some day they’ll remember my name
and possibly even which Glen
but this is a good start.
One discussion at the Accountability In Open Source workshop I attended this week was about when your village becomes a city. This was an analogy for when a small project, where everyone knows everone else (ie, a village) reaches that inflection point where that’s no longer the case.
Community norms, agreed upon by consensus and habit, need to be codified. Tasks that everyone knew how to do need to be documented, so that they can be delegated to people who weren’t there at the beginning. The purpose and mission of the project, which everyone knew because they were in the room where it happened, must be written down and explained to the people who came later.
The discussion covered a lot of ground, as one might expect, from reasons why projects don’t survive this transition (founders’ unwillingness to share control with a larger group; user demands outpacing developers’ bandwidth; company tries to capture more value from the growing audience and ends up alienating them; etc.) to specific things that a community should do to prepare for and succeed through this phase.
Projects tend to succeed when the participants have ownership. Project leaders should therefore be willing to share leadership, rather than clinging to it. At the same time, they should clearly document project goals, and non-goals, to stave off value drift and feature creep, which can be the death of a project.
A common theme with small projects which was addressed at some length was that they tend to be controlled by Large Personalities, rather than by a project mission. That can lead to power struggles, interpersonal squabbles, and decisions being about the who rather than about the ideas themselves. Project growth is an (often missed!) opportunity to move past that, and refocus on specific goals.
Projects should proactively create roles (and give them titles! that lets people know that their work is valued!) that community members can step into. This involves looking around and inentionally documenting the stuff that you just do and don’t think about. Write runbooks. Ask for a shaddow, and ask them to follow the runbook with your supervision. Incrementally improve it with the steps that you just automatically do and forgot to write down. Over time, relinquish control and let them just take it. Encourage them to identify the next person in the succession path.
At the open source accountability workshop earlier this week, Stephen Walli used a phrase that really resonated with me. He called his role (and mine) open source diplomats. We do much the same thing that diplomats do – lots of conversations, negotiations, wheedling and persuading – which is all incredibly hard to measure.
He mentioned that he investigated how actual diplomats are measured, and, turns out, that’s really hard too.
A large part of my work is what we snarkily refer to as preventing dumpster fires. We identify potential errors in open source engagement, and we work with the teams in question to ensure better outcomes. This might be something as simple as helping an engineer persuade a project to welcome their patch, in ways that are appropriate to that community. Or it might be something as potentially catastrophic as avoiding a fork of a major open source project, which might harm reputation and careers, and burn trust in critical communities.
That’s hard to measure. I mean, I could put in my monthly report that I avoided 10 catastrophes, but there’s only my word that those catastrophes would have happened otherwise. And, even then, quantifying the cost or impact of those catastrophes, or of avoiding them, is also impossible. Would customers care? Would it affect revenue? Would it be a blip in the tech news? So many of these things are impossible to predict. I have only my decades of experience and a gut feeling to guide me in most of these scenarios.
It’s also easy to abuse this kind of situation. I could, for example, simply state that, by my wisdom alone, we avoided a billion dollar loss. Yay me. Who’s to say otherwise? And, indeed, I have, in the past, worked with people who did exactly that, and got away with it, for years. Which is in large part why I care about trying to find ways to quantify what I do, and why it matters — often to people who don’t understand the nuances of open source community engagement.
Unfortunately, this particular part of the workshop produced more questions, and anecdotes, than actual solutions, but one thing was raised by several people. Many engineering roles at large corporations are measured by what you released/launched/shipped. As such, engineers working in open source are at a disadvantage for promotions or recognition because that’s not often an actual thing in the projects that they work with. Moreover, you can realistically work for a year on a feature and then have the community say, no thanks. (Granted, there are ways to mitigate that, but that’s another article.) This makes it very important that people who understand open source are involved in discussions around promotion and recognition, and find ways to reward open source participation in that process. Notably, everyone in the room said that their employer is bad at that, so a lot more discussion is warranted here.
Over the past 2 days, I attended an open source accountability workshop at Carnegie Mellon University in Pittsburgh. I wasn’t entirely clear, going in, what I was getting myself into, since the term “accountability” could mean any number of things. It turns out, we discussed many different meanings.
You can see a high-level view of what the workshop was about on the event website, although I don’t know how long that resource will be available now that the event is over, so I mirrored it HERE for my own records.
Accountability means several things in this context. Questions considered include:
Now, obviously, we were not the first people to address these questions. And we won’t be the last. But the conversations were very interesting, and gave me not only a lot of new ideas, and related questions, to ponder, but also gave me a significant to-do list of stuff that I now want to try to do within the community development committee at Apache.
So … as usual, I went to an event and came home with yet more work to do.
I expect to have several followups to this post, about various specific topics that are echoing in my brain. These include some of the following:
The last two pages
call for
something profound
Not just a
throw away
to fill the space
Something
they’ll be talking about
years from now
on r/poetry
But instead
I wrote this
I conduct my daily life
as I always have:
The work in front of me,
followed by
what’s next.
Powerful men with no regard
for anything
but their own power
change the world,
ignore decency and kindness
but I must
answer this email,
file this expense report,
wipe up this spill
I spent the last several days in Lagos, Nigeria, attending OSCAFest 2025 and other related events.
(Warning: Long)
While I’ve spent lots of time in Africa, that was all 35+ years ago, and also I’ve never been to West Africa, so I didn’t know what to expect.
It was lovely. The people were friendly and welcoming. The roads were … exciting. The accents were a delight to the ears. And the food was *amazing*.
I arrived on Tuesday morning. It was a 10 hour flight from Atlanta, and it’s a 5 hour time difference.
On Wednesday, I attended CHAOSSCon Africa 2025, a one-day event put on by CHAOSS, the Community Health Analytics in Open Source Software project. This was an event talking about how to participate in open source projects in meaningful ways. There was a lot of focus on non-code contributions, as well as general tips around earning trust in these communities.
As the name CHAOSS implies, the organization is primarily about community health metrics. US and EU CHAOSS events have been primary academic – about the science of measuring community. I have asked, in the past, questions like “Now that you have measured us, what should we do to improve”, and felt that the answer was “That’s not our lane.” But in the past two years, I’ve seen a LOT of stories coming mostly out of Africa about how CHAOSS has engaged with young developers to build their skills, particuarly around engaging with, as well as creating, open source projects, in healthy ways. To me, this is an upgrade to the mission. I’m very curious if this is an intentional shift in strategy, or if this has just been organic change stemming from the passionate African communities. (I’m also inclined to attribute this to some of the amazing community-centered people that have joined CHAOSS over the past few years, including, but not limited to, Ruth Ikegah!)
On Thursday I attended Sustain Africa, which was an event that I received an invitation to pretty late, but thought sounded interesting. It was hugely valuable. There were perhaps 100 people there. They were, I think, mostly from Nigeria, but there were also people from all over Africa. We broke up into groups to discuss what sustainability looks like in various topic areas — OSPOs, Government, Design, Mental Health, and so on. It took a little while to get rolling, but once we got started, there were some fantastic discussions in these areas, with practical tips about how to be intentional about planning for sustainability.
I was able to share some anecdotal advice around dealing with burnout in one’s open source endeavors. (I was, I think, the oldest person there, and certainly had been in open source longer than anyone else.) And was also ablet o share some about how an OSPO can help shape a company’s (or government’s) culture around open source participation.
And, finally, on Friday and Saturday, I attended OSCAFest Africa, the main event. I’m not sure how many people were there, but I heard someone say 900.
There were presentations with deep technical content, community engagement advice, career advice, design, documentation, and so much more, across five tracks.
The highlight was, as usual, the conversations with individuals. They were from a wide variety of industries, from government agencies, to education, to electricity, to software. And there were a lot of early-career software developers and AI practitioners who were looking for ways to build their skills in the open source technologies that they were involved with.
On Saturday I had the great honor of giving one of the keynotes. I spoke about the two themes that has stood out to me in the previous three days — sustainability and sovereignty.
For centuries, Africa has been compelled to rely on Europe, the United States, and China for so many things. Open source is an important way in which African companies and nations can take control of their own destiny. And doing it in ways that are sustainable, by taking ownership of the projects they participate in, rather than being followers, is a critical part of that.
My talk — Plan To Fork (So You Won’t Have To Fork) — focused on thinking long term about investing in open source projects we depend on, and addressing participation pain points and community dysfunctions head-on by taking leadership in those communities. I *think* it was well-received. And I think it was the largest audience I’ve ever had for a talk, with both the main auditorium and the overflow hall completely full.
Two other talks really stand out for me.
Linda Ikechukwu gave a talk titled “Ditch Passion. Follow Curiosity”, about selecting your path in life based on learning new things. She talked about how the usual “follow your passion” advice can be misleading, given that so many of us are passionate about things that will simply not make a viable career. But if you focus on curiosity, and learning new things, you will find yourself in a position to be an expert on something that others struggle with.
And a group of kids from the Techstars Hub program talked about their projects in open source and the skills that they learned there. This was enormously inspring, and I look forward to seeing these kids take leadership in technology in Africa in the coming years.
Overall, this was a great event, and I was enormously proud that AWS sponsored this event, and helped make it possible. I hope I’ll be able to attend this event in the future, and continue to watch Africa take its place as a leader in technology and innovation.
The Veldt, by Ray Bradbury. The first chapter of The Illustrated Man. Recorded for my son.
Most of the talks that I attended at Open Source Summit last week in Denver were in the general category of recruting and mentoring of new contributors. This is a bit of a brain dump of that content.
The first talk I want to highlight was a panel session featuring Dawn Foster, Ruth Ikegah, Matt Denny, and Suah Khan, titled “First PR to lifelong impact” What particularly stood out to me here was the following:
Clearly identifying a specific skill, or goal, for which you are trying to recruit is so much more valuable than just saying “Come help us!” It can be very intimidating to be asked to simply look around and find something to do, but when you’re asked to do a specific thing, there’s none of that initial confusion as to where you’re going to be useful. If you want to help a project recruit, have informal conversations with various people about where they could use help, or what isn’t getting done.
Don’t underestimate the value of recognition. Saying thank you, publicly as well as privately, is what keeps people around. List contributors in your release notes, even if they only did something small.
Present your information in multiple formats. Just because you prefer to learn by reading doesn’t mean that’s the “right” way. Short format videos are more appealing to (some) younger people. Provide a prominent “Prefer video?” link on your text content, and vice versa. Some people just want the facts. Some people want to talk to you, while some prefer to never have to talk to anyone. The more formats you can provide content in, the better, but there’s definitely a tradeoff with maintenance costs.
The next two things that I went to are a lot to summarize.
I went to Emily Shaffer’s talk “Nowcomer … but not new”, which was one of the most valuable presentations I’ve been to in ages. She does a lot of what I do – mentoring experienced programmers who are new to open source. Her notes/slides are HERE. I will post the video here once it’s available. Her practical tips about teaching people how to do the weird uncomfortable things that open source requires were just fantastic, and I can’t really do them justice. The main thing for me, though, was trying to get folks to understand that their internal goals and deadlines are completely uninteresting to open source projects, and trying to use those as motivation won’t work – you have to find ways to appeal to *all* users, not just yours.
I also attended a mentoring unconference. The notes from that are HERE. The section on mentoring non-code contributors was particularly valuable, with lots of practical tips about how to motiviate people to contribute to open source even if they don’t much care about software. In particular, more clearly communicating what problems your software solves, and for whom, was a recurring theme. And helping, say, a lawyer understand the kind of impact that their work would have, helping *millions* of people rather than the handful their daily work reaches, can be powerful motivator.
I have been resisting AI for a long time, for a variety of reasons. Based on some conversations at Open Source Summit last week, I am reluctantly starting my AI journey. I’m documenting this in video format, at least for now. Maybe I’ll get AI to transcribe them later!