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. Ed --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
