This was a topic from our Developer day from an offline conversation with an Open Source Software guru. Let’s continue the conversation here.
–
We spoke a lot about using agile in open source projects. He did agree that some agile methods may work but it’s very difficult with unpaid volunteers who can’t be told what to do. Volunteers really won’t be on board with that.
What he did suggest that there are two specific aspects that can easily be borrowed. The first is that who ever starts a contributing project is the product owner for that product in that as the originator of that project, they have own the vision of where that product goes. It’s hard to say no to people who contribute effort but as the product owner, they should set the vision of where they see their project going. More on sub projects later. We had a good conversation on that.
Second (we were on this topic a lot, he was passionate about this) is that we should have a clear cadence or “release train” where contributors know that if they want their changes to be published, the need to have their work in by a certain date to meet the release. This creates, even in a widely distributed project, a sense of working toward the same goals and a sense of urgency because developers will want to get their changes in before the next build is published. This also helps the user community because they know when to expect the next release, when to see bug fixes and they are not overloaded with too many releases with insignificant changes.