Doccomm Sprint: Ecommerce (GetPaid) Report

(compiled and edited by Chris Johnson, ifPeople)

Happy Birthday, GetPaid!

Live from e, the 29th of June 2007, born was one GetPaid, child of Plone and Community. The excited parents were gathered around a room accented with blue, red, yellow, and green chairs. They shared in the joy of seeing their combined contributions resulted in something amazing: Plone and Community had just given birth to a commerce system!

Time of birth: doccomm Plone Sprint, Day 5, Summer
Place of birth: e <photo>, GooglePlex, Mountain View, CA
Given name: GetPaid
Family name: Plone
Weight at birth: 1.5 Mb
Delivery method: buildout

GetPaid’s approach to ecommerce is to be (a) useful out of the box and (b) flexible (find more at www.plonegetpaid.com). This approach reflects the value that Plone itself provides: a full feature set that can easily be deployed complemented by a flexible system that can be customized and extended for particular use cases. The use cases targeted for the current release included basic donation processing and simple stores.

GetPaid provides the tools needed to easily integrate those features into a site: a cart, checkout, workflow, payment processor integration, administrative screens, and end user interface. At the DocComm sprint, held at Google June 25-29, over a dozen people contributed to the features that now make up GetPaid. In addition to the front-end features, the sprinters created a testing framework and created an entire set of test scripts to ensure quality now and in the future.
<!– D([“mb”,”u003cbr />Led by Kapil Thengavelu, core Plone committer and author of many products for Plone and Zope, the sprinters worked together pair programming towards the goal of the week: getting paid! The group generated ideas and implemented side by side; they also created, tracked and closed issues (with the help of a remote sprinter from Argentina) on the project’s Google Code are: u003ca onclicku003d”return top.js.OpenExtLink(window,event,this)” hrefu003d”http://code.google.com/p/getpaid” targetu003d_blank>code.google.com/p/getpaidu003c/a> . Each day twenty people would gather in our instant messaging channel on IRC (#getpaid) to follow what was going on, rallying the sprinters, and ask questions. The sprinters and organizers – all volunteers – were hosted and fed by Google, fueled by Guayaki yerba mate, and supported by several sponsors from the community who made the event possible.u003cbr />u003cbr />Among the accomplishments of the week for GetPaid:u003cbr />- an elegant framework thanks to Kapil’s architectingu003cbr />- Integrate three payment processors (u003ca onclicku003d”return top.js.OpenExtLink(window,event,this)” hrefu003d”http://Authorize.net” targetu003d_blank>Authorize.netu003c/a>, GoogleCheckout, PayPal)u003cbr />- Create a shopping cart and means of adding items to itu003cbr />- Refine the means designating content as &quot;payable&quot;u003cbr />- Provide a working delivery method for the product (via buildout/ploneout) for technical users to quickly get set upu003cbr />- Integrate user information collection and registration into the checkout processu003cbr />- Order management interface to track both site-wide transactions (and status) as well as to provide end users a view of their own transactionsu003cbr />- Shipping functionality via integration of UPSu003cbr />- Tests! Unit, doc, and functional testsu003cbr />u003cbr />The future looks bright for this newborn! GetPaid still has a lot of work to be a complete system, but is near the point of its first release. Next on the horizon is:u003cbr />- A remote sprint (continuing energy of the sprint at Google)u003cbr />- Documentation of API and roadmapu003cbr />”,1] ); //–>
Led by Kapil Thengavelu, core Plone committer and author of many products for Plone and Zope, the sprinters worked together pair programming towards the goal of the week: getting paid! The group generated ideas and implemented side by side; they also created, tracked and closed issues (with the help of a remote sprinter from Argentina) on the project’s Google Code are: code.google.com/p/getpaid . Each day twenty people would gather in our instant messaging channel on IRC (#getpaid) to follow what was going on, rallying the sprinters, and ask questions. The sprinters and organizers – all volunteers – were hosted and fed by Google, fueled by Guayaki yerba mate, and supported by several sponsors from the community who made the event possible.

Among the accomplishments of the week for GetPaid:
– an elegant framework thanks to Kapil’s architecting
– Integrate three payment processors (Authorize.net, GoogleCheckout, PayPal)
– Create a shopping cart and means of adding items to it
– Refine the means designating content as “payable”
– Provide a working delivery method for the product (via buildout/ploneout) for technical users to quickly get set up
– Integrate user information collection and registration into the checkout process
– Order management interface to track both site-wide transactions (and status) as well as to provide end users a view of their own transactions
– Shipping functionality via integration of UPS
– Tests! Unit, doc, and functional tests

The future looks bright for this newborn! GetPaid still has a lot of work to be a complete system, but is near the point of its first release. Next on the horizon is:
– A remote sprint (continuing energy of the sprint at Google)
– Documentation of API and roadmap
<!– D([“mb”,”- Set up demo site with latest version of productsu003cbr />- Clean up integration of workflow and payment processorsu003cbr />- Organize additional developers and funding to build out for specific use cases of &quot;premium content&quot;, &quot;pay to submit&quot;, and advanced store features.u003cbr />u003cbr />The Recipe: Beans and Riceu003cbr />u003cbr />For those who are interested in more technical information…check the directory where your buildout ran and meet getpaid.core and PloneGetPaid. They are designed to work together a system that, architecturally speaking ties us to CMF, but that is built in Zope 3 (and then bridged back to run in Zope 2 by Five). The product getpaid.core is a pure Zope product, while PloneGetPaid provides Plone integration and configuration.u003cbr />u003cbr />The approach to integrating with a site is to provide the ability to make any content in a Plone site &quot;payable&quot; by providing a &quot;marker interface&quot;. This trick, inspired by the Plone4Artists project, allows GetPaid to add to the site without actually changing the existing content. The system is built using Zope 3 technologies for adapters so that it can easily be adapted for custom storage of data (for example, using relational database for the store). This opens possibilities for integration with other enterprise systems, advanced reporting, and even making multiple stores per site! Check out u003ca onclicku003d”return top.js.OpenExtLink(window,event,this)” hrefu003d”http://code.google.com/p/getpaid” targetu003d_blank>code.google.com/p/getpaidu003c/a> for more on the product and its use.u003cbr />u003cbr />Where get paid goes from now?u003cbr />u003cbr />&lt;geek&gt;Eggs Don’t Care!&lt;/geek&gt;u003cbr />u003cbr />The future of GetPaid largely depends on the adaptation and extension of the system by the community itself. The architecture and pending work on documentation and roadmap will provide a foundation for contributions. The sprint was an important step in getting new people into the code and working with the product. What’s next? Well, we will have to see – maybe you want to be a part of that! Visit u003ca onclicku003d”return top.js.OpenExtLink(window,event,this)” hrefu003d”http://www.plonegetpaid.com” targetu003d_blank>www.plonegetpaid.comu003c/a> and get connected!u003c/div>”,0] ); //–>- Set up demo site with latest version of products
– Clean up integration of workflow and payment processors
– Organize additional developers and funding to build out for specific use cases of “premium content”, “pay to submit”, and advanced store features.

The Recipe: Beans and Rice

For those who are interested in more technical information…check the directory where your buildout ran and meet getpaid.core and PloneGetPaid. They are designed to work together a system that, architecturally speaking ties us to CMF, but that is built in Zope 3 (and then bridged back to run in Zope 2 by Five). The product getpaid.core is a pure Zope product, while PloneGetPaid provides Plone integration and configuration.

The approach to integrating with a site is to provide the ability to make any content in a Plone site “payable” by providing a “marker interface”. This trick, inspired by the Plone4Artists project, allows GetPaid to add to the site without actually changing the existing content. The system is built using Zope 3 technologies for adapters so that it can easily be adapted for custom storage of data (for example, using relational database for the store). This opens possibilities for integration with other enterprise systems, advanced reporting, and even making multiple stores per site! Check out code.google.com/p/getpaid for more on the product and its use.

Where get paid goes from now?

<geek>Eggs Don’t Care!</geek>

The future of GetPaid largely depends on the adaptation and extension of the system by the community itself. The architecture and pending work on documentation and roadmap will provide a foundation for contributions. The sprint was an important step in getting new people into the code and working with the product. What’s next? Well, we will have to see – maybe you want to be a part of that! Visit www.plonegetpaid.com and get connected!

Doccomm Sprint – Day 4

It was a quiet day on the ecommerce side today… payment processors, administrative screens and viewlets were being hacked away at while documentation for GetPaid was starting to develop.

The highlight of the day was a walk from our sprinting headquarters to the main GooglePlex for lunch with Alexander Limi.. Weather was gorgeous ..
See new pictures at http://www.flickr.com (tags: doccomm sprint plone)

Documentation team announced.. “this half of the wall is done! woohooo” (refer back to the card sorting posts over the last day or two).

All in all the day was productive… as a sponsor, an organizer and participant.. I have to say.. Go Plone! you rock…

Doccom Sprint – Day 1 recap

Getting ready for Day 2 of the Doccom Sprint at Google in Mountain View and sitting here reflecting on our first day of sprinting.Google was gracious in providing us a space to sprint. The weather here has been gorgeous as usual. California in June is the best place to be.. (I’m prejudiced of course.. ). The vegetarian sandwich at lunchtime was sublime, as were the homemade chocolate chip cookies.

We started the day with a round of introductions and then split up into two groups.. “GetPaid” and “The Doc Side” (a la Erik Rose’s “come on over to the doc side”)

The documentation team created a circle of chairs and leaned in to discuss some hardcore doc issues as the “GetPaid” team assessed the tasks needing to be done.. and who wanted to tackle what.. After a bit they broke out and started doing what they do best..

In the end we had a group of five or so guys working on unit tests (Dave Fowler (GSoC student), Eric Steele, David Brenneman, Brian Gershon, David Siedband (siebo).

Bill Schindler (bitranch) and Stephen Hindle (mech422) will be working on thecheckout wizard with Kapil T (hazmat)

Chris Johnson (cjj), Veda (vedawns) and myself are working on the UI aspect of the GetPaid system.

I had some “battery” issues with my camera but I was able to grab a few pictures

IMG_0356

and one movie at the Welcome Dinner.. Francis Ford Coppola I am not..

http://video.google.com/videouploadfinished?docid=3322331461815857289&cid=788f68e9d249e39b

Pliorities – Plone Priorities

When Plone was merely an infant (oh so many years ago) we were so proud of all it could accomplish. Launch Plone and you launched a community website with membership and a cool wysiwyg editor for keeping content up-to-date (still love ya Epoz). You could even create your document months ahead of time and have it scheduled to show up on the site when you wanted it to.. and then have it “expire” when you didn’t need the document visible anymore.

Ecommerce was nonexistent (unless you hand-rolled something with Python). Documentation back then was as sparse as any other Open Source project at the time (it was a given). We didn’t care.. we learned how to use the system through trial and error.. and we created our own documentation through mailing lists and spur-of-the-moment tutorials popping up on websites and weblogs (blogs).

We didn’t really need ecommerce. Most of our sites were brochureware, non-profit community sites and corporate intranets (I know I built quite a few Plone based corporate intranets).

The needs of the average online proprietor has changed. He wants to manage his entire business through his web site. He wants security and workflow easy-to-use browser based wysiwyg editors and he wants to have the ability to take orders online. Whether that’s orders for a product (digital or otherwise) or provision of a service the business owner provides he needs to know that if he wanted to sell something online, he could.

There has been a lot of discussion over that last few years of potential ecommerce applications but many attempts have fallen by the wayside due to lack of funding and interest. Let me be the first to say I’m one of the guilty ones, I jump up and down and complain about our lack of ecommerce functionality and yet.. here we sit a couple years later with limited options.

Integrators need to be able to tell potential converts that ecommerce implementation is a priority. Please take note I said A priority.. doesn’t have to be number one..but it really needs to be brought forward as a major concern because as a developer/designer who has worked on other CMS’s.. it seems counterproductive to act as if lack of ecommerce is not affecting adoption of this project in some larger deployments.

Ecommerce implementation matters and I propose we plan a week long ecommerce/documentation sprint and make strides towards creating the most secure, most UI friendly and highest quality ecommerce system out there.. (and get our documenters together to keep the fire stoked in improving our documentation story)

Let’s not let this spark fizzle out..