Why the name Ubercore?
This is a question asked by Jes in IRC, and moved to the forums for further discussion.
uberchic: i'm confused by the new name still, perhaps you can help clear that up for me
[1:17pm] rszrama: mikejoconnor: sure thing; I might tag IslandUsurper with that, as it sounds like he's already scoping out the possibility of a Coder upgrade
[1:17pm] uberchic: as in why not just continue calling the project ubercart?
[1:17pm] alpritt joined the chat room.
[1:18pm] uberchic: i feel silly asking now, but i would feel even sillier asking later
[1:18pm] rszrama: uberchic: sure; the new name reflects primarily the ideas outlined in http://www.bywombats.com/blog/10-22-2009/ubercart-20-and-ubercore-initia... that were better expressed in http://www.ubercart.org/forum/announcements/13802/planning_and_developin...
[1:18pm] rszrama: the latter one was published at one point in time and is still accessible to people who have admin access on Ubercart.org
[1:19pm] rszrama: I think it does the best job thus far of explaining the goals for Ubercart to be in the application space vs. merely the component module space
[1:19pm] univate: I understand the idea of ubercore as being what drupal is for CMS and ubercart now going to be what Open Atrium is, an application that just runs out of the box.
[1:19pm] rszrama: univate: I think that's the best future, especially if Ubercart wants to contend against the likes of Magento
[1:20pm] uberchic: I have read both, and am curious as to why not to follow the open atrium approach and re-name the shipped package and not the core
[1:20pm] rszrama: univate: otherwise there will be that perpetual confusion
[1:20pm] mikejoconnor: univate: by abstracting ubercore int oa module vs app, we totally open the door for that
[1:20pm] uberchic: and i am all for ubercart continuing to be a streamlined module
[1:20pm] rszrama: uberchic: I suppose we could do that; but then what's the point of building up an Ubercart name and brand at all? may as well build up Views or CCK as a stand alone brand as well
[1:21pm] DamZ: the core needs to be renamed if we want not to be tied with the history of ubercart
[1:21pm] DamZ: *we do not want to be*
[1:21pm] uberchic: and why wouldn't we?
[1:21pm] uberchic: unless it is a totally different project...
[1:21pm] rszrama: DamZ: do you mean the existing codebase / revision history?
[1:21pm] ChubbyDirt: access denied for both of those links...
[1:22pm] DamZ: rszrama: yes, and the previous design decisions
[1:22pm] CrashTest_ joined the chat room.
[1:22pm] DamZ: ubercore is an open process
[1:22pm] uberchic: chubbydirt: will publish, for this meeting
[1:22pm] DamZ: ubercart is not, anymore
[1:22pm] ChubbyDirt: thx
[1:22pm] rszrama: ChubbyDirt: my blog link should be fine I think
[1:22pm] DamZ: (because there is a lot of history)
[1:22pm] rszrama: ChubbyDirt: I just accessed it as anonymous
[1:22pm] uberchic: damz: how do you mean
[1:23pm] rszrama: just so the discussion doesn't take up too much time, can we offload this question to the forums?
[1:23pm] ChubbyDirt: got it... thx
[1:23pm] uberchic: which forums?
[1:23pm] rszrama: this meeting isn't really a hashing out of issues but more of a realignment / moving forward meeting
[1:23pm] uberchic: d7uc or uc,org?
[1:24pm] DamZ: uberchic: the name of things matter, and we need a fresh perspective
[1:24pm] rszrama: uberchic: I suppose if the question is "why the name Ubercore", a thread on d7uc.org that outlines the problems / questions would be ideal - the idea being that topics in the forums result in documentation changes on the site itself
[1:24pm] uberchic: damz: i agree, and this new name is confusing, and implies ties with ubercart
[1:24pm] rszrama: aside from naming, does anyone else have any questions about the general goals for Ubercart on D7?
[1:25pm] mikejoconnor: uberchic: they are not to competing items. we are building one to improve the other
[1:26pm] uberchic: damz, mike: apologies, happy to continue this elsewhere, still confused, but happy to move on
Comments
Damz, I am particularly
Damz, I am particularly interested in your statements: 'ubercore is an open process', 'ubercart is not, anymore'. And I want to know more about your perspective on that, specifically.
Univate, I think that Ubercart should continue to be like what drupal is for CMS, continuing to get refined, to leave the room for other 'open atriums' in drupal online commerce applications.
Mikejoconner, a reference from the (now unpublished link) above: "Now it's much more useful and could be reintroduced as a component in a larger Ubercart installation profile." How then would Ubercart and Uberdrupal not be competing install profiles? Can't ubercart continue to be refined, for the benefit of uberdrupal?
All, my only suggestion is that Ubercart continue to be the name of the main module, which IS, and was always intended to be "the minimum systems and entities without which we will not have a coherent project and which we need to build and support all our other features." Granted at the beginning of Ubercart, I'm not sure anyone new what that meant, or how to accomplish that, which is how we end up with what there is now. I have no argument that ubercart doesn't need some major improvements, it does, and it will get them, and why can't it get them following in Ubercart 3.0, or 4.0, instead of via 'ubercore 1.0' ?
I also think it would be of benefit to have all of this information available in one location, instead of needing to check ubercart.org, and d7uc.org, and http://drupal.org/project/ubercore, and http://drupal.org/project/ubercart. Why the duplication?
If this is truly starting completely over, with new insight, and a lovely new D7, then why keep an affiliation with Ubercart? I can't say a fresh start doesn't sound appealing, it does, I am just unsure why the name should be so similar and confusing.
Jes wrote, "All, my only
Jes wrote,
"All, my only suggestion is that Ubercart continue to be the name of the main module, which IS, and was always intended to be "the minimum systems and entities without which we will not have a coherent project and which we need to build and support all our other features." Granted at the beginning of Ubercart, I'm not sure anyone new what that meant, or how to accomplish that, which is how we end up with what there is now."
As one who has been developing the project from the get go, I can confidently say that Ubercart was never meant to be the "minimum systems and entities without which we will not have a coherent project and which we need to build and support all our other features." Perhaps there's some definition confusion here and it would be helpful for me to create a visual that explains the difference.
If you look at the core systems brainstormed in [node:53] and [node:54], you can get an idea of what we mean when we talk about Ubercore being the minimum systems and entities. Now, if you think about Ubercart, anyone can come up with examples where our goal of a killer out of the box experience intentionally made Ubercart more than a core API set from the beginning. We've always planned on configuration that makes it easy to use Ubercart out of the box, because that was a key weakness of the e-Commerce module package we wanted to avoid.
Thinking in terms of explicit features, I'd point out the core catalog module, the various payment method and gateway modules, the various shipping quote modules, the out of the box image support via CCK / Imagefield integration, the core product feature modules and more as instances that refute the claim that Ubercart has always been designed as a "bare essentials" core. There are so many examples here it feels kind of silly to even have to be making this point.
So, the point of the Ubercore is to add a laser focus on an improved, leaner core with much better horizontal integration and dependence (a la Views, Fields in core, etc.). But it's doing this without changing what Ubercart "is and always has been" - "an exciting open source e-commerce package". A package isn't a core, but with a solid core the possibilities for improving the package are multiplied. As I mentioned in today's IRC meeting, this was illustrated perfectly by UC Recurring's removal from Ubercart 2.x.
To that end, calling the core "Ubercore" is no more a departure from the project it's designed to support than changing the nature of "Ubercart" to just a core set of APIs would be. In fact, I think this is less confusing than to remake Ubercart itself as a core, and Ubercart as a whole will be better off staying as it is now.
@uberchic I wrote uberchic:
I wrote
uberchic: they are not to competing items. we are building one to improve the other.
I suppose there could be some confusion, let me be a little more specific.
Ubercore and Ubercart are not competing, we are building one to improve the other. See my comment below for more information on that subject.
Why Ubercore?
I’d like to start by saying Ubercart + Drupal are the best ecommerce system currently available, however I believe that Drupal is definitely the stronger of the two, and I will explain why.
Ubercart is quickly approaching 3 years old, and during those 3 years, it has grown far beyond the initial scope of the project. Virtually all of the feature creep has had a positive effect on the store administrator, but has had a negative effect on the code itself. This is caused by placing site administrators in the drivers seat for the majority of the first two releases.
This user centric development is what makes Ubercart so good. Site administrators /builders know where the major external faults are, they find the bugs, and fight with ui confusion. Ubercart would not be what it is without the great user feedback. Unfortunately, very few of the 14,000 Ubercart users also develop custom features. From a developers ux perspective, Ubercart’s 30,000+ lines of code, are 31 modules of features present a major maintenance problem.
Consider this: As a developer you find a great way to improve the payment system, your changes to the underlying API result in a nice 100-200 line patch, with a much better data model. Unfortunately those changes break the 7 other payment systems in core, now your patch is at 400 line. Then you find you need to modify the cart, and order panes, and your at 600 lines. These modifications change the way taxes are pulled into the checkout pane, and you have to refactor some of the tax module. Those changes cascade to line items, and your back to the order module. Although this may be a bit extreme, it is very plausible.
So the solution, we could refine Ubercart. Instead of 31 modules we could take it down to 5 or so core modules, possibly even one. The problem is the users of Ubercart expect an out of the box ecommerce solution, and if we start removing features, we will lose our market share. Furthermore, if we spend all of Ubercart 3.x focusing on internal API’s, we will likely lose ground on features, thus losing market share to other solutions like Magento.
Solution, 2, we extract the 5 core Ubercart modules, into a new module called Ubercore. Ubercore focuses on data models, APIs, and developer experience. Meanwhile we leverage Ubercore in Ubercart. This will allow Ubercart to focus on user experience, and additional features. Because Ubercart is using a set of APIs, a change to the payment data model won’t cascade into huge patch effecting multiple modules. Furthermore, the simple process of building Ubercart with Ubercore will allow us to rapidly identify gaps in our API, and other potential problems, fixing them before we hit release candidate.
So why Ubercore? because users love features, developers love APIs, and abstraction is good.
I don't think we need to
I don't think we need to worry about losing marketshare to Magento (please note the spelling of the word "losing" and never make that mistake again, thanks), because Magento is missing an important element of Ubercart: Drupal. You have Magento which is specifically a store, and you have Drupal which is a general-purpose CMS which can serve as a store (among all sorts of other things) with the addition of the Ubercart modules. It's apples and oranges, in my opinion. What we really need to worry about is UC not meeting developers' and users' needs leading to the forking of Ubercart or the creation of another "competing" ecommerce system for Drupal - or allowing for eCommerce to "catch up."
Why Ubercore
I think Mike really hit the nail on the head as far as my argument goes. The issue here is maintenance, pure plain and simple. Ubercart, in and of itself, is sort of difficult to add new features to, or refine existing one for all the reasons Mike outlined. Furthermore, the APIs that exist currently could use a bit of refinement (really, what API couldn't?) point being, Ubercart the module in and of itself, has a lot of inter-dependencies on those apis, so an upgrade in one api perpetuates a need for an update in any module that depends upon that API. This is the nature of the beast. In the case of "ubercore" we're not restrained in this way. Since api changes would result in major version number changes, "Ubercart" might be dependent on say... "ubercore 1.x", and then after apis in "ubercore 2.x" are stable and released, ubercart could start the venture towards upgrading to make use of them.
Ryan's point I think is important at this point, because as he says, ubercart is NOT the bare minimum, and Mike's point of user impact plays here as well, we don't want ubercart to be the bare minimum, we want it to satisfy the customer's needs. Unfortunately, the developers needs aren't being met, and this (ubercore) is probably the simplest solution to that problem.
As far as Uberdrupal (since no one has addressed it) I can understand your confusion. Let me see if I can explain better:
Ubercore is the bare apis, a system that defines how to write a new payment gateway, or how to define a new shipping type, or whatever. Ubercart is the various modules that have been deemed necessary as supporting the 80% of users who use the system (conforming to the 80/20 rule). Ubercart runs commerce systems, ubercore defines the apis ubercart uses.
Uberdrupal is a solution for those who don't want to spend the time learning to set up their own system, and believe that the defaults that have been defined by that profile are sufficient to run their commerce needs. It's a shortcut to getting ubercart up asap. It could also include things that ubercart (the module) can't... say a custom theme, or other packages outside of ubercart that are useful (say a wysiwyg editor, or whatever).
I hope this (plus Ryan and Mike's explanation) sufficiently answers the question. The 3 can exist in parallel and in fact problem should. Strength in the foundation (ubercore) translates up the chain, and ultimately improves everything that builds off of it.
+1 - Thanks for the thoughts,
+1 - Thanks for the thoughts, Kris. I'd even go so far as to muse about what it would look like for UberDrupal itself to become redundant and discontinued if Ubercart took over that space.
Eh...
I'm not entirely sure that's plausible, unless all the module that currently make up "Ubercart" were moved out of it and into their own projects, and Ubercart itself were moved to become a distribution. If that happened though, I think it might make things a bit more concise, and I was just musing on how I'm not entirely sure that having CA in core is as advantageous as having it as its own module. On the other hand I'm sort of wondering if actions/triggers can't suffice, but that's certainly not a topic for this thread. :-)