(I posted this on Ovid's use.perl journal as well...)

I haven't taken a detailed look at Maypole yet (no tuits), but just off the top of my head there are a number of similarities between Maypole and OpenInteract (I'll focus on the still-in-beta OpenInteract2 because it's got a lot more going for it). Generally OI2 is much more heavyweight and designed to adapt to more environments than Maypole. But that doesn't mean it's better -- as usual flexibility comes at a price, in this case complexity. And as usual whether this complexity is worth it really depends on what you're doing.

• OI2 is very big. The HTML doc snapshot for the next beta weighs in at 1.3 MB -- and some parts need better docs :-) As a result you need to do more work to startup a new system, although the quick start guide helps out with that.
• Both rely on the Template Toolkit, although OI2 supports additional content generation methods (pluggable, and it's distributed with support for HTML::Template and Text::Template)
• Both are tied to an object-relational mapping solution -- OI2 uses SPOPS while Maypole uses Class::DBI. But I think both can use other solutions without too much problem (that is, using SPOPS objects in Maypole and Class::DBI objects in OI2). Class::DBI is generally simpler than SPOPS but SPOPS also does LDAP and some mildly interesting stuff with security.
• OI2 seems to be more internally declarative. (Keep in mind, this is based on a cursory look at Maypole -- I wouldn't be surprised if under the covers they did much the same thing.) So in Maypole you map a URL to an action (represented by a PerlHandler) using Apache. In OI2 a package (or distributable application) contains an 'action.ini' file which registers classes (and optional parameters) with the framework and tells it what names it will respond to. Another component is responsible for mapping incoming URLs to names. You also declare if an action is secured, what methods are not allowed, and more. In fact comparing the beer DB example from Simon's weblog entry to the OI2 package development tutorial is pretty useful -- note that the first part of the tutorial does things the "longer" way, the second part introduces the 'common' actions and does it more declaratively.
• You can use OI2 under multiple environments. Currently Apache 1.x, CGI and LWP are supported, with a working (but probably suboptimal) version using Apache 2.x in the next beta.
• OI2 focuses on creating distributable, standalone applications. So I can send you a zip file (foo-0.01.zip) and you can run:

  $ oi2_manage install_package --package_file=foo-0.01.zip
  $ oi2_manage install_sql --package=foo
  [download]

  and have it install that application's database structures, initial data, templates, static HTML pages and images, configuration, classes (including actions, TT plugins, normal Perl classes), localized messages (in the next beta), etc.

There are almost certainly more differences, but I have a non-Perl day job to get back to :-) That said, I think the application server problemspace is sufficently complex that having multiple solutions are extremely useful.