Adapting Scrum to a Volunteer Setting

I have recently joined a young hackerspace still in the process of setting itself up. We're fortunate because the space has a few internal projects that need working on and no shortage of volunteers to work on them.

There have been some discussions on how to organize these projects. My most recent professional experience has been with Scrum so I'm considering pitching a Scrum approach for our software projects, but I'm not sure it will be a good fit.

Although I've seen Scrum work well for small full-time teams, the nature of this organisation is different:

• The members are volunteers. Some are full time students. Others work jobs full time. We can't expect a constant level of contribution from anyone as their real lives take priority.
• While pretty much everyone has years of experience writing software, not many members have done so professionally or in teams.
• There is no Product Owner. The requirements for these projects are determined by a committee. The members of this committee will also be working on the implementation. This means we will have no single, dedicated, Product Owner.
• We have no deadlines (soft or hard). The projects will get done when they get done.

These are pretty significant differences, but I'm not convinced they will be blockers to applying Scrum. I think some minor tweaking could get us over this hurdle:

• If we change Sprints to have a fixed story-point size, but fluid duration (time), we can still benefit from iterative releases without putting unrealistic delivery pressure on volunteer devs.
• We can ditch burndown charts and velocity calculation. If I understand correctly, these are tools and metrics that work as a bridge between the dev team and the Management. They serve to report progress in a form that is meaningful to both the developers and the stakeholders. Considering we have no one to report to (no Project Manager, no Product Owner, and no outside stakeholders) I believe we can drop this altogether.

Things I think we could benefit from which won't require tweaking:

• The Requirements Gathering meeting(s). Where everyone sits around a table and discusses User Stories, sketches up UI mocks, and builds up a Product Backlog.
• Sprint Retrospectives. This will be an interesting way for us to converge on a development process that works for us as a team of volunteers.

Things I'm not sure about:

• How should daily Stand-ups be treated? I wonder if they would have much value at all in our setting. My understanding of the stand-up ritual is that it helps communication by naturally disseminating information throughout the team. Considering the fact that our Sprints will likely be delivering much less complexity than an average Sprint there might be less need to be abreast of all the other team members' progress/developments.
• Should I push for XP things like Continuous Integration, Code Reviews, and TDD? I'm concerned this will be asking for a lot. I'd be more tempted to bring these concepts in on future projects once people are more familiar with Scrum and working as a team.

My Questions:

Can Scrum be adapted to a volunteer-based environment?
And, is my planned approach so far going in the right direction?