I run Perl.com as part of my day job. Partly due to its heritage and partly due to the nature of the Perl community, it's always been a challenge to find the right audience and publish effectively, where part of that effectiveness includes financial stability and self-sustainability.
One of my main goals for the site this year was to increase its traffic, both in pages viewed and unique visitors. There are normal ups and downs, but so far so good. (In fact, the ratio of visitors to pages viewed is substantially better than for any other site I edit.) However, I'm wondering how to continue this trend next year. At some point doing the same thing will likely cease to work and I want to have a better plan before that happens.
I wrote recently about distrusting your fanbase. There's definitely a fanbase here of a few thousand people who will automatically read almost any article on the site. There's a good parallel to book buying habits too -- we can almost guarantee a fixed number of sales for any given Perl book. However, that number isn't hugely profitable; it likely flirts on the edge of profitability.
Growth (and the kind of profitability that makes this worth pursing, rather than giving up in favor of something that can beat inflation, for example) won't come from giving the experts what they want. That might work if what the experts wanted were so detailed or tedious or difficult to research, find, collect, summarize, and present that they would pay for it, but that's not the case in the Perl world.
Most Perl programmers aren't gurus. Based on the numbers, most of the Perl programmers in the world don't read Perl.com. Most of the programmers in the world aren't Perl programmers.
If there's growth, it'll mostly come from there, not from convincing use Perl posters (or even readers) to read articles.
That doesn't mean that we'll never publish detailed articles about specific modules or projects or pieces of the internals. It's one thing to give beginners something to think about and another to expect them never to need advanced information. It does mean that I'm looking for articles and lighting articles and evangelism and ideas to reach a million Perl programmers who've never heard of the site and the several thousand a week who download Perl with our assistance.
This week we're running an article from Rob Kinyon about subroutines. There's plenty to say about them and I can only think of several dozen people in the world who know everything the article says already.
If you've ever wanted to write but thought you weren't experienced or famous enough to explore a topic in depth, here's your chance. Pick an aspect of Perl that you wish someone had explained to you when you were just learning and explain it once and for all in a couple of thousand words. If that's you, let me know.
(I'd also love suggestions on how to get the Perl Testing book in front of the eyes of and into the hands of people who need it. Do you know software testers? Can you write a review for a big website? Did you find it useful, entertaining, informative, or worth talking about?)
The Perl Debugger. I put off learning it for years, but now I use it all the time.
This morning I traced a misconfiguration in a TWiki, which involved a simple text mistake on a config page. Another person and I spent a while looking at the page and didn't see the problem, but when I could go under the hood and twiddle with the bits it became clear very quickly what we had done wrong.
I've already written an article on basic perl debugger commands for The Linux Journal but I could possibly write a shortish article with a more hands-on bent.
Best regards,
Dave Baker
