I suspect the question was just so open-ended, we didn’t know where to start.
So, let’s start with the basics:
Though you didn’t ask specifically, I’ll chime in on the OS. I recommend CentOS 4. Stable, secure, and long lifecycle. It does have the minor issue of only having PHP 4 and MySQL 4, but PHP 5 will be provided by us in the near future (I think some test packages are already in the repo for FC3 or maybe CentOS 4, don’t recall now…but it’s pretty close to being ready, regardless).
Next up, the commerce package. Both Interchange and osCommerce seem pretty full-featured and supported by large developer and user communities–those two aspects are probably more important than any single feature (except for any single features that you must have for your deployment).
The biggest pros with Interchange are that it’s been around a long time, so it’s pretty stable, and that it’s written in perl (I’m bigger fan of perl than php for numerous reasons).
The biggest cons include the stupidity of the Interchange documentation. It makes elaborate, and seemingly unnecessary demands, for a special purpose perl install that is unlike any perl distributed by OS vendors. In short, if the documentation authors have their way, you’ll install a private perl, and a bunch of CPAN modules, just for Interchange. This is a maintenance nightmare. As far as I can determine, this downright insane advice is to gain a small performance benefit (even if it doubled performance, which it doesn’t, it only matters to people getting thousands of hits an hour). The installation and maintenence seems a bit overwhelming, as well. Anyway, if you ignore the stupid “you must use a non-threaded perl!” advice, installation isn’t so bad and maintenence gets a lot more sane. Interchange is also a bit more complex than it needs to be for many small-scale users, as it has lots of buzzword compliant features that you probably don’t need (SOAP, for example), but will have to deal with anyway. But if you’re doing something large, and have the developers to implement it, Interchange is probably where to start.
osCommerce is in PHP, which makes me almost as itchy as the stupid Interchange “non-threaded perl” thing, but a lot of folks like it, so it’s probably a wash. It also seems to have a lot less stupid extra stuff. Interchange, for example, has its own application server. osCommerce just runs as a PHP app inside of Apache (which, technically makes Apache the app server). I believe this is cleaner, though the separate app server model is very very popular with enterprisey people (Tomcat, Zope, etc. are all application server-based products, and even Ruby on Rails likes to have its own app server, and it pretends to be anti-enterprisey). So, osCommerce probably wins points in the “how difficult is it for a regular user to fit all the right pieces together without ripping out much hair or hiring one of the developers” category. And, of course, Virtualmin will do some of the installation and configuration of osCommerce for you. That should be an indicator of it’s simplicity…even a stupid computer, with a little clever scripting, can do most of the installation for you.
So, to make sense of my random babbling:
Install osCommerce and see how far you can get with it. Spend an hour or two poking at it. If it looks like it does everything you’ll need, and you’ve managed to get far enough to be creating stores, I think you’ve got your winner. I suspect you’ll spend more time than that wading through Interchange docs just to get part of the way to a working install, though in the end you might find Interchange more powerful (and though I prefer maintaining software in perl, I can’t push that preference onto others, especially when the choice seems to be between software that is small, simple, and seemingly featureful enough for most needs in osCommerce and large, over-engineered, and kinda bossy in Interchange).
I considered Interchange for our store here at Virtualmin.com and got so far as installing it (but not getting it actually working)…but in the same amount of time I spent on Interchange, I had OpenACS running with not only a store, but forums, a bug tracker, a FAQ manager, and a few other niceties. I’ve now had enough time with OpenACS to know it was probably a mistake, anyway, but I believe Interchange would have been a bigger mistake.
Then again, maybe I’ve just had time to learn that any currently existing large-scale web application, other than Webmin, is a nightmare to maintain and to extend. Maybe the techniques for developing web application frameworks just haven’t matured enough to be maintainable or comprehensible. Hmmm…Maybe I ought to write a whole new shopping cart and forum and bug-tracker using Webmin’s web-lib.pl, plus a few CPAN modules. Or maybe I’ll save that until after all of the Virtualmin work is done.
Also worth noting: If you find a good consultant to perform your administration for you, $100/hour is reasonable. If they’re really good, it won’t take more than three or four hours to get you rolling with a working and sane deployment of either product. But finding someone really good is damned near impossible.
If you work out your requirements very very very clearly and precisely (take time to learn the software, so you’re not requesting things be deployed that don’t exist–sometimes this means searching the forums and the web to be sure a feature that is claimed on the osCommerce or Interchange website actually works in the real existing software…for example, OpenACS claims about two or three times more applications than it actually has, because half of them don’t work and quite a few more require quite a bit of coding and bugfixing to be useable, Zope/Plone is even worse than OpenACS), you can simply get a few quotes from contractors that work in the field for the full job–forget the hourly stuff. Just ask for a binding price for the full amount of the work.
It then becomes the contractors job to determine the amount of time and how much they need to make it worth their time. They’ll probably charge a little higher than their hourly rate, seemingly, but they’ll be motivated to work faster and you have some reasonably firm time estimates to base your plans on. But, be vigilant of yourself not to add or change requirements during the project without expecting to correct the pricing. Contractors hate this more than anything, and you’ll get charged double next time you need anything from them or they’ll simply refuse to work for you (they’ll say, “I’m too busy to take on any projects right now”, or put you at the bottom of their queue, “I can get to you a week from next year”).
Knowing what you actually need is probably a better way to reduce your costs than worrying too much about what the hourly rate of the contractor happens to be–if what you’re asking for takes 100 hours, it’s going to be expensive no matter what (and worrying over $50 or $100 rates is worth doing), but if you plan to deploy a stock standard commerce package in a stock standard manner and get a few pointers from your contractor about how you create stores, change graphics, modify databases, etc. then you’ll looking at just a few hours. A difference of maybe $200 from the cheapest to the most expensive.
And, of course, in the 100 hour project, you might find that the higher priced contractor does the work two or three times as fast. Before I shutdown Swell, we would often drop into a Squid deployment that had been underway for weeks or months, and at $125/hour I’d start from a fresh install of Squid and have the deployment wrapped up in a day, sometimes three or four days if I had to write custom software or train people to use it. They’d been penny-wise and pound-foolish up to that point, putting their entirely inexperienced local staff on the project or hiring a generic “Linux nerd” from their local population, and found that it took far longer than planned and at far more expense…all to avoid paying $1000/day to an actual expert to do the job quickly and correctly. Hmmm…you have to wonder why I quit doing that at $1k/day to work on Virtualmin at less than a tenth of that rate?
In short, if you find someone who is the acknowledged master of a subject, pay them a premium with a smile on your face, knowing that the work will be done faster and better than by an amateur who charges twice as much. You’ll probably pay less in total, too. The difficult part, of course, is finding that expert.
Hope this helps. I’m not an expert, I’m afraid, as I’ve never deployed either Interchange or osCommerce. And, to be fair to Interchange, I’ve never even looked at osCommerce in any serious way, except to toy with the Script Installer in Virtualmin to be sure it worked. So, osCommerce may have more ugly problems than even Interchange…
Best advice I can give is to just dig in and try things.