By kulfi on
I've heard rumblings of this for a while, and it didn't really influence my evaluation of Ubercart as my preferred module.
Ryan (from UB) has set things straight with http://drupal.org/node/312142#comment-1025627. Ubercart is not an e-commerce fork.
Comments
Yes, it doesn't seem to be a
Yes, it doesn't seem to be a fork, but this is an academic discussion. It is GPL after all.
Anyway, if someone wanted to be a historian, he should start with an exact definition of "fork" (it doesn't mean just code reuse), should find an early dev version of ubercart and some specific version of e-commerce, and should show how ubercart used to be e-commerce with some modifications applied. That might earn the respect of other historians and history buffs.
...but this is an academic
so true-- but the not so veiled attack of calling one of the ubercart developers a liar without any actual evidence to back it up whatsoever is hardly a matter for historians only. In the grand scheme of things gpl is gpl no question, but when it comes to unsubstantiated attacks (which the other post appears to be) i can understand why clearing up the confusion is important.
===
"Give a man a fish and you feed him for a day.
Teach a man to fish and you feed him for a lifetime." -- Lao Tzu
"God helps those who help themselves." -- Benjamin Franklin
"Search is your best friend." -- Worldfallz
Seem?
It's not an academic discussion, GPL or otherwise. Claiming a project to be a fork of another is a practice in coding that is well understood and has a clear meaning. There are practical ramifications when projects fork, you have the potential for common exploits, bugs, etc that have to be dealt with as well as, in some cases, a desire to remain compatible. Forking of a project requires a common code ancestry and that just does not exist with regards to Ubercart and Ecommerce. The publicly accessible revision history does not show any commonality in the origins of the core code for either project, there is no common root that can be pointed to as I worked to illustrate in this post:
http://drupal.org/node/312142#comment-1027386
So, none of the concerns that should be rightly raised when a project forks are applicable to Ubercart and Ecommerce. Neither is intended to be compatible with the other. Their lack of a common code base means that their potential exploits, bugs and such aren't going to be common concerns. Forking is not inherently bad, but it usually merits justification. But, since Ubercart can be shown to not be a fork of Ecommerce these two projects should stand on their own merits like Firefox vs. Chrome vs. Konqueror, etc.
To learn more about forks I recommend this Wikipedia article:
http://en.wikipedia.org/wiki/Fork_(software_development)
For those interested in prominent open source forks this article is very good: http://royal.pingdom.com/2008/09/11/10-interesting-open-source-software-...
not true.
I notice you're posting a lot of messages like this on the forum. There's no smoke without fire, I suppose.
For the record, Ubercart replicated the main functionality of Drupal eCommerce as well as the main design methodology of Drupal eCommerce and setup a parallel project. That constitutes a FORK in anyone's parlance, particularly in an open source Drupal parlance.
Ironically, you fail to see the implications of setting up a forked project like Ubercart in the Drupal community. i.e. it splits the community.
A classic example illustration of that is your own words, i.e. "Ubercart is my preferred module".
In other words, because of the fork, we have TWO seperate and parallel projects on Drupal that are essentially trying to achieve the same thing. We also have TWO seperate development/user communities that are essentially trying to achieve the same thing. The resulting replication, duplication of effort and energy is astonishing. It's ridiculous and it's exacerbated by you and others incessantly posting on the support forum.
Has it occured to you that it might be smarter to have ONE Drupal eCommerce API....in the same way as there is a Forms API, for example, where users/developers can utilise common shipping, cart, checkout, payment gateway functions etc. and contribute bolt-ons and adaptations to build different Drupal eCommerce applications?
When that penny drops, maybe you'll realise why the Ubercart approach is an unpopular one in Drupal circles and hopefully, with the launch of Drupal eCommerce version 4.x the mature and intelligent Drupal developers involved in ubercart will merge with the Drupal eCommerce team so we can all benefit from a more coherent and efficient approach to eCommerce with Drupal.
That constitutes a FORK in
And wrong again:
Parallel != Fork
In order for something to bifurcate it must exist as a single entity first. Ubercart is no more a fork of ecommerce than linux is of windows.
===
"Give a man a fish and you feed him for a day.
Teach a man to fish and you feed him for a lifetime." -- Lao Tzu
"God helps those who help themselves." -- Benjamin Franklin
"Search is your best friend." -- Worldfallz
Really, its time for you to
Really, its time for you to stand down. The preponderance of fact has shifted the correlation of forces decidedly against you, if this is not readily apparent. Ubercart is ascendant, and this incessant effort to discredit, slander, and belittle the UC developers and those who help UC has been revealed for what it is.
In fact, I would wager that your posts have done more to divide the Drupal community than anything I have seen here in a few years.
Having said that, I will most certainly try the new version of the Ecommerce module and see how well it works, because that is the beauty of open source and the free market system.
Allowing people to come to their own conclusions is a far more powerful method of persuasion than trying to undermine the hard work of UC developers and supporters -- and what is, by one of many independent accounts, an outstanding product -- with nonsensical prevarication. Mature and intelligent, indeed.
----------------------------------------------------------------------
http://music.bwv810.com
http://classicvinyl.biz
http://davidhertzberg.com
I am a writer, researcher and solo drupal freelancer.
Now that it has been
Now that it has been established that there is no technically valid allegation for forking, it has come to the good old discussion of duplication of functionality (Hey! They are doing ecommerce too! How is that?).
This kind of duplication has been often a source for frustration for site developers, especially the new ones who want to pick modules. But also it earns the gratitude of many site developers who were not satisfied with the existing solutions.
You should think in real-world terms. It is not generally true that there is a waste of effort in the developers community. Do you really think that the developers of Ubercard would do the same amount of work for the existing e-commerce module if they didn't like its direction and the priorities of its developers in the first place? Or should they do their own work to cover their needs and then keep it to themselves? No, this is exactly how open source is supposed to work.
Cooperation in an existing project is strongly encouraged, but if you try to force it, the more enterprising people would just become uninterested, and *that* would be a waste of resources.
=-=
While I agree that on some level duplication can be a pain in the rear, especially for newcomers. I don't know that it should be applied in such broad strokes. Especially when it comes to such large modules.
Competition isn't a bad thing in any market place. Competition inspires innovation in many cases. IMHO both communities and the drupal community at large could benefit from the competiton of two modules striving for excellence.
..
In theory that sounds plausible. In the Drupal context, it simply doesn't work - hence the reason the Drupal community introduced rules to curb the Ubercart approach with modules. i.e. If a similar module, with similar functionality already exists, the Drupal modus operandi is to submit patches, ideas and improvements for that existing module rather than creating a fork.
The reason your theory falls apart, in a Drupal context. is because allowing the ubercart approach to continue would mean we would have 100s of modules all with the same/similar functionality and 90% similar code.
That's not competition, very misunderstood. That's a complete mess.
As an illustrative example: Ubercart replicated the main design methodology of an older version of Drupal eCommerce when it was built. Those design flaws exist in Drupal eCommerce 3 (and older versions) but they also exist in Ubercart. The Drupal ecommerce team identified those weaknesses over a year ago and embarked on a complete, bottom-up re-write of the Drupal eCommerce suite of modules.
I spoke to Gordon recently and the new Drupal eCommerce (version 4) is nearing completion and what's very frustrating for the community is that there would be much more developers available to push through the new version, if the project wasn't forked and split in the way it was by Ubercart.
What's also frustrating about Ubercart is the way they are presenting an illusion of competition. It would be great if ubercart was a completely new approach and design methodology to ecommerce, but, it isn't. I've used both and I was, quite frankly, astonished to see how similar Ubercart actually is. It truly is astonishing and what's particularly galling is the way they are using bully tactics on the Drupal forum and flooding threads with unnecessary insults and curious claims.
So, for me, it's not just the forked approach by ubercart and the impact that has had on the Drupal eCommerce project, It's also the spirit and tone of their team of bullies/trolls.
The bottom line is: forking modules in the way Ubercart did is not the "Drupal way" and bullying tactics is not in the open source spirit of things.
http://pastebin.com/f3f951a57
=-=
I suppose that I should have been clearer that I was making a general statement about the "no dupe idea" and not a specific statement about ecomm or ubercart as I haven't the experience with either to know of the similarities and certainly don't know enough to determine whether one is a fork of another. Though I see where I used the word "such" which is what muddied the waters :)
..
I'm afraid I don't agree with you.
Ubercart replicated functionality of an existing module. It also replicated the design methodology of an existing module and on the authors own admission, copied code from an existing module to build a fork of the project.
Regardless of the amount of code the ubercart team copied, the very fact that they have replicated functionality and design methodology constitutes a FORK in Drupal parlance.
That depends on a few things. Foremost are:
(a) It depends on the motivations behind the fork. If, let's say, there's a commercial interest in the development and launch of the fork, I imagine it would suit the team not to follow the "Drupal way" and support the existing module.
(b) It also depends on the quality of what the ubercart team were putting forward.
(c) It also depends on how the ubercart team presented their ideas to the Drupal eCommerce team. Judging by previous blow ups between members of the Drupal community and the ubercart team and judging by the incessant and immature trolling, coupled with unnecessary insult slinging, I wouldn't be in the least bit surprised if they embarked on similar bullying tactics with the ec team.
1. Notice that I didn't say
1. Notice that I didn't say that it was established that ubercart is or isn't a fork. I said that it was established that no valid argument has been made that it is, which means that no real discussion of this matter can be done. Let me explain:
In the other discussion mentioned in the first post here, you argued that ubercart is a fork of an old e-commerce version, but you forgot to show anything specific which anyone interested could check and verify. In this discussion here, you shifted to more general considerations, leaving out what a fork is or isn't and how that can be shown.
So, no argument has been made about uc being a fork of anything.
2. About (a), I completely agree that whether the uc developers would do much development work depends mostly on their motivation and much less on the well-being of the community. This is a truth of life. The remaining question is what would that motivation be. Commercial interest, consulting work interest, building a fat resume? Why should anyone want to second-guess that, and what is wrong with any of these motivations as long as it is OK with GPL?
The expression "the drupal way" also caught my eye. Whatever it is, it sounds good. I have used it in the past to signify "assembling systems from modules", but I am not sure how it applies here. It all seems drupalish enough to me.
About (b) and (c), quality and presentation, somehow I didn't completely understand how these affect whether the uc developers would do much development work or not. Have you followed the issues queues and watched how maintainers of big projects almost always react to suggestions for any major changes? (Often for good practical reasons -- to keep the thing in working condition while maintaining their own job priorities.)
In the other discussion
I've made it very clear that Ubercart replicated existing module functionality, replicated existing module design methodology and the ubercart team themselves admit they have copied ecommerce code.
There's nothing wrong with replicating functionality or design methodology - I bet there are thousands of modified versions of Drupal eCommerce out there in live production sites - the problem arises when you decide to launch your version as a new contributed module. Because it forks the project which is *NOT* the "Drupal way" of doing things.
I've also made it very clear that in the process of replicating Drupal eCommerce methodology, Ubercart has design flaws that exist in older versions of Drupal eCommerce. Specifically version 3.x and earlier.
The implications of that approach means that we now have a forked Drupal Commerce development and user community. Which is ridiculous and leads to a huge amount of wasted time and energy. Particularly when you consider that there is so much common ground between Ubercart and Drupal eCommerce. Such as shipping, payment gateways, location, address and so on.
Probably the most vivid illustration of how bad it is to fork a project is the current technical situation with Ubercart and Drupal eCommerce at the moment..i.e. The Drupal eCommerce team have identified the key weaknesses in the design methodology and decided, with version 4.x, to completely rewrite the entire Drupal eCommerce suite...which is great. However, because Ubercart practically replicated Drupal eCommerce design methodology, the Ubercart project has the same design methodology weaknesses that exists in earlier versions of Drupal eCommerce (specifically Drupal eCommerce version 3.x and earlier versions).
The point is, if the drupal eCommerce community wasn't forked and split, by Ubercart, we wouldn't have had such large gaps and delays in the improvements in Drupal eCommerce and ironically, it's only a matter of time before the Ubercart team realise that they need to address the design methodology weaknesses in their own Ubercart project...the same design methodology they replicated when they forked the Drupal eCommerce project.
It's quite simply a ridiculous situation and it's truly astonishing how much functionality and methodology is replicated in ubercart. It's almost as astonishing as how short-sighted and unpleasant the Ubercart fanboys/trolls are on this forum.
My only hope is that when Drupal eCommerce version 4 is complete, the more intelligent Ubercart users will realise that they are far smarter, long term, to actually look towards developing a Drupal eCommerce framework or API, where common code, like shipping modules and payment gateway modules can be shared across all eCommerce applications for Drupal.
Since this is the very core
Since this is the very core of your assertions, please help us by providing the evidence to backup the following (source: http://drupal.org/node/312142#comment-1025269):
Name calling, and suggestions that others possess a double digit IQ because they don't wish to cooperate with you, is not nice, and is certainly not the "drupal way."
----------------------------------------------------------------------
http://music.bwv810.com
http://classicvinyl.biz
http://davidhertzberg.com
I am a writer, researcher and solo drupal freelancer.
evidence
Download an old version of Drupal eCommerce (version 3.x or earlier) and download an early version of ubercart.
(a) Ubercart replicated functionality
(b) Ubercart replicated design methodology
(c) Ubercart have replicated code (the Ubercart team have admitted they have copied Drupal eCommerce code.)
In otherwords, it's crystal clear that there is roughly a 90-99% overlap of functionality, features and design methodology between the two projects
The only noticable visual differences are the layout of the admin, the checkout and shipping pages. Everything under the hood is almost a complete replication of functionality, features and methodology.
Like I said earlier, there's nothing wrong with all of the above. There are probably thousands of Drupal eCommerce installations that fit the above description.
The *PROBLEM* arises when a module that replicates *existing* functionality and *existing* design methodology is released as a contributed module on drupal.org because it FORKS the ecommerce development community and FORKS the user base.
Please reply to this
Please reply to this post:
http://drupal.org/node/312142#comment-1027345
----------------------------------------------------------------------
http://music.bwv810.com
http://classicvinyl.biz
http://davidhertzberg.com
I am a writer, researcher and solo drupal freelancer.
It may be a good idea to
It may be a good idea to rethink your arguments (or maybe your whole theory?). There has been a long time since I saw a discussion going on for so long without having convinced even a single person. I suggest that you look into arguments which the readers can verify for themselves, rather than quotes and general assertions.
Also remember that this is a more or less technically minded community, so it is possible that an argument which would cause quite a sensation elsewhere sometimes is not as effective here.
Finally, it is part of the open source culture to fully respect a developer's work and to take it or leave it.
I'm amazed.
I find it quite astounding that many of Phillip Mc's posts are directly name-calling, accusing users of spamming, bullying and trolling. Directly accusing the programmers of lying, calling people that use Ubercart ridiculous short-sighted unpleasant fanboys. He directly questions the financial motives of another user who is discussing their own preference. He claims there is a "Drupal Parlance" that's at odds with all other uses of the language ... and, um, the meaning used by everyone here at Drupal too. ... All this flavoured with a nice big bunch of paranoia. I certainly can't see the spam, attacks and insults he says the Ubercart camp is continually launching!
All this .. and everyone is being patient and polite with him, just trying to get him to stop the rant and just use words, logic or proof correctly.
Why is everyone so nice?
OK, at one point there was what could be called an insult. After having it explained he was wrong for the umpteenth time by different folk, the language heated up to the point where he was told he was being dumb. Harsh words... This is what Phillip describes as "a code pi$$ing contest by throwing insults about"? Obviously a sensitive soul. Or a loon.
Disclosure: I've used early Ecommerce and with a lot of tweaking found it adequate. I've followed, but not used Ubercart, and even took apart an early round of code. It was so different from ecommerce that I avoided it since then as I'd only just managed to understand the way ecommerce worked, and didn't want to start again with a different system.
As an evangelist, Phillip Mc has today made me want to give Ubercart another chance. Someone this unstable promoting a religion is a bad sign. I'll try the system people are happy using rather than one that needs a high priest damning all others to guilt-trip and scare us into his one true way.
.dan.
if you are asking a question you think should be documented, please provide a link to the handbook where you think the answer should be found.
| http://www.coders.co.nz/ |
.dan. is the New Zealand Drupal Developer working on Government Web Standards
dman: now you know why we
dman: now you know why we are being patient and polite.
----------------------------------------------------------------------
http://music.bwv810.com
http://classicvinyl.biz
http://davidhertzberg.com
I am a writer, researcher and solo drupal freelancer.
Heh, speaking for myself, I
Heh, speaking for myself, I think I have been treating this as a tech support issue, trying to help Philip make a good argument if one exists. ;-)
I do realize that I sound patronizing when I make very elementary logical statements, but hey.
interesting...
by all means, give ubercart a go.
I have and this is what I discovered:
(a) Ubercart replicated functionality
(b) Ubercart replicated design methodology
(c) Ubercart have replicated code (the Ubercart team have admitted they have copied Drupal eCommerce code.)
In otherwords, it's crystal clear that there is roughly a 90-99% overlap of functionality, features and design methodology between the two projects
Or to quote an Ubercart Developer:
The most frustrating part of using ubercart after using Drupal eCommerce, is that you very quickly realise that the only noticable visual differences are the layout of the admin, the checkout and shipping pages.
Everything under the hood is almost a complete replication of functionality, features and methodology.
On the subject of functionality, if you're using Ubercart for a live site Ubercart have added a feature that sends sales data from your site to the Ubercart team and Ubercart company. I only discovered it by accident and it's an OPT OUT feature...not an OPT IN feature.
But you cannot show us the
But you cannot show us the code to support your assertions.
Keep digging.
And best of luck.
----------------------------------------------------------------------
http://music.bwv810.com
http://classicvinyl.biz
http://davidhertzberg.com
I am a writer, researcher and solo drupal freelancer.
as a by the way..
It's not the only time the Ubercart guys have been involved in forking a project.
Here's a pastebin copy of a discussion between the drupal developers and Ryan (rszrama) from the ubercart team re: the forking of pm_lite.
full discussion.
The reaction of an Ubercart developer to that discussion is very apt....don't you think?
Like I said earlier, by all means give ubercart ago. If you're in any wayfamiliar with Drupal eCommerce, you'll realise very quickly the similarities. I estimate there is a 90-95% overlap.
Hmmm, no php tags. although
Hmmm, no php tags. although it looks like code. We are getting warm.
Keep digging.
And good luck (I mean it this time).
----------------------------------------------------------------------
http://music.bwv810.com
http://classicvinyl.biz
http://davidhertzberg.com
I am a writer, researcher and solo drupal freelancer.
You've just provided the
You've just provided the DISPROOF of your own argument, lol. Bravo!
It's clear for anyone reading this exchange, anyone who has a command of the English language that is, that a Parallel is NOT THE SAME as a Fork-- THEY ARE TWO SEPARATE CONCEPTS.
Ubercart is a parallel project, not a forked project.
If you want to discuss the relative merits of parallel modules in the drupal universe that's an entirely different, and valid, discussion. And btw, goes far beyond UC and EC.
===
"Give a man a fish and you feed him for a day.
Teach a man to fish and you feed him for a lifetime." -- Lao Tzu
"God helps those who help themselves." -- Benjamin Franklin
"Search is your best friend." -- Worldfallz
Details and specifics, oh how I love them.
Philip says:
I have seen you comment to this effect several times without any detail about the weaknesses. Please describe the weaknesses. I would love to see a description of several, but I don't want to ask to much of you. One would suffice, if that is all you can come up with.
Other posters have asked you for examples / details and received non-specific answers, so I am going to offer up an example.
Let's pretend the following:
Ubercart requires a user to log in before checking out and you consider this to be a weakness in the design methodology because this causes users to abandon their cart. The E-commerce devel team has fixed this in their new version by allowing anonymous checkout with an option (chosen by the user or the admin) at the end of checkout to create an account.
The response I am looking for from you would be:
Ubercart requires a user to log in before checking out which is a weakness in the design methodology because this causes users to abandon their cart. The E-commerce devel team has fixed this in their new version by allowing anonymous checkout with an option (chosen by the user or the admin) at the end of checkout to create an account.
Just for the record, (according to my memory) Ubercart has always allowed anonymous checkout while this features was added into the e-commerce module after development of Ubercart started.
Peace
-Andy
Restaurant Equipment