[Catalyst-dev] Catalyst Marketing Plan Draft

Zbigniew Lukasiak zzbbyy at gmail.com
Fri Oct 20 08:06:53 CEST 2006


Hi,

Going back to the marketing document I see one more thing that can be
added there - some introduction why we at all need this marketing.
Based on this we could deduce who should we market to etc.

Top of head reasons that can be added there:
- hosting companies should treat Catalyst as a serious framework and
make life easier for those using it
- more people working on Catalyst add ons
- more users of Catalyst means better testing

There are also disadvantages - more people working with Catalyst means
APIs need to be more static, any change would involve much more
communication between parties etc.

--
Zbyszek

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.
>
> I've put together a plan in a MS Word doc that I've attached and paraphrased
> below. Basically we need to come to agreement on some high level decisions
> before any action can be taken. For now, I'm using MS Word because I like
> and am used to their outline numbering system. I can make it available in
> PDF if preferred. I paraphrased the content in this email this time around
> and will probably continue to do so for things that need decisions but the
> intention is for the full plan to live in that document.
>
> 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
>
> We need agreement on this because it has been debated as to what types of
> users Catalyst wants to attract, if any. People will have their individual
> opinions but we need Catalyst dev+doc+mktg to come to an agreement and for
> all three groups to accept that target audience as a driver in goal setting.
>
> 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.
>
> How should we, as a group, decide on this?
>
> 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"
>
> This is geared towards non-Perl users as well as management types. We have
> the users and the technology to back it up.
>
> 3) What is the Catalyst Solution Bundle
>
> 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.
>
> In the past, this was Task::Catalyst. The issues:
>
>   3.1) Can we get control of Task::Catalyst
>   3.2) Are these still the right components
>   3.3) There should be a recommended cache compoent
>
> The solution bundle will need to be supported by doc and dev to make the
> bundle as seamless and productive as possible.
>
> 4) Does the Catalyst solution need anything else to support the message
>
> If we are going to pitch Catalyst as a great solution, the product needs to
> match the expectations generated:
>
>   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?
>   4.2) Built-in caching that you can just turn on seems to be a selling
> feature for other frameworks. While Cat has plugins, should we have a
> recommended plugin and the ability to just turn it on and have the Cat app
> save cached content to a MyApp/tmp/cache directory?
>   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?
>
> Is there anything else?
>
> The information in this email is a parapharsing of a MS Word doc I put
> together and am attaching. It's also available at:
>
> http://www.dev411.com/catalyst/CatalystMarketingPlan_draft.doc
>
> Let me know what you think of the above and how we should come to concensus.
>
> --
> John Wang
>  http://www.dev411.com/blog/
> _______________________________________________
> Catalyst-dev mailing list
> Catalyst-dev at lists.rawmode.org
> http://lists.rawmode.org/mailman/listinfo/catalyst-dev
>
>
>
>


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/



More information about the Catalyst-dev mailing list