Chapter Seven
Open Source Sustainability
You’ve started this journey, made measurable progress from the trailhead. It feels good. But also the sweat of exertion reminds you that its work to get where you’ve gone. A day-hike is as good as a lunch walk is as good as a guided expedition. But the view from wherever the trail leads you reveals further mountains to climb, as far as the eye can see. This evokes the Haitian Creole proverb, “dèyè mòn gen mòn” meaning “behind mountains, there are mountains.” Challenge, and opportunity. If you let your imagination run wild, you might wonder or worry, “now what? What’s next? When do I stop?”
Luckily, open source contribution isn’t the Seven Summits290 of mountain climbing. There is no checklist to compel you toward someone else’s idea of success. I’ve suggested that planting your flag at the summit of an open source mountain is not the end-all goal—value comes from the experience itself and the trails we blaze for the next travelers. So our mission should be yes, to keep our destination in mind, but not without a conscious understanding of the preparation, planning, and surefooted steps we can take to get there. No one sprints up mountains, and no one can run to open source success. We need to act within patterns that we can sustain. We should work with a mindfulness of teamwork, shared purpose, and acknowledged risk. And we must accept that someday we will choose to stop.
Dispassion by Design
Open source projects don’t need to evoke thoughts of late-night hacking sessions, crowded coffee-shops, or blockbuster developer relations parties. These scenes convey to some the “passion” for coding. It’s rubbish. Programming can be a job. There is no altar at which we must sacrifice to prove our worth. It can be as Josh Clark puts it “boring,”291 predictable, and well, work. He suggests design system work “is not to invent, but to curate.” Open source can align with that, while still holding true to our larger concept of open source as a movement, a force for change, a new medium we get to shape in mind and body. I hope I’ve equipped you with enough tactics and perspectives to feel comfortable in this position.
You’ll be confronted with plenty of noisy examples to the contrary, however. Someone open-sourcing harder than you. I laughed to myself writing that. You won’t be making or contributing to any software if you burn out. The concerns of a project will tug at you, fueling doubt and imposter syndrome. It can feel like and become a real burden if you let it. Let’s call attention to some of these. In the end, its purposefulness, not passion, that will sustain you.
You Won’t Make Everyone Happy
Inevitably someone will be dissatisfied with your work, by choice or omission. Establish clear expectations so users know the territory they are stepping into. The gradation of relationship you design is up to you. I suggest that the community you create is a responsibility. In connecting we further everyone’s goals. Others see free code as that and nothing further. There is no relationship. There is no “open source supply chain.”292
How people interact with your project is a consequence of the expectations you set. Happiness shouldn’t necessarily be the measure of success—but clarity in value and telescoped outcomes. If you release breaking changes, are unresponsive, and leave the code to stagnate, consumers will not come to expect quality. Careful improvement and intentional communication create more confidence. Work at what patterns you want to establish and reinforce with your actions. Past success is an indicator of future performance here. I’d bet on those odds.
Your API Won’t Fit Every Use Case
The reasons you create your project are likely clear at the outset. But you won’t cover an exhaustive array of use cases. You’ll forget something, or the environment will change around you. Someone will want slightly different data flow, output, or file format. They might even be willing to contribute it. Or more likely, you know exactly where to introduce that if-then check.
These changes are tempting to make, why not accept them? Afterall, I’ve praised the virtue of the improv artist throughout this book. Accepting of change and iteration is a welcoming force within an open source project. But you need to think through the consequences of each change introduced into the project. Luke Wroblewski quips “every mobile app attempts to expand until it includes chat. Those applications which do not are replaced by ones which can.”293 Expanding the core offering of your project can ironically make it less desirable. I’ve been in talks with teams that turn down software because it does too much, introducing single points of failure. The ability to compose small packages together is the real power of healthy tech stacks.
The command line arguments, config file options, and modes of a project add up to cognitive overload for newcomers and maintainers. Divergent paths create multiplicative paths that pressure you to test every permutation in perpetuity. Make sure you accept changes for the right reasons. Don’t compromise the balance of effort you’ve cultivated within your project. A change too far may diminish your mental model of the software. An innocuous pull request might omit documentation, or it might introduce new flows you hadn’t had to consider.
Projects need time to acclimate to foreign code. If you can, make sure substantial contributions come with some upfront guarantees that the contributor will stick around to explain and help. The Innersource Commons defines a “thirty day warranty” pattern294 for just this purpose. It’s easier to pull off within an organization, but applying the same concept to an open source project is fair game. If nothing else, it communicates to contributors that you value their work but need their help in supporting it. Hopefully they’ll be flattered, and since they are already engaging with a large effort, you know they are motivated to see the project succeed.
My time with Pattern Lab included plenty of moments where I wasn’t mature enough to accept use cases beyond my mental model. I had a mixed bag of success in accepting change. The API made sense to me as-is, why change it? I was lacking in empathy and imagination. Some changes I accepted in pursuit of improvement, but the coding style was terse and unfamiliar. It made it harder for me to feel ownership. The contributor thankfully added tests and stuck around for quite some time, but nonetheless it always felt “not invented here.”295 I should have identified my limits, confronted these feelings, and communicated my need for help long before I hit the merge button.
Beware Assigning Too Much of Your Self-Worth
This is what I’d assign as the most direct effect on my own burnout. It cannot be said enough: you are not your code. Problem is, with open source software, more often than not, you don’t have a manager or set of colleagues to remind you of this—it’s only you and the backlog. I hope that you can look back on the code you wrote yesterday, last month, or five years ago and laugh, not feel embarrassed. Give yourself permission to be wrong and have learned. You know more now than yesterday and you’ll know more tomorrow than you do today. Alice Goldfuss encourages us to take note of moments when we can look back and see self-improvement, or observe when the novel pattern becomes muscle-memory.296
Every issue cannot be an existential crisis or you run the risk of becoming one too. Walk away when you are done for the day. Afford yourself thinking time, yes, but not at the expense of everything else. Walk your dog. Play with your kids. Eat some pizza. Letting your psyche rise and fall on the fortunes of your open source work will surely be a wager you don’t want to make—the house always wins.
You’ll be exposed to stressors. I try to recall that:
-
People will copy you; accept the flattery
-
People will steal your ideas and remix it; consider it product feedback
-
People will nit on your code; open your mind to improvement
-
People will want things faster; encourage them to contribute
Emotions will come from every interaction you have with your community. Acknowledge and make space for your reaction, and then respond when its healthy to do so, if at all.
Walk to Emergencies
I trained briefly to be an EMT Paramedic. I still remember my instructor telling us never to run when on the scene. The time savings doesn’t really matter in most circumstances, and you’ll arrive at the patient with elevated vitals. Not the best way to start intubation where one slip can break teeth. An actual EMT Ross Cohen expanded on this to also mention297:
Running is risky. If we trip, fall, get hurt—now there’s two patients.
Running to a patient prevents us from spotting hazards on the way in. Remember, we’re walking into an unknown. We must carefully observe and assess for danger. On the walk in we’ll notice the downed power lines, the room full of people passed out from a gas leak, the dog protecting its injured owner, the hoarder’s junk on the floor when we round the corner, the attacker who assaulted the victim, the weapon lying next to the bystander, etc.
Running makes it harder to keep our cool and operate at peak effectiveness. We need to be the calmest person in the room. Everyone takes their cues from us. We need to think clearly and act deliberately, decisively, expeditiously, smoothly.
Our open source work needs to be likewise methodical. If everything elicits a fight-or-flight response we would exhaust ourselves and desensitize our notion of real urgency and danger. If an issue comes in, on someone’s dev environment, and there’s a workaround, perhaps we can take a breath and think through how we got here and how best to act. The triage skills you hone over time will shield you from too much worry—a negotiation of user empathy and your own safety.
Rarely in open source is urgency a real problem. It might be very noisy when CI systems break across the world, but it’s more nuisance than crisis. Libraries that are consumed need to be installed as upgrades by customers, pass through any number of dev and QA environments, and be deployed to their production environment in order to cause real harm. So allow yourself to get comfortable before you debug. Asking “what’s changed recently” is always a good start. Understand the impact of the problem as a step towards building remediation options. If there’s true instability, revert and roll back to a stable state if you can, saving the post-mortem “why” for after service is restored. If there’s an omission or unexpected behavior, gather more information, maybe write a failing test first.
Contributors Will Come and Go
The spectrum of engagement is a highway with many lanes, onramps, and offramps. Not all roads lead to the same destination, and not all drivers have a shared journey in mind. Efforts to onboard and retain contributors should be built-in byproducts of your investment in good documentation and governance. Remember, we want a new contributor to be just as advantaged as the first few. What a contributor needs to know should be discoverable, in writing, and up to date. Investing in self-service context-building will always pay off, because it scales better.
I know because I can remember the enthusiastic messages exchanged between me and new contributors, telling them the same things I told the last one. It felt good in the moment to be making new connections, no doubt. But more often than not, those personalized training sessions didn’t shape lasting contributors. This can be deeply disappointing if you look to these newcomers as a tag-team partner too eagerly. Respect and honor the time others can give you, meet people where they are, and open as many lanes as you can.
“Sustaining Maintaining”
Dave Rupert gets top billing on this section for his inquisitive blog post of the same name.298 He outlines the challenge of burnout and scale we’ve covered here and suggests how to chip away at these problems. I appreciate his earnest sharing of personal experiences too. Of particular resonance to me is the acknowledgment that when burnout encroaches, we seek refuge elsewhere to cope. It becomes a stall that’s hard to pull out of. Some of the things we open source grow up to be more than side-projects, toys, learnings, or errant ventures. It’s how people make a living. It’s a responsibility. It’s a burden. It’s a relay race we must acknowledge we can only run so many legs of.
I agree with Dave that money and time yield the best results. I posit that corporate engineers have the largest role to play here, whether they know it or not. He says, “Open source maintenance needs a manual,” and in my wildest dreams this book could meet that measure. If you’ve open sourced something and are struggling, find comfort in these pages and the resources they point to.
Many others are committed to improving open source sustainability too. The Sustain project299 was conceived in 2017 as a sort of “unconference”—meetups and loose working groups focused on advancing topics like governance, documentation, marketing, licensing, ethics, and more. They also host several podcasts300 worth checking out across subject areas. The Community Health Analytics in Open Source Software (CHAOSS) project301 is a Linux Foundation project “focused on creating metrics, metrics models, and software to better understand open source community health on a global scale.”
I am energized by the increased interest and awareness in sustainability. I think we as a community are now understanding that most software problems are people problems, and that us people are worth supporting, patching, and funding.
Pace and Piecework Progress
When I’m not coding or corralling kids, I pretend I’m a carpenter. During the pandemic I insisted I needed to hand plane302 my workbench and the desktops I made for me and my son. I found two-thirds success so I guess I cannot go pro yet.
I read it as a sign of encouragement, though, when my wife bought me The Why and How of Woodworking, by Michael Pekovich. What struck me was that the ethos of the early chapters could be written as a manifesto for healthy open source development. Look at what Pekovich calls his rules, from the chapter entitled, “Make Shop Time Matter”303:
It’s not the number of hours, but how you use them
Make it a habit
Do your thinking away from the shop
Make sure it’s worth building
Why the little things are the “big things”
Shavings or sawdust?
Our mindset makes a difference
A new technique and a new tool with every project
Rethink perfect
Don’t rush, but don’t stand still
Respect the miter
Sometimes you just need to let it go
Sawdust and miters might be a stretch, though I could convince you we are talking about dependencies. I’d love to dwell here longer, but I bet you can see it too. Open source work, woodworking, needlework, footwork, teamwork—all work—requires time and craftsmanship. We need to treat every task as important, additive, and interconnected to the whole. Cutting a corner can come back to haunt you. Blunt tools or outdated dependencies slow you down and can be dangerous. The shop or Git branch left untidy between jobs will sap your productivity the next time you find a moment. Or worse, contributors will find your mess first.
The pace of your contribution does not need ridiculous velocity. It can be modest, mechanical, prioritized, and steadfast. Dispassionate care toward your project and the open source movement will give you staying power and more control over the arc of work you engage in.
Dog-fooding
The paramount means to sustain development of an open source project is to keep using it. I won’t pretend this is profound. But it’s something I realized too late with Pattern Lab. I drifted away from daily driving my own software, and in doing so slowly became insular. It wasn’t intentional—but my career took me away from it and the spare time I could devote to it wasn’t enough. I thought I knew what the concerns of the community were. And even so, I couldn’t muster the sustained energy to make progress.
Acknowledging the stagnated development, I wrote “I, Maintainer.” It was a short admission, admonishment, and call to act in accordance with community interests. Fashioning myself after Isaac Asimov, I coined, “Muenzenmeyer’s Laws of Open Source Maintenance.” I’d like to revisit them, five plus years later304:
A maintainer may not harm a user or, through inaction, allow users to come to harm.
A maintainer must shepherd their project and empower the community to do the same.
A maintainer must protect their own existence as long as such protection does not conflict with the First or Second Laws.
By the way, simply writing them didn’t change the trajectory of my burnout. Not long after, I retired from active development of Pattern Lab. And these “laws?” How do they hold up, even to my own scrutiny? Well, the First and Second law still feel unassailable to me. I don’t buy into to the idea that open source is a dumpster that you rummage through for treasure. I’ve made myself clear that it’s more than that. The community you create, intentional or otherwise, is inextricably linked to the act of sharing it in the first place. Impact over intent.
The Third law, however, I got wrong at the time. It reads as a doubling down that community is more important than self, when that is flat out backwards. The rest of the post even walks back the law right away:
When a maintainer chooses their reality over the reality of their users, they betray the trust put in them by users. They are prioritizing their own needs.
Good. No one else will as easily.
But to do so without implementing a healthy, sustainable community is acting against the interests of the project. It is an abdication of the very responsibility they have earned.
I guess you could spin “protection” as a graceful exit, but I think I’d rather be obvious:
3. A maintainer must protect their own existence as long as even if such protection conflicts with the First or Second Laws.
I feel that my experience shaped the theory that corporate developer contribution is key to long-term success. I also had to experience the failure of unmet expectations as a maintainer. Engagement must come from a healthy community of users, and you must count yourself among them. You build empathy with your users by experiencing the same constraints, triumphs, and shortcomings as they do. This broadest realization of the spectrum of engagement has us acting as consumer and contributor from moment to moment. You need to be connected to the concerns of your community.
Funding
“Money is the least-effective language in the open source sustainability conversation. But it’s a language we use a lot, because it’s so widely understood,” says Duane O’Brien, former director of open source at Indeed.305 As our project grows and more time is needed to care for it, it feels natural to want to be compensated. No one should question you for monetizing your skill and stewardship.
Accepting funding is a direct solicitation for support. You’re creating a pathway for others to empower you. What promises are you making with donations? How will you disburse them to collaborators? Think through if money is the real bottom line for you. Would you get more piece of mind from more contributors instead? The same platforms mentioned earlier are good places to start. Open Collective, Patreon, GitHub Sponsors. More will certainly sprout up. GitHub launched an accelerator program306 in 2022 that pairs a stipend with access to industry experts to empower open source maintainers to focus full time on projects. The company Clerk is sponsoring full-time development of the next version of the Colin McDonnell’s Zod validation library as a temporary “OSS Fellowship.” 307 I hope to see more novel funding efforts from corporate interests.
Legacy, Sunset, and Succession
We wouldn’t be responsible maintainers if we didn’t know when to part ways with a project. We might do more harm when we linger or stagnate. Do you do your best work when you no longer have the time or heart for it? If we have the resolve to rip the Band-Aid off, the community will be better for it.
How do you make the decision to step away? I joke that parenting is fifty-one percent worth it. It’s that one percent that makes all the difference. Kids, it’s more complicated than that, but boy do we have our moments. Open source can be a relationship not unlike parenting at times. When something’s your baby, your mind can make a pretzel of any rough situation to justify sticking it out. You go through the motions, but don’t find fulfillment in it. A lot of feelings can get tangled into the work. It might seem endless and inescapable. But this isn’t raising a child or caring for a loved one—those responsibilities are sacrosanct. Open source should have off ramps rooted in personal safety as well as normalcy. So try to think about the specific tasks. If the thought of sprucing up the issue log, helping users, cutting releases, documenting everything, and (I suppose) coding doesn’t consistently bring you fifty-one percent contentment, you might want to consider a hiatus. Maybe that threshold percentage is greater for you, you with the high-expectations. And they should be high, because we all have limited time and don’t intend to squander it.
If you decide to walk away and there is no one ready to take the baton, make it clear within your project that you are looking for a maintainer or that the project has run its course. Coalesce what community you have around a fork perhaps. Most code repositories now have a means to archive a repo as read-only. This communicates clearly that the project is not interested in future engagement.
Hopefully your project has attracted a community willing to take up the mantle of responsibility. Their enthusiasm and readiness to succeed you is the final artifact of the training efforts your actions influenced. Be clear about what engagement expectations you have as an emeritus member. Take comfort in knowing that while you may no longer be a maintainer, the spectrum of engagement remains open to you.
Where We Go Next
I asked Abby Cabunoc Mayes if she’d speak with me as part of writing this book. She’s been program lead of Mozilla’s Open Leaders program (where I was fortunate enough to join a cohort in 2018). She’s spoken at conferences including OSCON and StrangeLoop, keynoting EuroSciPy and Community Leadership Summit. She organizes with the folks at Sustain and is an OpenJS Foundation Board Director. Abby is also an Open Source Program Manager at GitHub. To be clear—Abby has unparalleled awareness of and advocacy for open source communities.
Abby was forthright with sharing that we as an industry are still figuring out sustainability. “Open source is so new. We are at an inflection point. We’re so reliant on open source right now, but the models don’t seem to be working. I think there’s a model of open source that we haven’t tapped yet.” The transactional model of open source contribution feels just that—a buying and selling of value. It’s business. It’s impersonal. No release in 4 months? What have you done for me lately? We need to manifest a purposeful, larger perspective, like Jeremy Keith inspired with his Earthrise analogy. Abby challenges us to think of open source as a movement, not pay to play. Don’t focus too much on the venture-capital-funded heavyweights.
Abby highlighted a Twitter thread that suggested that major tech companies were not structuring job descriptions and promotion guidance with open source in mind.308 Maintenance doesn’t seem to be a strong selling point to leadership. It’s hard to quantify how a bug fix impacts the bottom line (until the lack thereof does). Min-maxing to get ahead makes sense in our society, but it’s not without cost to the commons. This threatens the very idea that we can aspire to be more than the needs of our current selves. We need to demand recognition from employers that open source engagement is a job function—one that’s worth hiring, training, retaining, and rewarding.
She also reminded me that maintainers are leaving the ecosystem. This could certainly be burnout or natural attrition, but increasingly in our thirty year old Web, age will become a factor. The maintainer of the minimist CLI tool abruptly left the community and outright deleted their GitHub account and repositories. This package has twenty-one thousand direct dependents and almost two hundred million monthly downloads.309 It cannot just go away. The community stepped in, as it usually does, to steward this and many other packages. But we’re missing something here. We cannot discard this work like orbital debris and act surprised when catastrophe occurs. We need an offramp for these maintainers that is safe and managed and has healthy value exchanges. A retirement where they don’t fear their inbox.
The 2024 xz utils vulnerability310 was enacted in large part due to socially engineered pressure to add another (malicious) maintainer. I myself have been given push access to projects after a few months of work. Maintainers are starved for help. Those fault lines of inclusion and exhaustion and exploitation and value: they are building up pressure. Something’s gotta give—and it should be all of us, and companies, giving a damn.
Abby continued, “we need to make room for casual contribution. With timeboxed scopes. More obvious onramps and offramps. We are connecting and getting places faster than ever, but haven’t strengthened the muscles of working together as a group.” All this echoes the spectrum of engagement, and the rapid pace with which our social coding has exposed fault lines always present in any community. “It needs to evolve,” Abby says of open source, “but in evolving what open source means, we need to think about what parts we are leaving and what parts we bring with us.” She cited how the push for codes of conduct led to the pressure to truly enforce them, which revealed the need for better overall governance. Advancing expectations. She sees the opportunity amidst the challenge. I hear weariness at times, but there’s a certain optimism too. A deep optimism that you can reliably draw from once you’ve seen open source in its best lights, connecting with strangers and advancing common cause. It’s a strong feeling to chase.
I asked Abby what motivates her to contribute. She told me of her grandmother Paz, who passed away from cancer. Through a series of events, Abby found herself writing software to advance and curate cancer research. “Open source was not the norm. Researchers would fudge their data or omit data so they could publish faster. It was hindering innovation.” People at academic conferences would give presentations based on work done in Abby’s software. “‘I use that every day’, almost everyone said that,” according to Abby, in those early days of her career.
She told me, “I think that’s what’s best for the world.”
I mean, really, what else is there to say?