Chapter 6: Module Maintenance

Chapter 6 - Module Maintenance
by?Sam Tregar?
Apress ? 2002
Companion Web Site

AS SOON AS YOU RELEASE your first module, you become the maintainer of your creation. A maintainer is the person in charge of the continued development of an open-source project. As maintainer you'll receive bug reports, requests for new features, and contributions from other developers. It's your job to make decisions about the direction of the project and release new versions. This chapter will introduce some useful tools and strategies that can make your job as maintainer easier.

Growing a User Community

Every successful CPAN module is fed by an active user community. A developer working alone on a project with no other users has a shelf life of approximately three releases before moving on to more entertaining work. This can be artificially extended with various enticements-revolutionary zeal, a weekly paycheck, caffeine, and so on-but ultimately an active community is an absolute requirement for the continued life of a module.

An active user community confers a number of benefits. Users will employ your module in ways you won't have anticipated. This can be both entertaining and inspirational; as you and your users see new uses for your module, you'll naturally come up with new features to make those uses more convenient. More fundamentally, users of your module will provide crucial testing for your module, identifying bugs that you would never have run into on your own.

Although having users is essential, it's not uncommon for a successful CPAN module to have a single author throughout its life. CPAN modules are by nature on the small side of open-source endeavors and are usually within the capabilities of a single developer. However, a module whose only developer is also its only user will not evolve beyond its original conception; it may be a technical marvel, but without a user community it's doomed to a short and uneventful life.

Since user communities are so valuable, it's worthwhile to spend some time thinking about what can be done to create one and get the most out of it. More than half of the effort of building a user community is marketing. The effort starts with picking a good name for your module, and continues in how you promote your module, how you involve users, and how you make subsequent releases. Your users are your customers, and as we all know, customer service is job one.

Manning the Help Desk

As the maintainer, you are the default destination for any questions or complaints concerning your module. Even if you didn't include your e-mail address in your module documentation (you hermit!), CPAN has it on record. Suffice it to say that if your module is used, you will receive e-mail about it.

The e-mail you'll receive falls roughly into two categories-useful and bewildering. The useful e-mail will contain feature requests, bug reports, and questions. In the second category, you'll find e-mail that sounds like a bug report but doesn't contain nearly enough information for you to be sure-usually something along the lines of "it doesn't work!!!" In this case you need to do a little coaching; explain what information you need in a bug report and how such users should go about getting it. You may have to repeat your advice several times, but hang in there. Sometimes there's a real bug to be found, and the sooner you find it the better. Also, it's sometimes necessary to point out that you're providing this service for free; people with limited experience in the open-source community will occasionally slip into "irate-customer mode". The sooner you correct that behavior, the better, for you and for them!

Running a Mailing List

Running a help desk is a useful service, but it doesn't tend to foster much of a community. The interaction is entirely one-to-one with you and each user carrying on private conversations. This is time-consuming and often thankless work. In order to get the most out of your user community, you need a more inclusive system. Running a mailing list can help turn individual users into a user community.

On a mailing list, users can interact with one another rather than solely with you. When you answer a question on the mailing list, your answer will be read by all the list members. This can help reduce the number of questions you receive. Over time members of the mailing list will be able to help you answer questions from new users.

Experienced users on your mailing list can help you answer questions about your module's development. When you have an idea for a new feature, you can post it to the mailing list and get reactions from your users. Your mailing list is also a good place for you and your users to float RFCs for related modules (see Chapter 5 for an explanation of RFCs) and make announcements of general interest.

A mailing list also attracts a class of users who wouldn't use a help desk-lurkers. A lurker is a user who doesn't say much-that user will subscribe to a mailing list for a project just to listen and learn. However, that doesn't mean lurkers are totally useless; they will still occasionally submit bug reports and every once in a while shed their cloaks of silence and join the discussion. When this happens, you'll certainly be surprised at the depth of knowledge their surveillance has produced!

When you run a mailing list, you become the moderator. A moderator is responsible for maintaining a certain level of civility as well as keeping the discussion reasonably on topic. Being a good moderator takes practice, but you can learn a lot by joining other mailing lists and observing how the moderators deal with problems.

Establishing a New Mailing List

There are many free resources available for creating a new mailing list. Those listed in the following text are popular with CPAN module authors at present, but you should be aware that their services might have changed by the time you read this.

Once you've set up a mailing list, you can put the subscription information into your module documentation, since your users will hopefully look there when they have questions. CPAN also maintains a list of Perl-related mailing lists. You can view the collection and register your new list at http://www.lists.cpan.org.

SourceForge

SourceForge is a site that provides a number of services, including free mailing lists, to open-source developers using their homegrown, open-source SourceForge software. To register a new SourceForge project, you must submit a description of your project. The process is similar to registering a namespace with CPAN, although SourceForge tends to act on registration requests more quickly and probably won't care if you've chosen a bad module name. You can find instructions by going to the SourceForge site at http://www.sourceforge.net.

Once you've registered a SourceForge project, you'll have access to a number of free services-mailing lists, Web-based discussion areas, CVS, Web site space, a public FTP site, bug tracking, task lists, news, and more! I'll be discussing some of these later, but it's definitely worth checking out to see what they've added since this book was published.^[1]

The SourceForge mailing lists are of the GNU Mailman^[2] variety and come with a Web archive set up automatically. Administration is performed through a Web interface where you can manage user subscription and mailing-list policy.

Yahoo Groups

Yahoo offers free mailing lists as part of their Yahoo Groups service. The mailing list is run using proprietary software created by Yahoo and supports access through both e-mail and a Web interface. Note that only Yahoo members can join the list, and the Web interface is obscured by numerous advertising screens. For more information see http://www.groups.yahoo.com.

Rolling Your Own

It's not hard to set up your own mailing list if you have a UNIX machine handy that can send and receive e-mail. If you run qmail^[3] as your mail handler, then Ezmlm^[4] may be your answer. It allows users with normal e-mail accounts to set up their own mailing lists. Alternately, if you run Sendmail (available at http://www.sendmail.org) then you might find the venerable Majordomo (see http://www.greatcircle.com/majordomo/) meets your needs. Another popular package is GNU Mailman (see http://www.list.org), which works with both Sendmail and qmail. Of course, these are just a few of the more popular alternatives-there are far too many mailing-list packages to list here!

^[1]SourceForge also markets a proprietary, commercial version of its site software for sale to large organizations. Depending on your politics, this might seem like an interesting possibility or a damning impurity. If you like the software but curse the wayward business model, the Free Software Foundation runs an entirely free version of the SourceForge software at http://www.savannah.gnu.org.

^[2]See http://www.list.org for details.

^[3]Written by Dan J. Bernstein and available at http://www.qmail.org. You can learn more about qmail by reading the excellent book The qmail Handbook by Dave Sill (Apress).

^[4]ulinkAlso written by Dan J. Bernstein and available at http://www.ezmlm.org.