• The problem with “same terms as Perl” licensing

    Shlomi Fish brought up an angle to the problem with slapping a boilerplate "same terms as Perl itself" at the bottom of your modules when you distribute them: Which version of Perl do you mean?

    For me, I've used that line out of laziness, because I didn't care to think too much about specifics of the details. Now I'll be going back and specifying in my modules.

  • Open source is not piracy

    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.

  • Searching CPAN from Firefox

    David Filmer posted a snazzy Firefox trick that puts a CPAN search in the search dropdown in Firefox. Works wonderfully.

  • Rethinking the interface to CPAN

    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.

  • Call for grant proposals, 2008 Q2

    The Perl Foundation is calling for grant proposals for Perl-related projects. This can be a great way to get funding a project you're working on, or would like to see worked on. TPF has funded Strawberry Perl, Perl::Critic, pVoice and dozens of other projects in the past. Maybe yours can be the next.

  • Perl is back at OSCON 2008

    The schedule for OSCON 2008 has just been announced, and the Perl track is back with a vengeance. Last year, our favorite language seemed to be falling out of favor with five tutorials and nine sessions. This year, it's five tutorials and fifteen sessions. Tim Bunce's DashProfiler and Eric Wilhelm's Stick a fork() in It: Parallel and Distributed Perl are the two that jump out at me.

    I won't be speaking about Perl. Instead, I'll be talking about Just enough C for open source projects and part of Michael Schwern's tutorial-length People For Geeks extravaganza.

  • Google now returns code snippets

    Google's main search screen now returns code snippets in its list of results. This is not just in code.google.com any more.

    I needed to find the docs for the PHP function ftp_connect, so searched Google for it. (I could have gone to php.net and searched there, but why?) The list of results has three hits to PHP manual pages, and the fourth and fifth are bits of code that use ftp_connect. Anyone know if they're getting Perl stuff in there as well? I tried it with WWW::Mechanize, but couldn't turn up hits.

  • Technical debt in your file headers

    Here's a little article about the "file header tax", lines of boilerplate at the top of files that serve no purpose. Copyright notices, disclaimers, maybe even some revision history, it's all just clutter, and clutter is technical debt.

    Take a look at the next file you edit. Is there anything at the top of it that is not functional code? Ask yourself if it really needs to be there. If in doubt, throw it out.

  • Don't trust yourself or your code

    Jared Parsons writes about how Part of being a good programmer is learning not to trust yourself. It's filled with basic but all-too-often-forgotten wisdom about defensive programming. Key bits: "Turn assumptions into compiler errors," "The best way to avoid making bad assumptions is to actively question them at all times," and "1 test is worth 1000 expert opinions."

    I also chuckled to see a sidebar disclaimer that said "All code posted to this site is covered under the Microsoft Permissive Lice." I'd heard of parasitic licensing before, but never like this!

  • ack 1.78 is out

    After three months of lots of development work and intermediate releases, I've released ack 1.78. There are tons of new features and lots of compatibility fixes for Windows. ack is a replacement for grep that is geared to working with trees of code.

    Highlights in this release include:

    • Files specified on the command line are always searched, even if they don't match a known filetype
    • Ability to ignore directories
    • Pager support
    • More flexible grouping options
    • Many more languages recognized and existing ones improved, including CFMX, Actionscript, assembly, Tcl, Lisp, Smalltalk
    • Ability to define your own languages based on filetype

    ack may well change the way you work on the command-line with source code. Try it out and let me know what you think. You can install it by installing App::Ack from CPAN, or downloading the standalone version to your ~/bin directory.

  • Perl Foundation elects new members

    The Perl Foundation has three new members

    • Karen Pauley, Steering Committee Chair
    • Josh McAdams, Public Relations
    • Jeremy Fluhmann, Conferences Committee Chair

    Thanks to Josh to taking the mantle of PR from my shoulders! I wouldn't be surprised if we wind up teaming up on some stuff down the road....

  • Help find students for Perl projects in Google Summer of Code 2008

    (Following is Eric Wilhelm's call for participation in Google Summer of Code.) -- Andy

    The Perl Foundation is participating in Google's 2008 Summer of Code™ and we have a lot of capable, willing mentors looking forward to working with some talented, driven students. So, we would like you to help find those students (and quickly -- the students must apply before March 24th.)

    This is a rare opportunity for students to get a chance to get a paid summer of hacking on exciting projects like Parrot, Perl 6, Moose, Jifty, SVK, Catalyst, or their very own Perl modules or applications. It also brings new talent into the community and gives the student a hefty "real world" experience with a knowledgable mentor. Further, employers love to see this sort of demonstration of teamwork, handling deadlines, communication skills, resourcefulness and etc.

    We're looking for promising students who are interested in open source (or maybe you know someone who *should* be interested in open source.) Knowledge of Perl is optional if the project is Parrot-related. The student doesn't need to be an expert in the problem domain (after all, learning is part of the process), but should bring a big pile of creativity, problem-solving skills, and determination.

    Students should review the page of suggested projects, encouraged to bring their own proposals (those are often the best.) The most important first step is getting in touch with the community and discussing their project idea with potential mentors.

    Google has posted some flyers if you happen to have a university bulletin board or hallway handy:
    http://code.google.com/p/google-summer-of-code/wiki/GsocFlyers

    Additional info:

    http://www.perlfoundation.org/perl5/index.cgi?gsoc2008
    http://code.google.com/soc/2008/
    http://code.google.com/soc/2008/faqs.html

    (Note that Google has particular requirements to do with the fact that they are paying the students. The student must be able to show their eligibility regarding enrollment and employability.)

    Remember, the Perl community draws talent from many fields, so if you came to Perl from a non-computer-science major and still have contacts in that department from your university, it is probably worth mentioning to them.

    Please feel free to forward this to whoever may be interested.

  • Tim Bunce debunks Perl myths

    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.

  • Perl Foundation accepted in Google Summer of Code 2008

    Details are non-existent right now, but the Perl Foundation is back in Google's Summer Of Code program. Congratulations to all who helped us get in there, especially Eric Whilhelm, who displayed an astonishing level of JFDI to get this to happen.

  • TPF helps defend the Artistic License

    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.

  • rt.cpan.org source released

    Jesse Vincent announced that Best Practical has released the source for rt.cpan.org. All the general magic that Jesse &amp. co. use to make the de facto bug tracking system for the CPAN is now available from BestPractical's Subversion site.

    Jesse says "If you've been hankering for a new feature in rt.cpan.org, now's the time to start sending patches. After 3 good patches, we'll grant you a commit bit to the rt.cpan.org extensions." Kudos to Jesse for opening things up and helping spread the workload of maintaining this crucial tool.

  • USENIX opens conference proceedings

    USENIX, the Advanced Computing Systems Organization, has announced:

    USENIX is pleased to announce open public access to all its conference proceedings.

    This significant decision will allow universal access to some of the most important technical research in advanced computing. In making this move USENIX is setting the standard for open access to information, an essential part of its mission.

    USENIX could not achieve such goals without the support and dedication of its membership. We urge you to encourage others to join USENIX. Membership helps us present over 20 influential conferences each year and offer open access to the technical information presented there.

    The proceedings are available at http://www.usenix.org/publications/library/proceedings/

  • LINSWAN: An acronym we can steal from Ruby

    Pat Eyler's recent blog post introduced me to a term I hadn't seen from the Ruby community. MINSWAN stands for "Matz Is Nice, So We Are Nice."

    What a marvelous idea! I'd like to steal it as LINSWAN, for "Larry Is Nice, So We Are Nice," although I suspect that people might get confused and think of Pittsburgh Steelers Hall of Famer Lynn Swann.

  • Use seq or jot to do repetitive numbering

    I just now had to clean up some tables in a PostgreSQL database. The prior DBA thought that it would be good to split up tables into lx1, lx2, lx3 up to lx20. After I combined all the tables together, I needed to drop the originals. I could have written a Perl program to generate a series of drop table lx1; commands to feed into the psql command-line client, but instead I used the seq tool:

    $ seq -f'drop table lx%g;' 1 20
    drop table lx1;
    drop table lx2;
    ...
    drop table lx20;
    

    If you don't have seq on your system, as on Mac OS X, you probably have jot, as in:

    jot -w'drop table lx%g;' 20 1
    

    Then again, if you just have to do it in Perl:

    perl -le'print qq{drop table lx$_;} for 1..20'
    

    but I like to use other tools than the Swiss Army Chainsaw sometimes.

  • More companies openly supporting Perl projects

    More companies are showing their support for open source projects, and I couldn't be happier about it.

    Those of you following Ovid's blog on use.perl.org, or reading his code improvements in the perl-qa mailing list, should give thanks to the BBC for supporting his Perl work. It's not all philanthropic, of course, since the BBC wants good tools for themselves, but I love that they're letting Ovid hitch his stories to the BBC wagon. That helps give Perl some credence in the eyes of open source skeptics.

    Now, as you readers of Mechanix know, Devel::NYTProf is the hot new profiler in town. Not only is the New York Times allowing code to be released, it turns out there's a blog, open.blogs.nytimes.com, where Adam Kaplan announced the module. I love that a company that's not (exactly) in the software business is blogging about their open source software work. Let's hope it's a light in the darkness that others will lend their illumination to as well.