Expectations of volunteers in open source

I wrote a comment on another blog and it turned out to be something I wanted to excerpt part of 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.

One of the reasons that open source is so successful among other developers is precisely because they are less dependent on the original authors for ongoing support.

In the Perl world, CPAN on the surface looks like a library of works by individual volunteers and any individual module might or might not have fanatical support by the author. But there is often depth below the surface. Some modules 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, modules get forked in the normal way of open source projects.

Perhaps one of the things that CPAN or CPAN 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 a CPAN author for most of my modules 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
  • If I am no longer interested in maintaining one of my modules and you want to take it over, I will give you co-maintainer rights

(On a slightly related note, this issues raised in this post are additional reasons why I want to hear mst give a talk called Patches Welcome.)

This entry was posted in cpan, perl programming and tagged , . Bookmark the permalink. Both comments and trackbacks are currently closed.


  1. Posted May 20, 2010 at 9:02 am | Permalink

    I had some similar ideas about API depreciation policies: http://perlalchemy.blogspot.com/2009/09/change-management-and-foss-authors.html In general I am an optimist here. If some authors start being a bit more explicit and if that is indeed something that is needed by module users - then these authors modules will become more popular and provoke other competing module authors to add similar clauses to the documentation of their modules.

  2. dagolden
    Posted May 20, 2010 at 9:42 am | Permalink

    I think to some extent, author reputation has substituted for documentation. E.g. I know RJBS and trust him to write an maintain his stuff. But that only works for people inside the community long enough to get to know authors and their histories. It doesn't do much to help new users or new authors. It's a community built on trust and trust scales slowly.

  3. Posted May 20, 2010 at 10:40 am | Permalink

    Well - trust and reputation is one thing - but willingness to support a particular module is another. For example I am more willing to quickly respond to bug reports for my modules that I am currently using at work. There is also a full scale for modules being more or less experimental.

One Trackback