Hi Scott,
I just wanted to take a moment to comment on your experience with
Piggybak. It sounds like you already realize the challenges associated with
a fixed cost project, as well as the need to allow the client to assume
risks involved in using open source tools.
The refactoring going on in Piggybak at the time of your project was done
to allow for more simple order calculations and provide the opportunity for
extensions to more easily integrate into the order cost calculations, which
at times has been challenging in other ecommerce platforms. End Point is
extremely familiar with Spree, because Spree actually became Spree (from
Rails Cart) while its creator was employed at End Point and we are involved
in many Spree projects. We are also familiar with ror_ecommerce and have
evaluated it for use on several projects. I personally feel that each
ecommerce platform has pros and cons and while Spree is mature when
compared to Piggybak, that maturity also comes with quite a bit of
technical debt, as well as numerous refactors that have not always been
backwards compatible.
We're sorry that Piggybak did not work out under these specific project
circumstances and I hope that we do not miss the opportunity to collaborate
in the future to improve our open source tools. Piggybak development
continues and we are making strong progress in building out an ecommerce
platform that is both minimal and modular enough to leverage the developed
strengths of the exiting Ruby codebase. If you, or anyone on this list
would like to know more or try things out, please don't hesitate to contact
me.
Thanks,
Steph
On Wednesday, February 27, 2013 7:51:17 PM UTC-5, Scott Olmsted wrote:
>
> David,
>
> Thanks for your input. My client's needs were really pretty simple: a back
> end to enter items to sell and report on what's been sold, a shopping cart,
> and integration with Stripe.js, which they were keen on ("credit card
> numbers never hit your server!"). They wanted this as part of a perhaps six
> to ten page site with some CMS capability to change a few things. Spree
> just seemed to be overkill, not flexible, and not a good fit. ror-ecommerce
> seemed rather risky, with one person maintaining it. Only option left
> seemed to be to write it from scratch.
>
> Then I stumbled upon Piggybak. Created by a group with lots of e-commerce
> and Spree experience as a gem. Tying into RailsAdmin for the back end, it
> looked perfect for my limited needs. It is an add-on to an existing site,
> not a complete site. It had features like supporting varieties of the same
> product, such as different quantities, and they were willing (for some $ of
> course) to add a Stripe module. It looked mature enough to depend on. I got
> a signature on a contract and a deposit and built the site and some of the
> e-commerce part.
>
> Then, disaster. Immediately, the creators of Piggybak embarked on a major
> refactoring, and based the new Stripe module on this. The new version was
> released with many, many bugs. I spent some client money debugging it, and
> a bunch of uncompensated time as well. Would-be freelancers, take note.
> Your contract should make mention of factors beyond your control, as mine
> does, and make clear that all such risks are assumed by the client. I just
> wanted to salvage the project even if it cost me.
>
> Could I have asked them to base the Stripe module on the old version of
> Piggybak? Only if they had given me that option. And I wouldn't have taken
> it. Who wants to be tied to an older version of a gem?
>
> We finally killed most of the bugs, but what killed the project was of
> course the budget. The client wanted guarantees I could finish within $X
> because they had an overall budget in mind that they didn't communicate to
> me earlier. I figured it would take $2X at least, and possible more, since
> I work strictly on a time and materials basis.
>
> Piggybak is a good idea and I hope they succeed with it, but it failed for
> this project.
>
> Scott
>
>
> On Wednesday, February 27, 2013 12:36:56 PM UTC-8, David Henner wrote:
>>
>> Scott,
>>
>> That article is very old so take it with a grain of salt now. I wrote it
>> so... All being said, Spree appears to have addressed many of the issues.
>> I still have issues with their solution but I also think it works
>> depending on what you want to do.
>>
>> I would not expect to customize spree and expect to upgrade spree though.
>> I've been on a couple spree projects and most eventually start tearing out
>> spree's core if they become really big. Everything being said Spree is
>> MUCH better than starting a project from scratch. The number of mistakes
>> that can be made are numerous.
>>
>> At the end of the day you should give spree and ror_ecommerce a test
>> drive before committing to either solution.
>>
>> I assume your project is already being built. I'd love to hear how
>> things are progressing.
>>
>> Dave
>>
>> On Sunday, August 12, 2012 10:03:21 PM UTC-7, Scott Olmsted wrote:
>>>
>>> Anyone used Spree or ror_ecommerce for an e-commerce site? My client
>>> wants to sell biological samples by credit card or purchase order, post a
>>> few pdfs and other files on the page for each product, and perhaps export a
>>> file to Quickbooks, including taxable status. Will customizing Spree take
>>> longer than creating from scratch? What about using ror_ecommerce? Any
>>> validity to the author's claims and criticisms of Spree? (
>>> http://ror-e.com/posts/1)
>>>
>>> Thanks, Scott
>>>
>>
--
--
SD Ruby mailing list
[email protected]
http://groups.google.com/group/sdruby
---
You received this message because you are subscribed to the Google Groups "SD
Ruby" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
