[epo-core] What are we going to -do- with this non-profit we have, anyway?

[Mike Whitaker]

J Shirley wrote:
> Probably the least favored response: marketing
>
> I'm viewing that aspect more as an investment.  If we market, and get
> people interested in what we're doing (which means we have to do a
> good job) then it stands to reason that we'll get more people and thus
> more money.
>
> The downside is this could very well be subject to trends, which
> allows the coffers to overflow one season and the next bubble we'll be
> right back where we're at.

I'm in agreement on marketing.

>> I'm wondering if enperl shouldn't focus its money on getting stuff  
>> visible
>> rather than advancing the project's codebase
>
> Right, marketing :)

That'd be marketing, then.

I've said a number of times that IMO Perl's problem is perception,  
pure and simple, and I've had any number of folks echo that.

>> So for example there was some talk about getting a new design for  
>> some of
>> the perl.org sites - maybe we could Just Pay A Damn Designer for  
>> that.
>>
>
> Please.  I think it's imperative to understand that in order for us to
> appear as good as "those guys" it is imperative for us to look as good
> as those guys (I'm not speaking of any "those guys" in specific,
> really, so please don't take that as a rails reference).  Talking to a
> usability person would also make sense.  How do we make the site
> accessible for the various demographics we've discussed before (Green
> coders, converts, business folks, system admins, etc)

See above re perception. We need shiny modern looking Web2.0y sites  
(yes, I know Web2.0 is a pretty nebulous term, but there's a modern  
style that looks slick to most folks, and gives the impression that  
we actually have folks with a grasp of marketing/graphic design in  
the organization, rather than just being a bunch of techies with an  
axe to grind.

>> I think also maybe a -small- stipend, UKP50 or so, for useful  
>> articles
>> that contribute to the cause might be good. My experience is that  
>> people
>> don't tend to write these for the money anyway (I know several  
>> perl.com
>> article authors who never actually chased them up to get paid) but  
>> I suspect
>> it might be worthwile having a small cash chunk anyway.
>
> Imagine people in other countries, though.  If they could write an
> article a week, that would nearly cover living expenses.  That's good
> incentive.  I agree this is a good point, but we should have
> publishing guidelines (as well as licenses).  Something along the
> lines of we get unlimited edit and publication rights, and maintain a
> joint copyright.  That will allow us a lot of flexibility to retool
> the articles and evolve them.  One thing that truly pisses me off
> about the perl.com articles is that they have horribly outdated
> articles (like Catalyst) and no indication that shits done changed.

And we need a review panel so that we don't publish things in good  
faith that are WRONG, or incomprehensible.

> "Enlightened Perl presents the Perl Luminaries Awards, brought to you
> by (Six Apart|Yahoo!|Shadowcat)" has a nice ring to it. I think that
> to get corporate sponsors we'd have to have specific return points
> -and- a dedication to it.

I like that. Might be worth asking Y! if they'd be willing :)  
(Although we are phasing out Perl for new developments... but that's  
apparently because we can't hire enough Perl devs, which comes back  
to the perception issue.)

> The major thing that people want is a copy'n'paste solution.  If we
> control the medium for this, we can control the perspective of copy
> and paste.  People use phpBB3 and the plugin system there is shit, but
> they use it because the expectations are already set and they believe
> it is simple.

People use J2SE - Java plus its core modules - and J2EE - Java plus  
even more modules - at least in part because there is a big thick  
standard which says 'this is how you do X in Java'.

Perl has TMTOWTDI. Which is all very shiny, but makes big businesses  
go weeble, because they don't want more than one way, they want a  
nice big standard that allows them to say 'hire me N developers with  
the following skillset' and know what they get as a result.

We need, IMO, to be the ones who write that big standard, and the  
hell with TMTOWTDI.