I wrote a comment on another blog and it turned out to be something I wanted to copy and expand upon here. The open source software community depends a lot (though not entirely) on volunteer effort and there is a potential conflict between the commitment of those volunteers and the expectations of users:
On the topic of free software and volunteerism itself, I think you are conflating obligations and commitments. Volunteers may commit to an obligation, but by the nature of volunteerism itself, they are free to uncommit themselves and rarely does anyone have the means to enforce the obligation.
However, if someone depends on volunteers to accomplish some goal, it’s reasonable to want to understand the strength and duration of the commitment over time.
If I volunteer for a local fire department, the leaders of the fire department and the members of community would like to know that I take my commitment seriously and won’t decide not to respond to a fire alarm because I’m more interested in going to see the latest movie.
Unfortunately, in open source, the level of commitment is usually implied and not explicit. In deciding to use any particular piece of open source software, one has to decide whether one is comfortable with the level of commitment of the author(s) and should ask for clarity (or accept uncertainty) when the commitment is unstated.
The advantage of open source is that one is not held entirely hostage to an author’s lack of commitment because the code is available and one can always take it and fix it. And if one doesn’t have the skills to do so, then it’s even more important to evaluate one’s comfort with the commitment of the volunteer author(s) and decide whether non-free software or paid support is a better option.
At first glance, open source package communities look like a collection of works of individual volunteers and any individual library might or might not have fanatical support by the author. But there is often depth below the surface. Some libraries have whole communities built up around them and releases might come from different authors. Others have co-developers or have handed the reins over to successor developers. Other times, libraries get forked in the normal way of open source projects.
Perhaps one of the things that open source authors could do better is to show those deeper pools of support, or be explicit about how they intend to support certain modules. I’m not saying they should promise what they can’t or won’t deliver, but there is no harm done in making the implicit commitments explicit.
For example, without thinking too deeply on it, here is roughly the commitment I make as an author for most of my libraries unless I’ve stated otherwise somewhere:
- If you contact me about my code, I will respond in a reasonable time (a week or so) and will try to remember to apologize when it takes me longer to get back to you
- I will attempt to give you a sense of my triage – whether I intend to do something about issues quickly or whether I may never get around to it.
- I will respond more quickly to bugs that make my code generally unusable or have security implications and less quickly to bugs that have workarounds and to feature requests that don’t help me in some way, too
- If you send me patches, I will look at them. If your patches are well thought out, consistent with the style and direction of the project, and include tests, I am very likely to incorporate them quickly. If not, they may linger or even be rejected outright.
- I make no explicit commitments about what “quickly” or “slowly” means as it depends entirely on other commitments in my life