Posted by alanburke on November 27, 2008 at 4:59pm
All in one general purpose e-commerce solutions:
E-commerce frameworks
These modules provide no commerce themselves, but integrate with payment systems to provide an API to make it easier to build commerce sites:
lm_paypal
Simple Paypal Framework
Smaller/ Lighter weight modules / External shop integration
Zen cart integration (no releases?)
EZ Shop
"Pay per node" type solutions
Pay-per-node
Pay2Publish
Ubercart Node Checkout
PayPal Node
Solutions Specifically for Donations
Many of the "e-commerce modules" above could be used for donations, but there are also donation specific modules.
Papilia integration with external service.
Civicontribute - an extension of the civicrm package
Comments
Uhm.... I think not :) These
Uhm.... I think not :) These two module-collections are very different both from a technical and end-user prespective. This is like saying that it's a shame you own both a large family car for vacations and a small electric car for city driving because they are both cars...
Sure there are a lot of "duplicated" functionality but they often do them differently from a technical perspective.
In my eyes it's only positive that these systems co-exist. If one of them was a forked version of the other with some minor differences I would totally agree with you but that's not the case here. If it were true that they were mere variations of each other one of them would have disappeared a long time ago.
Best regards,
Thomas Kulvik
Ny Media AS
www.nymedia.no
+47 920 28 082
Different, but still duplicate
While I agree that they're technically quite different, I'd still argue that the two sides could be accomplished in one module if efforts were consolidated. Hence I'd agree with the "duplicated modules" badge.
But this is a big can of worms ;)
~~~
{ TopNotchThemes | Fusion Drupal Themes }
This is from the mission
This is from the mission statement of this working group:
E-Commerce and Ubercart aren't "extremely similar" and I think that saying that they're elephants in the room is wrong and unfair to both the projects and to their maintainers. It's a sensitive subject, certainly, but there has indeed been talk of "consolidating efforts" and creating "shared APIs."
I got an email notification when gordon posted "huh?" to this thread but I don't know where the comment went.
I think that saying that
?
Absolutlely no offense intended - I've used both projects on different sites, and they are both excellent.
[Thanks Gordon, Brmassa, et al & Ryan, Lyle et al].
"Elephant in the corner" is a great phrase - I thought it was particularly apt in this case, as I perceived these modules to be 'similar' in purpose, but they hadn't got a mention in this group yet.
Perhaps I should have paid closer attention to the group mission, but at an overall level, they DO have the same purpose - providing a shopping cart system.
Granted, they don't share much from a code/architecture point of view.
To be honest, I'm not overly concerned that there are two projects, but much like I don't use Joomla, I'd rather focus on learning how to use one 'shopping cart system in Drupal' , rather than 2.
I don't know what the future holds - but hopefully both projects remain healthy.
In an ideal world, I do believe that they could slowly merge over time, perhaps by working on a common Cart API for Drupal 7, with their own features on top of that.
I could be talking out of my hat on this one..
The question I think is, can
The question I think is, can we answer the question:
Which shopping cart should I use?
...and be able to provide different answers depending on the requirements of our customers. If the answer is a clear YES! then these two modules deserve to co-exist. Otherwise there is a whole lot of duplicated effort going on, and these two modules need to, as someone has suggested, consider working on a way to merge efforts.
there will always be scope for collaboration
You could also say that Drupal and Joomla should merge. :)
But seriously, one of the goals to reduce duplication is to reduce duplicate code redundancy, and there are opportunities there I believe.
In general one would like to see:
-- both projects reducing their own codebase to just core required modules
-- both projects constantly reducing their own codebase by utilizing more and more goodness in Drupal core
-- 3rd party contrib modules that implement payment gateways and shipping under both systems (eg Worldpay module or UPS module compatible with both)
-- a non-interactive function library that both projects contribute to and share. (There are a lot of generic list functions in these modules)
Em Space use both of these projects so we see benefit in some collaboration. They are big projects though, and it can be heavy going. I had to drop out of EC for time reasons.
But the reality is (in my opinion) that pressure from Ubercart has improved E-Commerce. Ubercart took a lot of code initially from E-Commerce (and the similarities remain) so I think the benefit flows the other way as well - and so it should!
Ubercart took a lot of code
It was only about 20 lines of code.
I'll happily stand corrected
I'll happily stand corrected on that. I looked at the tables Ubercart created when it was installed for one of our projects, and I felt like I had gone back in time on e-Commerce, but this may have been the nature of the type of data that needs storing I assume. I'll look again one of these days.
More generally, one thing I always wanted to see with e-Commerce was a re-write of the whole thing (with or without an upgrade path). In effect this something the Ubercart guys got to do (I was jealous), and why I always thought Ubercart was a very good thing.
So I'm going to say that the same general concept still applies, they did get at least one big benefit from e-Commerce: what mistakes to avoid. ;)
..
But the reality is (in my opinion) that pressure from Ubercart has improved E-Commerce.
I'm afraid I must disagree.
No matter how it's dressed up or presented...Ubercart forked ecommerce. While you are correct, Ubercart did take a lot of code and concepts from Drupal eCommerce, the real problem is that it also replicated the functionality to a ridiculous degree. That meant the Drupal eCommerce community was forked as well....resulting in less coders, testers, patches, bug spotters etc. for the original eCommerce project.
Any developers who have been around for the last few years will have witnessed the rapid slowdown in development on the eCommerce suite of modules when Ubercart came along. So I think it's a tad disengenuous to suggest that ubercart improved Drupal ecommerce.
What's worse...Ubercart spawned the release of a huge amount of duplicated modules on drupal.org.....in the form of payment gateways....payment gateways are small add-on modules that connect your shopping cart to a credit card processing company, like worldpay or paypal etc.
I'm currently porting a payment module from Drupal eCommerce to Ubercart and it's so frustrating, knowing that:
(a) all the extra work porting the module to ubercart is completely unnecessary and wouldn't have happened if Ubercart had of adopted the best practices approach to module development..i.e. payment gateway modules SHOULD be able to work with both ecommerce packages.
(b) All this extra and unnecesary work is actually contributing to the landfill of duplicated modules on drupal.org.
I can see the value of Ubercart...whenever I get an email from a newbie asking for ecommerce help, I always point them to ubercart. It is an ecommerce solution for drupal that is easy to setup. However, I think it's important that we (as a community) learn from the Ubercart approach and be more vigilant in future about situations like this.
Ironically, if the Ubercart team had of followed a more sensible and astute approach, they would have reduced the amount of code they had to pull together by simply using the same payment gateways that already existed.
I have no idea why the Uber
I have no idea why the Uber crew decided to reinvent the wheel instead of just hacking e-C (though I would be interested in hearing their reasoning). But I just want to say that I don't subscribe to the "no duplicated module functionality" mentality for a microsecond. By the grace of God, I have choice in the products I buy and the people I vote for, so why not the modules I use for my sites?
Maybe Ubercart's presence hasn't made e-C better, but e-C's presence has made Ubercart better; the Uber crew looked at what e-C was doing and said, "What could we do better here?" Of course, "better" is a highly subjective term, but that's just it - if you think Uber is better for your needs, you can use it and be happy. If you think e-C is better, you can use that and be happy. More choice means better choices, which means happier people. Let a hundred modules bloom.
The Boise Drupal Guy!
erm...
I have no idea why the Uber crew decided to reinvent the wheel instead of just hacking e-C (though I would be interested in hearing their reasoning)
I've no idea, to be honest but there is a company, shareholders and investors behind Ubercart. Drupal eCommerce just relies on the Drupal community and donations. Which may suggest a bigger picture.
But I just want to say that I don't subscribe to the "no duplicated module functionality" mentality for a microsecond.
It's the exact opposite approach that has got Drupal to where it is today, Garrett. When you see space for improvement, you submit a patch/feature request to the module maintainer(s). If your patch doesn't go through moderation by the community, by all means copy the code, hack it but you certainly DO NOT release it as a new module.
In the same, breath, I don't think the Ubercart investors would be too happy if you took a look at Ubercart..decided you could so something better.. copied Ubercart code...duplicated funcionality and released a new ecommerce package on Drupal.org.
Incidentally, Drupal is the only CMS that I have come across that has 2 payment gateway modules for the same payment gateway. It's ridiculous Garrett.
My point would be that the community should be more vigilant about Ubercat style forks. Regardless of how much code they copied from ecommerce, the functionality was practically identical.
I've no idea, to be honest
Are you tilting at windmills? There are no companies, shareholders or investors behind Ubercart that have ever been made apparent to me, and even if there were, so what? What "bigger picture" are you implying?
There are donators and advertisers for their site, but they hardly count as any sort of corporate structure.
Cheerleading e-C is fine, but please don't turn it into some sort of bizarre anti-capitalist paranoia.
The Boise Drupal Guy!
no windmills garrett
calm down. There's no windmills or bizarre anti-capitalist paranoia here. Speaking of which, you're also wrong about the company behind Ubercart.
The main guy behind Ubercart has a history of forking drupal modules and I can't come up with any reasonable explanation to why they decided to copy ecommerce module code, hack it and then release it as a new module on drupal.org, other than it had some business logic behind it. That's not ant-capitalist paranoia Garrett...it's the only logical explanation I can come up with.
Leaving that aside....now and again you come up against a project where a hack is required. The correct procedure is to submit a patch and if it's of benefit to the rest of the community, it becomes part of the core module. If the hack doesn't get comitted as a patch, the developer will just make a note of which module requires special attention the next time the site/module is upgraded.
That approach has proven to be very succesfull...Drupal would not be where it is today, if developers simply copied, hacked and released new modules.
My point would be that the community should be more vigilant about Ubercart style forks. Regardless of the amount of code they copied from ecommerce, the functionality was replicated to about 95%. That's simply ridiculous, Garrett.
The ramifications of that approach has resulted in a plethora of duplicated modules, with duplicated code and duplicated functionality on drupal.org. Like I said earlier, Drupal is the only CMS I have come across that requires 2 seperate modules, to do the exact same thing, with the exact same payment gateways.
As for the cheerleading comment....I'm not against Ubercart. I think it's great that Drupal users have a choice too....but it's the approach that is the problem. Ubercart could just as easily have been a few alternative modules to the ecommerce core rather than a fork of functionality, a fork of code and a fork of the Drupal commerce community.
Think about it Garrett.
Instead of 2 groups of developers spending twice the amount of time coding.....2 groups of testers spending twice the amount of time testing......2 groups of patchers spending twice the amount of time patching 2 different payment gateway modules that do the exact same thing...you have 1 payment gateway.
Let me know if there's any part of that sentence you have difficulty understanding.
Ditto for other add-on modules, like shipping/courier gateway modules...and so on.
Okay, first off, a fork of a
Okay, first off, a fork of a project copies code from that project. A project which offers different code for similar functionality is not a "fork." Referring to UC as a fork of e-C is going to cause a lot of undue confusion. If you're aware of this and you're saying that early versions of UC actually recycled e-C's code in any significant way… that's another bizarre claim you're going to have to back up.
Second, I'm well aware of the process of submitting patches for projects, from both a hacker-with-a-pet-issue perspective and from a weary project maintainer's perspective. It usually works, but there are also downsides. Maintainers may have different priorities than the majority other project users over what issues are important to fix, and maintainers may be hesitant to accept patches which make substantial changes in fear that the patch will break something else or otherwise cause problems which the maintainer will be expected to support and/or fix.
The functionality of any given car on the road replicates that of any other given car by about 95%, if not more. Yet isn't it great that one can choose from cars offered by Ford, Toyota, Hyundai, BMW, Jaguar…? If nobody was allowed to build mass-market cars after Ford did because Ford was the first to build mass-market cars - if instead you were told that you could only sell replacement parts for Ford cars and hope that Ford would use your parts in their cars - the industry would look pretty bleak.
Just let the code flow, brotha. Don't stifle it with legislation.
The Boise Drupal Guy!
Ryan admits that at least a
Ryan admits that at least a few modules (I believe payment related) were forked directly from e-Commerce.
Oy vey. I happened to
Oy vey. I happened to browse across this thread on accident. I wasn't going to respond to these old topics until I saw this post from mikey_p, because it deals with non-existing personal admission from me. I'll point out that we've explained and defended our actions in much larger threads on d.o, including pointing to explicit examples in the source and code repositories to illustrate.
My simple statement: I'm not sure where you're pulling this from, but I never admitted any such thing. Ubercart was not a code fork at all, although some wish to extend the term to introduce duplicated efforts, not just code. Ubercart did not start with e-Commerce code and repackage it for its own purposes, and it has certainly never included any e-Commerce modules (payment or otherwise, for better or for worse). None of this really matters now, but it's at least what I've claimed, what I'll claim now, and what I've verified substantially (explicitly linking to the CVS and Bazaar trees) in other discussions of the topic.
My statements in response to Dublin regarding the corporate atmosphere around the project: I was an employee at a company where the project began. I was doing the job given to me in return for the salary I received. I was not a manager, an officer of the company, a shareholder, etc. There are no "investors behind Ubercart." If I did something malicious to derive monetary benefit from an existing project as Dublin has suggested above, I did an extremely poor job. I no longer work for the company, am making no money from the time I still spend developing, maintaining, and promoting the project, and fortunately I have not let down any fictitious investors that are now upset with me for wasting their money. : )
Furthermore, the IRC conversation you linked to regarding my "history" of forking modules is the result of someone's ire against me experimenting with a private node module instead of contributing to Privatemsg. Following that conversation (which was actually quite personally discouraging at the time), the person upset with me actually reviewed and provided constructive feedback of the module in question, and we have since moved on and cooperated elsewhere. That discussion has also been hashed out elsewhere, but I fail to see how that benefits your case regarding Ubercart. It's more an uninformed ad hominem point than anything.
That's all I have to say. I realize this thread is 7 months old now and have no desire to resurrect it. However, since this thread will exist in perpetuity and contains misinformation about me personally, I felt the need to at least respond to the misinformation.
Thank you for your time,
-Ryan
...
Your analogy of a car is a curious one.
Sorry if it's insulting that I have to ask you this...but...you do realise that BMW is in direct competition with Jaguar, Garrett?
In a similar way to how...erm...Joomla and Drupal could be considered rival solutions.....or magento and oscommerce.....and so on. I hate to be the one to break it to you, but, the very ethos of open source community development is that people work together not against each other. I guess you must have missed that memo.
In other words, if one member of the BMW design team decided to go off on a tangent and build a completely new car, from scratch, based on an existing model, just because he came up with a great new idea for windscreen wipers....I don't think the rest of the BMW community....the manufacturers, the product team, the management team, the testers, the troubleshooters and everyone else involved in the process would be too chuffed. Don't you think?
In fact, I imagine some of the BMW community might argue that it may have been smarter to submit the new idea to the rest of the car design team for consideration and work together as a community. That way they can use the same manufacturing line, the same chassis, the same doors, the same tank, the same seats and the same windows if the new windscreen wipers warrants a new BMW model.
Like I said earlier, I'm porting a payment gateway module from ecommerce to ubercart, which is not unlike like a BMW manufacturing and design team having to rebuild the chassis of a BMW Gina from scratch, just because the windscreen wipers are different on the UC_BMW Gina.
You don't have to be the sharpest tool in the shed to conclude that's a ridiculous and avoidable situation, Garrett. And it's just the tip of the iceberg. In eCommerce land, the same situation applies to creating DHL or UPS add-ons, shipping, tax and currency conversion modules.
The bottom line is Ubercart was a fork of Drupal ecommerce....regardless of how it's dressed up and regardless of how much code was copied. You may disagree with that and pull more curious analogies out of the air in an attempt to gloss over that fact, that's your choice, but, I vividly remember the collective raising of eyebrows by the community when it was initially forked. Besides, it misses my core point, which is this:
It's crystal clear that the Ubercart approach may have brought some short sighted benefits, but, it has also clearly led to long-term and negative ramifications. Specifically it (unnecessarily) forked the ecommerce community and (unnecessarily) introduced extra development work and is continuing to (unnecessarily) clog drupal.org up with (unnecessary) duplicated modules with (unnecessary) duplicated functionality.
My argument is that, we as a community, should be more vigilant about Ubercart style forking/duplication of functionality/code and appoint a Drupal module ombudsman should an argument arise between someone wanting specific patches submitted and a module maintainer who is reluctant to apply those patches.
That's one way of avoiding Ubercart style forks/duplication of code while at the same time, not throwing the baby out with the bathwater. As an example, an Ubercart suite of modules would have been welcomed if it had of plugged in and interacted with non-core ecommerce modules..like payment gateways...tax modues...courier gateways and so on.
What you're suggesting, Garrett, is discarding the very ethos of open source community development which is to work together, not against each other. Which, by the way, is one of the reasons that Ubercart is in the Drupal Modules Hall of Shame.
I'm all for letting the code flow, brotha....but not in the Ubercart way or in the way you're suggesting.
Dub
My argument is that, we as
And you're suggesting (while misusing "ombudsman" just as you're misusing "fork") that a single individual be responsible for dictating what is and is not acceptable to work on and release for the community. If that's not antithetical to the open source movement, I don't know what is.
You're sounding like Big Brother in the 1984 commercial. I guess I'm the lady in track shorts with a hammer. If you don't let people code how they want to, finding their own solutions, solving their own problems, and, yes, reinventing a few wheels, then what's the point? Where's the fun of it? You and your tl;dr posts are a serious downer, really.
The Boise Drupal Guy!
..
Sorry Garrett, but that's even dumber than your earlier car anology.
Getting an ombudsman to take over a project or dictating what is and what is not acceptable is not something I would support. Certainly in the way you put it Garrett. I think that's a dumb idea.
However, I would advocate for the use of an ombudsman in the correct sense of the term....e.g....where a dispute arises between a module maintainer and someone who submits a patch.
Consider if the UC team had of approached the Drupal Community (acting as an informal ombudsman) prior to launching their project on Drupal.org (As opposed to the flaming that occurred after they launched it) the outcome may have been very different....
As an example, if you remove all the handbags over the word "fork" on this thread, you will notice a common theme...i.e.
.
Once that penny drops for you Garrett....I think you'll understand more why your car analogy was about as relevant and enlightening as a soggy biscuit.
Stop using the word fork, really...
Let's stick with the standard definition of fork so we can discuss the matter at hand okay? Or we're not going t o get anywhere with all the animosity surrounding this issue.
----<===============An example would be Beryl/Compiz (which merged later), the pidgin fork (an example of users dictating demands to developers), and there are others (including apparent contrib modules of ubercart as mikey_p mentions). wine and winex/cedega another.
Would you call date/calendar a fork of event? No, I think some might be offended by that actually. They're two independent projects competing against the same solution. The same as the main ecommerce and ubercart projects.
However whether it is a fork or not (it's not) is regardless to whether or not ubercart and ecommerce projects should cooperate.
The car analogy that Garrett made and you extended was fairly poor. We're not like BMW or a collection of car companies. We're not even like GM, multiple competing companies who cooperate. We don't all work for Dries or the Drupal Association, but we come together via free will and interest to cooperate (or compete). However resources are limited, and splitting developers between competing projects does drain the potential for both. Was this risk worth it? Should ubercart or ecommerce merge their codebase or stop supporting one or the other?
I don't know about those questions, but at this point I think ubercart has grown too large for a possible merge (as mentioned above). Perhaps what we'll learn at Drupalcon with import will change that. Here's an obvious duplicate project to end all duplicates.
"module ombudsman". Wow, this would be a pretty biased position. I'm not sure how well it would be taken. Good luck though. Right now we're free to see other methods of implementing a solution that may be required to do the job, and then share that implementation with the rest of the drupal community on an official web site. If one person's vision of UI differs from another, then we may be locked in simply because someone came first and it would be silly to try to accommodate another feature request. This position actually may cause more forks, albeit in private repositories and implementations of drupal web sites. I don't like this at all personally. I'd rather be free to introduce a competing viewpoint (if necessary).
...
This [Ombudsman] position actually may cause more forks, albeit in private repositories and implementations of drupal web sites. I don't like this at all personally. I'd rather be free to introduce a competing viewpoint (if necessary).
Erm..I'm sorry if it is insulting to point this out but an ombudsman is a term used to describe someone, or a group of people (like a community) who step in when competing viewpoints are irressolvable and there is no definitive right and wrong.
To pick a hypothetical scenario out of the air....let's say you have been using the Drupal eCommerce modules for a while..and have spotted some room for improvement or you have worked on a project that required significant hacks to acheieve what you want.
Let's say that you then submit those patches for review to the Drupal eCommerce team and they are rejected, for whatever reasons...perhaps because of code was messy...or the code would cause problems later on...or the drupal ecommerce team already had similar plans in the works and a smarter way of approaching it...
You might get a little frustrated...you now have a hacked Drupal eCommerce installation that will be tricky to upgrade.
So you try again, to submit the patches for review. After being turned down, for whetever reasons, you have no where else to turn to, apart from renaming all the functions, table names, some variables, shuffling some code about and releasing the project as a new suite of modules on Drupal.org.
What I'm suggesting is that we introduce a new system or protocol whereby you DO have somewhere to turn to, Where your argument IS heard and the community steps in as the ombudsman to try and reach an agreement that is beneficial to the entire community.
That community ombudsman may even save you a huge amount of time...i.e. instead of replicating the ENTIRE functionality of Drupal eCommerce, you could just replicate a few core-modules that interact with existing modules, like payment gateways, shipping modules, tax modules etc.
Thank you for your
Thank you for your clarification. I still agree with mikey_p below.
Actually there is pretty
Actually there is pretty much a single company behind Ubercart. Ryan has stated
At least 3 of the primary developers work for this company.
Referenced here...
Garrett, pointing out others cheerleading for e-Commerce is fine, but please don't turn it into some sort of uninformed cheerleading for Ubercart.
thanks Mikey
thanks for pointing that out, Mikey_p, but, to be honest..what I'm more interested in is how do we, as a community, avoid Ubercart style scenarios in future. I'd like to throw out the idea of a module ombudsman (in the form of the Drupal association, maybe) who would step in, should an argument arise between someone wanting specific patches submitted and a module maintainer who is reluctant to apply those patches.
Anyone who took a summary glance at both codebases would have spotted how similar they were at the outset and of course Ubercart copied eCommerce code...that's a given...but it wouldn't take long for an ombudsman to reach the conclusion that it might be a good idea to create a side-line project, where non-core modules are shared, rather than duplicated. Where payment gateways...tax modules....shipping modules...don't have to be replicated. And more importanty, the ecommerce community isn't forked in the way it was.
What's slightly worrying is that Ryan is talking about incorporating new features and concepts (which are, coincidentally, already available in the new Drupal eCommerce) into Ubercart. That's obviously in the interests of the Ubercart company, but, I would argue that it would be of more interest to the Drupal community if Ubercart took the lead from Drupal eCommerce in a different way and renamed a few functions and variables to match Drupal eCommerce...so all the non-core modules can be shared.
The new Drupal eCommerce is almost ready for release, so the timing is perfect for this sort of consideration. I don't see it devaluing the Ubercart company necessarily...I see it as increasing it's value, because the work load is reduced dramatically and the UC team can concentrate on their own core-code adaptations rather than replicating existing modules.
While I like pointing things
While I like pointing things out when I can, I'd really have to disagree with you on the idea of an ombudsman in terms taking over individuals projects.
The only thing I would support is a review of all new modules committed to CVS (maybe put the project nodes in unpublished moderation until approved), and the filtering of *OBVIOUS* forks from being published on d.o.
By obvious fork, I am implying not duplicated functionality. Rather different approaches from different starting points is encouraged. What I am referring to is an individual who disagrees with a maintainer and takes the code and modifies between 2-5%* of it and declares it a new project. That is what should be discouraged on drupal.org, the duplication of code, not the duplication of functionality.
* I don't believe Ubercart would have qualified in for this, in fact I would estimate if probably only borrowed about 2-5% of code from e-Commerce for it's first releases.
I'd really have to disagree
I'd really have to disagree with you on the idea of an ombudsman in terms taking over individuals projects.
That's not what I'm suggesting.
An ombudsman is someone who steps in when there is an apparantly irresolvable dispute to try and reach a positive agreement. They wouldn't take over projects like you and Garrett are suggesting. I think that's a dumb idea.
Re: the use of the word fork...regardless of how you dress it up, Mikey, Ubercart forked Drupal eCommerce and forked the Drupal eCommerce community. That's indisputable, regardless of the amount of code they directly copied or the amount of functions they simply renamed.
That's why Ubercart is listed in this Drupal Modules Hall of Shame.
by the way..
I don't know where you got the idea that Ubercart only copied 2-5% of the code from ecommerce, mikey_p. that certainly doesn't ring true with my observation of the codebases when ubercart launched. And that's even factoring in all the functions, table names and variables that were renamed and therefore don't show up on a DIFF.
If you were comparing line for line, you would probably come up with 2-5% but I remember the first time I looked at Ubercart and was surprised how familiar it all looked...the code concepts, the database structure as well as the code itself. In the same breath, your review of new modules might stand a chance of working, if you aren't doing the maths or the comparisons.
The problem is...regardless of the amount of code ubercart copied directly from Drupal ecommerce...or from other eCommerce packages...the ramifications are still the same.
I'm also not suggesting that Ubercart shouldn't have been launched. I think it should...but, in a smarter way. e.g. wouldn't it be great if ubercart did it's thing and ecommerce did it's thing and they both shared payment gateways, tax modules, shipping modules?...most of which submit and collect the exact same data from the exact same websites and deliver it back to drupal in the exact same way..
i.e. they don't make a blind bit of difference to the way ubercart/ecommerce works.
Actually it's more that the
Actually it's more that the perception of competition has influenced econmerce. I know gordon, and not wanting to msirepresent him, but he's quite passionate about making ecommerce the better module.
When it comes down to it ajlowe did try to work on ecommerce, but typically the project was too 'big', probably only gordon had a broad understanding of the bits, and no-one had time to provide decent time to help integrate the ideas. So my perception was that ajlowe didn't really have any options. (My subjective experience as a then-maintained.)
..
I don't get the same impression from Gordon. I think he's a solid, genuine and honest developer who just wants Drupal eCommerce to be as good as it can be. In the same breath, I don't think Gordon sees it as a "competition" with Ubercart. Ubercart copied the concepts and some code at the outset, but, now they are very different. Particularly the new version of Drupal eCommerce.
Ironically, your point about Gordon not having the time or resources to explain or flesh out the bits and pieces was actually made worse because of the way Ubercart forked the Drupal ecommerce community. I've been reluctantly pinging him on IRC asking questions, that you would normally find in documentation, but, because of the fork in the community..there is scant resources around Gordon where he can delegate.
How he and his team of developers have brought Drupal eC to where it is today, is beyond me.
That said..I've posted my two cents on how we can (a) recover the Ubercart ramifications and (b) possibly avoid future Ubercart scenarios. It would be interesting if we could move on from the "they did: they didn't" pantomime and hear other ideas on how to avoid it in future.
I don't think Gordon sees it
Well I admit I'm reading into gordon a little, he actually prefers not to talk about Ubercart at all. You should have a beer with us sometime and see for yourself. :P
But to be clear, I know where you're coming from.
Choice is good
All I can say is that when I joined the Drupal community and needed an e-commerce solution, E-commerce seemed to be it. Actual experience was that it was (at that time) problematic to set up, didn't do what my clients wanted it to, and actually REMOVED core functionality between versions. I forget which version upgrade it was, flat rate shipping, something core to all my e-commerce stores, was completely removed, and the response from the E-commerce developers at the time was something paramount to "live with it, we're not planning on putting it back in again ever". So I was left with a choice. Leave all my sites on an old version of E-commerce (that was still somewhat buggy, and didn't do the job well enough yet), or find an alternative.
Many months later, Ubercart came along, and let me tell you, it was a breath of fresh air. Even the early betas were easy to set up, easy to use, did all the things website owners expect of their e-commerce solutions. The developers were listening to suggestions and providing workable solutions quickly and easily.
Both E-commerce and Ubercart have a valuable place in the world of Drupal. Choice is good, and friendly competition healthy. Friendly competition, with cooperation on things like shared APIs would be even better.
I agree that E-commerce and Ubercart should try and work towards standard APIs so that e-commerce-related modules such as payment gateway modules can be plugged interchangeably into either. That way we have the best of both worlds -- choice of which to use, and minimization of duplicated code.
Community is key
I hope Gordon and his fellow developers realize that one of the biggest (maybe the biggest) reason why Übercart became so popular right away wasn't because it was such a excellent technical solution (i've been using it since the first Alphas and I have to say that it wasn't "state of the art" back then). The reason is the strong focus Ryan, Lyle and others have had on building a large community around Übercart. They have excellent documentation (User guides, dev guides, APIs), a large and very active forum, a large contribution library, live sites and a lot more (have you visited http://drupalecommerce.org/ lately?). They also spend a lot of time replying to posts and getting to know their contrib developers, which in my opinion, is key.
If e-C really wants to compete with übercart they need to focus less on making every line of code better than übercarts and rather spend some time making sure their solution is a real and attractive choice for other developers (and shop owners). Right now my impression is that e-C is kind of a "in-house" thing between the core e-C developers. But of course, that's just my personal opinion.
Have a nice holiday everyone :)
Best regards,
Thomas
choice is great
hi Asimov,
I agree that choice is good...but, that's not what is in question here and that's not why Ubercart is listed in the Drupal Modules hall of Shame.
I disagree with the apologists who claim that only a small fraction of code was actually copied by Ubercart and therefore it isn't a "fork" in their eyes. Ubercart may have renamed functions, db table names and variables, so a pedant can point to a line-by-line diff and say "this is different", but, 95% of the functionality and 95% of the concepts was copied by Ubercart. No matter how you dress it up, that constitutes a fork, Asimov.
You make a good point about Ubercart being easier to use and setup for newbies but I would argue that isn't a justification for a fork.
There were a number of options open to the Ubercart Developers:
(a) Fork the ecommerce project and launch a new seperate suite of modules on Drupal org
(b) Contribute patches into the ecommerce project.
(c) Build a core set of Ubercart modules that can plugin with existing ecommerce modules (e.g. payment gateway modules, tax modules, shipping modules and so on) so the ecommerce community isn't completely forked, moduels can be shared, documentation can be shared and forums can be shared.
I think the arguments for (c) is very strong. What's the point of having 2 seperate development communities, 2 seperate support forums, 2 seperate issue trackers, 2 seperate bug fixing communities and 2 seperate modules for the paypal payment gateway?
It makes no difference, whatsoever, to setting up ubercart or ecommerce, Amisov...and it makes no difference to the visitors to a Drupal shop. No difference whatsoever, Asimov.
But it makes a huge difference to the Drupal community, Amisov. A huge difference. Drupal.org is getting clogged up with a huge amount of unnecessary modules and developers have to waste a huge amount of time duplicating code and functionality.
What's curious is that the many responses on here tend to be fixated on the pedantics of what constitutes a "fork". As if everything is okay if their interpretation of a term doesn't apply!!!
It would be interesting andmore constructive if they could leave aside the pedantry and focus on the reasons Ubercart is in the Drupal Modules Hall Of Shame...i.e. the Ubercart approach could and should have been much more astute and what can we do to avoid the Ubercart approach in future.
Some things are too different
Some aspects of the way that Ubercart functions are fundamentally at odds with the way E-commerce does them. I doubt these fundamental core changes could have been done as add-on modules or patches. Could you "patch" or "contribute" to Joomla, and make a Drupal out of it? I don't think so.
E-commerce and Ubercart are different enough in their implementations to justify different names -- if you've implemented both modules on a number of shopping sites then you'll know what I mean. I would also argue that E-commerce as it stood at the time that Ubercart was developed was too unwieldy to be simplified without actually reducing quite a lot of what makes E-commerce what it is. Doing so could even have required removing a fair bit of functionality of extreme value to some, in order to simplify things for others. Hence (in my personal subjective experience):
E-commerce = full featured and powerful
Ubercart = simple to use, with a helpful and communicative developer community
"Simple" and "Full featured" are often at odds with each other, and that alone may require separate projects to meet both requirements. Let's stop being E-commerce or Ubercart fanbois and recognize that each has a valuable role to play. The projects just need to learn how to play nicely together rather than being "us vs. them" war camps.
..
I have and I know you're wrong. If I was to guess at what was different in the workings of the core ubercart/ecommerce modules when it was duped, forked, mimicked, whatever you want to call it....I would have said between 2-5%.
The concepts, framework, even the database structure...was almost identical. True there were a few minor cosmetic changes and differences in how the admin page worked or how shipping costs were displayed, for example, but, beyond that it was spectacularly similar.
However, that isn't the problem. The problem is they forked, duped, mimicked, whatever you want to call it...the ENTIRE ecommerce suite and community.
Instead, they could have decided to do the checkout, cart and admin differently, but, not rehash all the other modules...they could have stayed the same. Don't forget, asimov, we're talking about two extremely similar Drupal modules...we're not talking about oscommerce and magento or drupal and joomla, which have very different ways of doing stuff.
Like I said earlier. There is no valid technical argument to have 2 groups of developers creating 2 different payment gateway modules that submits and collects data from the exact same websites in the exact same way.
common thread
When you remove all the handbags over the definition of the word "fork", I think there's a common thread emerging here and that is:
Do people agree?
Dub
I would certainly agree that
I would certainly agree that teamwork and consensus, and a community spirit of cooperation are what open source projects are all about. Quibbling over what constitutes a fork, and if such a thing is good, is really secondary. More than one choice of how to do thing things is an advantage, and it doesn't have to be at the expense of cooperation either.
If Drupal e-commerce can be accomplished by using open e-commerce APIs to allow compatibility and therefore reduce everybody's workload, then perfect. I know Gordon has said that it is an objective of E-commerce to make use of existing modules for functionality where possible rather than try to duplicate them. The same could apply if all Drupal e-commerce initiatives can agree to some common approaches, without some sort of "ombudsman" to frustrate people by deciding whose ideas are better than anyone else's. Drupal works because everybody gets to scratch their own itches, and giving them to tools and structure to do so is the way to continue, without prescribing only one right way to do things, or one supreme decider to say whose ideas are important, which would mean all others don't get a chance to grow into something equally useful, serving someone else's needs.
If the E-commerce team and the Ubercart team can constructively work together on some APIs and code that is of mutual benefit, but still have the freedom and flexibility to differ sometimes in their priorities and approaches, and where necessary, to do some things independently to serve a different need, then everyone wins. I suspect that the teams themselves may be the ones needing to come around to this though, otherwise we'll forever have the "E-commerce vs. Ubercart" wars, which the core teams inadvertently allow to continue by not identifying areas of mutual interest where they can work together.
Also, as has been mentioned elsewhere, every open source project needs to listen to the community it supports, otherwise people will do their own thing regardless of whatever anyone tries to put in place, if only because they have no alternative but to do so in a restricted and overly-controlled development structure. And let's not forget what makes open source better than closed -- everyone gets a shot at contributing to an existing codebase, or alternatively trying their own, better implementation, and everyone then takes the best of that and makes something even better. E-commerce can benefit from an Ubercart, and Ubercart can benefit from an E-commerce, because each can still take the best from the other and incorporate it anytime they want. The more constructive cooperation, with freedom to differ when needed, the better.
well said..
Well said asimov. I agree with most of what you said, although, I disagree with your assertion that an ombudsman should decide whose ideas are better than anyone else's. That's a role usually fulfilled by a judge/jury and I wouldn't support such an initiative.
I would, however, support an Ombudsman in the traditional sense..i.e. An Ombudsman (which can be an individual or a group..like a community) in the traditional sense, doesn't have power to legislate and is more about reaching an agreement between two conflicting parties. In the context of Drupal, that means seeking a compromise that both conflicting parties can agree to and a resolution that benefits the wider Drupal community.
I also disagree with the "e-Commerce V Ubercart wars" notion. It's only the Ubercart team who appear to be keen to fan the flames of a so-called "war". In almost every thread on drupal.org or on groups.drupal.org you rarely ever see anyone from the ecommerce team or user group blowing their own trumpet. Only this week, I received an email from Scor asking me to contribute to a discussion about ecommerce because the poll that was taking place on groups.drupal.org was so imbalanced.
My point is, it's NOT a war and it SHOULD NOT be a war. But the very fact that it is so difficult to have a discussion about drupal ecommerce, without the ubercart team or user group jumping all over the thread, is an example of how Ubercart has FORKED the Drupal eCommerce community and many would argue that is yet another reason why Ubercart deserves to be in the Drupal Modules: Hall of Shame.
In other words...I don't see it as a childish module war, Asimov. I see applications where Ubercart is a good choice and I see other applications where Drupal ecommerce is the better choice.
What what I also see is how the ubercart approach has led to a fork in the community and a huge amount of wasted time, energy & effort replicating functionality, replicating modules and so on. If there's any "war" going on, that's what I would fight against, because it is ridiculous, divides the drupal community (as you have so poignantly illustrated in the "module wars" analogy) and leads to a landfill of duplicate modules.....
A raft of duplicate modules, Asimov, For. No. Valid. Technical. Reason....other than a few functions and filenames are prefixed with the letters UC_.
Like I said earlier..I'm porting a payment gateway module to ubercart at the moment, in response to requests from other members of the Drupal community. So it's very vivid, to me, how unnecessary and ridiculous all that extra work is.
Dub
I agree...
You are still hung up on being called out about your use of language though. The reason why you agree on a standard definition is so that less miscommunication occurs, and in my experience that's the main reason why "wars" start in the first place. The only reason I can think of that you insisted on using the word fork is that you are trying to intensify the argument in bias of one side or another. We are calling you out on your use of propaganda-like language.
If you want this to be a civil matter you need to be more objective. That said...
I don't really have an opinion one way or the other of whether ecommerce or ubercart came first or which is better. From the outside your argument seemed petty. If you're really interested in not increasing animosity you would settle down somewhat in like the post you have done above. This statement "Ubercart has forked the Drupal eCommerce community" is better. You refer to a fork in terms of community (pool of developers and users) rather than codebase. This is a good step, but still a bit aggressive your aim is not "war".
...
I'm not getting hung up on any language mradcliffe.
If you guys are hell bent on pursing a Flat Earth line of argument and have a problem with the use of the word fork, so be it, but, that's your problem, not mine, mradcliffe. And I fail to see how blithering on about language, animosity and pettiness is going to change the unavoidable, undisputable and okums-razor-esque fact that ubercart is in the Drupal Modules Hall of Shame for a reason.
Oh and by the way, if you could actually contribute something to the discussion it would be useful as well.
That said...I'm guessing you didn't read my original points before the Flat Earth apologists poured in...here it is again for your benefit:
...Ubercart spawned the release of a huge amount of duplicated modules on drupal.org.....in the form of payment gateways....payment gateways are small add-on modules that connect your shopping cart to a credit card processing company, like worldpay or paypal etc.
I'm currently porting a payment module from Drupal eCommerce to Ubercart and it's so frustrating, knowing that:
(a) all the extra work porting the module to ubercart is completely unnecessary and wouldn't have happened if Ubercart had of adopted the best practices approach to module development..i.e. payment gateway modules SHOULD be able to work with both ecommerce packages.
(b) All this extra and unnecesary work is actually contributing to the landfill of duplicated modules on drupal.org.
I can see the value of Ubercart...whenever I get an email from a newbie asking for ecommerce help, I always point them to ubercart. It is an ecommerce solution for drupal that is easy to setup. However, I think it's important that we (as a community) learn from the Ubercart approach and be more vigilant in future about situations like this.
Ironically, if the Ubercart team had of followed a more sensible and astute approach, they would have reduced the amount of code they had to pull together themselves by simply using the same payment gateways that already existed.
Just in case there's any confusion about language, mradcliffe...here's a quick note: When I said "I can see the value of Ubercart"....I really meant: "I can see the value of Ubercart".
I hope that clears up any civil or language problems you are alluding to.
dub
Wow
You really do have a bee up your bonnet against constructive criticism.
maybe you're right....
Maybe that was a tad strong, but, it gets very frustrating when you keep hearing the flat earth brigade going on and on and on.
Despite the amount of code the Ubercart team have acknowledged they copied...despite the amount of functionality that was copied, despite how the ecommerce community was forked as a result, despite the amount of arguably replicated and unnecessary modules Ubercart has contributed to drupal.org and despite the fact that it's sitting here in the Drupal Modules hall of shame forum.
If that wasn't bad enough, as soon as any discussion kicks off, the flat earth brigade are in like a shot, with tenuous arguments about pedantics and language, as if Ubercart was really all just a fantastic coincidence and by some strange twist of fate, ended up in the Drupal modules hall of shame by accident. I ask you. Even creationists would cringe at such a display of denial.
Meanwhile, Drupal.org's landfill of duplicated modules gets bigger by the day, mradcliffe.
If you think I have a bee in my bonnet, can you imagine how big a bee is in the bonnet of the drupal ecommerce team? A group of developers who built up the core concepts, codebase and community from nothing, only to see it forked spectacularly and in such a cavalier fashion and with such hubris.
updated the wiki
I updated the wiki to include a few other similar modules. I don't think it's productive to have massive discussion threads on the topic of duplication being "good" or "bad". We've had them before. The consensus is that duplicate is bad because it makes it hard to choose the right module, but preventing duplication is worse because it prevents innovation.
This group is really about documenting the duplication, identifying any real differences in the module, making it easier for users to find the right module for their situation, and (when possible) encouraging combination of efforts.
--
Growing Venture Solutions | Drupal Dashboard | Learn more about Drupal - buy a Drupal Book
knaddison blog | Morris Animal Foundation