Stephen,
There is a difference between what drives a release in a project where folks are paid to deliver by a certain time-frame and in the open-source community. In both types of projects, time and features are both considerations in a release. However, because open-source projects are purely voluntary (unless a company is employing folks to do work on an open-source project), the work a contributor or committer can perform on the project is prioritized below: jobs, family, and other issues depending on the developer. Because of this, while a contributor or commiter to an open-source project may only need a couple of hours to complete a task, those hours could be spread out over a couple of days or weeks. As such, many open-source projects PMC's will choose either 1) to delay a release until release-specific features can be included, or 2) drop sets of features in order to meet a given release date. In fact, many PMC's will use both of these techniques to get a release out to the community. In the apache community, the Jira Roadmap is very useful in figuring out both of these items. Additionally, most apache projects will have jira tickets addressing each specific release. In those tickets, you can see the discussions about both the content of a release and the timeframe. For your specific need, you may want to consider exposing your customer to the Roadmap, and to express the fact that while a release may be tied to a given date and feature set, neither is set in stone. In that manner, apache projects are similar to may real-world projects where schedule slippage is not a rare thing, especially with growing feature sets. In short, burn-down charts and other agile/waterfall tracking techniques will not work well in tracking open-source projects. It would likely be a waste of time to try to provide time estimates, unless there is a very dedicated core regularly submitting/committing code. I hope that helps. v/r, Karafman, PMP, CSM (and many other arcane certifications)
