eCommerce News & Resources by oscommerceuniversity.com

In his post on CRE Loaded Clutter , Chris at oshelpers.com describes FDMS as inessential clutter in the course of presenting what is essentially an explanation of why CRE Loaded 6.3 is so overpriced for the feature set.

I beg to differ on this specific point.

Perhaps, as the system designer responsible for FDMS and the Chief Operating Officer of the firm which sold the system I have a few biases of my own here.  Download related issues in CRE Loaded accounted for a respectable portion of system complaints before FDMS development.  The existing download system lacked some pretty obvious marketing tools and capabilities.  The reporting systems sucked.  Those issues were just about enough by themselves.  Add to them the negative impact of the “Zero Weight Guessing Game” in the checkout and shipping routines which affect 100% of all cart users and the development of  FDMS  and its eventual inclusion into the core distributions was completely justified.  The market demand was also more like 20% than the 0.2% Chris estimates off the cuff.    The system also made it a lot easier for shops with physical products to offer product related downloads such as instruction manuals, user guides and brochures  — pushing the number of potential benefactors even higher.  The list of reasons why FDMS is both essential and “A Good Thing” goes on and on.   Inessential is not justified here – though it is certainly fair to say the system is  over-priced when considered against other needs clammering for attention in the CRE Loaded code base.

CRE Loaded actually did a splendid job of selecting contributions for inclusion in the cart up to the 6.2 release.  In fact, it came very close to continuing that streak in the 6.2 release itself.  Ugly story there that I might tell someday, but not today. Fact remains that the top features in any CRE Loaded distribution can still be found in the top downloads of all time for osCommerce contributions and most of them remain in the top 50 if not the top 10 out of over 5000 candidates.

What Chris missed,  ignored  or chose not to  communicate there is that beginning with 6.2, CRE Loaded was no longer to be a “loading project” but a development project. Not a secret at all.  I certainly mentioned it in the CRE Loaded forums as I drove development in a new direction and I am pretty sure Chris was there to see it.    It was the right course then and a better one today.

The problem is that Chainreaction has an issue with steering a course that  calls on building a development company.  A problem with any course that relies on providing value to the community for which the community feels a need to pay.   The fact that so much clutter of any type remains is a reflection of this problem as much as anything.   That 107 of 114  feature requests made over the past 3 years remain open, many of them unanswered much less un-implemented is a clear sign of the weakness of Chainreaction Ecommerce ‘s  commitment to meet community needs.

But is it? There seems plenty of reason to doubt whether the approach is either new or open source. My original concept when proposing CRE Loaded commercialization was to charge a standard fee per copy distributed with a 30 to 90 day support window, following which support could be obtained on a contract basis. Revenues would be further augmented by internally developed documentation and education offerings made available both directly to the public on Chain Reaction’s own site, and via a distribution network of existing community vendors. The value of the software would be increased by ongoing addition of new features designed and built in house, and refactoring of the core code to bring it into alignment with the current PHP and MySQL feature sets and changes in the security environment.

What has emerged appears to be little more than SaaS without the second S. Here is why.

The “manual” posted on the latest incarnation of their website is a thinly disguised knock off of Kerry Watson’s 6.2 Users Manual. They may argue that there are few other ways to state the programs use, and that just may be. But why can’t the ‘designers’ of the software do any better? They should for example, have access to and include information on input formats and boundaries, and systemic capabilities and limitations which are not readily available to the non-programmer. Such information is not, as of the date of this writing, available in their “users guide”. Their “educational program” consists of a page buried 3-5 levels deep in their site which asks the users to inform Chain Reaction of their educational needs so that content can be developed. So much for educational and documentation support.

Their new releases are “subscription” based. But there is some room for question as to just what users would be subscribing. What does Chain Reaction deliver in return for its charges?

Read More

I’ve worked with osCommerce and its derivatives for quite some time now. So had the architects of the Magento shopping cart before they came up with the idea of building a completely new Open Source shop cart. Given that osCommerce is widely considered to be the most popular Open Source cart, and that it has at last count 4766 community contributions from its 178,210 members you might wonder why they felt the need for a new cart. It is a good question, and here are my comments on one aspect of the question.

osCommerce has a very minimal release schedule. The Open Source philosophy of “Release Early, Release Often” is just not on the agenda. The last few releases have been backports of new code with minimal impact in terms of business features available in the cart.

Magento has, thus far, offered frequent releases offering significant new functionality long requested by members of the osCommerce community. Data export tools and a much improved backend are only the beginning – the difference is just huge. osCommerce is rather undocumented – and certainly so in terms of official documentation released by the designer. It has a person (one) responsible for developing or leading development of documentation – but little if any cohesive information pertinent to the current release. osCommerce does have established (if poorly understood) API’s for module development and a large body of shipping, payment and order total modules exists.

Magento has selected a professional PHP development framework on which to base development – offloading part of the development and documentation cost while taking advantage of organizations known for excellence in training. Varien has made an effort to get documentation in place with a wiki which, if not regularly maintained, does offer documentation by development team members which can be used to build shipping and payment modules. These are certainly very reasonable areas of focus for a project in this stage of its life cycle, and the practice bodes well for the future.

The osCommerce website features an active community forum with many involved community members. Quite a few of those members are technically accomplished and offer willing assistance. But there is little to no participation from the project members – announcements are few and far between and while many fans of the project constantly urge new members to wait for the 3.0 release of osCommerce – the 3 year wait for a release strains their credibility to the breaking point. If not further.

The Magento website encourages participation and has many actively involved members from both the community AND the project. The rapid move from the 0.7 release to a full 1.0 release is a welcome change. While it has resulted in some lag between semi-official Wiki postings on the APIs intermittent postings and updates by official developers offers a new hope that finally some balance between progress and stability will be available in an Open Source eCommerce project.

By now, the picture should be clear. You could say that the  single biggest problem faced by the osCommerce community is the lack of an osCommerce project. Lacking this challenge, even the technical difficulties related to an EAV based database management scheme and the high demand for buzzword compliance placed on Magento coders is unlikely to hold this new kid on the block back for long.