Build for Inheritance
What if the best measure of your impact in open source isn't being needed, but making yourself unnecessary?
We are often rewarded for becoming indispensable, both in our professional and our personal relationships. There is satisfaction in being the person who understands the obscure subsystem, who remembers the history behind a difficult decision, or who can step in and solve the problem that no one else can solve. Being needed can feel like evidence that our work matters, that we matter. But in open source, indispensability is often another name for fragility.
A release process that only one person understands is not really a process. It is a dependency. A project whose history lives entirely in one person's memory does not yet possess shared knowledge. And a community that can survive only through the continued sacrifice of a handful of exhausted people is not yet sustainable, no matter how many stars the repository has or how green its dashboards remain.
This is not a criticism of those people. In fact, if I'm being honest, I'm one of them. More often, it is a testament to how much they have invested and how much they have quietly carried. But it does suggest that good stewardship asks us to do something somewhat counter-intuitive: to care deeply enough about something that it eventually no longer depends on us.
We care deeply enough whenever we explain not only what we did, but why we did it.
We do it when we turn an answer we have given ten times into documentation that means no one has to ask the same question an eleventh.
We do it when we write tests that preserve knowledge of the behavior we intended, when we simplify something clever so another person can understand it, and when we record the context behind a decision rather than allowing that context to disappear into an old chat thread or someone's memory.
And perhaps most importantly, we do it when we invite another person into the work before we desperately need their help. When we give someone room to make a decision, to own a release, to lead a conversation, or even to make a mistake without immediately taking the work back from them.
These actions can be easy to dismiss as overhead. They rarely have the drama of solving the hardest technical problem or shipping the long-awaited feature. There may be no benchmark that captures their value and no release note that gives them proper credit. But they are the actions that turn individual expertise into collective capacity. They are what transform a project from something held together by heroes into something genuinely held in common.
And this is an important part of what it means for open source to be community-driven.
It does not mean that everyone must participate in every decision, or that expertise and leadership no longer matter. It means that knowledge, trust, context, and authority are distributed widely enough that the work can be carried by more than a few people and that there is a visible path for someone new to become one of those people. In open source, we are always building an inheritance.
Someone we may never meet will eventually read the documentation we wrote, encounter the interface we designed, puzzle over the test we left behind, or search through an old issue to understand why the software behaves as it does. That person may never know our name, particularly now in the age of AI. But they will encounter our judgment. They will discover whether we anticipated their confusion, whether we respected their time, and whether we left enough of a trail for them to understand the work and make it their own.
As open-source maintainers in a globally distributed world, so much of our shared life exists in code reviews, chat messages, meeting notes, and the moments when one person takes the time to bring another person into context. A shared purpose is not sustained by a mission statement alone. It is sustained by the small, repeated choices through which we make our knowledge available, make room for others to lead, and ensure that no one has to carry important work entirely alone.
As engineers, maintainers, designers, project leads, and community leaders, our value is not measured only by what we can accomplish ourselves. It is also measured by what others become able to accomplish because we were here.
Every project will eventually pass from our hands. Code will be rewritten. Interfaces will change. Roles will change. New people will arrive with ideas that we didn't anticipate.
That is not a failure of our stewardship. That is its purpose.
We should strive to build things worth inheriting and to do the quieter work that makes inheritance possible.
Because the best proof that we mattered may not be that the work still needs us. It may be that, because of how we cared for it, others can carry it farther than we ever could carry it alone.
Athan Reines is a software engineer at Quansight and core developer of stdlib.
stdlib is an open source software project dedicated to providing a comprehensive suite of robust, high-performance libraries to accelerate your project's development and give you peace of mind knowing that you're depending on expertly crafted, high-quality software.
If you've enjoyed this post, give us a star 🌟 on GitHub and consider supporting the project. Your contributions and continued support help ensure the project's long-term success and are greatly appreciated!
Acknowledgments
This work was supported in part by the National Science Foundation under Award No. 2449410.
Disclaimer: Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.