C105 Mechanics of running an OS project

This turned into a discussion about how the Grouper project handles collaboration. The two projects are very similar and hopefully the following discussion points will help OpenRegistry to grow:

• grouper was collaborative from the start

  • 2 schools bristol and chicago

  • cardiff, penn, duke

  • Tom knew he needed this but there were no solutions out there

  • Got something written that was missing pieces but was a start

  • Penn had their own interests, it wasn't just right

  • Penn doesn't typically do Open Source

  • technology matched developer skills

  • 1.6 is stable

  • 2.0 is next major release

  • release twice a year

  • roadmap, not formal governance

  • conference calls every other week

  • Rob at Cardiff wanted to contribute it back

  • SVN branches are different versions

  • working on 2.0

  • fix in 1.5 branch, merge that forward into 1.6 and 2.0 branch

  • Trunk is development version

  • Trunk changes throughout

  • coarse roadmap, point of discussion twice a year

  • figure out the target ahead of time, functionally

  • if you have a change that might effect people who don't want, put in a switch in the config

    • 5 committers

    • motivated by not forcing people to move large pieces outside the project

  • what do deployers want, not what do committers want

    • use case driven, motivated by a specific use case

    • avoid hypothetical, at least one happy customer

  • feature branches? in a minor release

  • important that someone consistently handle the merging

  • each committer has their own area that they work on

    • web services, UI, complex internal API, LDAP, ESB, Documentation

  • by and for the community

  • Mechanics of adding new users - earn your way on

    • feed them some ideas to generate patches

    • do it through issue tracking Jira

    • attach patch files through Jira

    • our committers look at them

    • existing committers vote