[Epo-marketing] A few words on perl and marketing

[Christopher Nehren]

A while ago, I volunteered to write an article for EPO regarding why
marketing is important to perl. This is the first draft of the results.
I've still got some edits to do, but would regardless appreciate some
fact-checking from those who know their history better than I do. Being
of the pedantic sort I would also appreciate any grammatical reviews as
well. Thanks!

--
Best regards,
Christopher Nehren
-------------- next part --------------
Marketing. The very word can incite Perl programmers to gather
pitchforks and gnash teeth. Why is that? Perhaps it's because we see it
as a wholly social venture bereft of benefits. Marketing is something
the "marketing department" does. Marketing is for those sleezy folks who
smoothtalk and connive others into buying what we spend hours coding.
It's beneath us; people in the marketing department are Evil. How could
one possibly focus on interpersonal relations when there's code to be
written? Those marketing people are strange. If our code is worthwhile,
people will naturally flock to it. "If you build it, they will come,"
and all that.

Unfortunately, the world is not so simple. There's a serious problem in
the Perl community, one that stems rather ironically from our devotion
to our code. Before getting into that, though, we need to cover some
history. Set your Wayback Machines for the Internet of 1995. The
Internet is just getting off the ground, and all the people staking
claims in the New Frontier need something to tie together all these
technologies that were never designed to work together. Enter Perl. Of
course, CGI was Perl's darling. If one needed some quick general
programming task that was more than the shell could handle, Perl was
there. System administrators loved (and still do love) Perl for its
powerful bindings to the underlying C library and the accounting and
filesystem operations found therein. Perl's powerful data processing
features made it a natural for any kind of database programming.
Originally designed as a kind of sed on steroids, Perl naturally handled
all the text processing needs back then.

The Internet of 1995 was very kind to Perl. We were the big fish in the
pond. Everyone knew Perl, or wanted to know someone who did. We were
the king; we were on top. And we reacted to that relationship. We grew
complacent, we grew confident. We were the best of the best. No one
could ever, ever topple Perl. No one could ever beat Perl at anything.
Everyone who had a job as a Perl programmer in 1995 was set for life.

The dot com bust had a funny way of proving a lot of people wrong in a
lot of ways. This is the story of how the Perl community was wrong,
what's happened as a result, and what we can do about it. Thankfully,
all is not lost. As has been shown recently in many places across the
community, Perl is far from dying. But at the same time, it's no longer
the de facto language of choice. We've been told not to look at book
sales. I feel that this is unwise. Book sales represent what people want
to learn. I can remember going to my local Barnes and Noble (large US
chain bookstore) in 2003 or so to buy my first Perl book: the Llama, of
course. I had a difficult time wading through all of the Perl books
trying to find it. They were everywhere. "No, I don't want the Nutshell,
or Programming Perl, or Algorithms with Perl.. I'm just a noob." Fast
forward a few years. I was at that same bookstore a few months ago to
pick up a novel or two and decided to check the tech book section out of
curiosity. What I found was disturbing. There was an entire shelf
section devoted to Java. They had maybe five Perl books, total. Not
several copies of different books, but rather five separate books on
Perl. There were more Ruby books, more C# / VB.NET books, and far more
Java books. What the hell happened? What did we do wrong?

It's not so much what we did so much as it is what we didn't do. Quick,
think of a brand of coffee, a computer operating system, and a computer
hardware manufacturer. Which companies did you think of, and why? While
I'm not claiming to be psychic here, I can certainly attempt to explain
why you thought of the things you did. It's everything to do with
marketing and buzz. Now put yourself in a new programmer's shoes. She's
fresh to the industry and wants to learn programming. Without any
external influences (schooling, employer), she'll likely choose one of
the more popular options. The thought process works something like this:

"It's popular, so it's probably something that I can use to do my job.
It's popular, which means there's a lot of support available for it.
It's popular, so that means that there's a lot of code I can reuse to
make my job easier."

While our new programmer only reaches the last thought after reinventing
her own IRC and HTML parsers, that's how the human mind works in most
cases. The subconscious human mind associates popularity with inherent
quality. Safety in numbers, herd mentality, etc. While I'm not saying
that this is the optimal way a human mind should work, that's the way it
works.

Much of the modern Perl populous would say something like this: "Good,
we don't want people like that anyway. We want the rational people who
can think for themselves and see that Perl is better than anything else
out there. If they're going to be swayed by marketing and personality,
we don't want them."

Why do we feel that way? Why do we have such an aversion to marketing
and popularity? Some of us--myself included--are even guilty of doing
things that we know are unpopular strictly for the point of making
ourselves less popular. Perhaps, when we were young geeklets, we were
unpopular ourselves. Perhaps we've become comfortable with being
unpopular and only seek those who are unpopular as well. Perhaps we look
upon being popular as a kind of lowest common denominator. I can tell
you with absolute certainty that Bill Gates in no way harbors any
negative thoughts about Microsoft's popularity.

Imagine what it would be like for Perl to have 95% market share.
Everywhere you go, there's Perl. Available Perl jobs outnumber every other job
sector by orders of magnitude. Everyone wants a Perl programmer. Demand
for Perl programmers skyrockets higher than it is already. That kind of
world sounds like it would be really awesome to be a Perl programmer ...
and it sounds oddly familiar, doesn't it?

Andy Lester understands this quite well. He's started a blog to talk
about cool Perl things. So what? Lots of people have blogs. But look at
the name. Perl *Buzz*. It's specifically designed to get people talking
about Perl. He made a post about this, too. Andy gave a number of great
suggestions for how to help. I posted a comment on that entry, however,
lamenting my trials with people throwing FUD in my face whenever I
mention Perl. 

What do we do about that? I've pondered how to deal with the FUD since
before I posted that comment. It's pretty gripping. Changing peoples'
opinions about things is immensely difficult and something the other
party needs to want on their own. It's not something we can force to
happen, regardless of any pretty words we can write. Instead, we need to
act. But what to do? The problem, as I see it, is almost entirely
contained within the Perl community. While this means that it's almost
entirely our fault (which it is), it also means that it's almost
entirely within the Perl community's power to change things.

The first problem that I see is that we're insular. This affects other
communities as well, but we've taken it a step further. We're
complacent, vainglorious about it. That's fatal. We're proud of making
fun of Python and Ruby and PHP. But what does that get us? Maybe a cheap
sense of satisfaction, like a grade school bully would get. That's all.
Is that what interacting with one's colleagues is supposed to be? I
don't want to think so. I'm going to go out on a limb here and say that
most people doing Perl work these days have at least passing respect for
the community of sharing on which Perl and the Free Software movement
are based. This community is at its best when there is free, limitless
exchange of information between all parties. What kind of information
sharing occurs between Perl programmers and Python programmers? Perl
programmers and Ruby programmers? Perl programmers and (blasphemy!) PHP
programmers? Not very much--or at least not as much as there should be.

We need to be more inviting of people from other communities. One of
Perl's greatest strengths (manifested in CPAN) is that it glues
technologies together well. Every day we take advantage of this fact in
one way or another. Perl can just as easily run a corporate intranet via
Web browsers as it can manage domain registration, network routing,
Bayesian spam filtering, and all manner of other hard computer science
topics. Perl excels in gluing software and hardware resources together.
But what about wetware resources? The Perl community prides itself on
being based upon sharing and gluing. But we aren't doing very much
gluing with regards to our greatest, most untapped resource: our
colleagues.

I can give a concrete example of this. Patrick Michaud spoke at YAPC::NA
2008 about his PHP Wiki software and about going to a Python conference.
Both these statements met with boos and jeers. Instead of wondering how
other people solve problems (opinions about technical merits aside,
Python and PHP do solve problems, or they wouldn't exist), people poked
fun at him for venturing outside of the safe and comfortable world of
Perl. Our view is dangerously close to a sort of technical isolationism.
We all know the benefits of community involvement in software
development. Otherwise we wouldn't have conferences like YAPC or
various Perl workshops or Perl Mongers or Perl Monks or any of the other
Perl community resources. So why is this limited to just the Perl community?

Equally important to being open and welcoming of the viewpoints that
other communities have is being willing to give our viewpoints to other
communities. Knowledge of a system is most valuable when it's best
disseminated. Tell other communities how Perl does things. Explain why
the Perl community feels that these methods are the best. Honestly and
earnestly try to involve other communities in discussion of how to do
things. But most of all, be open to criticism. The Perl community does
not know everything. If it did, I wouldn't be writing this, as there
would only be Perl. If the Perl community had all the answers, perl (the
program) would be perfect, and no one would have a reason to use
anything else. This path can be more difficult. We can't force other
people to be open to our viewpoints regardless of how open we are to
theirs. But in the end it will foster a community of sharing that will
benefit everyone involved. And we'll have a lot more time to write code
since we won't be getting into petty language wars.

How will these approaches help the Perl community, though? People think
Perl is dead, that it's past its prime, that Ruby or PHP or Java is the
next best thing. If we can show the outside world that Perl programmers
are still active, still coming up with viable solutions to problems that
everyone writing code faces, then perhaps we can engender the sort of
curiosity that gets people to doubt their fast held and misinformed
viewpoints about Perl being dead and without a future.

I know that these viewpoints about Perl being dead and without a future
are wrong. I hope that they stay wrong, indefinitely. Most people who
have a job writing Perl want to keep that job, or at least have the
opportunity to continue coding Perl in the future. The ability to
continue doing work in Perl solely depends upon the availability of Perl
jobs. For there to be Perl jobs, people who need work done need to
realize that Perl is a viable tool to use for the job. If these people
believe that Perl is dead, they will not accept Perl for the job.
Because of this, we--the Perl community--need to embrace our colleagues
in other fields. If we can show them that our tool of choice is still
vibrant and viable, perhaps we can convince them to reform their opinion
about it, and maybe even use it. Perl--and by extension much of CPAN--is
licensed under the GNU GPL. This license encourages sharing and freedom.
While we've carried out the letter of that license in the technical
sense, we've failed to carry out the spirit of that license in the
social sense. I feel that we have great potential in this area. It is
our responsibility to see it doesn't go wasted.


This work is licensed under the Creative Commons Attribution-Share Alike
3.0 Unported License. To view a copy of this license, visit
http://creativecommons.org/licenses/by-sa/3.0/ or send a letter to
Creative Commons, 171 Second Street, Suite 300, San Francisco,
California, 94105, USA.