On Monday Sean Quinlan became the 100th contributor. We have a week left to get 128 contributors. Part of the experiment is to get as many people involved as we can, at any level. I don't care how much you donate: a $1 donation is just as good as $100 when we are counting contributors.

I've received lots of feedback. Some people want to contribute without creating a new account on yet another website. Some people don't mind a new account since they can login with Facebook, but they don't want to give their credit card to a site they haven't used before. Some people don't want to use a credit card, or the US-based payment processor doesn't like their non-US credit card.

For the final week of the experiment, we want to open this up to alternate means of funding. If you've been put off or excluded by the crowd funding site, you can donate directly to Jeff through the PayPal or Flattr buttons on his MetaCPAN page. Although this money won't show up on the Crowdtilt site, we can make a virtual donation to represent everything Jeff gets through the private channels so the Crowdtilt campaign still "tilts".

This also works for the people who want to make a semi-anonymous donation. Jeff will know who you are through your PayPal of Flattr account, but we won't list you as one of the contributors.

If none of these work for you and you'd still like to contribute, let me know what would work. Part of the experiment is to discover the ways that the Perl community would like to contribute directly to projects they like. There are other experiments I want to try once this one ends, and I'm collecting feedback and listening to what people have to say before I think about those.

Pure Perl modules are usually fine, but Heroku is a limited Ubuntu environment that doesn't have all the libraries you probably expect to already be there. One of the modules I needed had DB_File as a deep dependency, so deploying my app (with Heroku toolbelt and Mojolicious::Command::deploy::heroku) fails. I get the rainbow barf from the uni-raptor.

It's not as simple as running cpanm (once you know where it is) because there's a shebang line problem:

$ heroku run --app appname -- /app/vendor/perl/bin/cpanm --verbose --no-interactive DB_File
Running `/app/vendor/perl/bin/cpanm --verbose --no-interactive DB_File` attached to terminal... up, run.8045
bash: /app/vendor/perl/bin/cpanm: /tmp/perl/perls/perl-5.16.2/bin/perl: bad interpreter: No such file or directory

I can specify the perl path myself to fix that:

$ heroku run --app appname -- /app/vendor/perl/bin/perl /app/vendor/perl/bin/cpanm --verbose --no-interactive DB_File

Now I can watch the output to see that it's missing libdb:

Running `/app/vendor/perl/bin/perl /app/vendor/perl/bin/cpanm --verbose --no-interactive DB_File` attached to terminal... up, run.4646
cpanm (App::cpanminus) 1.5018 on perl 5.016002 built for x86_64-linux
...
--> Working on DB_File
Fetching http://www.cpan.org/authors/id/P/PM/PMQS/DB_File-1.827.tar.gz ... OK
Unpacking DB_File-1.827.tar.gz
...
cc -c  -I/usr/local/BerkeleyDB/include -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2   -DVERSION=\"1.827\" -DXS_VERSION=\"1.827\" -fPIC "-I/app/vendor/perl/lib/5.16.2/x86_64-linux/CORE"  -D_NOT_CORE  -DmDB_Prefix_t=size_t -DmDB_Hash_t=u_int32_t   version.c
version.c:30:16: error: db.h: No such file or directory
make: *** [version.o] Error 1
FAIL
! Installing DB_File failed. See /app/.cpanm/build.log for details.

This isn't a huge deal. I can compile DB_File locally and include the result in my app, but now I know that's what I need to do.

Wendy noted that deleting distros was a topic at the recent Lancaster QA workshop. She didn't say much, but it sure sounded like people were looking to create policies and work to police something.

CPAN has never been curated, and that's by design. Let's keep it that way so the rules committees leave it alone. :)

I've been playing with crowd funding tools, in Perl and in other areas. I posted a note to Twitter looking for volunteers, and Jeff suggested a particular Pinto feature which he needs for Stratopan, a hosted Pinto service that manages private CPAN with exactly the versions of distros that you want. I set up on Crowdtilt, a funding platform on top of Perl's Dancer framework. Jeff made the video to introduce himself. Crowdtilt waived their fee because they love Perl.

Pinto is Jeffrey Thalhammer's private CPAN management tool. If you don't recognize the name, think "The guy who invented Perl::Critic", which he gave the world for free.

Jeff wants to do this full time. My job (for which he offered me 10% of the company he's set up to do it) was to find him enough financial breathing room that he could spend a solid month working on turning the mostly done concept into a private beta. It's a bit magical that we calculated that number to be exactly $4096. My other job is to be the immodest one with the open guitar case. All of this money goes to Jeff so he can focus on the code.

We're already 15% of the way there, with me throwing in the first bit of money. If you want Stratopan, throw in any amount. I'd rather have 512 people giving $8 than one person paying the whole thing. We want to turn this into a service for everyone, and 512 customers could be the right size to make a serious go of it.

If you don't need Stratopan or Pinto but you use Perl::Critic, a thank you donation would do quite a bit, too. Crowdtilt only gives us the money if we hit our target, but they also let us collect more than that. We aren't expecting Veronica Mars levels of funding, but we wouldn't complain about that either.

But, don't stop at giving money. Spread the word. Our secondary goal is to measure the reach of social media into Perl. Don't just retweet or link; tell your own story. Let people know how Pinto can make your life easier. Have a competition to see which Perl monger group can find the most money or the most participants.

Us using MobRater doesn't mean that the most voted nomination will get the award, but the committee will certainly take that into account. There might be a great nomination that comes in at the end and doesn't get that many votes. To help get around that, check back sometime to vote on the new people added.

You can vote on the names there and also add your own. I'm really looking for new names, especially in the communities that might not overlap that well with the US and European communities that I knew much better. So far, we've had no one from India or Africa receive an award, and we've had very few recipients from Asia and South America. There might be people doing great things for their local communities that don't get much press far away.

I specifically choose to work on my cpan script because it's part of core Perl, and I'd like to see other people who contribute directly to core try out some of their own features under "Perl". For those who aren't a contributor, I'm also interested in what you'd pay and how much you'd pay for a feature to be improved, implemented or whatever. Maybe you'd only pay $10, but maybe 1,000 other people would pay $10 too.

I'm also thinking of what I'd like to try next. I have a list of things I'd like to do, but I don't have any idea of the things that many other people would like me to do.

perlpolicy says

As of Perl 5.12, deprecated features and modules warn the user as they're used.

There's the deprecate module which provides this warning. A module is deprecated for at least one cycle before it's actually removed. That doesn't help much if you skip over several perl versions.

Module::CoreList tracks deprecated modules too.

And, as one commenter, mentioned, the fallback is for people to read the perldelta pages to find the changes between the version they are using and the version they want to upgrade too.

The information is out there, and as programmers, we have everything we need to play with it however we like. :)

I've been thinking about what a psychic ninja would actually do. He'd be a highly skilled worker who gets your work done without you knowing he did it, and he'd do it before you knew you wanted it done. If a psychic ninja was your gardener, you'd never know that grass actually grew, but you'd have the best lawn in the neighborhood.

How would that sort of thing show up in Perl? I haven't had many ideas about that yet, but I've been slowly hatching some idea where Perl can recognize structured data. We can play with XML, JSON, YAML, and all sorts of other formats, but we do that by loading a particular module and telling perl to use that module to parse the data we give it.

A bit more sophisticated are module families. We have several parsers for each of those types, and some *::Any modules to select the best one that's installed. Can we go ten steps further to make an Any::Any? Something detects the incoming data, knows the module family, and loads that. This technology already exists. It's File::Magic, which is just a Perl implementation of something we can do on the command line. I'm not talking about cheating with MIME types either. That's just Ninja. I have Psychic::Ninja.

The output side would be similar, but that's more complicated. If you start outputting HTML to a socket, it adds CGI or HTTP headers. If you output something that looks like CSV, you get an Excel spreadsheet. If you output XML, it directs it to /dev/null. Perhaps it looks at the directory you're in or where you are putting the data to figure out what you likely want for the output format. Some of this technology already exists in IO::All.

Those two things I can imagine having lots of smarts and heuristics. We can train our psychic ninja to do all that. It's the stuff in the middle that I need to figure out. Is there enough information in the universe that the module can make a good guess at the task? Besides all the machine learning stuff to draw from previous runs, what other things can the psychic ninja observe? Command history? The rest of the command line, including previous and future commands in the pipeline? That is, can I just do this and have the right thing happen?

% pninja < input.xml > output.xls

It doesn't really matter what the answer is because it will end up on my list of all the other things I think about and do nothing with. I do like thinking about how much I can reduce user instructions to a program and still get what I want.

It might be easier to figure out what an Glowing Octo Ironman would do. That's just a triathlete who's drank too much Red Bull and happens to have extra arms and legs.

That fee waiver is interesting. I've looked at many crowd funding sites. Most at least charge the credit card fees. Fractured Atlas, where I'm a board member, charges 7% for their fiscal sponsorship program. If TPF wanted to set up their own program, not only would they have to charge some fees, even to just cover costs, but they'd have to manage it as well. If there's already someone doing all that work and doing it for us for free, so much the better.

The only way I'm really a developer for Perl is through CPAN.pm, which bundles my cpan(1) program. It's a small thing. One of my to do items was easy fastest-mirror support. For the public, www.cpan.org acts as a global load balancer (thanks DynDNS!). That's for the mirrors that the Perl NOC folks know about. My particular interest is private and local mirrors, whether for the real CPAN or the DarkPAN variety. It's a small feature that we can use as a test of the service before we think about using the service for larger projects. Maybe we like it and maybe we don't. Remember though, they are in beta, so we have a chance to help them improve their service and help other open source projects who don't have funding organizations.

I've already pledged to my own project. I don't particularly want anyone's money (after US taxes, I end up with so little anyway), but if you'd like to contribute a little bit to match me, I'll take my pledge and put it into the next Perl project. Perl developers: think about what you might want funded.

There are much bigger things we might fund for Perl through something like this, but I'll be the guinea pig. Any Perl developer (and you have to be a current contributor to propose a project) interested in funding through Catincan can talk to me privately if they like.

If you want to funding existing TPF projects, such as the general Perl Core Maintenance Fund, you can donate directly through TPF.

David Golden also pointed me to Crowdtilt, a social funding site running on Dancer.

I think we can improve on this wonderful but underrated social feature. I created the ADOPTME user awhile ago to house the distributions from PAUSE authors who had passed away. I would modify the build file to give a warning, bump the version, and upload as ADOPTME. That's too much work, though.

Around the same time, Andreas started to provide the PAUSE permissions data as 06perms.txt. This example shows that I have "first-come" permissions (a quirk of PAUSE and me being an admin), Sinan has "module-list" permissions, and there are three comaintainers:

Crypt::SSLeay,BDFOY,f
Crypt::SSLeay,CHAMAS,c
Crypt::SSLeay,DLAND,c
Crypt::SSLeay,GAAS,c
Crypt::SSLeay,NANIS,m

If you give permissions to ADOPTME, those permissions will show up in
the permissions list too:

Mac::FileSpec::Unixish,ADOPTME,c
Mac::RecentDocuments,ADOPTME,f
Mac::iPhoto::Shell,ADOPTME,m
Mac::iTunes,ADOPTME,m
Math::Cephes,ADOPTME,c

(New maintainers should kick out ADOPTME as a co-maintainer, though. I'm pretty sure Math::Cephes has a full time maintainer now).

There are several ways you can add ADOPTME as a maintainer:

• If you've registered the namespace, you can edit "CPAN User-ID" field. You lose all control of the module this way.
• For all modules, you can pass primary maintainership to someone else.
• You can give a user co-maintainership

Having done that, when someone comes to the PAUSE admins asking to take over a module, we can short circuit our normally conservative "announce publicly and wait" process to transfer it immediately. Even active PAUSE contributors can use this to avoid having to respond to takeover requests for modules they no longer use. We might even be able to make this a no-human-contact process. You log into your PAUSE account, use a form to ask for permission for the adoptable namespace, and get permissions immediately. Of course, that depends on me actually building that into PAUSE myself, most likely. All the PAUSE code is in Github, though, if someone wants to do it themselves.

Even better than that, though, is the list of adoptable modules that we can advertise to people who'd like to work on a project that they didn't start themselves; there are a surprising number of requests for that sort of thing. PAUSE also has module status flags that can indicate this. The support level "a" flag denotes "abandoned; volunteers welcome to take over maintainance". However, you have to register the namespace to use that, and someone (probably me) has to manually approve the registration. That's a bit of extra work you don't want if you're actually abandoning the module.

I'd really like to see someone hack MetaCPAN to show an "Adopt this module!" thingy in the search results and the various module pages. It's probably a long shot of anyone hacking RT to show people reporting or examining module bugs that the module is adoptable.

$ perl5.14.2 upj.pl
File count is 13130
Total posts is 10243
Duplicate count is 2677
Uncounted is 210
------------------------------------------------------------------------------------------
Year | Total |   Jan   Feb   Mar   Apr   May   Jun   Jul   Aug   Sep   Oct   Nov   Dec
------------------------------------------------------------------------------------------

2001 |   154 |     0     0     0     0     2    24    26    21    25    16    29    11

2002 |   357 |    26    30    33    14    39    21    29    43    29    33    27    33

2003 |   512 |    36    35    50    46    19    36    40    59    50    48    49    44

2004 |   847 |    60    52    76    73    68    82    67    80    57    81    77    74

2005 |  1235 |    87   100   100   121   117   110    95    96    91   114   125    79

2006 |  1499 |   134   122   121   115   135   134   111   153   114   138   142    80

2007 |  1458 |   138   128   119   143   121   136   135   133    88   144   111    62

2008 |  1058 |   114    99    99   125   122   107   110    82    64    57    50    29

2009 |   617 |    44    44    48    63    70    40    51    45    39    63    60    50

2010 |   883 |    63    69    56    98    95    64    89    79    64    85    59    62

2011 |   868 |    83    79    96    62    67    71    64    87    71    66    68    54

2012 |   679 |    61    63    83    58    62    58    42    60    48    63    37    44

jobs.perl.org provides its own counts. I don't know how it's counting, but its data doesn't fit what I see from the postings. For instance, in January 2013 it counts 111 jobs but there were only 101 posts in that period. I also suspect that it's counting duplicates. I asked about this last year without an answer.

The 210 uncounted messages are people posting directly to the list, spam, and other non-job postings.

I only count the first instance of a posting by looking at it's URL. According to the nntp archive, many jobs have repeated posts. I don't know if these are for the same seat or the same position with multiple seats:

 43 http://jobs.perl.org/job/2308

 26 http://jobs.perl.org/job/10810

 23 http://jobs.perl.org/job/5231

 19 http://jobs.perl.org/job/1129

 19 http://jobs.perl.org/job/7420

 16 http://jobs.perl.org/job/5206

 15 http://jobs.perl.org/job/11684

 14 http://jobs.perl.org/job/11634

 14 http://jobs.perl.org/job/14088

 13 http://jobs.perl.org/job/5848

 12 http://jobs.perl.org/job/5086

 11 http://jobs.perl.org/job/4096

 11 http://jobs.perl.org/job/5167

 11 http://jobs.perl.org/job/5580

 11 http://jobs.perl.org/job/6799

 11 http://jobs.perl.org/job/14730

 10 http://jobs.perl.org/job/2843

 10 http://jobs.perl.org/job/4559

 10 http://jobs.perl.org/job/13608

I put all the data in a JSON file.

Jeff said it would be trivial to make a cert theme, and now that I've collected all the data, it's someone else's turn to do that. :)

A better LinkedIn makes the world a slightly better place for me. Our ill-defined, disparate, and disperse community has many parts that can be improved and I spend a couple of minutes each morning moderating some LinkedIn stuff. Other people help out in other sites. There are a couple of things that I'd like to encourage.

I want to recruiters to see that CPAN Developer's Group badge and ask candidates why they don't have it. Even if that means the person only ever uploaded one module, that means they've gone through the process once, which I think is the biggest obstacle to sharing. Once they get over that hump, even if just to get the badge, they are a slightly better Perler. And, it's all about a long journey where each step makes them slightly better. If they are hiring better Perlers, I'm dealing with better Perlers when I show up.

I want to put it in the mind of Perlers that they can make a better labor market for themselves, now or later, by showing recruiters that there are many people who are part of the Perl world. Even if most of the Perlers aren't looking for situations, a situation might find them. There's very little that someone can do to verify what happened tat some job otehr than asking a someone else they don't know (and anyone can find three good references). However, there are thousands of people who can testify to someone's CPAN activity, module usefulness, and so on.

Even people not looking for a situation affect the job market by the skills and associations they present. Recruiters have wonderful tools to find people now. They aren't limited to the self-selected set of submitted résumés or the word of mouth of the small group of people they know. They see information for people who aren't looking for jobs. They see patterns in profiles, and each profile slightly changes their view. The way I present myself makes another person think a little bit differently about what they expect from other Perlers in the same way that the way you present yourself affects how people may think about me.

Marketers might call all of this "brand maintenance". It's just unorganized and volunteer driven, just like some other stuff we like. I don't have to do it all. I just have to do a little and trust that other people will do a little somewhere else.

I was wondering about that last week as I was reviewing a code base that runs on v5.8, a common situation for companies with big Perl applications that have been around for awhile. I'd like to have some chart that shows which vulnerabilities you have based on your Perl version.

I figure someone might have this somewhere, so I haven't done the work to make the list myself.

Curiously, I found that CERT has Perl programming standards. Now I'd like a Perl::Critic plugin that checks all the CERT things. I think that would be a good candidate for a TPF grant, actually.

Who's invented the day extender so I can get twice the time each day to do all the things I want? :)

Of course, LinkedIn is a trust network. Things like these endorsements, or the CPAN Developers Group and the Advanced Perl Users Group, let someone outside the Perl universe know one person inside then discover trustable people they don't know. With so many companies looking hard to find good Perl programmers, your endorsement might be able to help a friend who's a good programmer but not highly discoverable.

I was amused at a few other possible endorsements. Does Randal Schwartz know Perl?

Is Damian Conway good at public speaking? I can endorse him, although they don't have a button for "Everyone else should just give up":

Right after I finished my LinkedIn tasks, I watched Rachel Botsman's "The Currency of the New Economy is Trust" TED Talk, which just happened to be next in my podcast feed. She mentions Stackoverflow: