I just want to add that I went through a similiar process-- evaluating Minivend (similiar to OM). I was impressed by all the complex features, all the power and flexibility. What I found was that it was relatively easily to put up a new store, as long as it was almost identical to the demo. It was very hard to extend it though. It provided poor debugging feedback, and had a number of abstractions that I just didn't need. So I ended up spending a lot of time learning how to do things "The Minivend Way" that I already knew how to do efficiently with Perl and SQL.

Finally, (this took a couple of years) my Perl and SQL skills improved, and we are migrating away from Minivend in favor of a light-weight custom toolkit that we wrote ourselves. This has been a great decision. It just supports Postgres and is lacking a lot of Minivend's features (and documentation :), but we only need one database to run our websites and we have the features the we need.

I've been very happy with this decision. At least with my own Perl and SQL, I can give a reasonable estimate of how long something will take, and I know I can tweak it any which way it needs to go. With Minivend, I'd get on a debugging detour that could take 5 hours, mostly figuring out what when wrong. And yes, once this project gets cleaned up and refined, it's expected to be released as Open Source.

Funny thing though, if you look for Perl-based E-commerce solutions available at the moment, there are a ton of them-- a lot of people are developing their own solutions for their niche instead of adoptiong a monster package. I think this makes some sense with e-commerce-- It's so complex that really makes sense to find a package that has just the complexity you need, rather than learning an overly complex package that you just use a subset of.

-mark