Discourse on the Net is tough enough without lowering yourself to pointless name calling. The Free Software Foundation ought to know better, especially when their work is so important.

Today John Sullivan posted a story about problems the FSF has with Amazon's release of the Kindle source code yesterday. Their three main issues are:

• Not all the code is included.
• Changes to Kindle code do users no good because users cannot legally update their devices
• Important features remain secret.

The article is well-thought out, and clearly makes the three points. It would be a fine article if not for the insulting headline: No, Amazon did not release all of the Swindle's source code.

Why, FSF? Your article stands on its own, so why sling the mud? Why lower yourselves to juvenile name-calling? What do you hope to gain by calling the Kindle the Swindle? Are we to think "Ho, ho, those clever FSF folks!" I can't imagine.

Relatedly, please read Roger Ebert's article "The O'Reilly Procedure" on the lowering of the standards of debate in our society.

In my job as editor of Perlbuzz, I get email all the time asking me to run announcements about all sorts of Perl-related things. They're usually announcements of a new release of some module, or something about an upcoming conference. And usually I don't run them, because they violate the first rule of announcing something:

An announcement that says "PerlWhacker v1.5.3 has been released" is not interesting to anyone but a small handful of people. The most important part of being interesting is that your announcement has to have an angle.

Without an angle, there is no reason for the reader to read past the headline

The angle is the part of the story that says "This is why this is interesting to you, the reader." There has to be a reason that a story is interesting, not simply a recitation of facts. There has to be a hook, a reason for the potential reader to see a headline, or maybe the first paragraph, and say "Huh, I'd like to read that."

Here are some examples.

• Bad: "Devel::NYTProf version 2.04 got released, here's the change log." No angle, very boring, unlikely the reader will pay any attention to the story, if she even clicks it in her feed reader.
• OK: "Devel::NYTProf v2.04 got released, and it now uses 90% less disk space by using the Zlib compression library." Sort of interesting, because the reader can say "Huh, that sounds like a cool hack. Still, what's the effect on the reader?
• Good: "Devel::NYTProf v2.04 got released, and it uses 90% less disk space, because Nicholas Clark was trying to run NYTProf on the entire Perl test suite and ran out of disk space, and he worked with Tim Bunce on a patch." That's an angle because it tells a story that the reader can relate to.
• Great: "Devel::NYTProf v2.04, and it uses less space, because Nicholas Clark was running the Perl test suite against it, and here's a link to the findings from that research." Bingo!

Assume that the reader knows nothing about what you're announcing.

Finally, you must assume that the reader doesn't know what you're talking about. Most of the announcements I see are announcing to a small group of people who are aware of what is being announced, simply notifying that group that something has happened, excluding the readers not yet in the know.

I'm going to pick on the announcements for Summer of Code, both because they're excellent examples of how to exclude readers, and because I want the GSoC to succeed wildly. That's why I took the time to revamp the announcement when I ran it last night.

The original announcement that Eric Wilhelm ran is this:

The Perl Foundation has been officially accepted into the Google Summer of Code 2009 program as a mentor organization!

Hopefully some of you have identified some potential students already. Now we need your help getting them to submit their proposals.

http://leto.net/dukeleto.pl/2009/03/tpf-accepted-to-google-summer-of-code-2009.html

The student application period begins Monday, March 23rd and runs through April 3rd. (Students note: you can edit your proposal throughout that 11-day period -- getting it started early and talking to potential mentors greatly increases your chances vs throwing it over the wall at the deadline.) See this page for details:

http://code.google.com/soc/

Interested students and potential mentors, please read the GSoC info on the Perl wiki:

http://www.perlfoundation.org/perl5/index.cgi?gsoc http://www.perlfoundation.org/perl5/index.cgi?gsoc_2009_projects

If you're interested in mentoring or have a good project suggestion, now is the time to get your info up on the wiki so students will know about your code and where to find you.

Eric has done a ton of work for GSoC this year and last, and it's safe to say that the Perl involvement GSoC wouldn't be as great, in fact might not even exist, without Eric's work, so this is no knock on Eric. But this announcement has some huge failings, and it leaves questions in the mind of the reader who doesn't know what GSoC is.

• What is Google Summer of Code?
• Why is it interesting that TPF is a mentor organization?
• Why do I care about it?
• What's in it for me, the reader?
• What is a student?
• Why would a student want to join GSoC?
• What is a mentor?
• Why would someone want to be a mentor?

In short, Eric wrote the announcement for the people who already know what GSoC is, and excluded the other 90% who don't. Jonathan Leto's announcement has the same failings.

It makes sense why Eric and Jonathan wrote they way they did. They've been busting their asses for weeks (months?) working to set things up. They've been working inside the echo chamber of other people that are involved in the project. The parts of the project in the forefront of their minds are the details like how to sign up and how to write a proposal. However, to someone unfamiliar, it's noise until he knows the overview.

Get people to read your words

Whether it's an announcement of your software, or a resume, or a posting in your blog, you have to give the reader a reason to read what you've written. When writing, we tend to focus on the details of the text, expecting that the reader will consume our every word. Problem is, people aren't like that. We skim. We read titles. If it's not interesting we move on.

In my book on job hunting, I hammer home the idea that without a compelling summary at the top of your resume, the reader is not going to spend much time digging the good stuff out of your bullet points at the bottom. It's the same rule with announcements about your software project.

Next time you're going to announce something, show the announcement to someone who is not involved with the project, maybe a co-worker or your spouse. Ask him or her to explain what you're announcing. Try to understand how your article sounds to someone unfamiliar with it. Your project's success may rely on it.

Dave Rolsky wrote a fantastic article on the many different criteria on which you can choose your software to use. For example:

Easy to integrate - Some libraries are designed to be integrated with other modules (Catalyst), some want you to embrace their world (Jifty).

Complete - Some libraries come with a complete solution (Jifty) and some require you to put together a bunch of pieces into a whole (Catalyst).

Which is better? The answer, of course, is "it depends." Is the project for in-house use, or will it be distributed? Is it a one-off, where the base install will do most of what you want? Or are you likely to want to extend beyond those constraints?

Most importantly, Dave points out:

I'd like to see people state their priorities up front, and explain why it's important for the work they do. Often this gets left out of the discussion. Without this information, we often end up just talking past each other.

The extension of that is that many people may not even have thought about what their priorities are. Consider how often you'll see a question, such as at Stack Overflow, that asks "What's the fastest way to do X?" Most of the time, the querist hasn't even thought about that "fastest" part; it's just assumed. (For that matter, that's like assuming that the most important part of a new job is how much it pays, but that's a topic for another blog.)

Make sure you know what your priorities are. Question your assumptions. Your project will thank you for it.

A Perlbuzz guest editorial, by Dave Everitt

As the "the glue/duct tape/chainsaw that holds the web together", Perl is all but invisible to most web users. It is still one of the best-established languages of choice, yet remains behind the scenes and out of the limelight. This "brand invisibility," coupled with the factors outlined below, has contributed to the erroneous perception that Perl is outdated or unfashionable in the glaring light of other more energetically-promoted solutions. Despite the continuing dominance of LAMP, what do most web designers think the "P" stands for? Not Perl.

Cultural perception and perceived popularity don't help anyone to make a logical evaluation; this is an attempt to put the record straight.

"Design? That's for designers!"

Many Perl monks (and other alpha-geek programmers) hold design in some kind of contempt. Here are some comments by Perl coders:

• Don't trust designers with code:
  "...now you can pass "helloworld.tmpl.html" to your web designer to modify it in her/his favorite HTML editor. (Just tell her/him not to touch the HTML tags starting with "<TMPL_")" -- HTML::Template Tutorial
• Design is trivial:
  "If you find yourself lacking as a web designer or generally couldn't care less, you can give your templates to a web designer who can spice them up. As long as they do not mangle the special tags or change form variable names, your code will still work." - HTML::Template Tutorial

This kind of wilful separation from design is a big put-off factor to newbie web programmers, and is endemic throughout the Perl community: "designers can't come in here until they're willing to learn serious code". In other words: "the aspirant must show humility". Understandable perhaps; and, once you start trying, the community is as helpful and friendly as can be. Just not overly welcoming to "designers"; in fact, some Perl websites appear almost deliberately or even proudly ugly. Perl templating solutions like HTML::Template or Template Toolkit get ignored by most web designers in favour of comfy, close-to-hand solutions like PHP, ASP.NET, whatever Dreamweaver offers, or younger and prettier models like Ruby on Rails or Python's Django.

Here's a more rational approach to the "design vs. code" separation:

"...the best Perl programmers are rarely the best HTML designers, and the best HTML designers are rarely the best Perl programmers. It is for this reason that the separation of these two elements is arguably the most beneficial design decision you can make when devising an application architecture." -- Jesse Erlbaum, Using CGI::Application

This remains true, except that increasing numbers of people and teams are becoming good enough at coding and design to handle both passably well, They're choosing to invest the time necessary to learn both, as the Ruby on Rails explosion demonstrated. The Perl community needs to respond with a makeover and, maybe, some key "we're cool" websites like Catalyst's website to help rescue Perl's dated image, even if many Perl programmers don't care about it.

Most designers want to be included in the "our site is cool, therefore we're cool crowd," not shoved in next to an ancient HTML website in ANSI colours.

Where are my web pages? How do I know what does what?"

Programmers know that effective templating separates logic from content from style. However, designers familiar with web pages and visual appeal are often used to working with actual files, unlike programmers who can hold everything in their heads, and in lines of code that don't look at all like what they're going to produce.

Instead of these cosy actual files (the static web pages), most templating means that a site's links call a script that generates the pages. In other words, your website becomes a web application program, with all the power and flexibility. The literal, clunky file-for-every-page website disappears in the process, and this is just where many designers get a bit lost in starting the journey.

Both the original DHTML and current Ajax are effectively still attempts to turn web pages into dynamic web applications. What isn't obvious to the designer is that these technologies have been around for ages. They don't see that secure and reliable interaction with the server, solid yet flexible programming in Perl can drive a zippy Web 2.0 site as easily as Ruby on Rails.

Designers who want to start programming sometimes fail to make the conceptual leap from web pages as static files, to web applications consisting of components and screens. Failing to make this leap means they fall instead between logic and content by defaulting to PHP, Dreamweaver templates, Cold Fusion, etc. Perhaps this failure to make the complete leap happens because designers feel uncomfortable without seeing the actual "pages" they're working with, or because the dominant web design software makes it easy to adopt its own default solutions.

Where are the "Perl tools" for Dreamweaver? All the publiclity and books read "Dreamweaver CS3 with ASP, ColdFusion, and PHP." If Eric Meyer can improve CSS support in Dreamweaver, could the Perl community do the same towards integrating Perl tools? A million design houses across the world might then at least see a menu item containing the word "Perl" in their favourite software.

"Perl is impossible to read!"

Perl itself can be no harder to learn or read than the PHP to which many designers default. Learning Perl is far from dead, now in its 5th edition, and is regarded as one of the best books for anyone learning programming in general.

However, Perl programmers often delight in the potential economy of the language, and their concise code can appear obscure and impenetrable. I've even heard good programmers, fluent in other languages, say "Perl is horrible" or "unreadable". Yet to a beginner, Java (to take one example) is far more "horrible", verbose and complicated -- just compare "hello world" in both languages.

Actually, beyond that initial step, how easy code is to understand depends on who does the coding. Precisely because there's more than one way to do it, Perl can be written as readably as any other language. Most times this isn't obvious to a beginner because Perl coders don't need to keep it obvious when they can use powerful shortcuts or write one-liners. With this in mind, my Perl monk friend replied to a draft of this article with a "line noise" of caution:

I wouldn't recommend it as a first language. It's a second or third language. That's when it becomes powerful. I wouldn't want to put people off programming by making them look at @s=map{s/_/!/gi}grep{!~/^#/}@p.

"Perl/CGI is slow (and gets slower with increasing server load)"

This isn't true with FastCGI FastCGI or mod_perl. But try telling a designer who may only just be discovering the unforgiving nature of the command-line that these are an easy install. Or persuading a popular shared hosting provider (where many designers are hosting) to supply them on their list of default options.

To complicate the issue, there's also a groundswell of opinion against the complexity of frameworks in general, with sites prototyped in Rails being redeveloped with other tools. Then there's the shared hosting debate.

Isn't there a gap opening up here for tried-and-tested but nicely packaged Perl solutions for web development? Can't we fit between a designer's static pages and a full-blown framework? But just try finding a good-looking Perl templating tutorial that shows off the kind of tidy, well-crafted and semantic XHTML and cutting-edge CSS that the best designers produce, or a one-click Perl template install with a good-looking promotional website.

Rails has demonstrated that speed isn't initially the issue. Ease, buzz, style and ubiquitous market presence are. Perl doesn't have to remain the dowdy elder sister -- given the same kind of push, it can go to the ball too.

"So what's a poor designer to do?"

If you want to develop your skills, ask "will I be using a programming language at least 2-3 times a week to actually do something; that is, as much as you currently use (X)HTML/CSS?" If not, you'll almost certainly forget what programming you learn and might be better off leaving it to "real programmers".

However, if you do want to develop those skills, a good route is to experiment with a templating system that encourages the separation of logic and presentation, like HTML::Template or Template Toolkit. Work through the tutorial websites and just get something working. All you need to know for starters is that HTML::Template fills HTML templates dynamically with data according to the logic in your Perl, or that Template Toolkit generates static pages from your Perl.

What you, the designer, must learn first

You do run Apache locally on your machine, don't you? Okay. Now get CPAN and use it to install Perl modules for your platform. Be mindful of case-folding if you're on Mac OS X Yes, I know there should be a guide to all this, but like all learning curves in big territories, there's no authoritative manual. To make it easier, perhaps there could be.

To make an intelligent comparison, you might want to try Ruby on Rails. The latest OS X already has RoR bundled. If you've done all this and are still committed to PHP, keep the logic apart from the design or tears of despair will follow. Steer clear of the convolutions that PHP allows, and note the following well:

PHP has full support for classes, attributes and methods, and supports object-orientation, but the key problem is that no one seems to use it! There is a vast body of sample PHP code on the web, but nearly all of it is absolutely dreadful. HUGE long procedures, no structure, little code refactoring, and intermixed code and HTML that is impossible to read and must be impossible to maintain.
-- Tim Roberts, Python Wiki

Anyone who has been there will echo "yes, it is impossible to maintain," but that's not the language's fault. It might not all be squeaky-clean, but there isn't a vast body of "absolutely dreadful" Perl on the web. As a designer looking to settle on a language, that's a very valuable pointer. If you've ever had to plough through lines of "impossible to read" and "impossible to maintain" PHP, you'll understand that although PHP can be written as well as any other language, it often isn't.

If ways can't be found to improve the overall quality of PHP authorship, well-styled bridges just need to be built for designers serious about programming to visit the Perl community. When they get there, they'll need to feel at home.

Dave Everitt is a print-turned-web designer/developer who internalised HTML and CSS in the last century and steadily developing Perl skills in this one. His work includes the roles of web designer, educator and new media academic.

Perl's big problem is one of perception. The other day, a job candidate asked me "You're moving your web apps from PHP to Perl? Shouldn't it be the other way around?" Why did he think that? The candidate knew no Perl, and only a bit of PHP, so had no technical reason to believe that PHP was better than Perl. So why did he think Perl was subservient to PHP in the web arena?

What I suspect is that Perl is just less visible, and not just in the sense of crap like the TIOBE index where it equates hits for "Foo programming" popularity of the Foo language.  I'm talking about in the real way people see the world of programming.

I'm certain that PHP has become a de facto choice for basic web apps because it's just How You Do It these days. You see enough PHP in the context of the web, it starts to sink in.

Why is Ruby on Rails so popular? Is it better than Perl on Catalyst? Or is it just that people hear about Rails more? I suspect the latter, because perception is reality. When people perceive Perl as being dead, or not as powerful as other tools, it might as well be.

There are three goals I'd like to address:

• Perl needs diversity, needs new blood, both in users and community as well as tools.
• Perl needs more active mindshare in the programming world.
• Perl 5 must continue to be seen as a viable language.

The three actions to take: Decentralize, diversify and colonize.

Perl must decentralize

Perl has a great infrastructure. We have the CPAN. We have the various sites of perl.org. We have Perl Mongers and perlmonks, and so on. Unfortunately, we've grown complacent. It's time to start looking elsewhere for infrastructure and community.

Standardization on tools makes sense if the tools are the best possible tools available. In many cases, the infrastructure already in place in the Perl community may not be the best there is.

Is the Mailman installation running on lists.perl.org the best mailing list solution for you when you need to start a mailing list? If not, then consider other options. Starting a list at groups.google.com is trivial, for example.

Is rt.cpan.org the best bug tracking solution for your modules or projects? If not, then look at other options. Many of my modules, such as ack and WWW::Mechanize are hosted at Google Code, where I use the bug tracking system there.

Is use.perl.org the best place to host your blog? Maybe you should post somewhere else. Certainly that was the case with me. I found that use.perl.org wasn't the news site I wanted it to be, so I started Perlbuzz as an alternative, literally doubling the number of news sites devoted to Perl.

Note that "alternative" does not me "replacement". It's possible to have two similar but diferent projects, websites or whatever that both fill a need. If, say, Perlbuzz replaced use.perl.org, we'd still only have one news site, which is no better a situation than we started with.

Some of the alternatives might not be community-based. Google Code, is not run by altruistic volunteers. Commercial interests will usually have more time and money to spend on providing useful infrastructure. That's no knock on the volunteers, but merely taking advantage of what the commercial interest has to offer.

(I know at some point someone will say "At some point decentralization is harmful." I agree, but we're nowhere near that point. Such a problem to have!)

Perl must diversify

The mantra "There's more than one way to do it" is at the core of Perl the language, but this is not always the case in the Perl community. We must always remember the guiding principle of TMTOWTDI.

The first place to diversify is with people. I suspect, but cannot prove, that the Perl community's size is a net loss as time goes by. We must constantly be trying to bring new people into the fold, to take advantage of their innovations, and to make what we do more fun.

Second, we must be willing to launch new projects, even if they're similar to existing projects. It could be a module, or a website, or an entire application. The knee-jerk resistance to diversity often sounds like this:

• "Why do we need Getopt::Whatever, we already have Getopt::Long"
• "Why do we need another templating system?"
• "Why do we need Jifty/Catalyst/whatever? We already have Maypole."
• "Why do we need Perlbuzz, we already have use.perl.org?"

I've never understood this fear. It sounds like the resistance is based on the premise of "I wouldn't want to do that project, so you shouldn't either." It's the refrain of someone with a closed mind, unable or unwilling to imagine what could be. In the case of similar modules, the refrain usually goes "It's too hard to find the module you want anyway," but that's not a problem of the module, but of the way things are found in CPAN itself. (And if you'd like to address that little bit of decentralization, please take a look at my Rethinking CPAN mailing list.)

Ultimately, fear of the new is counter to the principle of TMTOWTDI. Indeed, plurality is at the very heart of open source, and it's additive, not subtractive. Template Toolkit need not take away from Mason. Perlbuzz need not take away from use.perl.org. Perl didn't take away from awk and shell. In any of these cases, if the new solution does take away from another, then the other solution was an inferior one to begin with.

Decentralizing and diversifying do two things. First, it opens our minds to alternatives that we may not have considered. It makes us more likely to find solutions that are better than what we started with. Second, it helps with colonization, the ultimate goal.

Perl must colonize

The other day, Tim O'Reilly posted on his Twitter feed a link to a cool article about life in the universe which mentioned Von Neumann probes, theoretical space craft that can replicate themselves using materials found in their travels. A single probe could travel some distance, replicate a thousand cloned probes, which would then launch in a thousand different directions, repeating the cycle.

That's what we need to do: Colonize the mindshare of the world to let them know that Perl is still viable, and a hell of a lot of fun. These new Perl lovers will spread the love as well, and the cycle will continue. In terms of action, it means simply "helping make more people aware of Perl as a cool & useful language." Fortunately, it's a case where we can think globally and act locally, even passively.

The biggest effect I see you, the reader, as being able to have is by spreading out Perl's web footprint. I want more places for people to find out about Perl, rather than a few big ones.

This colonization approach goes hand-in-hand with decentralization. Take my ack project, for example. ack has a number of footprints out there:

• A project home page, entirely separate from any perl.org or cpan.org infrastructure.
• A Google Code home page with source repository and bug tracker
• The ready-made search.cpan.org page for ack which points to both.

That's three times places for people to stumble across Perl, to see it mentioned. A separate home page also makes it more likely to get linked from somewhere else, as when Daring Fireball linked to ack and thousands of people came to see about ack. That's thousands of people who went and saw "Huh, here's a tool in Perl."

Of course, a few thousand visitors isn't going to change any mindshare. That's why it's not just me that needs to work on this. Fortunately, decentralizing and diversifying makes colonization easy.

Our Google footprint is pretty bad, anyway. When I search for "perl" in Google, the top five hits are:

• perl.org, which is a good base.
• perl.com, O'Reilly's Perl page, also a good base.
• The wikipedia entry for Perl, which certainly isn't much help for a beginner
• www.cpan.org, with its front page that expects that you know what you want.
• An old perl 4 man page from Carnegie-Mellon University

Is this the best impression that we have to give the world?

Adam Kennedy gets it

Adam Kennedy's Strawberry Perl is a marvel of the principles I've talked about. Strawberry decentralizes, as it uses none of the core perl.org infrastructure, and it diversifies and colonizes by giving Windows users an alternative to ActivePerl, which for many users is not robust enough. When people talk about Strawberry Perl, it helps with mindshare as well.

Adam is a great example of someone who has set out to make improvements to a part of Perl, and implemented it without worrying about permission or duplication, helping Perl as a whole along the way. I thank him for it. I suspect his Perl On a Stick project will have similar results.

How you can help?

The strategy of decentralize/diversify/colonize takes actions at all different levels. You don't have to go create your own Perl distribution, or even write any code. Here are some other ideas to get you started.

• Post a Perl-related web page to Digg, reddit or any of the other social bookmarking websites.
• Bring someone new to a Perl Mongers meeting, even if Perl isn't his/her primary language. Especially if it isn't his/her primary language.
• Go to a user group meeting for another language. See what they're talking about. Share the Perl perspective.
• Start a blog outside of the use.perl.org hierarchy. If you already have a u.p.o journal, keep it, and post to both places.
• Start a mailing list related to a project of yours. Host it somewhere like Google Groups. Don't worry that "people won't be able to find it," because the list of groups at lists.perl.org is no model of organization, either. Besides, the only people who know to look at lists.perl.org are the people that already know there are lists at lists.perl.org. They're not who we're after.
• Start an alternative to perlmonks.org. Perlmonks is a fine site, but it's long in the tooth, daunting to newbies, and frustrating to search. Surely there's a different way to have an online Perl forum that is better in many cases.
• Work on a project that helps cross-pollinate Perl to the rest of the world. The Test Anything Protocol is a good example of this.
• Review a book about Perl. Get it posted to Slashdot or another big tech site.
• Write about Perl in your blog. Even if you think it's not interesting to Perl people, that's fine. Someone will want to read it, and you'll spread that mindshare.
• When you talk about Perl, don't be afraid to use the F-word and the L-word: "fun" and "love".

What do you think?

I'd like to hear your ideas. How can we expand Perl's reach? What have you done to help decentralize, diversify and colonize? How can we keep Perl fun and exciting?

Two comments I don't need to hear: "This will never work" and "This is a waste of time." If that's what you have to contribute, trust that I've taken your insight into account already, and save yourself some typing. Alternative courses of action, however, are more than welcome. Also unnecessary: "None of this would be a problem if not for Perl 6."

Acknowledgements

Thanks to a number of people who have helped discuss these ideas with me as I put them together. These include Pete Krawczyk, Jeffrey Thalhammer, Ricard Signes, Liz Cortell, David Hand, Jesse Vincent and Elliot Shank. I'm sure I've forgotten some, so I apologize if I left you off the list.

Jeff Atwood's blog Coding Horror is one of my favorites. Until yesterday, I'd been recommending it unreservedly.

Jeff's made a big stumble, and I hope he corrects it soon, publicly. In his latest article, We Don't Use Software That Costs Money Here, he talks about how the free software alternatives to non-free software are getting better all the time. Unfortunately, he claims that

It's tempting to ascribe this to the "cult of no-pay", programmers and users who simply won't pay for software no matter how good it is, or how inexpensive it may be. These people used to be called pirates. Now they're open source enthusiasts.

He couldn't be more wrong. There is no equating software piracy, the theft and misuse of copyrighted software, with using open source, where the license specifically allows and encourages the redistribution of the software. Piracy violates the terms of the copyright and license. It's possible to do this with open source software as well, by not following the terms of the license.

In fact, there's no difference between open source software creators protecting their freely-licensed software from owners of non-open licensed software, such as the unfairly reviled Metallica, from protecting their works as well. When we applaud the Software Freedom Law Center for suing companies that violate the GPL, we should also recognize that owners of commercial software licenses should enjoy the same rights to protect their licensing terms as well.

I'm urging Jeff Atwood to correct his mistake. Open source software is nothing at all like piracy. Open source is about the license, not the financial cost.

I've started a group, rethinking-cpan, for discussing the ideas I've posted here. -- Andy

Every few months, someone comes up with a modest proposal to improve CPAN and its public face. Usually it'll be about "how to make CPAN easier to search". It may be about adding reviews to search.cpan.org, or reorganizing the categories, or any number of relatively easy-to-implement tasks. It'll be a good idea, but it's focused too tightly.

We don't want to "make CPAN easier to search." What we're really trying to do is help with the selection process. We want to help the user find and select the best tool for the job.

It might involve showing the user the bug queue; or a list of reviews; or an average star rating. But ultimately, the goal is to let any person with a given problem find and select a solution.

"I want to parse XML, what should I use?" is a common question. XML::Parser? XML::Simple? XML::Twig? If "parse XML" really means "find a single tag out of a big order file my boss gave me", the answer might well be a regex, no? Perl's mighty CPAN is both blessing and curse. We have 14,966 distributions as I write this, but people say "I can't find what I want." Searching for "XML" is barely a useful exercise.

Success in the real world

Let's take a look at an example outside of the programming world. In my day job, I work for Follett Library Resources and Book Wholesalers, Inc. We are basically the Amazon.com for the school & public library markets, respectively. The key feature to the website is not ordering, but in helping librarians decide what books they should buy for their libraries. Imagine you have an elementary school library, and $10,000 in book budget for the year. What books do you buy? Our website is geared to making that happen.

Part of this is technical solutions. We have effective keyword searching, so you can search for "horses" and get books about horses. Part of it is filtering, like "I want books for this grade level, and that have been positively reviewed in at least two journals," in addition to plain ol' keyword searching. Part of it is showing book covers, and reprinting reviews from journals. (If anyone's interested in specifics, let me know and I can probably get you some screenshots and/or guest access.)

BWI takes it even farther. There's an entire department called Collection Development where librarians select books, CDs & DVDs to recommend to the librarians. The recommendations could be based on choices made by the CollDev staff directly. They could be compiled from awards lists (Caldecott, Newbery) or state lists (the Texas Bluebonnet Awards, for example). Whatever the source, they help solve the customer's problem of "I need to buy some books, what's good?"

This is no small part of the business. The websites for the two companies are key differentiators in the marketplace. Specifically, they raise the company's level of service from simply providing an item to purchase to actually helping the customer do her/his job. There's no point in providing access to hundreds of thousands of books, CDs and DVDs if the librarian can't decide what to buy. FLR is the #1 vendor in the market, in large part because of the effectiveness of the website.

Relentless focus on finding the right thing

Take a look at the front of the FLR website. As I write this, the page first thing a user sees is "Looking for lists of top titles?" That link leads to a page of lists for users to browse. Award lists, popular series grouped by grade level, top video choices, a list called "Too good to miss," and so on. The entire focus that the user sees is "How can I help you find what you want?"

Compare that with the front page of search.cpan.org. Twenty-six links to the categories that link to modules in the archaic Module List. Go on, tell me what's in "Control Flow Utilities," I dare you. Where do I find my XML modules? Seriously, read through all 26 categories without laughing and/or crying. Where would someone find Template Toolkit? Catalyst? ack? Class::Accessor? That one module that I heard about somewhere that lets me access my Lloyd's bank account programtically?

Even if you can navigate the categories, it hardly matters. Clicking through to the category list leads to a one-line description like "Another way of exporting symbols." Plus, the majority of modules on CPAN are not registered in the Module List. The Module List is an artifact a decade old that has far outlived its original usefulness.

What can we do?

There have been attempts, some implemented, some not, to do many of these things that FLR & BWI do very effectively. We have CPAN ratings and keyword searching, for example. BWI selects lists of top books, and Shlomi Fish has recently suggested having reviews of categories of modules, which sounds like a great idea. I made a very tentative start on this on perl101.org. But it's not enough.

We need to stop thinking tactical ("Let's have reviews") and start thinking ("How do we get the proper modules/solutions in the hands of the users that want them.") Nothing short of a complete overhaul of the front end of the CPAN will make a dent in this problem. We need a revolution, not evolution, to solve the problem.

Tim Bunce has put together a presentation debunking three pervasive myths about Perl:

• Perl is dead
• Perl is hard to read / test / maintain
• Perl 6 is killing Perl 5

That last one has a sort of corollary: "Perl 6 is taking too long", which presupposes that anyone can say how long Perl 6 should be taking.

Jim Brandt writes in the TPF news blog that the Perl Foundation is helping a court case surrounding the Artistic License. A Java project has adopted the Artistic License and is now in the middle of a legal battle that could be important legal precedent for future cases regarding open source licensing. TPF has helped support an amicus curae brief in the case.

Jim's article notes "the argument [in the case] that there can be no remedy to a copyright holder who chooses not to charge money for their work." It's kind of like how puzzled relatives ask why me work on open source projects if I'm not getting paid to do it, as if it's less worthwhile that there's no money (directly) changing hands. Here, the plaintiffs in the case are trying to make that perception into settled case law. Thanks to TPF for their work here against that happening.

Here in the Perl echo chamber, there's a lot of talk about advocacy and getting people to use Perl and whether Perl is more popular in the job market than PHP, but I think most of that is just wind in sails. We talk and talk and talk but when it gets down to it, people don't use Perl because it's bigger in the job market, or because of a well-argued thread on Slashdot. People use Perl because the power of Perl makes their lives easier.

Back on the 17th, I posted that Perl would be allowed in the Microsoft Scripting Games. Now, I'm no friend of the "scripting" moniker, but I was glad it was allowed in and thought maybe there would be some good visibility for the power of Perl.

Then I saw the results.

Event 2 in the competition was to read in a text file of comma-separated values of ice skating scores, drop the high & low scores from each skater, and show the top three skaters and their average scores. Trivial for Perl, right? The solution that Microsoft posted, however, was effectively a VBScript script translated to a Perl program (by their own admission).

Here's the solution they posted.

%dictionary = ();

open (SkaterScores, "C:\\Scripts\\Skaters.txt");
@arrSkaters = <SkaterScores>;
close (SkaterScores);

foreach $strSkater (@arrSkaters) 
    {
        $intTotal = 0;
        @arrScores = split(",",$strSkater);
        
        $strName = @arrScores[0];
        @arrScoresOnly = (@arrScores[1],@arrScores[2],
                @arrScores[3],@arrScores[4],
                @arrScores[5],@arrScores[6],@arrScores[7]);

        @arrScoresOnly = sort({$a <=> $b} @arrScoresOnly);

        $intTotal = @arrScoresOnly[1] + @arrScoresOnly[2] + 
                @arrScoresOnly[3] + @arrScoresOnly[4] + 
                @arrScoresOnly[5];
        
        $dblAverage = $intTotal / 5;
        $dictionary{$strName} = $dblAverage;
    }

$i = 0;

foreach (sort {$dictionary{$b} <=> $dictionary{$a} } 
                     keys %dictionary)
    { 
        $i++;
        print "$_, $dictionary{$_}\n"; 
        if ($i == 3) {exit}
    }

Just dreadful. Among the atrocities: Stringing together list elements with plus signs to get a sum; Hardcoded array indexes; Hungarian notation prefixes of variables, in addition to the Perl sigils; breaking out of a loop after three records are shown, rather than starting with a list of the top three. It's just not good idiomatic Perl code.

Perl's arrays and hashes are powerful, and underused here. Perl arrays are treated like C arrays.

In a few minutes, I had put together the following program which is shorter and clearer because it takes advantages of Perl's strengths.

use warnings;
use strict;

my %averages;

open( my $SCORES, '<', 'c:/scripts/skaters.txt' )
    or die "Can't open score file: $!\n";
while ( <$SCORES> ) {
    chomp;
    my ($name,@scores) = split ',';
    @scores = sort @scores;

    # Drop high & low scores
    pop @scores;
    shift @scores;

    my $total;
    $total += $_ for @scores;
    $averages{$name} = $total/scalar @scores;
}
close $SCORES;

my @names_by_score = 
    sort {$averages{$b} <=> $averages{$a}} keys %averages;
for my $name ( @names_by_score[0..2] ) {
    print "$name: $averages{$name}\n";
}

(I'll admit I haven't tested it against their sample data because their sample data is only available in a self-extracting .EXE, which is a bummer for us non-Windows folks, no?)

After I wrote my solution, I noticed that they have an Experts Page that includes links to solutions offered by Jan Dubois of ActiveState. No surprise, Jan's solution is exemplary Perl, and I'm glad that Microsoft provides it. My frothing subsided a bit after discovering this.

Rather than arguing with non-Perl people about which language is better, let's show them. Even more, let's show the people who think that Perl is only a scripting language, only for web sites, or can't be deciphered that Perl will make their lives easier if they'd only open their Swiss Army knives beyond the first blade.