[Catalyst] RFC: The paradox of choice in web development

[Jay Kuri]

I think a lot of folks make good points.

I am not arguing that we do not promote things.  I am arguing that

A) it's not as bad as it first seems.

  -- and --

B) before we can promote Catalyst / Perl, we have to know where we
want to position ourselves.

I think it's a mistake to try to compete with Rails for the newbie.
Some large percentage of newbies will never do anything more than
occasional tinkering if they stick with web development at all.  We
have limited resources and we don't want to waste our time there.  To
make Catalyst accessible to the rails-like newbie, we have a TON of
work to do and it's the wrong direction, in my opinion.

Catalyst is a solid framework with lots of available options, I don't
think we should hide that fact.  I've worked with Rails, it is what
led me to Catalyst in the first place.  Rails is great for greenfield
projects.   Using Rails to replace an existing system is a nightmare.
Their 'framework' requires too many adjustments to the problem space
(db changes, changes to how authentication occurs, etc.)

To be sure, Catalyst works easier if you can make those kinds of
decisions / changes.  Catalyst has the advantage, though, in the
existing system space because it can be made to fit, and in most
cases, rather easily.

I just went through this process with a client.  I had to explain why
we chose Catalyst and Robert is correct here.  In the enterprise, it's
a hard sell.  It really comes down to total cost and maintainability.
I sold them on Catalyst for a few reasons:

1) There are other perl programmers out there.

2) There are other big companies using perl / Catalyst (iplayer, etc.)

3) Speed of development will increase dramatically.

4) There is commercial support outside of my organization.

5) Catalyst is maintainable and there is a focus on remaining
compatible with past deployments.

It was not an easy sell by any means, but the biggest issue was not
Framework related, but language related.

In my opinion, these are the things we need to highlight.

We have two markets we are selling to, the developers and the
executives / decision makers.  The executives need to see the above.
A failed project means their job, and that's what they are looking to
ensure doesn't happen.    This is the information that needs to be out
there front and center.

We also have to sell to the developer.  This is an easy sell for the
clueful, but we I agree we don't do a very good job of promoting what
Catalyst can do for a developer.   I think the key points here are:

1) Catalyst can do greenfield apps very easily, but can also be made
to fit in to an existing system.

2) There is a ton of integration to various systems (Authentication,
Databases, other sources) that save you huge amounts of time when
developing.

3) There are a number of 'helpers' that make it easy to get a basic
app up and running.

4) A premium is put on keeping backwards compatibility.  Though
Catalyst is moving forward all the time,  once you build it, it will
stay working.

5) We have a hugely helpful community.  While they expect you to have
a basic clue, beyond that they will go out of their way to help you
figure things out.  The irc channel should be showcased here.  Perhaps
even a #catalyst-help should be created with a focus on helping
newbies (a web interface to #catalyst-help would be good)

If we can communicate these things to newcomers (both developer and
executive) we will be in good shape.  Again - I don't think we should
compete with Rails for the newbie, Catalyst requires some clue and we
don't have the time / resources to guide people in learning perl.
Again, I think if we really want to compete we should focus on what
Catalyst is... and that is more flexible and capable than other systems.

Jay

On Feb 15, 2009, at 8:12 AM, Robert L Cochran wrote:

>
>>> The fact is that Oracle does not try to compete for the low end of
>>> the market with MySQL.  They don't want it.  They never did.  Why
>>> do we?
>>
>> The comparison is good, but not very exact. I know companies which
>> don't use PostgreSQL but Oracle, because Oracle is better known
>> (because it offers discounts to the software companies that
>> distribute
>> it, so they have the interest of promoting it), and because Oracle
>> offers tech support.
>> The big companies usually want to pass the responsability to others,
>> even if they need to pay some more.
>>
>> Octavian
>>
>
> Well said. Availability of support, tons of free documentation, very
> flexible pricing options, plus extremely good education and
> certification programs, is what puts Oracle ahead. There is a huge
> mass
> of getting-started type documentation in favor of Oracle, and they
> make
> it freely available on the web. They have excellent formal
> certification
> programs. I can speak from actual experience -- I've taken several
> Oracle University classes.
>
> In my company, the selection of programming languages is determined by
> what is specified in our Enterprise Architecture. That specification
> does not include perl or perl-ish frameworks. It does include .NET and
> Sun Java. For frameworks at Tier B, we use Rational Application
> Developer and various Rational tools. Yes, they cost a lot of money,
> but
> there are a lot of people trained in their use and there are a heck
> of a
> lot of free tutorial resources available. That means an applications
> programmer faced with a deadline can get support fast. And while we
> are
> relatively small customers to IBM (which markets the Rational
> Suite), we
> still get fairly good pricing because we already contract for so much
> IBM support and we have used IBM mainframes since they were first
> produced many years ago. Choices are driven by price and support. We
> have a lot of Microsoft and Sun-certified people. We buy heavily into
> Sun and IBM equipment. We don't have any perl people.  Large
> enterprises
> want new projects to follow the Enterprise Life Cycle. I'm not sure
> how
> perl fits in the ELC, because so many different reviews from different
> IT areas are required in the ELC and I'm not sure how perl would pass
> scrutiny in these areas.
>
> Without the training, without the documentation, without the tools
> needed to educate positive masses of programmers, Catalyst will not go
> very far. It is very hard to use right now, unless you have training.
>
> A wise fellow out in California once compared two word processing
> products, Microsoft Word and WordPerfect, many years ago. He wrote, in
> part: "..it is hard to beat the top quality documentation that is
> produced by Microsoft." That is why Microsoft Office is the most
> widely
> adopted officeware platform now. Microsoft provided great
> documentation
> from the start, made Word and other tools very easy to use, and people
> bought. I think Microsoft's dominance in the market is testimony to
> the
> effectiveness of their superb documentation. Pricing is certainly
> involved too, but Office was never a closely guarded secret made
> available only to an elite few. It gained dominance because it was
> made
> available to everyone. Microsoft went one step further when it
> wanted to
> push adotpion of Internet Explorer: it gave the product away for free
> (at a time Netscape was charging a lot of money) and it provided a lot
> of documentation there, too.
>
> Bob Cochran
>
>
>>
>> _______________________________________________
>> List: Catalyst at lists.scsys.co.uk
>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>> Searchable archive:
>> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>> Dev site: http://dev.catalyst.perl.org/
>>
>>
>
> _______________________________________________
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/