|go ahead... be a heretic|
Comment onby gods
|on Feb 11, 2000 at 00:06 UTC||Need Help??|
Assuming there's no way we can use the Camel, we need to think about what a logo is and what it's used for. A logo should be instantly recognizable at any scale. A poorly designed logo may look cool at 80x80 but resemble a thumbprint at 25x25. It should be easy to draw, suggesting sparse design and little fine detail. A perl logo would be placed on web pages, so it will need to work as a 25x25 icon and as part of a 640x40 banner. A logo should not rely on color. A red version should carry the same base information as a blue version. This will allow for greater flexibility in use.
A mascot for perl would have to emphasize its strengths: Portability, flexibility, and power. Perl is available for almost every platform in use today. Perl, in conjunction with CPAN allows you to address most problems. It may not be the best solution, but it'll help you produce a great temporary fix lickity-split. Finally, perl's text parsing features make jobs that would be monsters in C or Java easy.
The best ideas I've heard so far are the Swiss Army Knife and Duct Tape. One of my favorite lines ever is "Perl is the duct tape that holds the web together". The problems with depiction are numerous:
I'm pretty sure that Victorinox owns the copyright to the familiar red knife image, although they may be amenible to licensing. Copyright not withstanding, a Swiss Army Knife with all the blades extended and a Camel on the case would be pretty cool.
Duct Tape is less strongly copyrighted, but difficult to depict in a meaningful way. It's a roll of grey tape. How do you make that exciting and eye-catching? How do you distinguish it from a zero, a tire, or a doughnut?
Seems to me that the model to look to is Tux. He's instantly recognizable, easy to draw, and there are dozens if not hundreds of remixes that still scream "Linux!" Linus himself laid down some good guidelines in the above link. They're worth examining.
All that said, the Camel is already strongly associated with Perl. If there's a way to formalize that relationship without losing anything, why change?