Difference between revisions of "NotesOSCommunity"

Latest revision as of 23:23, 18 December 2015

Open Source Communities - How they work and what makes a good one?

Introductions

Seventeen participants, with a variety of backgrounds. More than half have contributed to some open source contributors.

Facilitator -

Drupal Community Example

Went through the entire life cycle working on something that was a hobby of a group working on "scratching their own itch" to a stage with lots of institutional. Was a hobby project in open source space until picked up with specific user model as content management.

Started Civic Base (plug in to Drupal) - one of only two Drupal companies. Then explosion of companies.

Now about a 150 people making a living off of this software. That made possible by a whole bunch of other people.

350 active developers thousands of people logging into the project

Different strata of people

• 20 or so people who make up the "Drupal mafia", about half of which make a living on this. Core group.

• Contributor model - handle other aspects. 300+ modules.

300 people.

• 155,000 dropple sites Drupal

• One guy is the drupal support person - free advice. Without being a developer. Critical role in community - kind of the indespensible guy. But not the developer.

Broader Lessons and Challenges

Challenge now

• Challenge is how to get other people to be the support system.

• What has stayed the same - the core group of 20 people.

• Lesson: having the right about of segmentation. Setting up intermediate systems.

• Currently, not enough granularity - only until recently was their enough documentation. Typical issue - module owners didn't care about documentation.

• Now getting users involved in the documentation process - but this took leadership.

• Since there is no centralized paid support, each consultant writes their own "customer documentation" but no way to bring that back to the project. This is a problem, what is broken.

Community ethos: Talk is silver, contribution is gold.

• There was a public issue queue - but most collaboration happened via email or IRChat

• $15 million now going into Drupal community. Some should be going to the developers, but not much.

• Two proven models for contributors - hire the developer who knows the domain or provide bounties for "specific piece of code". Otherwise high failure rate.

• If you really want to get contributions back, you need to provide the right incentives. Success of code bounty.

The limitations of 'Scratch your own itch' model

Still a big issue in open source. Idiosyncratic itches solved in idosyncratic ways.

• Example of a request that lead to code written casually, that broke a bunch of features, and stayed broken.

Goes to question of how to create the business model - enabling more pathways for feedback and centralized funding for development. e.g. I want "this part of the non-profit project" to be contributed back to Open Source community. Still a hard argument to make to non-profits.

One consultant mentioned doing "total cost of ownership" analysis for open source software vs other proprietary system, sending part of difference back to development effort. Assumed obligation to contribute to community.

...and supporting the core community Biggest barrier is market of customers who assume that investment is one-time. Need to have buy-in to concept of community participant. Need to avoid code forks. Communicate that.

Vendors in Drupal world recognize need for community support.

Limitations of hiring a bunch of coders to do some module. Created a problem for long term. The Civics module is stable but relies on maintainance by 7 coders.

• Can non-infrastructure projects work in the open source model?
  • wordPress (million installs) - awesome product , dozen dev.
  • firefox -
  • dramatically high failure rate for products, but lower for projects.

• Missing in Open Source model
  • Usability experts
  • Business analysis
  • Product management

what you find in the Fortune 500 software companies.

Examples of monied interests coming along to solve these missing things in the open source model

• Firefox - monied interests filled the gap. (mozilla investments)
• Linux - support structure that came along later to cover the last 10% that was needed. (e.g. IBM)
• Drupal - starting to happen now or in near future.

ACS example

• open sourced all of their code. --> OpenACS
• Underpinning of the model went away when company went bankrupt.

Different risks when a funded developer group goes away vs. an organic project that graduates to "monied interests" that fill the last 10% gap.

Challenge faced by several in groupHow to create a sustainable business model as a consultant, but balancing that with need to support the community, for long term sustainable source of software.

Moodle example

Online courseware softwares. Online learning software. Grad student hobby, more installations for this purpose than large "industry standard" software. They've captured most of the market but not recognized as such. (9500 deployments). Then a group of Universities got together and paid $7 million to create new "open source software" (siccay -spelling) - only a few dozen installations.

Three things to tell the larger group

1. Key motivation in any successful project is Scratch your own itch - recognizing this and the gap this creates for "last 10%" (usability experts, support documentation, product marketing) and the need to solve this in your community.
2. Open process and transparency for the project (e.g. process for code submissions and feature requests)
   • you publish the standard and follow them.
   • Importance of roles and segmentation of project
3. Growing organically, too much money can kill a project, but not enough community can make it dormant.

Resources

http://www.producingoss.com/

--64.3.20.194 13:42, 25 March 2006 (CST) Notes by James Dailey (jdailey @ gfusa.org)