Let me start off by identifying myself as an employee of Broadleaf Commerce, so I may be somewhat biased. The reason for developing Broadleaf really has everything to do with the platform itself. If you look at the open source e-commerce solutions out there, you are correct in that there are a number of them. However, when you start to filter them by various parameters, including Java, Spring, Hibernate - the list becomes very small. It was always our intent to come up with a compelling e-commerce platform targeted at today's enterprise users. With that theme in mind, we knew we had to go with Java, Spring and Hibernate. This is the core technology stack that is preferred by much of the development community, especially in the enterprise segment. Also, to satisfy the complex domain and integration requirements of these users, we designed the system from the ground up with extensibility in mind. We think of extensibility as a natural extension of the Object Oriented programming techniques you already practice daily. This translates into leveraging the power of Hibernate extension and polymorphism for the domain, as well as the ability to override, tweak or completely replace every service, DAO and entity in the codebase. Our configuration is also extensible, and goes beyond standard Spring application context override to provide more configuration merge capabilities that allow us to pull away some of the additional Broadleaf configuration complexity so you can focus on the configuration that matters for your app. So while the end results may be similar between our software and others, we believe the decision on what path to take to achieve that end goal is an important one and Broadleaf Commerce offers a powerful and flexible way to get there.
I feel I should also briefly mention, since you mention Flex above, that we are currently in development of our 1.5 release, which includes a re-worked administrative application based on GWT that will replace our current Flex-based admin. This choice has allowed us to propagate the same theme of extensibility that we already embrace in the core platform to our administrative platform. The new admin will offer the same flexibility for override and replacement through Object Oriented programming paradigms that developers already enjoy in the core platform. In addition, the admin application automatically recognizes your entity extensions and includes your additional fields in the admin interface without any coding effort on your behalf. The admin interface also honors entity polymorphism and will adjust the editing interface according to each type (think of a media product that has two extensions in the form of book and movie - even though they are both media entities, they each have unique fields and the admin interface honors this distinction). We're also working on changesets and some other interesting features for 1.5. We're targeting milestone releases beginning around April, so stay tuned for more.
