DevSummit07:Exploring Opportunities for Collaborative Development

From DevSummit
Revision as of 23:22, 20 May 2015 by Vivian (talk | contribs) (1 revision imported)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Facilitated by Laura Quinn, Idealware and Jeremy Wallace, Fund for the City of New York

Collaborative development - where multiple organizations share the cost and responsibility for application development - holds obvious promise for the nonprofit sector, where budgets are often very limited and needs are overlapping. But there are relatively few major success stories in collaborative software development of nonprofit tools. Why is this? What can we do to foster more collaborative projects and make more of those that are started end up in success?

We'll brainstorm around this topic, addressing such themes as:

  • What are the key challenges of collaborative development?
  • What's the right scale on which to collaborate?
  • Who are the right players for a particular collaboration?
  • What success stories do we have as a sector? What are the elements that contributed to their success?
  • What collaborative projects have been tried but didn't succeed? What can we learn from them?
  • How can we foster an environment that makes collaborative software development easier?


Session notes

Agenda

  • Go round
  • Brainstorm of Troubles
  • Models
  • Success Stories
  • Take aways
  • Examples and links

Round up

Steven

  • Done some stuff, imagination is better than reality in experience

David G

  • CivicSpace, 20 collaborations
  • Conclusion: lots of promise, lots of problems

Mozilla guy / CollabNet

  • No non-profit experience per se
  • Collaboration managers

Mark from Brooklyn

  • How to involve people when there's lots of interest

Matt, Volunteermatch

  • No experience

Jason

  • Software being funded from a collaboration of

Kevin

  • Environmental software

David from Bratt Collective

  • Like the idea of a collaboration manager


Rob Miller, Open Planning Project

  • Software that allows people to collaborate
  • Experience with burning man, integrating lots of volunteers and rolling people into process already going on

Dan M

  • No relevant experience

Amanda

  • Non-profit Open Source Collaboration project
  • Particularly interested in community media
  • Excited about organizations with a particular need coming together to solve that need

Brainstorm of Troubles

  • Alignment of vision
    • When you bring people together it's not custom development and people need to coordinate and compromise
  • Alignment of resources is an issue (i.e. money)
    • Always a resource spectrum
    • A bunch of people put in $3000 still might not be enough given sustainability
  • Freeloading -- how to deal with people that didn't kick in money but would benefit
  • People who want to help but don't have the wherewithall
    • lack of experience and abilities
    • matching varying skillsets
  • When to bring other groups in when an initial group builds it
  • Managing clumps of developers who work in the same room, making everybody feel peer to a process
  • Work cultures and coding practices
  • These problems seem exactly the same as the issues when individuals collaborate
  • A lot of non-profits can't articulate what they do or don't have set up methodologies
  • Branding
  • Ownership and buy in -- when orgs demand more or less
  • Time zones, bandwidth issues, accessibility
  • Logistics can be worked out, but endemic problems are harder to work
  • Costs of collaboration are often invisible
    • David from CivicSpace -- 19 agencies -- initial cap was 18% of total budget for cost of collaboration, but the real percentage was 35%
    • Long term benefits might be there
    • When do you say that this model does not work or is not appropriate
  • Perception of higher risk
  • Inertia of all the collaborators -- harder to start over
  • Business and ownership models

Models

  • Consortiums
    • Ownership -- if 8 people pay for a product, getting them to agree to release it to future people
    • Be up front about the situation
    • Using a steering committee
  • Development
    • Can be costly to initial org, but
    • Single initiator -- meet my needs, but with limited scope, and an eye toward bringing others into the party -- always keep it public
    • Hosted services can initially get around licensing, but how to open source?
    • Many things are developed organically, how to open it? How can clients be more vocal about ownership.
    • Being up front about licensing
    • Ownership of data is also a major issue
  • Show and tell
    • There is a difference between a customer and a "developer"
    • Collaboration between customers is impossible
    • But collaboration between developers can be successful

Success stories

  • Katie -- Center for Arts Management and Technology
    • Using a distributed grants system
    • Single funder that was public-spirited, but adoption was handled by individual organizations
    • Chicago opera house developed a CRM and ticketing system that they are now licensing to many other large houses across the country
  • United Way
    • Using a corporate development model and spin it into a product and act as any vendor
  • Major success stories are all the successful open source projects
    • Plone
      • The coupling is pretty loose, and very successful
      • Started ad hoc, then grew an ecosystem
    • 501c's
      • Linux Foundation
      • Eclipse
  • Successful projects
    • All started with an initial push and then people glommed on
    • Subversion started from scratch with just collaborators and an idea
      • Could have done it commercial, but would have cost millions in marketing
      • Bringing in community minded core people
      • No specific commitments from core people
      • Funded less than total 20% of intellectual property
    • Look into non-software developments
      • Open Standards
      • Community foundations having a set of needs
    • Success of a collaboration depends a lot on shared vision
      • That's why seeds are powerful ways of organizing people
    • Successful projects always have a sense of being ONGOING

What are the Lessons

  • Depth of shared vision
    • By whole cloth trust
    • Seeding / initiation
  • Prepare for costs of collaboration and make them explicit -- 20-30% of project management
  • Plan for generalization and open-ness
  • Transparency of process and ownership
  • Having conversations that can be DOCUMENTED -- even in same room, conversations over email
  • Concious of issues of branding (as a proxy for ownership)
  • Two successful models
    • Seed and snowball method
    • Initiator funder
  • Successful projects always have a sense of being ONGOING
  • High risk (money) / high reward (social -- net economic)

Examples & links

  • Martist
  • Producingoss.com -- Download it for free -- how to build a vibrant, mutli-party process