While I admit to being "old school" when it comes to project management, I would like to point out something.  To a large extent, documentation IS the deliverable in these projects.  This collaboration project is extremely different than most of the OSE projects since it involves the creation of an abstract thing we call software.  I'm not saying that we can't apply agile techniques to hardware development, but there are differences between hardware development and software development.

Consider the 12 principles laid out in the wikipedia article:

Customer satisfaction by rapid delivery of useful software

Who is the customer in an OSE project?  The ultimate customer - the person who builds a GVCS tool from our plans - is really present in the process at this time.  Marcin and the other folks at FeF come the closest.

Welcome changing requirements, even late in development

Being flexible to changing requirements will be needed.  Designs will change has we get deeper in to the development of GVCS technologies, but it does sorta imply that there are requirements known in advance.  There needs to be at least some guiding requirements before the process can start.

Working software is delivered frequently (weeks rather than months)

Let's face it - no matter how much we'd like it to be otherwise, we are not going to be cranking out new hardware prototypes every week or even every month.  Interestingly, Marcin and I had a discussion on this topic.  I put forth the notion that developing the Steam Engine would likely be an iterative process involving several actual prototypes.  He rejected that in favor of trying to "get it right" the first time.  That shaped my approach to the project and I shifted a lot more attention into design review, up front drawings, etc.

Working software is the principal measure of progress

In an OSE hardward project, we will need two measures of progress:  working documentation (ie, free of bugs and problems) and working prototypes (which can take a significant time to build).

Sustainable development, able to maintain a constant pace

This is something we need to be better at.  OSE, at this time, is very "bursty" as people shift from thinking to designing to prototyping to production.  Part of this has to do with Marcin being central to most of the active OSE projects.  His time as become very precious and he slices himself rather thin.  Still, things are happening.

Close, daily co-operation between business people and developers

What business people?  Most of us are volunteers who have a limited amount of time to contribute to OSE development efforts.

Face-to-face conversation is the best form of communication (co-location)

While I agree that F2F is better, most OSE projects will be globally distributed.  Geography cannot be overcome, therefore we'll need to adapt to the challenges it engenders (such as time zone differences).

Projects are built around motivated individuals, who should be trusted

Generally, the motivation is there, but work is required to sustain it.  I've been involved in enough OS and volunteer projects to know that the project leader/manager has the role of a cheerleader urging the troops onward.  The matter of trust is something that needs to be considered as well.  Generally, trust can be assumed based on some initial assessment of capability.  Managing broken trust is a delicate thing in volunteer organizations.  If you are too hard on people, word gets around and qualified volunteers go elsewhere.  If too soft, things don't get done.  It is a balancing act.

Continuous attention to technical excellence and good design

While some effort has been made to outline general OSE standards, they are not explicit enough to measure a project by.  Consider the lack of documentation standards, for example.

Simplicity

Simplicity will need to be managed into OSE projects through functional decomposition.  While some GVCS tools are quite simple, most are complicated and have dangerous aspects to them.

Self-organizing teams

We have the start of this but we need to have guidance on how to go about organizing.  I have made some attempts to describe how this should be done.  More work is needed.

Regular adaptation to changing circumstances

I think people will deal with this just fine.  Most OS contributors are comfortable with change, in my experience.

---

In sum, Vann, we need to give some thought to how agile development techniques apply to OS hardware.  It is a mistake to think that techniques that work well for software will work equally well for hardware.  I think, to some extent, we are charting new ground here.  Given that this particular project is focused on the tools that will foster and guide OSE projects, we should consider the bigger picture.  This includes an examination of the OSE project development process.

- Mark

I think you're being a bit unfair, Vann.  You seem to be forming the opinion that I'm against an agile approach - I'm not.  You also imply that don't know that much about it - also not completely true as I've worked on software development efforts that used SCRUM and XP.  You also suggest that I'm using a waterfall approach to the steam engine project - also not really the case since I'm pretty much the only one working on it.  As such, I feel free to tackle the work in the order that makes sense to me.  Methodology is largely there to coordinate the actions of a team.  I have used functional decomposition techniques to break the work down before tackling it.  It is already iterative in the sense that new information is coming to light, changing the requirements, the design, and the fabrication plans.  If my style doesn't quite match yours, I personally don't think that's a problem.  Work has gotten done.  It's moving towards prototyping at a steady pace - which is about all OSE can ask of anyone at this stage.

Regarding this project, since you are the project manager, I defer to your management style.  I believe I'm flexible enough to adapt to it.  If not, then I will bow out with no complaints or feelings hurt.

- Mark

also, the collab platform is much more than links on a page. you recall eerik's blogosphere idea and that it will make API calls to numerous servers.