Agile for Open Source projects

From AgileOpenNorthwest

Jump to: navigation, search

This is the notes from the session about using Agile in Open Source projects.

Taxonomy

We started out with a taxonomy of of what kind of Open Source projects vs. what kind of modifications people want to make, with some examples:

Levels of contribution 1 person "Hobby" open source Full Time ($)
1 line Flying Saucer Add Date Control Eclipse - increment number in copied line
small feature Eclipse - modify JUnit window
1 feature my business depends on ($) Eclipse - better Intellisense wheel
I love your project
New incompatible direction
non-programming contributions

Notes:

  • different levels of contribution are possible for the same project
  • some projects are easy to contribute one line two (many Ruby projects - because they have the source?)
  • some projects are hard to contribute to - the wall is high. They require the "I love your project" commitment. This is a barrier.

How to enable all levels of contribution

  • Diagram: pyramid of contribution size - large at the tip, 1 line at the base, a continuum.
  • Give everyone commit rights? (How to do this without disaster?!?)
  • Reduce complexity so that you don't have to understand everything to change one thing
  • How to deal with the complexity of many branches or distributed version control.
  • Core team holds responsibility for brand promises.
  • Full source projects (Ruby, Python) have an advantage over "DLL" projects (Java with jars, C#, C++ with DLLs) - even if source is available, it takes time to get it and install it.
  • Pairing sessions are very useful to get contributions in
    • my want and your system knowledge
    • how to do this without social capital
    • use EC2 as the dev environment? cheap to store on EBS, cheap to run, accessible everywhere
  • In-person meetings
    • Kickoff sprints or meetings
    • Periodic weekend sprints (or longer)
  • Distributed Version Control - git, hg
  • IRC "office hours" for submitting patches
  • Spread pairing out - get volunteers pairing with each other.
  • View pairing and accepting patches and changes as customer service
  • How to allow wide refactorings - that touch a lot of code?
    • Give commit rights, or use DVCS. Patches are too hard.
    • People need to part of the process. Core team needs to trust, or understand and improve.
    • Developers need to communicate design intent of changes - but how? Pairing is one way. In person. What else?
    • Need trust. Build trust. It's really important.
  • Retrospectives
    • Find a way to get everyone's input...
    • Rotate times to get different time zones in person
    • Use wikis, email to solicit ideas and input
Retrieved from "http://www.agileopennorthwest.org/wiki/index.php/Agile_for_Open_Source_projects"
Personal tools