perl-embperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ed Grimm <>
Subject Re: Some observations
Date Thu, 24 Jul 2008 19:27:31 GMT
On Thu, 24 Jul 2008, Kathryn Andersen wrote:
> On Wed, Jul 23, 2008 at 05:34:39PM -0500, Neil Gunton wrote:
>> 1. What is up with Embperl? I have written to Gerald Richter both via
>> this list and directly to his email address, and had no answer. I
>> also  wrote to Angus Lees about the Debian Lenny Embperl package
>> being broken  but got no reply. The email archives here are full of
>> spam. It really  gives an "abandoned house" impression which is sure
>> to turn off any  prospective new users. If I was a potential user,
>> and I came onto the  Embperl site to check out the community, I would
>> assume that this is a  dying or dead project. Is Embperl still being
>> actively developed, or has  Gerald effectively put this to sleep? Has
>> the likes of Ruby on Rails and  PHP put Embperl firmly into the
>> history books, or is this actually still  an active project?
> I have certainly gotten the impression that Gerald Richter is
> not as interested/involved in Embperl as he used to be.

My impression is that Embperl works for Gerald, so he doesn't need to
mess with it as much.  The outstanding issues he is aware of are all
either Windows issues or documentation problems - and documentation
isn't his forte, his interest, his passion.  As such, his highest
Embperl priority right now is making it threadsafe - and even that isn't
a big interest, as he doesn't use Windows.

> There was a flutter of discussion when someone proposed integrating
> Embperl with Catalyst, but nothing seems to have come of that.

Good thing, too - only a few people use Embperl with Catalyst; it would
be a major upheaval for most of the people using both products to
integrate the two.

I think a much better project would be for an indepentant team to
analyze the two packages to figure out how to make them integrate
better, while not crippling either in isolation.  After the resulting
patches are accepted by both communities, they could then work at
marketting Catalyst to Embperl users and Embperl to Catalyst users, to
increase the overlapping segment.

Eventually, one could get to the point where full integration would make
sense.  But before that happens, you'd need to sell me on Catalyst,
because right now I just don't see why I'd be interested in it.

>> If Gerald isn't all that "into" developing it any
>> more, is there any potential for someone else to take it on in a more
>> active way?
> The potential is there, with FOSS the potential is always there (even if
> someone is forced to do a fork) but what is lacking is the will.
> In other words, nothing will happen unless somebody steps forward and
> *does* something.  But alas, we all wish that someone *else* would do
> something, and thus nothing happens.

That having been said, it generally works better for take-overs to be
friendly.  When one forks a project, some of the users stick with the
original tree, and some will take it as a sign to review the rest of the
market again.  That normally doesn't happen if the reigns are simply
handed over, especially if it's to a well-known lieutenant.

Right now, it seems to me that Embperl development has one
lead person, and a handful of casual patch providers.  We have
historically had a couple of other people provide more significant
additions, but there do not really appear to be any 'lieutenant' types
in this project.

If anyone did want to position themselves such that the community might
recognize a friendly takeover, the two areas that seem to me to need the
most help are making Embperl thread-safe, and improving the
documentation.  Additionally, most projects could use major code
refactoring.  I don't know the Embperl code well enoguh to know how much
it could use, but it's normally a fairly safe bet.

Finally, it's usually possible to convince people you know what you're
doing if you take point on most of the support questions, and you almost
always give correct answers.  However, this route generally requires
more volume than this list typically has.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message