-*- mode: outline; -*-

This is a non-organized typeup of some of my notes regarding a pattern
language for open source.  Each of these claims should ideally have
its own pattern, and there would probably be other super-patterns that
cover them in an overview sort of way.

**Have a community mailing list (a la freebsd-chat)
**Have a single responsible person for each task at each time
**Have an efficient decision making strategy
**Release working code, not ideas
**Release early
**Release often
**Keep your development code runnable
**Run your own code
**Project an inclusive image
**"Spend" mailing lists by topic
**Build short feedback loops for development (ie, have good comms
  inside your team)
**Avoid mail overload
**Use real-time communication
**Have a "canonical" form of communication
**Make hacking the code involve as few hassles as possible
**Spread write access around
**Have a single person have integration responsibility
**Use a review tree to avoid overloading single integrators
**Avoid single mailing list overload (e.g, use regional lists)
**Have a secruity mailing list
**Use Usenet
**Avoid Usenet
**Avoid single community overload
**Use version control
**Use Phones
**Let people become friends
**Hold conferences
**Use WikiWiki/Everything2
**Make things fun
**Use licenses to drive development
**Give tokens of recognition
**Avoid creating borders between contributors
**Make all contributors feel it might as well be them that do each
  single task.
**Use teams & delegation
**Use Job/Problem tracking
**Appoint a team secretary
**"Rough consensus and working code"
**Use dictatorship
**Use democracy
**Use feedback loops
**Arbitrate conflicts
**Use "One coder on a crusade"
**Avoid a feeling of bueraucracy
**Use a written set of rules
**Avoid a written set of rules
**Avoid too many mailing lists
**Have enough mailing lists
**Have an architecture list
**Have a support list
**Have a "Help New Hackers" list
**Have a "Help new users" list
**Have an "advocacy" list
**Create "religious" users & developers
**Avoid "religious" users & developers
**Make support/warranty purchasable
**Use a standard license
**Use a custom license
**Use the GPL
**Use PD/BSD license
**Start a private "insider" mailing list
**Kepp all communication public
**Start a private chat channel
**Release full access to your version control system
**Avoid developer burnout by cycling positions
**Keep developers by giving them responsibilities
**Make developers get new ideas by working on other projects
**Have a security officer
**Have a build manager
**Use reproducable builds
**Use builds that adopt to the environment
**Use autoconf
**Avoid autoconf
**Program in C
**Use other languages than C
**USe marketing
**Avoid marketing
**Employ developers
**Avoid "for pay" development
**Build a "spirit" for our code
**Have styleguides
**Avoid styleguides
**Replace bad memes
**Avoid losing continuity
**Create an abrupt change (break continuity)
**Recruit developers
**Avoid too fast growth
**Avoid strong personalities (They cause conflicts)
**Recruit strong personalities (They short-circuit decisions and
  complete projects)
**Recruit mixed genders
**Recruit high-competence developers
**Recruit "low"-competence developers (for grunt work)
**Recruit doc people
**Start a news-website
**Avoid a news-website
**Create an announce list
**Load accounce with everything relevant
**Keep announce traffic as light as possible
**Keep the team culture/spirit
**Change culture as necessary
**Use as many libraries and other building blocks as possible
**Avoid dependencies
**Do not branch code unless necessary
**Branch when convenient
**Have a release engineer
**Have a person responsible for tracking any branched code
**Use development branches
**Switch modes for the entire development team
**Branch before release
**Branch after release
**Branch at release
**Release without branches
**Use code slush/freeze before release
**Avoid blocking development to roll a release
**Close all problems reports/known bugs before releasing
**Release on schedule
**Release with enough new features to be exciting
**Release with higher stability
**Test before you let code get into the codebase
**Rewrite code even if you can't test
**Change your APIs for the better
**Keep your APIs stable
**Release code to get a testing base
**Use lint
**Keep debugging code available
**Use notyet to declare future plans
**Avoid noteyet to avoid code bloat of never-went-there directions
**Create an option set that does as close to full coverage of the
  codebase as possible.
**Use external documentation
**Use internal documentation
**Make developers document their own code
**Use doc people
**Use assertions
**Drop unmaintainable code
**Pass as many contributions as possible
**Delay contributions if stabilization is necessary
**Handle contributions as quickly as possible
**Be consistent in hanlding contributions
**Handle each contribution after individual evaluation
**Allow contributions in even if you can't review them properly
**Review all contributions
**Decline contributions if the contributor is deemed dangerous to the
  project
**Declare project goals
**Avoid project goals
**Accept contributions even if the contributor is dangerous
**"Volunteers can't be told what to do"
  (Derive statements in both directions from this - the claim isn't 100% true,
  but not 100% false either.)
**Make install as easy as possible (to gain users)
**Make install hard (To get good users and make them feel special)
**Have an "external plugins" manager
**Have a project president/leader/spokesperson