Rio Ceballos, Córdoba, Argentina: Born was one GetPaid, child of Plone and Community. The excited parents shared in the joy of seeing their combined contributions resulted in something amazing: Plone and Community had just given birth to a commerce system! The first breath...er...transaction was processed today by authorize.net!

Certificate of Birth: GetPaid de Plone

Time of birth: FairSource retreat day 4, 5:55pm
Place of birth: Rio Ceballos, Córdoba, Argentina
Given name: GetPaid
Family name: Plone
Weight at birth: 394 Kb
Delivery method: tarball

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. 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.

That work was advanced by a dozen FairSource developers in Argentina working alongside the product's lead architect, Kapil Thangavelu. An issue that we were reminded of in the Google sprint when Ofer dropped in to the channel was that we need to have the product internationalized, which led to a sprint! Sprinting began at the Jornadas Regionales de Software Libre (Regional Free Software Conference) with a day of i18n sprinting, which then turned into a group effort to work towards the release at the FairSource retreat organized by ifPeople. After months of work, the first processed transaction went through today (see the message from authorize.net)

Led by Kapil Thangavelu (hazmat), core Plone developer, founder of ObjectRealms, 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 in Italy) 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.

Among the accomplishments of the GetPaid contributors:

• Shape the scope of the Red Ochre release around the donation use case.
  
• an elegant Zope 3 based framework.
  
• Integrate a payment processors (Authorize.net, and others in progress)
• Create a shopping cart and means of adding items to it
• Internationalization of the Plone and Zope products
  
• Provide a deployment mechanism 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
• 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 release!
  
• Documentation of API and roadmap
• Set up demo site with latest version of products (dev.plonegetpaid.com)
  
• Clean up integration of workflow and payment processors
• Make backups possible
  
• Organize additional developers and funding to build out for specific use cases of "premium content", "pay to submit", and advanced store features.
• Build a product catalog, document and provide an interface for categories
  
• Make the UI sexy with AJAX :)
• Add lots more usability improvements
  

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 part of the elegance of the system's design: getpaid.core is a pure Zope product, while PloneGetPaid provides Plone integration and configuration. (For those unfamiliar with the latest in Zope/Plone, the two products are designed to work together as 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 approach to integrating commerce with a site is to be able 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 interfaces and information to the site without actually changing the existing content (thanks, Zope 3!). The system is built using Zope 3 technologies for interfaces, views, viewlets, and adapters. Particularly noteable about the adapters is that we have been working to build in storage flexibility from the beginning. GetPaid can thus easily be adapted for custom storage of data (especially 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.

The main goal of the first release is to satisfy the needs for easy donation processing in a Plone site. Content marked as a donation gets a "donate" link that takes the user through a checkout process. Any piece of content can be turned into a donation (ie event, news item, page...) and be given a price. Additional functionality is provided for "buyable" content, ie things that would be added to a shopping cart. This allows for simple stores to be easily created in the site.

Amazing Support

As the organizer and primary cheerleader for the project, I have been amazed at the support that the community has given to us in this process. In particular, the set of visionary sponsors who supported the development and sprint activities over the last five months. This also couldn't have been done without the ongoing sprint-spirit, ingenuity, and attention of Kapil and the support in organizing from Jon Stahl. Thanks to all the contributors of the project and for the support of Tirza in helping me take the reins on "social sourcing" a project (see more on that in Italy ;).

Where GetPaid goes from here

<geek>Eggs Don't Care!</geek> Um...sorry for that outbreak. This whole sprint community thing just gets me excited :)

At the Google sprint, we had an important revelation, inspired by Steve's (Mech422) question: line items in an order need to be workflowed independently. Take the case where you order 1 case of Empower Mint, 2 gourds, a box of Divine chocolates from our hypothetical Fair Trade store. If the mint and gourds are in stock but the chocolate isn't (maybe someone snacking in stock room!?), then we want to be able to fulfill the order that we can. So we will charge for and ship out the products we have, and leave the chocolate pending till we get more in. Since these are both part of a single order, the order itself becomes a container of line items, each of which can be workflow-ed through the system.

The result of this was that Kapil refactored much of the system (since the end of the Google sprint) to make the entire system workflow-driven. The goals is to ship a system with a workflow that can be modified for custom business processes or integrations (these changes went beyond what the hurry.workflow offered, and are also being made available upstream). This has implied updates to the admin interface as well.

Given the changing understanding of the product, we are reworking the milestones and release versions. The "Red Ochre" release, our alpha, will be out shortly and be v0.3. That will be followed by v0.6 and v0.9 (and then 1.0!). After Red Ochre is out, it will be much easier for developers and others to contribute to the product.

But when it comes down to it...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 sprints were important steps in building community around the product and getting new people into the code and working with the product. Already there are companies using (and modifying) GetPaid. 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! Some things that we are looking into:

• Extensions to make the product ready for specific use cases: Premium Content, Membership organizations, pay-to-submit content, web delivery of content, and more
• Integration with other systems (Salesforce.com, accounting)
• ???
  

Most likely we will reorganize the "social source" process of building pieces of the project, this time focused on new use cases.

Thanks again to all the supporters of this project, both before, during and after this sprint! We couldn't do it without you!