Open Source projects are normally developer-driven and tend to lack ways for non-developers to make meaningful contributions. GetPaid, an ecommerce framework for Plone, was organized with a collaborative design process known as "social sourcing". This talk provides an update on the community organizing, fundraising, and development of GetPaid. Updated and slightly shorter than the Naples version of the talk.
Social Sourcing as a Collaborative Design Process: Story of GetPaid (Plone Symposium NOLA 2008)
1. Social Sourcing:
The story of GetPaid, ideas for
organizing software projects
Christopher Johnson
ifPeople | www.ifpeople.net
Plone Symposium 2008
New Orleans, LA
June 3, 2008
2. Outline
● Who, What, Why?
● What is Social Sourcing?
● Why is it important for Free Software?
● The Story of GetPaid & Social Sourcing
● Implications for Plone
4. What is GetPaid?
● eCommerce in Plone built on Zope3
– credit card processing
– order management
– shipping, fulfillment, inventory management
– 2 releases; 10,600+ lines of code
● Community
– 105 members on mailing list
– 34 contributors (15+ in 2008)
5. Why am I here?
● Voice for non-developers!
● Make Plone better: software, community,
marketing
● Get feedback and ideas (time for another
round of social sourcing for GetPaid!)
6. What is Social Sourcing?
Def 1: Open Source Software for Civil
Society Organizations (ie NGO/non-
profit)
7. What is Social Sourcing?
Def. 2: A project organizing approach
that gets diverse stakeholders to
participate to the software making
process, focusing on the value of
product.
8. Similar Process: Charrette
● Charrettes bring together people from
multiple perspectives at the design stage for
an intense collaboration.
– Root: French for “cart”
– More than just “crunch time”, it is also core to an
Integrated Design Process
9. Charrette
● Key: collaborative decision making in design
10. Data Center Charrette
● People from hardware, software, security,
energy, real estate and more
– Resulting design:
● 89% energy use reduction
● Equivalent computing power
● Increased reliability
– See rmi.org
11. Why is this relevant?
● Open Source Software projects are
driven by developers
==> Many projects naturally use agile
processes (sprints, pairing)
==> Developers, like architects, often
reticent to get “human” input
==> Difficult for non-developers to
participate in shaping outcome
12. Why is this relevant?
● Diverse perspectives enrich the product
==> Expectations from client clarified
upfront
==> Opportunities and constraints explored
fully
13. Why is this relevant?
● The quality of the process determines
the quality of the outcome
==> How you get it done determines
what you get done
==> Position product to have a strong
community
14. ● Plone:
– Flexible + very useful out of the box
● 2006 PloneConf ecommerce BOF
– Conclusion: Need state of the art payment
processing framework
15. ● To action! But...
– /me was new to community, not a developer, and
with no ecommerce software experience...but
loves problem solving!
– “Social sourcing” helped to be transparent,
inclusive, and improve the product.
● <DOCTYPE FREESOFTWARE PUBLIC...>
<div id=”entrepreneur”>
...don't be afraid!
16. Social Source v1.0 Alpha
●
– Study the market (benchmark)
– Put together a compelling plan
– Recruit the right people
– Engage a wide base in refining requirements
– Ask for money
– Celebrate successes
– Sustain it: fun, organization, motivation
– Regroup, review, and restart...
17. ● Step 1: Get oriented
– What is already out there?
– What do we know about those things?
– Why do we need something else?
● Result:
– Reference on Plone Commerce:
http://plonegetpaid.com/why/plone-commerce-backgro
– Need for the product:
http://plonegetpaid.com/why/need-for-this-product
18. ● Step 2: Make a plan
– What should we do?
– How can we do it?
– Who does it benefit and how?
– Make it pretty to look at...
● Results:
– Goal for GetPaid M1: Donation handling
– Sponsorship plan:
www.plonegetpaid.com/sponsor
19.
20. ● Step 3: Recruit leaders and participants
– The project needs a qualified “sheperd”
– Variety of expertise are needed
● Result:
– Lead architect: Kapil Thangavelu
– Organizer: Christopher Johnson
– NGO Liason: Jon Stahl
– Several more have stepped up!
– Developers and UI: various (see Credits)
21.
22.
23. ● Step 4: Refine the requirements
(participative)
– Get input of users, developers, user interface
experts, consultants/supporters
● Results:
– Architecture outline
– User stories
– Estimates and plan
24. ● Step 5: Ask for money!
– If you don't ask, you won't get it...
– Tips for asking:
● Connect needs with value
● Be transparent
● Be patient and persistent
● Result:
– Raised over US$12,000 for first release
– Contributions page
25. ● Step 5: Don't forget...
– Be accountable and transparent
26. ● Step 6: Celebrate successes!
– Reward and recognize people and their
contributions
● Deployments, releases, fixes
– Communication is important!
● Results:
– Blog, mailing list
– Celebrations...
27.
28. ● Ongoing:
– Make it fun!
– Keep it organized!
– Keep people motivated!
● Results:
– 4 Sprints (UNC, Google, Argentina, Naples)
– Google Code (wiki, issues, code)
– Blog, mailing lists, channel (#getpaid)
29. Social Source v1.0 Alpha
●
– Study the market (benchmark)
– Put together a compelling plan
– Recruit the right people
– Engage a wide base in refining requirements
– Ask for money
– Celebrate successes
– Sustain it: fun, organization, motivation
– Regroup, review, and restart...
30. What next?
● Time for a new round of social sourcing for
GetPaid!
● Encourage flow back into product of
customizations and extensions
● Capture feedback from users, developers to
improve project
● Need technical leaders in various areas
31. Implications for Plone?
● Plone is great!
● Lots of work heading into the future...but
towards what?
– Perhaps Plone could benefit from process
improvements that would:
● Clarify direction and identity
● Provide more inclusive design process
● Improve the overall product
● Strengthen Plone community
32. Plone Creation Process
● Overall vision:
– Open process associated with vision?
● How can users be more involved?
– Place to document it?
● Features:
– PLIPs process determines features...but you
have to be a “core developer” to make a PLIP
● Something before PLIPs but more specific than
vision?
● Way to involve non-developers?
