[Catalyst-dev] Catalyst Marketing Plan Draft

[J. Shirley]

On 10/17/06, John Wang <johncwang at gmail.com> wrote:
> The Catalyst project has created a marketing team in addition to the dev and
> doc teams. Currently jshirley and I are in marketing and anyone else who is
> interested is welcome to join. Marketing serves to promote the product
> (including docs) so it's important everyone is on the same page. My
> intention is for marketing tasks to be defined the Marketing Plan and agreed
> upon with the dev and doc teams. Once there is agreement, marketing can
> start executing against the plan.

Hi all.  This is my first post on catalyst-dev@ but you guys probably
know me from irc.

> The tasks include defining the target audience and the product.
>
> 1) Which of the following groups should be the target audience:
>   1.1) All web application developers including non-OO PHP and Rails
>   1.2 ) MVC/OO framework developers
>   1.3) All Perl devs
>   1.4) Perl devs with a clue

Here's my big opinionated spiel about this.  Just my thoughts as I
dump them out.

As I see it, there are two major groups.  There are the antiquated
Perl developers whom are stuck in sort of a spaghetti-monster code
base.  They can't migrate from Perl, and are hearing the marketing
speak about all the new hotness that is out in the development world
(whether it be J2EE, Rails or whatever).  These guys are easy
converts.  They may not have a clue, but they very well may have a
clue and are a victim of circumstance.  Very little marketing would be
required to get them to give Catalyst a good shot.  To market to this
group, guides for refactoring code to fit into MVC constructs would be
excellent marketing.

The second group are those who are probably more critical of Perl,
thinking of the language as duct tape and nothing that is
fundamentally fit for building large critical applications that must
scale well and have significant benefits over other frameworks.  This
should, in my opinion, be the focus of marketing efforts.  So, to
somewhat point to the list above, I'm thinking a break down of
marketing content that would be along these lines:
 - 50% of the material should be geared towards the non-developer
developers.  The types of people who need books and examples to code
something.  Designers with a technical mind, etc.  I think this
matches with item "1.1) All web application developers including
non-OO PHP and Rails"
 - 25% for the more afluent developers with a wider breadth and depth
of programming.  These are the people who will be swayed by seeing
performance and scaleability, as well as maintenance (for me, the low
cost of maintaining a Catalyst app is the biggest win) and
flexibility.  However, the flexibility will be daunting to the first
group.  This would be "1.2) MVC/OO framework developers"
 - The last 25% would be served for examples just to get things
bootstrapped and going.  Annotated POD with a comment list (like
PHP.net's functions).  Screencasts.  This would serve all groups
involved equally.

> I think Catalyst needs to target all web app developers but this means docs
> geared towards non-Perl users as well as making it easier for people to
> install without CPAN, etc. Because of this marketing cannot make this
> decision alone.

Agreed -- but what about all web app developers who turn into better
developers from using Catalyst?  If all of our material is designed
for the monolithic PHP coder, the glass ceiling is pretty low.

> How should we, as a group, decide on this?

Death match with sporks.

> 2) What is the elevator pitch for Catalyst
>
> An "elevator pitch" is the short sales message you can tell soemone in an
> elevator ride to get them interested in your product. This will depend on
> who we decide is the target audience. I think it should be something along
> the lines of:
>
> "The most scalable and flexible web framework backed by the largest open
> source library"

Scalable at this point is not and cannot be backed up with current
available facts.  What's the largest Catalyst app out there?  How many
nodes does it run on?  Vox?   Googling for "vox+catalyst" doesn't have
any decent results.  Rails can point to any 37signals app and several
others.

It certainly is flexible, but I'm certain some developers in decision
making positions aren't swayed by hearing that.  The maintainability
of a Catalyst app, as well as built-in testability (also thanks to
jrockway for the Selenium bindings) and documentation systems with
test are bigger points.  Hardware is cheaper than developer+QA time.

> People are interested in the entire solution not just the framework so while
> Cat is very flexible and has lots of options from a marketing perspective we
> need to start pushing one recommended solution. From a marketing perspective
> on the website, all these components will be marketed as part of the
> Catalyst solution while mentioning components can be swapped out.

I know a lot of you (Hi Matt) hate the term "Best Practices" but that
is what this is.  Catalyst needs a list of Best Practices.
Task::Catalyst should support this, and be the simple solution to
getting what you need installed quickly.  If not the name
Task::Catalyst, some other bundle package.

>   4.1) If we decide to target non-Perl users, can we make the Catalyst
> solution super easy to install for someone who doesn't know how to use CPAN?
> Should have Cat easily installed into a MyApp/vendor directory?

I had a Perl coder who doesn't do anything with CPAN (see
spaghetti-monster bit above) attempt to install Catalyst and gave up.
I think this is definitely a desired feature.

>   4.3) Documentation on writing tests for Cat apps. One of the big features
> of frameworks is that they make you use better coding practices including
> writing tests. I think we need some recommendations and documentation on how
> to write common tests for Cat apps using Test::Class, Test::MockObject and
> the like. Right now we have the source for existing tests and POD for
> Test::WWW::(Mechanize|Selenium)::Catalyst. Should have have
> tutorials on using these?

I think we definitely should.  I know many many many developers who
simply do not understand how to properly write test scripts for web
applications.

> Is there anything else?

It is a good outline, great work.  It covers the points I was thinking
of, and many more.  Above are the inline points and I'll go through
later.  It'd be good to get a wiki setup (MojoMojo, baby!) to start
updating the doc.   For now maybe we can just use a trac node (I don't
have access to Trac edits, btw)

Thanks,
-J.

-- 
J. Shirley :: jshirley at gmail.com :: Killing two stones with one bird...
http://www.toeat.com - http://code.toeat.com/~jshirley