View source for Seattle:Healthy and Sustainable Free and Open Source Communities

=Session Notes=

==Zack Rosen's story==

Started CivicSpace as part of the Dean campaign in 2004.  Spawned a nonprofit.  ~150 people make a living around the Drupal platform.  ~350 developers, etc.

==How the Drupal community works==

* A "core" of about 20 core platform developers -- only about half are doing this full time.

* Most development activity happens around non-core "contributed modules"  Est. 300.

* ~155,000 live installs of Drupal.

* Less than 5-10% of those users are at all active in the community.

* Consultant community -- people who are selling consulting & services around the platform.

Lots of volunteer activity.

Big challenge: plugging people into non-development roles.

For a long time Drupal was a "sleeper" project, that took a long time to grow beyond its core team.  All of the growth has been outside the core.

Core developers mostly communicate via mailing lists.  Users mostly use drupal.org forums.  Challenge is keeping the worlds separate when they need to be, and connected when they need to be.  Not enough labor available to tap the userbase and get them to contribute.

"Only very recently did Drupal get any decent documentation."  Took a heroic effort by Kieran Lal to kickstart the process.  Lots of leadership in the core, less leadership in the outer circles.

Nobody professionally doing support.  

==Discussion==

Question: Does Drupal have a model for sponsored development?  
Zack: sort, but it's "kind of broken" -- attitude right now is "talk is silver, code is gold."  Result is a lots of non-transparent development work.  Collaboration is in back channels.

Zack: two proven models for sponsoring development work

1) hire a developer
2) put bounties on code

High failure rate of people putting money into the platform and getting results out.

Question (PhilKlein): How do you cultivate passion in the community?
Zack: people scratch their own itches a lot.  Often minimal contribution back to the community.  But then someone makes super-heroic effort to create a great, shareable solution.

Question (AllenPoole): how to allow people to scratch itches while maintaining quality? 
Discussion
* SamMoscheck: the speed at which the community moves is very rapid. Hard to keep a grip on all the core & contributed modules.  Takes a lot of work to keep up with what's already been done.  This limits consultants' ability to contribute.  Tension between doing really cheap projects, and building in enough padding to contribute to the open-source community.
* MattBlair: don't overlook the value of user experiences. Aggregate and share your user experiences.  Build it into proposals.
* SarmeeshaReedy: build out cost analyses that show cost savings from open-source and funnel some of those savings into the open-source project.
* ZackRosen: things break down around missed expectations.  Trying to build optimal process for doing paid work, and teach it to vendors and through to customers.  Goal: avoid the costs of forking code. Scary to communicate this to customers.

Aaron: importance of avoiding "hit by a bus" factor -- critical dependence on an in-house developer.


JamesDailey: I'm facing a challenge where the developers aren't the ones feeling the problem.  What kinds of roles & responsibilities work?
Zack: lots of good projects out there.  Lots of failed products.  We understand how to collaborate around code, but not on the overall development process.  Handoff to moneyed interests is starting to happen for Drupal