![Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]](../sites/all/themes/drupal4hu/images/bg-center/bg-center_4.png)
Duplication is not bad, persay, but there are a great many areas where Ubercart and E-Commerce overlap, interfacing with the exact same external systems, which require the exact same API calls, and there's no reason not to combine efforts to make those APIs/services more usable for both EC, ubercart, and other community members who just want to leverage the API's but have no need for either EC or ubercart. (Quote from beeradb, published with permission)
So, could you please guys cooperate? I feel the Ubercart guys are much more interested in their own community than actually being a useful part of the Drupal community, and I have asked Ryan in person in Barcelona to try to cooperate with EC, but this never happened.
Commenting on this Story is closed.
Even though Ubercart is a fork of e-Commerce, the 2 systems are very different. I have looked at Ubercart recently and it still has the broken design methodology that exists in v3.x and lower of eC.
e-Commerce 4 which we are working on ATM has made major changes to the design of e-Commerce to help resolves these issues. Changes such as receipting, and building of products, which put e-Commerce head and shoulders above UC.
Ryan basically forked e-Commerce and there has been no communication or feedback of possible fixes or changes. Other than appearing on eC communications, such as groups and support lists by clouding the waters with responses on how UC does things. I have heard nothing from Ryan.
After the D6 version of Drupal is released I am going to be moving the receipting out on it's own, since it is really a stand alone module and can be used by any system to collect payments. Primarily designed to allow e-Commerce and CiviCRM to exist on the system with the same payment and reporting methods.
Ubercart has *never* been a fork of e-Commerce.
The only pieces that I know of in Ubercart that were ever in the e-Commerce system are the USPS shipping quote module (because I couldn't figure out their documentation), and a small piece in uc_cart. I think that piece deals with anonymous users' carts. Ryan wrote it; ask him for details.
My employer asked me to help write Ubercart a year and a half or so ago because he didn't think e-Commerce was the right solution for his company. He then decided to release Ubercart to the Drupal community. That's why he's the listed maintainer of the project. Even if no one used it, we would still be developing it.
Now, since the two systems are so independent, I believe that an abstraction layer between Drupal and the payment gateways really just amounts to an e-commerce suite.
E-Commerce (the module) needs a lot of extra hands to fill in all the gaps in the code, it has so many features with almost as many bugs. It would be great if there were more developers involved, but from what I've seen over the last year the E-Commerce developers seem to want to do everything themseleves.
Ubercart is promising, but I loathe the unconventional UI and other strange design approaches. I'm not sure how it caters to my country either, it was very US centric around the beginning.
I'm more interested in a strong integration between Drupal and Magento.
I think projects do have to decide whether it is good for the community of users to merge two projects together or not. It would be nice to see the effort being done on both e-Commerce and Ubercart focused on one project. But I wonder if the projects come from too different of a, for lack of a better term, cultural perspective?
Although I'm a big Drupal fan, so far Drupal hasn't been the choice for a shopping cart on the few projects I have done. I think the e-Commerce module offers current users of Drupal a fantastic way to bring a shop online. The module tries to stay true to the Drupal way. However, some of eC's Drupal strengths are seen as a weakness in the eyes of some. It has been my observations that those coming from a pure shopping-cart application (such as Zen Cart and osCommerce) or directly from a brick-and-mortar shop find EC (as well as Drupal) to be too different from what they are used to and eventually conclude a Drupal solution is not for them. I haven't evaluated EC4, but I'll take Gordon's word that things will be improving quite a bit since the last time I personally looked at eC.
However, as of today, it appears to me that the look and feel of Ubercart is more osCommerce centric and indeed the developers have some roots in the osCommerce experience. In my opinion, Ubercart is a better introduction into Drupal than the current eC for those people that currently run osCommerce sites or somethigng similar. My point is that while Ubercart has been pushing their project over eC, they didn't create the need for something different than eC...the users did. I think Ubercart is just fulfilling a need that for whatever reason eC was not. Of course, while these type of users may be more happy with Ubercart, eC4 could change all that...
I have not questioned the quality, feasibility, viability or whatever of eC or Ubercart, I have called out for cooperation.
Chx, yes your point was not missed by me though I can see with my comment as written could be assumed so. I merely wanted to point out the hurdles to that cooperation may be more significant than some of the other redundant contributed modules.
Perhaps, what you have identified is a problem that is just not specific to eC and Ubercart but in so many other Drupal contributed projects...too much redundancy. For me personally, when it comes to WYSIWYG editors, image modules, lightbox type modules, event modules, and access modules, I feel I spend too much time trying to figure out the right combination of modules needed to get the job done.
Perhaps, what is needed here is a model for how differing contributed Drupal projects have come together in the past to build common libraries. I know I have observed past efforts to do so (especially in the image/media category), but I find it difficult to measure their success in cooperation unless their efforts make it into the core. Anyone have some good examples to show?
Bryan, I think you're right on the money.
Chx is calling for sharing common libraries like payment gateways. This makes total sense and both projects are screwing up by not doing just that. Why does there need to be an Ubercart WorldPay gateway that is distinct and different than the eCommerce WorldPay gateway? Furthermore, why should the Drupal WorldPay gateway depend on either Ubercart or eCommerce? Why can't it be an implementation of the "Drupal Payment API" and make itself available to other modules needing to make payments? That's what Chx was saying, and instead of Ubercart and eCommerce module maintainers flocking here to accuse each other or defend their projects, it would be nice if people listened to Chx.
Yes! Please cooperate, share, work together, make separate API modules that they both depend on. That would be good. It would be nice if they both cooperated on stuff like shipping APIs and payment gateways,etc.
But I have to comment from a little bit different perspective... First of all, it WOULD be great if the basic API integrations were stand alone modules that anyone could make use of, HOWEVER with that said, it would also be a serious pain in the tail to get anything up and running as you'd have to download a million different modules just to get a basic cart up and running. As it is, I can choose eC and UC and with the exception of a hand full of dependencies that's really all I need (and UC is working to eliminate those dependencies at the moment, and I've not used eC in ages).
With that said, that particular complaint doesn't eliminate the benefits of what chx is suggesting here, however I do think it's something to keep in mind. If our objective as a community is to lower to barrier to entry, this suggestion makes a typical shopping cart just that much harder to set up.
Finally, I'd like to point out that a lot of these systems are already modularized in UC, and as such, it probably wouldn't be horribly problematic for an interested party to separate them out on their own, though that doesn't guarantee that either system would actually use those modules.
Eclipse
I decided to do some quick checking about ubercarts payment dependencies because your description didn't match my memory. I downloaded ubercart and set about to get the authorize.net module working, thinking this is a common use case... someone wanting a payment handling system but perhaps not a shopping cart of a full blown e-commerce solution. Here's what I found:
Depenencies for installation of Authorize.net payment gateways:
Payment (UC), Credit Card (UC)
Required to Install Payment and Credit Card:
Order (UC), Store (UC), Workflow NG
To Install Order, Store, Workflow NG:
Token, UBrowser , Tapir
That's 8 different modules needed to get authorize.net transaction handling, and 4 which already aren't in the Ubercart distribution. Simply putting the functionality in a different file doesn't get us much, a real step forward would be decoupling these modules from the rest of ubercart/e-commerce. Whats a fifth download anyway?
The point I was trying to make when I was quoted by Chx is this: for both ubercart and e-commerce send the exact same information to payment handling gateways, and receive the exact same information back - so why can't we have some corporation to get usable standalone API's for this stuff that benefits e-commerce, ubercart, and the community?
beeradb,
I think your description matches what I was describing, UC has 4 dependencies (which you basically need, period: TAPIr, uBrowser, Token, and Workflow-ng). Internally it has modules (many of which are pertinent to this discussion), but they are dependent upon the rest of UC. My understanding is that in the 6.x version they will be working to eliminate those 4 primary dependencies, but that's neither here nor there. The point of what I was trying to say is that UC is essentially a single download. I can deal with 4 dependencies, what I would have more issues with is 4 dependencies for UC, plus an Authorize.net, UPS Shipping, USPS Shipping, FedEx Shipping, Paypal and MORE modules. I mean that IS what's being suggested here yes?
Now, by contrast, if all of those dependency modules were maintained together in a single install (separate from UC or eC) then I'd be all for this proposal. But if everything is separate, I think that would be a serious barrier to entry. So I guess what I'm saying is that, if this proposal is acceptable to the UC/eC guys, then there should be a commerce bonus pack module with these modules all maintained there. However, someone needs to step up and say they're willing to do this, I've not heard either maintainer group say that they are, and considering everyone is trying to get their modules ready for 6.x this seems like a really bad time for this conversation as it will slow down that process. I for one would like to stop using 5.x for commercial installs and move to 6.x asap, and that simply will never happen w/o a viable commerce solution.
Eclipse
There really isn't any reason for not making these whole systems totally pluggable, and reusable.
The how has already been figured out as well: http://www.garfieldtech.com/blog/drupal-handler-rfc
I know they say it's the thought that counts but here I'm not so sure it will count for anything. I don't think we'll ever see any real cooperation between these two.