SourceForge Versus CPAN

The Perl Journal September, 2003

By brian d foy

brian has been a Perl user since 1994. He is founder of the first Perl Users Group, NY.pm, and Perl Mongers, the Perl advocacy organization. He has been teaching Perl through Stonehenge Consulting for the past five years, and has been a featured speaker at The Perl Conference, Perl University, YAPC, COMDEX, and Builder.com.

CPAN and Sourceforge might appear to be competing services, but they are actually complementary because they focus on different things. I am responsible for about 20 Perl modules available to the public. I use a mix of Sourceforge and CPAN to get the job done. If you are flexible enough to make small adjustments to how you work, you can make the most of both services and spend more time actually working than doing work so you can work. In a nutshell, Sourceforge does well at the general things while, not surprisingly, CPAN excels at Perl- specific things. What follows is a quick guide to when one might be more useful than the other for your purposes.

Where Sourceforge Wins

Sourceforge works for me because I do not want to be a system administrator. I want to focus on writing my software rather than developing tools to support writing my software. Sourceforge may not be perfect, but other people maintain it. It is easy to use for general things I need to do. What are its advantages?

Remote CVS. Sourceforge's biggest advantage to me is its no-hassle Concurrent Versioning System (CVS). CPAN does not have anything like this, so I would have to do a bit of work to let other people commit to any of my repositories if I administered them myself. I could set up local CVS repositories, but then I could not use them if I was at a different computer or I would have to enable anonymous access as well as access for people who want to commit changes. I would rather not be a system administrator, so I let Sourceforge handle that for me. They provide a nice CVS setup, a web interface to the repository, and a one-click process for adding committers. I can still access the repository with the command-line CVS tools.

Collaboration. Sourceforge is ultimately a collaboration tool, and the design of the tools is for projects with more than one member. This adds complexity, but most of it made sense after using Sourceforge for only a couple of days. I do most of the work on my modules, and I collaborate with Andy Lester who helps out with my Business::ISBN module and whom I help out with his HTML::Lint module. Working together with him was as simple as adding his Sourceforge user ID to my project—-a couple of keystrokes and a click. The Sourceforge system automatically does the necessary things to give him the appropriate access to CVS and other Sourceforge tools. With a little more work, I can set limits or responsibilities for collaborators.

Monitoring. Other Sourceforge members can monitor files that I release on Sourceforge. They will get an automatically generated e-mail that tells them I released a new file and what the changes are.

Releasing nonmodules. Although CPAN is really good for Perl modules, it does not work very well for scripts and other end-user applications. Kurt Starsinic has set up a scripts section, but a lot of people do not know about it, and it has only a handful of scripts. I could easily upload my scripts to CPAN and people could look in my CPAN-user directory to find the scripts, but I think the Sourceforge Files areas handles that better. You can download my cpan script (now included with CPAN-1.63) from Sourceforge, but not CPAN.

Where CPAN Wins

The Comprehensive Perl Archive Network (CPAN) is actually a collection of separate services, rather than a comprehensive and centralized service such as Sourceforge. This decentralization makes it easier to deal with the individual parts. Here's where CPAN has the upper hand:

Canonical source. The CPAN is the canonical source for just about anything Perl; and it would be foolish of me not to put my modules there. People can easily remember search.cpan.org, but not even I can remember the long Sourceforge URLs for my projects. Since CPAN is specifically a resource for Perl and its various front ends, it can focus on the special Perl things, like creating HTML versions of POD files so that people can read the docs before they download the module.

CPAN Search. The CPAN Search web site is at the top of my bookmarks. I visit it several times a day to read module documents or browse a distribution—all without downloading the module. Since it only has to work with CPAN, Graham Barr tailored it to Perl modules. People can easily find Perl modules, look inside them, go directly to CPAN Testers data, and many more things. Sourceforge has foundries, but they are not very useful to me for more than just grouping similar projects.

CPAN.pm and CPANPLUS. Perl has tools to automate the installation of Perl modules, but my modules need to be on the CPAN so these tools can find them. I firmly believe that the CPAN is one of the reasons Perl is as popular as it is. Python and Java, although fine languages, do not have something as useful or complete.

Automatic testing. The CPAN Testers test almost every module released to CPAN. Some testers do this for every upload automatically, while others do it only for the modules that they need to install. If a module fails, for whatever reason, I get e-mail from the tester that tells me the problem. I do not get this with Sourceforge because its focus is not on Perl modules.

New module announcements. With CPAN, I can find out which modules were uploaded today, or yesterday, or any other day. Several Perl news sources, such as use.perl.org, post this information automatically, and people expect to find it there. Anyone can see these announcements, whereas people need to be registered with Sourceforge to monitor a package. People can also easily discover new modules through CPAN module announcements.

Easy to automate. People actually upload to CPAN through the Perl Authors Upload Server (PAUSE), which is a simple web interface. It is easy to automate with a little web hacking, so I do not have to do anything other than use my "release" command-line utility, which FTPs the appropriate file to the PAUSE anonymous FTP directory, then visits the web site to claim the file for my PAUSE user ID. I can automate various other parts, too. Sourceforge has its own authentication scheme that involves cookies, and although a couple of Perl modules could handle that, I do not need the hassle. PAUSE is a collection of simple forms, whereas Sourceforge has a deeper menu structure.

Bug tracking. Sourceforge and CPAN both have bug-tracking tools, but I find that people who use my modules rarely use them. I put my e-mail address in the documentation of the modules and people write to me directly. I could encourage the use of CPAN's Request Tracker, but I do not let bugs sit around long enough for that to be a problem. I think that this is more important for users who cannot make the fix themselves (like in big, complicated C++ projects). Most people who report bugs to me seem to be able to send a patch, too, which means they already fixed it locally so they do not need to wait for me to fix it.

Mailing lists. Sourceforge offers mailing lists for projects, and CPAN does not, although the perl.org administrators are very liberal about creating mailing lists. I do not like mailing lists so much, so I tend to stay away from them.

Conclusion

Who wins—-Sourceforge or CPAN? Neither. I use the best parts of both. Sourceforge handles the mundane system administration bits and CPAN handles the nifty Perl-specific features.

References

CPAN: http://www.cpan.org/

CPAN Search: http://search.cpan.org/

CPAN Testers: http://testers.cpan.org/

CPAN scripts: http://www.cpan.org/scripts/index.html

Sourceforge: http://www.sourceforge.net/

brian d foy's Perl modules: http://brian-d-foy.sourceforge.net/

Business-ISBN: http://perl-isbn.sourceforge.net/

HTML-Lint: http://html-lint.sourceforge.net/

TPJ