Rails - Mar 2005 - Call for Ideas/Developers: Qanah Open Source Enterprise eCommerce

[I realized after I sent this that "Announce" in the subject might be 
construed as an as advertisement, thus would have been discarded.  My 
apologies for the duplicate post.  I also made a few edits.]

Hello all!

Intro and "Credentials"
My name is Joshua Kugler, and I currently a system administrator for the 
University of Alaska Fairbanks Center for Distance Education 
<http://www.distance.uaf.edu/>, and am currently pursuing my Masters in 
Computer Science.  I''ve used Perl for years, writing entire database 
driven web sites using it <see http://asuaf.org>; simple but 
functional.  I''ve also written an entire database app using MS Access 
and Visual Basic...nice, but VB isn''t my favorite language.  I was also
the project leader for several class projects, including our senior 
design project.

My intro to Ruby
I''ve known about the Ruby language for some time now, and was
especially
intruiged by just *how* object oriented it was.  Well, a few weeks ago, 
starting with the O''Reilly series, I found out about Rails.  As I 
learned more via the second part of the O''Reilly series, "Really 
Getting Started in Rails," and "Four Days on Rails," I really
started
to get excited.  So, yes, I must make a disclaimer: I have yet to 
program one line of Ruby code.  You can stop reading now if that 
disgusts you. :)  I''ve also written a couple of papers on software 
design and implementation.  See <http://asuaf.org/~joshua/papers/>

What I want to do
I''ve done googling, reading, and mail-list searching.  Other than a 
smattering of posts and references 
(http://textdrive.com/forum/viewtopic.php?pid=24856, and this thread: 
http://thread.gmane.org/gmane.comp.lang.ruby.rails/2349), I''ve found no
serious discussion of a solid, open source, Rails-based eCommerce 
application.  I''ll be needing a good, maintainable, extensible 
eCommerce system in a few (or several) months, and I want to 1) Learn 
Ruby and Rails, 2) get some project management experience, and 3) 
create something that could become a "poster app" for Rails (I know, 
Basecamp; I said "a," not "the").  eCommerce is something
that really
needs a lot of templating and site design apart from the back-end code 
and is ripe for something with good MVC separation like Rails.

The project will be called Qanah Open Source Enterprise eCommerce.  
Qanah (pronounced kah-nah'') is a Hebrew word meaning "to
buy."
Appropriate for an eCommerce app, don''t you think? :)

The Details
This will not be a rush job.  As much as my hacker/programmer instincts 
want to jump in and start implementing, I know better.  I''ve done 
enough projects where lack of planning came back and bit me.  So, this 
will not be a rush project.  If you''re looking for a product in a 
couple months, this ain''t it. :)  We''re probably looking at a
three to
six month design process to gather and orgainze requirements, do 
design, and do initial system layout.

I''ve registered for a project on rubyforge, and will shortly have more 
details forthcoming.

Conclusion
Well, I have a lot of ideas I''ll be distilling in the next few days and
weeks.  If anyone is interested or has questions, feel free to ask.  I 
know I''ve bitten off a big chunk, but I''m excited about
leading a
project and learning Ruby and Ruby on Rails.

j----- k-----

-- 
Joshua J. Kugler -- Fairbanks, Alaska -- ICQ#:13706295
Every knee shall bow, and every tongue confess, in heaven, on earth, and 
under the earth, that Jesus Christ is LORD -- Count on it!

you can spend most of your time doing user testing on low fidelity
prototypes -- as with RoR everything else is 10x faster.

are you suggesting a turn-key type eCommerce solution... ie: "enter
your company name here and you''re done teh c0nfiguration"

or are you talking like a toolkit / generators to assist in rolling
out a RoR eCommerce site?


On Sat, 19 Mar 2005 22:31:04 -0900, Joshua J. Kugler
<jkugler-jG/AHqQBv7lBDgjK7y7TUQ@public.gmane.org>
wrote:
> [I realized after I sent this that "Announce" in the subject
might be
> construed as an as advertisement, thus would have been discarded.  My
> apologies for the duplicate post.  I also made a few edits.]
> 
> Hello all!
> 
> Intro and "Credentials"
> My name is Joshua Kugler, and I currently a system administrator for the
> University of Alaska Fairbanks Center for Distance Education
> <http://www.distance.uaf.edu/>, and am currently pursuing my Masters
in
> Computer Science.  I''ve used Perl for years, writing entire
database
> driven web sites using it <see http://asuaf.org>; simple but
> functional.  I''ve also written an entire database app using MS
Access
> and Visual Basic...nice, but VB isn''t my favorite language.  I was
also
> the project leader for several class projects, including our senior
> design project.
> 
> My intro to Ruby
> I''ve known about the Ruby language for some time now, and was
especially
> intruiged by just *how* object oriented it was.  Well, a few weeks ago,
> starting with the O''Reilly series, I found out about Rails.  As I
> learned more via the second part of the O''Reilly series,
"Really
> Getting Started in Rails," and "Four Days on Rails," I
really started
> to get excited.  So, yes, I must make a disclaimer: I have yet to
> program one line of Ruby code.  You can stop reading now if that
> disgusts you. :)  I''ve also written a couple of papers on software
> design and implementation.  See <http://asuaf.org/~joshua/papers/>
> 
> What I want to do
> I''ve done googling, reading, and mail-list searching.  Other than
a
> smattering of posts and references
> (http://textdrive.com/forum/viewtopic.php?pid=24856, and this thread:
> http://thread.gmane.org/gmane.comp.lang.ruby.rails/2349), I''ve
found no
> serious discussion of a solid, open source, Rails-based eCommerce
> application.  I''ll be needing a good, maintainable, extensible
> eCommerce system in a few (or several) months, and I want to 1) Learn
> Ruby and Rails, 2) get some project management experience, and 3)
> create something that could become a "poster app" for Rails (I
know,
> Basecamp; I said "a," not "the").  eCommerce is
something that really
> needs a lot of templating and site design apart from the back-end code
> and is ripe for something with good MVC separation like Rails.
> 
> The project will be called Qanah Open Source Enterprise eCommerce.
> Qanah (pronounced kah-nah'') is a Hebrew word meaning "to
buy."
> Appropriate for an eCommerce app, don''t you think? :)
> 
> The Details
> This will not be a rush job.  As much as my hacker/programmer instincts
> want to jump in and start implementing, I know better.  I''ve done
> enough projects where lack of planning came back and bit me.  So, this
> will not be a rush project.  If you''re looking for a product in a
> couple months, this ain''t it. :)  We''re probably looking
at a three to
> six month design process to gather and orgainze requirements, do
> design, and do initial system layout.
> 
> I''ve registered for a project on rubyforge, and will shortly have
more
> details forthcoming.
> 
> Conclusion
> Well, I have a lot of ideas I''ll be distilling in the next few
days and
> weeks.  If anyone is interested or has questions, feel free to ask.  I
> know I''ve bitten off a big chunk, but I''m excited about
leading a
> project and learning Ruby and Ruby on Rails.
> 
> j----- k-----
> 
> --
> Joshua J. Kugler -- Fairbanks, Alaska -- ICQ#:13706295
> Every knee shall bow, and every tongue confess, in heaven, on earth, and
> under the earth, that Jesus Christ is LORD -- Count on it!
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

On Sunday 20 March 2005 00:57, Caleb Buxton said something
like:
> you can spend most of your time doing user testing on low fidelity
> prototypes -- as with RoR everything else is 10x faster.
I''m not quite sure I follow you here?  Can you elaborate?  Are you 
saying I''d have more time to do user testing because RoR is faster to 
develop in, or something else would be faster than RoR?
> are you suggesting a turn-key type eCommerce solution... ie: "enter
> your company name here and you''re done teh c0nfiguration"
>
> or are you talking like a toolkit / generators to assist in rolling
> out a RoR eCommerce site?
Well, I''m not sure "turnkey" is 100% accurate.  I would say
simple
configuration would get you a functioning eCommerce site.  Slighty more 
work would get you multiple stores, managers of departments, etc.

Although, I would like to be able to extract out parts that would be 
good building blocks

Like I said, I''m in the idea stage, so I''m sure a lot of this
is yet to
be hashed out.

j----- k-----

-- 
Joshua J. Kugler -- Fairbanks, Alaska -- ICQ#:13706295
Every knee shall bow, and every tongue confess, in heaven, on earth, and 
under the earth, that Jesus Christ is LORD -- Count on it!

Joshua J. Kugler wrote:
>On Sunday 20 March 2005 00:57, Caleb Buxton said something like:
>  
>
>>you can spend most of your time doing user testing on low fidelity
>>prototypes -- as with RoR everything else is 10x faster.
>>    
>>
>
>I''m not quite sure I follow you here?  Can you elaborate?  Are you 
>saying I''d have more time to do user testing because RoR is faster
to
>develop in, or something else would be faster than RoR?
>  
>
I think he''s suggesting you need not spend so much time in design (I 
think you mentioned, you planned to spend 6 months in design). Part of 
the philosophy behind RoR as I understand it is that you should focus 
design on the UI and features - the detail design of the application 
will follow logically from those decisions and the guidance provided by 
the framework, and it will evolve as you iterate.

The approach I''m taking in my first RoR project is I think classic RAD.
Think a little, do a little, think a little, do a little. Release early 
and often. Test cases provide the coverage and flexibility to refactor 
often as I learn the design better. 

In my professional work life, I''ve spent huge amounts of time in design
(it is mandated by our ridiculous waterfall process and funding model) 
and I think much of it is wasted. Eventually all the reams of design 
docs, UML diagrams etc. are worthless because the design has moved on as 
we''ve started solving real world challenges and there is little 
incentive to keep the design up to date (the exception being static 
models like class diagrams and ERDs). We understand the domain much 
better after we''ve been building awhile and  use the design docs much
at
all.
>  
>
>>are you suggesting a turn-key type eCommerce solution... ie: "enter
>>your company name here and you''re done teh c0nfiguration"
>>
>>or are you talking like a toolkit / generators to assist in rolling
>>out a RoR eCommerce site?
>>    
>>
>
>Well, I''m not sure "turnkey" is 100% accurate.  I would
say simple
>configuration would get you a functioning eCommerce site.  Slighty more 
>work would get you multiple stores, managers of departments, etc.
>
>Although, I would like to be able to extract out parts that would be 
>good building blocks
>  
>
I tend to think focusing here would be more fruitful. Unless you have 
really innovative feature ideas the world doesn''t really need another 
click-n-go eCommerce suite. But a framework for developing more 
customized eCommerce applications I can see - while these exist it would 
be nice to have one in RoR. I have to plead a lot of ignorance in this 
domain - it seems pretty well solved to me. Still, I know many companies 
develop custom eCommerce software so there must be good reasons why.
>
>
>
>
>  
>

On Sun, 20 Mar 2005 20:05:25 -0500, Jeremy Huffman
<jeremy-S3UG9Ld25dVMf0S0rWojDQC/G2K4zDHf@public.gmane.org>
wrote:
> 
> 
> Joshua J. Kugler wrote:
> 
> >On Sunday 20 March 2005 00:57, Caleb Buxton said something like:
> >
> >
> >>you can spend most of your time doing user testing on low fidelity
> >>prototypes -- as with RoR everything else is 10x faster.
> >>
> >>
> >
> >I''m not quite sure I follow you here?  Can you elaborate?  Are
you
> >saying I''d have more time to do user testing because RoR is
faster to
> >develop in, or something else would be faster than RoR?
> >
> >
> I think he''s suggesting you need not spend so much time in design
(I
> think you mentioned, you planned to spend 6 months in design). Part of
> the philosophy behind RoR as I understand it is that you should focus
> design on the UI and features - the detail design of the application
> will follow logically from those decisions and the guidance provided by
> the framework, and it will evolve as you iterate.
> 
> The approach I''m taking in my first RoR project is I think classic
RAD.
> Think a little, do a little, think a little, do a little. Release early
> and often. Test cases provide the coverage and flexibility to refactor
> often as I learn the design better.
> 
> In my professional work life, I''ve spent huge amounts of time in
design
> (it is mandated by our ridiculous waterfall process and funding model)
> and I think much of it is wasted. Eventually all the reams of design
> docs, UML diagrams etc. are worthless because the design has moved on as
> we''ve started solving real world challenges and there is little
> incentive to keep the design up to date (the exception being static
> models like class diagrams and ERDs). We understand the domain much
> better after we''ve been building awhile and  use the design docs
much at
> all.
> 
> >
> >
> >>are you suggesting a turn-key type eCommerce solution... ie:
"enter
> >>your company name here and you''re done teh
c0nfiguration"
> >>
> >>or are you talking like a toolkit / generators to assist in rolling
> >>out a RoR eCommerce site?
> >>
> >>
> >
> >Well, I''m not sure "turnkey" is 100% accurate.  I
would say simple
> >configuration would get you a functioning eCommerce site.  Slighty more
> >work would get you multiple stores, managers of departments, etc.
> >
> >Although, I would like to be able to extract out parts that would be
> >good building blocks
> >
> >
> I tend to think focusing here would be more fruitful. Unless you have
> really innovative feature ideas the world doesn''t really need
another
> click-n-go eCommerce suite. But a framework for developing more
> customized eCommerce applications I can see - while these exist it would
> be nice to have one in RoR. I have to plead a lot of ignorance in this
> domain - it seems pretty well solved to me. Still, I know many companies
> develop custom eCommerce software so there must be good reasons why.
 
Personally, I don''t think it''s "solved" at all, but
I''m baised, been
doing little else for the past 5 years - tho'' mostly on a single
platform.

The reason for custom eCommerce is simple: demand.  I''ve only done one
that was custom from the ground up, and that was early on using perl
(and quite painful).  Since then, I''ve been using a widely used cart,
that I''ve costumized to the point of insanity.

That said, I''d _love_ to see an open source project in RoR, and
I''d be
happy to offer input, feedback, ideas or even code (assuming I have
the time/skill needed for it).

Aside from the thousand things clients always ask for, here''s my dream
"core":

  a secure admin that''s fairly easy to use.
  the ability to run local clients to manage some of the heavy lifting.
  easy to customize look and feel - _very_ little logic in the html.
  easy to add new features - some form of module/plugin system
  variety of shipping methods
  variety of payment methods

Those last two aren''t important early on, but if they can''t be
expanded easily (and fairly quickly), it''s probably doomed long-term.

-- 
Bill Guindon (aka aGorilla)

On Sunday 20 March 2005 18:37, Bill Guindon said something
like:
> That said, I''d _love_ to see an open source project in RoR, and
I''d
> be happy to offer input, feedback, ideas or even code (assuming I
> have the time/skill needed for it).
Thank you!!
> Aside from the thousand things clients always ask for, here''s my
> dream "core":
Woohoo! Feature requests!
>   a secure admin that''s fairly easy to use.
Yep...I really want this too.  While there would be some things that 
would remain command line, or direct DB editing, I want to be able to 
do almost everything from the web interface.
>   the ability to run local clients to manage some of the heavy
> lifting.
Like XML-RPC type stuff to process information locally?
> easy to customize look and feel - _very_ little logic in the html.
Absoutely, and since we''re using Rails, the "view" portion
will probably
end up being most of our template engine.  I''m sure we''ll
create
several methods that you can put in your rhtml to print out 
links/images/etc in a certain place in the template.
> easy to add new features - some form of module/plugin system 
That is certainly something I want to see.  That will require some 
careful design to make the system open and extensible.
> variety of shipping methods
Yes!  One of my major frustrations with eCommerce systems that I''ve
seen
is that they limit you to whatever the developer has implemented.  I 
think I''ve only seen one system that would let you get account based 
quotes from FedEx...the rest, you just had to go with the stock rates.
> variety of payment methods
If it doesn''t already exist, I''ll probably port (or create)
something
like Perl''s Business::OnlinePayment classes.  That way, it would be 
easy to add any other payment method.

Hmm...just looking through the list, there is a 
Business::FedEx::DirectConnect too.  I''ll have to take a look at that.
> Those last two aren''t important early on, but if they
can''t be
> expanded easily (and fairly quickly), it''s probably doomed
long-term.
I have seen too many overly complex or closed-end systems.  While I know 
from the outset that creating an open system is harder because you have 
to think hard about leaving things open, in the end it makes things so 
much easier to extend.

Thanks for all the ideas and feedback.  I''m going to start on a Wiki
for
development ideas/feature requests.  If anyone wants to join, join 
rubyforge and drop me a line.

j----- k-----

-- 
Joshua J. Kugler -- Fairbanks, Alaska -- ICQ#:13706295
Every knee shall bow, and every tongue confess, in heaven, on earth, and 
under the earth, that Jesus Christ is LORD -- Count on it!

> >I''m not quite sure I follow you here?  Can you elaborate?  Are
you
> >saying I''d have more time to do user testing because RoR is
faster
> > to develop in, or something else would be faster than RoR?
>
> I think he''s suggesting you need not spend so much time in design
(I
> think you mentioned, you planned to spend 6 months in design).
Understood.  I said six months because this is going to be a part 
time/free time project.  So, it may very well end up being much less 
than six months.  We''ll see how design goes. :)
> Part 
> of the philosophy behind RoR as I understand it is that you should
> focus design on the UI and features - the detail design of the
> application will follow logically from those decisions and the
> guidance provided by the framework, and it will evolve as you
> iterate.
This is true.  But as for any DB based app, I believe you need to spend 
a lot of time thinking thorugh your table structure to allow for growth 
later, and so you don''t back yourself in a corner (e.g. have only one 
field where a user can store credit card data vs. a table where they 
can store several credit cards).
> The approach I''m taking in my first RoR project is I think classic
> RAD. Think a little, do a little, think a little, do a little.
> Release early and often. Test cases provide the coverage and
> flexibility to refactor often as I learn the design better.
When I look at the code size and complexity of some existing eCommerce 
projects, I''m not sure "do a little, think a little, do a
little" will
work in this case.  I''m *NOT* saying it''s a bad way to do
things (I
mean, I often code like that), but I just don''t think it would work 
well in this case.  I think most of the design will be concentrated on 
making sure we have the DB schema right, then once we get there, we can 
"code a little, think a little, code a little."
> In my professional work life, I''ve spent huge amounts of time in
> design (it is mandated by our ridiculous waterfall process and
> funding model) and I think much of it is wasted.
Ah, the waterfall model...yummy.  Not.
> Eventually all the 
> reams of design docs, UML diagrams etc. are worthless because the
> design has moved on as we''ve started solving real world challenges
> and there is little incentive to keep the design up to date (the
> exception being static models like class diagrams and ERDs). We
> understand the domain much better after we''ve been building awhile
> and  use the design docs much at all.
Right.  UML (or similar) for table relations.  A good requirements 
doc/wishlist doc.  Decent descriptions of how it all goes togther.  And 
liberal commenting in the code.
> >Well, I''m not sure "turnkey" is 100% accurate.  I
would say simple
> >configuration would get you a functioning eCommerce site.  Slighty
> > more work would get you multiple stores, managers of departments,
> > etc.
> >
> >Although, I would like to be able to extract out parts that would be
> >good building blocks
>
> I tend to think focusing here would be more fruitful. Unless you have
> really innovative feature ideas the world doesn''t really need
another
> click-n-go eCommerce suite. But a framework for developing more
> customized eCommerce applications I can see - while these exist it
> would be nice to have one in RoR. I have to plead a lot of ignorance
> in this domain - it seems pretty well solved to me. Still, I know
> many companies develop custom eCommerce software so there must be
> good reasons why.
There are parts that are abstracted out (e.g. there is a login generator 
for RoR), but some parts are hard to separate.  You could abstract out 
the module for querying FedEx/UPS/USPS for rates, but you really 
couldn''t abstract out the *entire* shipping module because that table 
keeps tracking of shipping methods, which are linked by ID to the 
orders table, etc, etc.  So, unless someone built their eCommerce app 
geared for your component, it might not integrate too well.  But then, 
I could be wrong.  As we go through design, I will try to keep an eye 
toward things that could be "component-ized."

I guess another thing for me is that in this case, I *want* an 
end-to-end app, but I want it to be customizable and/or easily 
extensible.  I don''t want to get to version 1.0 and then have to do two
more months of work to arrive at a usable eCommerce App.  But of 
course, that''s just me.

Maybe Qanah OSEE will be the "whole thing" and Qanah Shipping will be 
our shipping calculation module, Qanah Affiliate will be our affiliate 
admin module, etc.  That way, someone could take the whole thing and 
have all they need, or they could take parts, and add it to their 
eCommerce app.

Thanks for your feedback!

j----- k-----

-- 
Joshua J. Kugler -- Fairbanks, Alaska -- ICQ#:13706295
Every knee shall bow, and every tongue confess, in heaven, on earth, and 
under the earth, that Jesus Christ is LORD -- Count on it!

>When I look at the code size and complexity of some existing eCommerce 
>projects, I''m not sure "do a little, think a little, do a
little" will
>work in this case.  I''m *NOT* saying it''s a bad way to do
things (I
>mean, I often code like that), but I just don''t think it would work
>well in this case.  I think most of the design will be concentrated on 
>making sure we have the DB schema right, then once we get there, we can 
>"code a little, think a little, code a little."
>
>  
>
I understand. But I''m becoming more convinced that what is important is
working towards an architecture in which architecture is not important. 
What is really meant by architecture? It means making the right 
decisions the first time in those areas where change is expensive. But 
its expensive to make all the "right" decisions up front, and
ultimately
futile. Database change is generally considered expensive, but there are 
ways to make it less so. RoR provides a lot of them in the application 
tier. A good schema versioning/management system provides them in the 
data tier. I don''t want to say you shouldn''t spend time in
relational
design - thats important. But I''d focus first on your features, make 
sure those are complete for a solid first iteration and then your first 
cut of the data model will be very solid. By the time you''ve built a 
first iteration you''ll have realized you''ve already made
several
significant mistakes. If you''ve planned from the beginning for this
then
its not a problem - its part of the process.

On Sun, 2005-03-20 at 22:37 -0500, Bill Guindon wrote:
> Aside from the thousand things clients always ask for, here''s my
dream
> "core":
> 
>   a secure admin that''s fairly easy to use.
>   the ability to run local clients to manage some of the heavy
> lifting.
>   easy to customize look and feel - _very_ little logic in the html.
>   easy to add new features - some form of module/plugin system
>   variety of shipping methods
>   variety of payment methods
> 
> Those last two aren''t important early on, but if they
can''t be
> expanded easily (and fairly quickly), it''s probably doomed
long-term.
PLANET ARGON is currently working on this exact thing, basically taking
the guts out of pgCart ( http://www.pgcart.com/ ) (our current php
e-commerce app) and porting it to Rails. 

I hope that a few e-commerce apps pop up within the next few months so
that there is a nice variety of feature sets to give people choices. 

Cheers,

Robby

-- 
/***************************************

* Robby Russell | Owner.Developer.Geek
* PLANET ARGON  | www.planetargon.com
* Portland, OR  | robby-/Lcn8Y7Ot69QmPsQ1CNsNQ@public.gmane.org
* 503.351.4730  | blog.planetargon.com
* PHP, Ruby, and PostgreSQL Development
* http://www.robbyonrails.com/
****************************************/

Is this project going to be open source?

Robby Russell wrote:
>On Sun, 2005-03-20 at 22:37 -0500, Bill Guindon wrote:
>  
>
>>Aside from the thousand things clients always ask for, here''s
my dream
>>"core":
>>
>>  a secure admin that''s fairly easy to use.
>>  the ability to run local clients to manage some of the heavy
>>lifting.
>>  easy to customize look and feel - _very_ little logic in the html.
>>  easy to add new features - some form of module/plugin system
>>  variety of shipping methods
>>  variety of payment methods
>>
>>Those last two aren''t important early on, but if they
can''t be
>>expanded easily (and fairly quickly), it''s probably doomed
long-term.
>>    
>>
>
>PLANET ARGON is currently working on this exact thing, basically taking
>the guts out of pgCart ( http://www.pgcart.com/ ) (our current php
>e-commerce app) and porting it to Rails. 
>
>I hope that a few e-commerce apps pop up within the next few months so
>that there is a nice variety of feature sets to give people choices. 
>
>Cheers,
>
>Robby
>
>  
>

On Mar 21, 2005, at 8:28 AM, Robby Russell wrote:
> I hope that a few e-commerce apps pop up within the next few months so
> that there is a nice variety of feature sets to give people choices.
Well, people already have choices, between whatever crappy options 
already exist in the PHP/ASP/etc space of ecom apps.

Very few ''normal'' people care about the underlying technology,
so long
as it works. I know many ''normal'' people who _love_ PHP
because a large
variety of free and slightly-better-than-mediocre exists that uses it, 
and you can run it anywhere.

The appeal of a Rails ecom app, for non-developers, is that Rails makes 
it easier for developers to write _better_ apps in less time. I certain 
that people would love Basecamp or 43things just as much if they were 
written in PHP or Java or Perl, but those sites would have required a 
lot more time and effort to build in any other framework, and so the 
developer could concentrate on creating a kick-ass webapp. The love of 
Rails by non-developers comes out of their love for the site.

When a variety of outstanding free/open-source software exists for 
Ruby/Rails, and more hosts are capable of running RoR, then you will 
see normal people _love_ Rails the same way (or better) than they love 
PHP now.

That said,
I''ve been working on an ecom app, too, to meet my specific needs, which
is that of a small company that primarily sells its own stuff. This is 
my first stab, ever, at writing web software, and believe me when I say 
I couldn''t and wouldn''t be doing this without Rails.

I, and my business partner especially, would rather have gone with an 
easy-to-customize out-of-box F/OSS or even a cheap commercial package, 
but everything I looked at pretty much sucked for what we wanted to do 
with it. It seems that most of these e-com packages are designed either 
for small businesses that sell a small number of their own items, or 
''stores'' that sell a wider variety of stuff from a large
number of
manufacturers.

Bring into question a number of things I wanted to have for the site, 
that lie outside the domain of a traditional e-com app (rss feeds of 
news, better ways to interlink products, and a few other things 
specific to the type of stuff we sell), the ease of customization (why 
are so many foss/cheap ecom apps so fugly out-of-box?, and require so 
many hack-ish workarounds to get clean html/css?) and everything that''s
out there just stunk on toast.

Just some thoughts by someone who only took up the developer''s text 
editor because he was unhappy with his other options,

Matt (aka mly on #rubyonrails)

I think you have just created a feature list of a nice rails ecommerce app.
RSS feeds and nice xhtml and css integration. That is a good start.

I have created a cool package management  system for shipping based on class
rules that ties directly into UPS''s shipping rates API. Although it was
written in C# it could be ported over relatively easy. It can also work with
any Shipper API.

I think a base ecommerce system that solved A. End-user needs: like a plain
ole shopping cart, B. Business needs: Catalog, order tracking, shipping
tools, C. Developers needs: XHTML Template and css integration,
Extensibility using rails framework... Would be well ahead of the curve of
what is currently offered.

Just my 2cents

Scott Burton
http://spurton.blogspot.com
Spurton #rubyonrails IRC

-----Original Message-----
From: rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
[mailto:rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On
Behalf Of Matt Lyon
Sent: Monday, March 21, 2005 10:48 AM
To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
Subject: Re: [Rails] Call for Ideas/Developers: Qanah Open Source
EnterpriseeCommerce

On Mar 21, 2005, at 8:28 AM, Robby Russell wrote:
> I hope that a few e-commerce apps pop up within the next few months so 
> that there is a nice variety of feature sets to give people choices.
Well, people already have choices, between whatever crappy options already
exist in the PHP/ASP/etc space of ecom apps.

Very few ''normal'' people care about the underlying technology,
so long as it
works. I know many ''normal'' people who _love_ PHP because a
large variety of
free and slightly-better-than-mediocre exists that uses it, and you can run
it anywhere.

The appeal of a Rails ecom app, for non-developers, is that Rails makes it
easier for developers to write _better_ apps in less time. I certain that
people would love Basecamp or 43things just as much if they were written in
PHP or Java or Perl, but those sites would have required a lot more time and
effort to build in any other framework, and so the developer could
concentrate on creating a kick-ass webapp. The love of Rails by
non-developers comes out of their love for the site.

When a variety of outstanding free/open-source software exists for
Ruby/Rails, and more hosts are capable of running RoR, then you will see
normal people _love_ Rails the same way (or better) than they love PHP now.

That said,
I''ve been working on an ecom app, too, to meet my specific needs, which
is
that of a small company that primarily sells its own stuff. This is my first
stab, ever, at writing web software, and believe me when I say I
couldn''t
and wouldn''t be doing this without Rails.

I, and my business partner especially, would rather have gone with an
easy-to-customize out-of-box F/OSS or even a cheap commercial package, but
everything I looked at pretty much sucked for what we wanted to do with it.
It seems that most of these e-com packages are designed either for small
businesses that sell a small number of their own items, or
''stores'' that
sell a wider variety of stuff from a large number of manufacturers.

Bring into question a number of things I wanted to have for the site, that
lie outside the domain of a traditional e-com app (rss feeds of news, better
ways to interlink products, and a few other things specific to the type of
stuff we sell), the ease of customization (why are so many foss/cheap ecom
apps so fugly out-of-box?, and require so many hack-ish workarounds to get
clean html/css?) and everything that''s out there just stunk on toast.

Just some thoughts by someone who only took up the developer''s text
editor
because he was unhappy with his other options,

Matt (aka mly on #rubyonrails)

_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

On Monday 21 March 2005 09:48, Matt Lyon said something
like:
> That said,
> I''ve been working on an ecom app, too, to meet my specific needs,
> which is that of a small company that primarily sells its own stuff.
> This is my first stab, ever, at writing web software, and believe me
> when I say I couldn''t and wouldn''t be doing this without
Rails.
We''d love to have you on board to contribute ideas, and give your
input.
There are now mailing lists for Qanah.  See 
http://rubyforge.org/mail/?group_id=605
> I, and my business partner especially, would rather have gone with an
> easy-to-customize out-of-box F/OSS or even a cheap commercial
> package, but everything I looked at pretty much sucked for what we
> wanted to do with it. It seems that most of these e-com packages are
> designed either for small businesses that sell a small number of
> their own items, or ''stores'' that sell a wider variety of
stuff from
> a large number of manufacturers.
Yup, there doesn''t seem to be a good package out there that is both 
feature rich, and customizable.  Hopefully we can succeed in producing 
one that is both.

j----- k-----

-- 
Joshua J. Kugler -- Fairbanks, Alaska -- ICQ#:13706295
Every knee shall bow, and every tongue confess, in heaven, on earth, and 
under the earth, that Jesus Christ is LORD -- Count on it!

On Monday 21 March 2005 10:51, Scott Burton said something
like:
> I think you have just created a feature list of a nice rails
> ecommerce app. RSS feeds and nice xhtml and css integration. That is
> a good start.
Sure thing.  Qanah will certainly generate clean xhtml, and default 
implemenations will use CSS.  Of course, if someone hacks the templates 
and uses non-xhtml and non-css stuff, well, that''s up to them, but the 
support for it will certainly be there.
> I have created a cool package management  system for shipping based
> on class rules that ties directly into UPS''s shipping rates API.
> Although it was written in C# it could be ported over relatively
> easy. It can also work with any Shipper API.
We''d love to have you on board.  Join our developers list. :)

http://rubyforge.org/mail/?group_id=605
> I think a base ecommerce system that solved A. End-user needs: like a
> plain ole shopping cart, B. Business needs: Catalog, order tracking,
> shipping tools, C. Developers needs: XHTML Template and css
> integration, Extensibility using rails framework... Would be well
> ahead of the curve of what is currently offered.
That''ll go on the feature list. :)

j----- k-----

-- 
Joshua J. Kugler -- Fairbanks, Alaska -- ICQ#:13706295
Every knee shall bow, and every tongue confess, in heaven, on earth, and 
under the earth, that Jesus Christ is LORD -- Count on it!