This article is cross-posted from The Lead Dev.
Over the past year, I’ve written a series of articles for LeadDev, through which we began to define a social model of open source, based on the people who consume, contribute to, and maintain it, rather than a technical model of open source, based on the legal rights and responsibilities as defined in the license.
One year and five articles later, we’re much closer to arriving at a shared understanding around the challenges of working in and with open source, as well as how making the implicit explicit helps, but there’s still a way to go. In this final post, we’ll be reflecting on what we’ve learned throughout the series, identifying some patterns, and laying out what’s next.
If you missed any of my previous posts, you can find them here:
- A vision for a social model of open source
- Why open source projects should embrace operational transparency
- How to empower your open source users and contributors
- Five ways to care for your open source contributors
- How to communicate the state of your open source project
The importance of an expanded model of open source
Open source means something different to everybody. While the Open Source Definition (OSD) describes the criteria that a project must fulfill in order to be considered open source, and an open source license codifies it, the practice of open source varies wildly.
When I think about open source beyond this basic technical model, a vibrant picture paints itself across my mind: nodes, in a riot of colors. Splashed across a blank canvas, with lines spiderwebbed between them. A network that lives and breathes, the strength of its connections waxing and waning over time, expanding to make room for newcomers.
This Pollock-esque view is complex – an ecosystem of fiercely held principles, beliefs, and interests. Finding order in this chaotic system can be a challenge, but as we’ve examined it more closely, we’ve seen patterns start to emerge.
Here’s what we’ve learned:
Identifying common patterns and needs
When we started to define the social model of open source, our goals were multi-faceted and included the following: reduce maintainer burden, facilitate contribution, increase the resiliency of the ecosystem, and empower consumers with the information they need to responsibly use open source.
These are fundamentally difficult problems to solve. Some of that comes out of the origin story of open source, a movement with deep roots in counterculture and anti-establishment philosophies. Regardless of how mainstream open source has become, those of us who work in open source oftentimes consider ourselves rebels – subversive agents of change.
Even the idea of putting any type of structure around the practice of open source can be met with resistance, if not outright rejection. So how do we navigate the tension between keeping the culture and spirit of open source alive, while simultaneously giving it the meta-infrastructure that it needs to remain viable?
As we explored what this meta-infrastructure, or social model, of open source might look like, we identified patterns that may help with barriers common to open source projects. These include being explicit about:
- Why a project is open source
- How a project makes decisions
- Any ties the project may have and who funds it
- Who maintains and contributes to the project
- What state a project is in
- Where people can find the project’s various types of documentation
- The location of the project’s issue tracker(s)
- Avenues for discussion and expectations for communication
- Different ways to contribute, encourage new contributors, and recognize contributors
- Any mentoring programs and contributor ladders the project offers
Many open source projects already provide this information, but not necessarily in similarly discoverable ways. Some projects embed it right into their source, whereas others put it on their website. Still others do not spell it out explicitly, but instead rely upon participants' inference from disparate sources.
Understanding the complexity of the ecosystem
Software – open source and proprietary alike – has become increasingly complex. Projects and products do not have one or two dependencies; they have hundreds or thousands. For example, libsignal (the cryptographic library behind signal.app) has 223 direct open source dependencies alone. Each of those 223 has its own dependency graph as well.
If libsignal was a proprietary product, built without any open source dependencies, then a newcomer to the product would likely have a pretty good lay of the land. Complex and overwhelming? Definitely. But they could probably find the information they need to answer their questions, whether through reading documentation or by asking people through internal channels.
On the other hand, open source, for all its power and passion and potential, is a landscape of beautiful chaos.
Untangling a complex project may require combining through transitive dependencies, and for every dependency examined, we have to think about the cultures and unique practices that influence its behavior. That’s not a bad thing! But it does increase the cognitive load on everyone involved in an open source project. For maintainers, this cognitive load is amplified by the emotional labor of stewardship.
For all the talk these days about burnout, especially maintainer burnout, we have surprisingly few tools to offer any help. And when maintainers get burned out, it introduces or amplifies fragility into this complex software ecosystem.
Codifying a project’s model
If we want to increase the resiliency of open source, we need to decrease that cognitive load and emotional labor that maintainers disproportionately bear. That is the responsibility of everyone that participates in the ecosystem, whether their participation is active or passive.
All of the previous pieces in this series addressed the information that projects can provide, but to fully realize on the empowerment that results from that information, it needs to:
- Conform to an agreed upon format
- Use a shared vocabulary
- Live in a standard location
- Be low-to-no cost to maintain
A critical aspect is the format, specifically machine-readability. Without this, building tooling and frameworks reverts back to a manual process. Whether JSON, YAML, TOML, or whatever comes next, we need to be able to parse it.
While surfacing the information that we’ve explored is definitely a step in the right direction, making it parsable unlocks so many more possibilities.
Using and building upon a codified model
I would need another six or so pieces to even partially explore all the ways that creators and consumers alike could benefit from standardized information about a project. That said, here are a few:
- Filtering of candidate projects based on purpose or state
- Establishment of a policy around acceptable dependencies based on risk criteria
- Early warning system for projects at risk of maintainer burnout, underfunding, both, or more
- Easily migrate to a new code, issue, or fiscal host
- Seamlessly transition a project into or out of a foundation
- Well-lit and well-surfaced paths for new participants
Standardization feels heretical in the context of open source, but is just another form of the openness that open source embraces. It elevates the rest of how a project operates to the same level of transparency that we give source code. This is the natural next phase in the evolution of open source.
What’s next for the social model of open source?
Six articles and we’ve solved the sustainability of open source, what an accomplishment! Just kidding; it’s never that easy.
While together we have explored various aspects of open source projects that might benefit from standardization, we need many more discussions to start developing this concept into one that is mature and stable. Without consensus and critical mass within both the creator and consumer population, we will once again be working at odds with one another. Both need to see its value.
What’s next for this social model of open source? More exploration… and perhaps a new name… I hope you’ll join the discussion.