Previously, I made an article on what I call “The Moral Contract“: the unspoken agreement between free software creators, whether companies or individuals, and their users, who may also fall into either category.
The spotlight was previously on how companies sometimes exploit free software, prompting certain developers to adopt… let’s say, “innovative” business models, ironically breaching the very moral contract they depend upon. If you’re curious about that content, I recommend looking back at:
The moral contract
Balancing openness and revenue: navigating the moral contract in the evolving world of free software.
VirtualizeOlivier Lambert
Navigating the relationship between software maintainers and a sea of users can be a tightrope walk that often leads to maintainer fatigue. The scales may seem to favor the user majority, but it’s this interaction that can make or break an open-source project. In my experience, the relentless demands and high expectations can exhaust even the most dedicated teams. We need to encourage a community culture that values clear communication, appreciates the craft, and understands the limits of volunteer efforts to keep the project and its contributors thriving.
❤️ Honey moon
Launching an OSS project is often an answer to an existing problem and this is typically how many OSS initiatives take off. The original community cluster usually consists of early adopters, those already well-versed with the ecosystem. Consider a fork, for instance: If you initiate one, you’ll likely attract people who felt constrained by the original project and are now excited about this fresh direction. These users won’t require extensive documentation; they’re ready to dive in, test, and become a solid group of champions for your cause.
This phase is a tremendous boost for developers. It reinforces the belief in the project. At this point, I want to express heartfelt gratitude to all our Xen Orchestra and XCP-ng early adopters. Your enthusiasm and constructive feedback were instrumental in shaping our journey. For any OSS developer out there, my advice is to capitalize on this honeymoon phase: it’s a golden opportunity to accelerate development and enhance your project.
📈 Growth phase
If your project gains traction, whether through sufficient sponsorship to allow full-time dedication or through successful sales, you’ll naturally expand your community. And rightly so. Your software will begin to reach a broader audience, some of whom may be completely new to the initial user circles, yet they could be sympathetic to the open-source cause. This stage is crucial; it’s when you can significantly refine your product based on fresh perspectives that offer insights beyond what you or your early adopters could have envisioned.
It is also the time to establish comprehensive documentation. Without it, you risk losing countless hours rectifying user setups due to misunderstandings of “obvious” issues. Good documentation encompasses not only the “general” usage but also steers the contribution process: clarifying how to report bugs, complete bug reports, and so forth.
🎉 Success phase
Reaching this phase means your community has become self-sustaining, with hundreds or thousands of members engaging with each other. At this juncture, you’ll encounter users with diverse experiences from similar software and, possibly, unexpected expectations. They may wonder, “Why does it work this way?” or say, “I’m accustomed to that.” It’s vital to provide context quickly so they can grasp the philosophy behind your tool.
There are moments it seems like people searching for a spoon are critiquing your knife, lamenting, “0/10, can’t eat soup with it“. I know this all too well. Your job is to articulate the intended purpose of your tool. The more accessible this information is, the less you’ll have to repeat it. For our virtualization platform, XCP-ng, constantly explaining that it’s not a regular Linux distribution but rather an appliance meant for specific use cases has been time-consuming. However, the more we communicate this, the more people understand and stop trying to use it in ways it wasn’t designed for.
😫 The onset of fatigue
So, your community is flourishing, congratulations! Yet, with a growing user base come observable patterns that can be taxing.
The majority of your users are well-meaning, but some may not grasp the enormity of the effort behind an OSS project or the nuances of such an endeavor. A lack of respectful communication is sometimes evident, perhaps intensified by the anonymity of digital interactions.
Let’s explore the elements that contribute to OSS maintainer fatigue:
🦚 Entitlement
One of the most prevalent issues in open-source projects is the sense of entitlement. Community spaces, whether forums, Discord, or others, often witness individuals who expect immediate fixes for their problems. These users, having never contributed, express extreme dissatisfaction when they encounte