[Epo-marketing] marketing

[Chris Prather]

My promised longer response...

On Sat, Mar 13, 2010 at 6:29 PM, Tom Metro
<tmetro+enlightenedperl-marketing at tommetro.com> wrote:
> I've been on the EPO announce list for a while, but only joined the
> marketing list shortly after the recent discussion broke out on the announce
> list, first over the place mats and then over Padre. (Seems like more of a
> discussion list tan an announce list.)

Yeah, we're not well moderated.

> Recently the Boston.pm organizer took note of what was done for CeBit and
> wondered if Boston.pm should do something similar for the local LinuxCon.

"Yes!" However being that I live in Florida, I cannot really help
beyond encouragement from the other end of I-95, so that's easy for me
to say.

> I read one of the reviews of the Perl booth at CeBit and it sounds like it
> worked out well for them, but I'm not entirely sure what the message should
> be about Perl these days. There's certainly enthusiasm for promoting Perl,
> but it isn't clear that we can articulate compelling reasons for using Perl.
>
> The CeBit approach seemed to be to answer whatever random questions that
> came up, and to show off demos of a few projects. While that doesn't hurt
> the situation, a more organized and intentional approach might do better. (I
> had the same thought when reviewing the place mats, which seemed to draw
> attention to specific projects, but didn't communicate why those Perl
> solutions were compelling.)

I agree. I think the problem is that we as a community, or even a
limited community, or even a few people with ideas and loud mouths,
haven't really had the discussions about "next steps". The first step
was making sure that the community wanted to embrace Modern
Enlightened Perl, obviously the majority of the echo chamber does ...
and the rest are being silent or drowned out or something.

So now we need to frame what Modern Enlightened Perl buys you in the
context of programming at large.

The vanguards of Moose, Catalyst, and DBIx::Class show large popular
projects written in a Modern Enlightened style. That style needs some
articulation but from my perspective it is that they leverage Perl's
cultural strengths: flexibility, distributed development, and strong
conventions.

With Flexibility they embrace TIMTOADI allowing you to customize and
override. That is they choose configuration over convention at the
code level. All three of these packages reflect this in the sheer
number of their extensions. Catalyst::Plugin, MooseX, and DBIx::Class
as top level namespaces all have dozens and dozens of modules under
them above and beyond the core projects.

For distributed development not only do these three projects have an
open commit policy, that is anybody who shows up with a patch
generally gets a commit bit, they also utilize the infrastructure CPAN
brings to the table in a large way. They have very large test suites,
and responsive core maintainers who watch the automatic testing that
the larger CPAN Testers provide. They prefer to utilize CPAN
dependencies over re-writing code when it makes sense, taking
advantage of the 20,000+ packages in this 15 year old globally
distributed environment.

Finally with strong conventions let me focus on the project I know the
best of these three, Moose. Moose has worked hard over the last four
years to build out more support for authors of patches. We have a
documented support policy, a committers guide, and several
author-specific tests that include optionally testing *all* down
stream dependencies of Moose. We do this because, although we document
that we priorities correct behavior over everything including
backwards compatibility, our convention is that we try to maintain
compatibility where possible. We have our own best practices and
idioms, and have had several long discussions about where things
should be enforced via warnings and exceptions, and where we should
leave them at the discretion of the author. Obviously we are not
perfect at this, but we make the attempt and that in my biased opinion
counts for a lot.

These three factors are not unique to these three projects, they are
instead the ideals that the community who surrounds these projects
strive for. They are, in my opinion, the ideals that the Modern
Enlightened Community strives for.

> What I've been wondering is whether EPO has researched the reasons why
> developers have left Perl, the impression they have of Perl, and their
> concerns over using it on a work project. (Of course we can all speculate
> and guess at the answers to these, but there's danger in doing so from
> within the community, as those that have stuck with Perl have obviously not
> considered the deficiencies significant enough to justify abandoning the
> language.)

There has been no formal research. I'm not a social scientist, I have
no clue how to begin such a project. I would love to have some
research here.

> Once you understand the "customer perspective" better, you can then address
> it with all the marketing techniques that engineers hate, but are still
> effective on us: case studies (big names that still use Perl), statistics
> (CPAN modules, number of Perl jobs/programmers), feature comparisons (Perl
> vs. Python vs. Ruby), specific demos showing how to solve a common problem
> more effectively with Perl, talking points, etc.

The largest reason I've heard for people who stay with the Perl
community vs other communities is culture. From your terminology
you've already embraced the idea that Perl is losing ground some how,
I have at times held this idea too. I think however that isn't (yet)
the case. All of the Job surveys and whatnot I've seen suggest Perl is
only losing ground to other languages when you compare it's relative
growth to the relative growth of other languages. I think the case is
that Perl is an "established" language like Java, C,  and C++ ...
while the newer language Python and Ruby in particular, are still
going through the establishing themselves phase. This seems odd to
say, Python has been a cultural rival for a very long time now (at
least a decade), but recent graphs I've seen suggest it to be true
none the less.

The real power of Perl isn't that we can implement any given solution
better, it's that the odds are the solution is already implemented and
sitting on CPAN ready to be used. The real comparison is "write these
dozen lines in Python or Ruby" vs "Search search.cpan.org for someone
else's solution".

Modern Perl's slogan internally has been TIMTOWTDI BSCINABTE (There is
More than One Way to Do It. But Sometimes Consistency is Not a Bad
Thing Either). I think if I were to suggest a slogan that Perl should
have in the larger market place it's BTDTIAOC (Been There, Done That,
It's Already on CPAN).

-Chris