Or just a regular e-commerce site using Pinax as a collection of re-
usable apps?
If you mean social commerce, what do you mean by that?
A social site that uses recurring billing for subscribers to the site,
for example using CheddarGetter?
Or a site where many people offer products for sale with some social
features for both sellers and buyers, like http://etsy.com?
Or some combination of the above?
Or something else?
In my case, I am interested in groups of people and businesses who do
business together in some way. The sites might have social features
for buyers and sellers, use recurring billing for subscribers, and
also provide back-end business administration and accounting features
for the business groups.
You can read more about my work here: http://www.group-accounting.com
So far, most of my group business projects have used plain old
Django. Only one Pinax so far, for a cohousing group, and they use it
for community communication: meetings, community calendar, etc.
To me that is an easy answer since nowadays customers more or less
expect at least some sort of "social" even with a small and simple
webshop. Even if it is just the opportunity to have threaded comments,
something social is what folks want these days. We are more and more
dealing with a customer base that grew up with Facebook, Xing, Ebay,
etc. in mom's breast-milk already ...
Bob> If you mean social commerce, what do you mean by that? A social
Bob> site that uses recurring billing for subscribers to the site, for
Bob> example using CheddarGetter?
Yes, for example. As mentioned above ... I think theses days it more or
less does not matter what product is exchanged for money (or something
else than money) in return. E-books, porn, food, cars, real estate,
education, ... you name it. All sites will soon have some sort of
"social" aspects build-in I think.
Bob> Or a site where many people offer products for sale with some
Bob> social features for both sellers and buyers, like http://etsy.com?
If a Pinax social_commerce_project can be build so that one seller sells
to many buyers, why not build it so that many sellers can sell to many
buyers (Amazon-like) too? Let the implementer decide if his site has one
or many sellers. If commerce_project can do both, just by altering some
setting for example, this will attract many I think.
[skipping a few lines ...]
Bob> subscribers, and also provide back-end business administration and
Bob> accounting features for the business groups.
Can you give a few examples for "back-end business administration and
accounting features"?
BOTTOM LINE:
To summarize, I think (correct me if you feel I am wrong) the questions
still open for discussion are:
- do we want social features (groups/tribes, threaded comments, etc.)
in commerce_project at all. I say +1 here.
- shall commerce_project be a one seller/many buyers thing or many
sellers/many buyers. Is it possible to make it so that
commerce_project can be used both ways?
- what is going to be the actual billing API/backend? something we
write ourselves or shall we just use CheddarGetter? I think
CheddarGetter would be a reasonable thing to use in commerce_project
if made pluggable so it can easily exchanged with some other billing
API/backend.
- I think Harley did a wonderful thing with melting together Satchmo
and Pinax but in the long-run, as mentioned by Bob and Brian in the
other two threads about commerce_project, doing some generic
Pinax-based commerce_project is the way to go. Harley's creation
actually is not really in the same use case corner anyways so it will
never be either this or that ... both solutions will prosper.
I am +1 for a Pinax-based commerce_project that allows for one or more
sellers, has a stack of social options available (enable by adding apps)
and comes with some pluggable billing API (read CheddarGetter). What do
others think?
It is significantly more complicated, but I need it.
> Bob> subscribers, and also provide back-end business administration and
> Bob> accounting features for the business groups.
>
> Can you give a few examples for "back-end business administration and
> accounting features"?
For example:
If you allow for many sellers selling to many buyers, and you also
allow one customer order to contain items from different sellers, then
the site administration needs to split the money up among the sellers.
If the site keeps track of seller inventory, it will need to keep of
inventory by seller rather than by product, and possibly by location
or custodian as well (drop shipping).
If the site sells food, it may need to track lots back to the source.
Etc.
Not necessarily back-end, but other facets of many-seller sites:
* Each seller might want their own section of the site: web pages,
identity, followers, theme, etc.
* Sellers may belong to groups, as they do at Etsy, and present their
products in a group environment.