Posted by rickvug on December 20, 2006 at 9:17am
healthy competition
37% (14 votes)
wasted developer overlap / forking
13% (5 votes)
serving a different market
18% (7 votes)
getting it right
26% (10 votes)
vapourware
5% (2 votes)
Total votes: 38
Comments
competition within an open source project.
I've known about ubercart for a while now and haven't heard much discussion about it so I'm stirring the pot with this poll. From the Ubercart site:
What's your opinion about overlapping functionality within an open source project (Drupal specifically)? The project leader's stated opinion is that Ecommerce and Ubercart serve different markets and aren't in competition. Are we indeed richer for having more choices? Or are these developers are wasting time that could have been better spent improving what has already been built? Maybe they are making a valid point that the current system is needlessly complex for average users and a simple "all in one" solution is needed?
Discuss.
E-commerce is great, but it needs some alternatives
E-commerce is a real lifesaver, and probably one of the most important Drupal modules. But exactly for that reason, only one option is too little to choose from. One of the real downsides of there only being one e-commerce module is that there is only one way to implement an online store in Drupal.
Drupal's real strength is that you can create just about any kind of website you can imagine, and do it in a limitless number of ways, but E-commerce at the moment has to be done the E-commerce module way or no way. I think that an alternative will be brilliant for bringing fresh perspectives, and I'm sure the best code from each will be ported over to the other, so I don't believe that duplication of efforts is such a big issue.
One real biggie that I hope Ubercart will take to heart right from the start is that future versions need to maintain a realistic upgrade path, and at least maintain the same basic level of functionality as the previous version. E-commerce doesn't do this, effectively pegging a commerce-based site at whatever Drupal version it was created for. The removal of a generic shipping option in 4.7, for example, wreaked havoc on all my existing client sites, and I still have terrible hacks in place to try and compensate for it. I certainly won't be upgrading any of my clients' E-commerce-based sites to version 5.0 when it's finalised unless E-commerce is 100% upgradable, which is really sad because I love every new version of Drupal, any they would really benefit from what the latest version has to offer.
Just my opinion, but I'd rather work with an e-commerce module that has a slow development cycle that allows me to upgrade client sites sites to current versions of Drupal, rather than a faster development cycle that I can't make use of in existing sites because they are too incompatible without major redevelopment.
Please don't see this as an E-commerce bashing. It's my favourite module, and Drupal wouldn't be the same without it. I just think that more alternatives will make options available that we haven't had so far.
So from my perspective:
E-commerce - Brilliant!
More e-commerce modules - Even More Brilliant!!
is it open-source?
To be honest, I'm just disappointed that Ubercart is not hosted as a project on drupal.org. If it's open-source then the community is not benefiting. (Of course, if it's proprietary, then this whole thread is irrelevant anyway!)
As far as forking goes, asimov sums it up for me. There are all different ways to do things and better ways.
Definitely I'm a "forking is good" kind of guy. It allows gaps and niches to be filled, it increases the overall knowledge of the developers, it can lead to a healthy exchange of ideas.
E-commerce can be difficult to maintain because it's so broad, there's a lot of code in there that we don't like. There are limitations to the features. Bug fixes from non-maintainers can be slooow to patch. Really, any fallability you can name simply suggests that maybe there is a "better way". E-commerce is too megalithic to change dramatically, so it is natural for new projects to rise up.
.s
d.o
Yeah, a lot of my frustration is because ubercart is not hosted on d.o. I really don't know too much about it so should probably avoid blanket statements like "all forks are bad". If it was open source and hosted on d.o I think I'd feel a lot better about it (as the livetest demo looks pretty nice), and hey maybe even submit a patch or two? ;)
Well.. don't be
Well.. don't be disappointed. ; )
It's not our intention at Ubercart to make the software proprietary, and we certainly plan to open the code up to the general public. We're going to need everyone's help not turn it away! It's just that we got more publicity than we expected sooner than we expected. Partly because of the interest in some jQuery articles posted there and partly because of a blog post at Alledia comparing Joomla and Drupal.
Anyways, it's our goal to ensure the code is at the very least usable before it's released. We have clear development specs in mind that we want to achieve before posting the code up for scrutiny and addition. The main thing is extensibility. I spent a week in December rewriting checkout and order code to make both those things extensible by other modules. Had I released code sooner, it would've been bad for other developers. And there are just some key features that we already planning on implementing that releasing too soon would just cause the issue tracker to be filled with redundant feature requests.
When the code is ready, you can be sure there will be a project here at Drupal.org (though we may try and devise a cleaner way to do issue tracking) and there will be an announcement from one of us on the team.
Thanks for your interest!
Well...
Well, I have now setup 11 live e-commerce stores with the ecommerce package. My opinion is that you -cannot- make a "all in one" solution without having things a lot more customisable. For every site I create, the customers have a slightly different angle on things and want, not only other features, but also a change in the behaviour of the default features. There are very little flexibility and I have to admit that very old versions of OS Commerce completely crush the the ecommerce/drupal combo when it comes to accessibility for the users. And that's something we really need to start working on.
I have tried saying this so many times on the drupal forums, but no one seems to listen/agree. User accessibility, graphical interfaces and focus on a store owners day-to-day workflow should be the very first priority! Because right now, what my customers want is a old version of os commerce, and I have to convince them otherwise because of drupals beautiful framework ;)
All in all, I believe Ubercart is a great initiative and really hope they develop it with more focus on accessibility than the ecommerce package.
-Thomas
Forks
Why not focus effort on submitting patches to ecommerce? It's sad to see forking when so much work has been put into ecommerce. We should be focusing on improving our a strong open source community and making one system be flexible for all solutions.
I'd like to hear what parts of ecommerce need work so we can focus on that.
Some answers
I think you'd be interested in reading this thread. It tries to answer the questions about our purpose and why we're doing things the way we are.
But, ultimately, the answer is that we aren't writing the Übercart for the community. We're making it for ourselves to be exactly what we need from the get go, and it would take about as long to modify e-commerce to be just that. We do want the community to use and enjoy Übercart, and we will certainly accept help on it, but not until we're ready for it.
Übercart -- One cart to rule them all.
Ubercart -- One cart to rule them all.
I'm starting to work on some
I'm starting to work on some ecommerce sites that will be multinational, multilingual and multi-currency. From what I read, it looks like ubercart is still somewhat US-centric..
Alas, 'tis true. We operate
Alas, 'tis true. We operate several US stores, and as such are designing the cart with ourselves in mind. However, we are planning on making the appropriate features extensible for other countries (address formatting, shipping/payment modules, order total calculation/taxes, and currency formatting)... so feasibly, if someone wants support for another method they'll be able to get it done without hacking the Ubercart core.
Just an update to this,
Just an update to this, since folks are still finding it in searches... the latest Alpha versions have seen significant improvements in internationalization, and concerns like mfb's have been duly noted in our development plan. We have working country import files for a dozen countries that setup the necessary info in the DB for those countries along w/ address formats. More work is planned for i18n, and we're always looking for people to submit their country file. Instructions can be found through the stickys in this forum:
http://www.ubercart.org/forum/18