Agile is really a frame of mind, ARGH (I like that nickname - it's so expressive!).  It means being open to change and responding quickly and with flexibility.  While I would agree that certain specific agile processes for software development don't quite work, I think we can adapt it to meet our needs.  We might even be at the forefront of exploring how agile techniques might be applied to OS hardware. 

I also agree that documentation is one of our main deliverables, and that sets us apart from software development.  See my post to the Collaboration forum

Regarding restricted access, this is the start of a new OSE policy to create special forums restricted to contributors of an OSE project.  While they are visible to all, only team members are allowed to post to it.  It's intended to keep the conversation focused on project needs, while letting the larger community have visibility into what's going on.  Your response to post here is exactly right.  This is the right place for it.

- Mark

One good reason that those forums are closed is that design by committee or decisions by committee is a very painful and slow thing, and in general isn't effective. I've seen this process first hand. Here, we clearly know who the people are who are responsible for making the decisions, and who is accountable if things don't go well. At some point a decision has to be made and everyone has to accept it, and we move forward to either success or corrective action. A clear decision, for either agile or traditional processes, is much better than an unclear ambiguous decision.

General feedback in a separate forum is a perfectly acceptable and appropriate to give input as things develop.

Previously I also questioned this system in a separate thread, and while I agree with privileged project forums, I think the individual tools should have open forums. For example, there should be an open "Steam Engine" forum that anyone can post in about steam engines. There should be a privileged child forum "2011 OSE Steam Engine" for the specific implementation of "Steam Engine".

Not only do restricted forums restrict interference from the "bottom" but also from the "top". For example, there are probably some forums even Marcin himself shouldn't have access to. If he isn't actively working on the project, yet wants to occasionally pop in and make decisions, not only is the organizational structure not much of a structure, but his decisions will likely not be the as informed as the team which is dedicated to the project. If he has valuable feedback from experience in another project which he wants to loop to the team there should be a system to do that other than breaking the structure so that anyone with such feedback can give it in the same way.

(If anyone questions that last paragraph, saying it isn't an "agile" approach, then I'd respond back that the whole closed forum thing isn't agile. As my post states, I'm not saying closed forums are bad, but we should clearly understand what they mean and what they don't mean.)

Oh, hardly the end of the discussion, ARGH.  Even agile development has many flavors and nuances.  There is room for stylistic differences, IMO.  There is a saying in the OS Software world:  "Working code trumps all talk."  We might rephrase that as, "A working machine is what matters, not how we got there."  As long as people can understand what we've done and replicate it, we've done our job.

- Mark

@jason
>  MJN, remember people need to be able to pick up the development process
too where it was left off.  Which means they should have access to the
prior work.

Of course.  That's the whole reason for keeping the work in public places like the wiki, forums, and Pivotal.

>  I think it would be backwards to assume the machines produced by OSE at
full product release are "done".  They will always be evolving, always.

I agree with that, Jason.  We WANT them to evolve, improve, diverge, etc.  The more people tinker with the machines, the better off we all are - as long as people make their results known.

>  Unlike in software you can't take a part out or change something and
test it as easily, if it turns out that is something that was added for a
good reason you may be in for a surprise months later and you would
have a hard time "patching" the hardware.

It isn't always that easy in software, either, but I take your point.  Still, modularity is something we are striving to design into the tools and machines.  To give you an example from my project, the pins that cause the valves to open at the end of the steam cycle are threaded on one end and screw into the piston head.  This is so that they can be replaced with pins that are slightly longer or shorter - since this affects the amount of time that steam is admitted to the cylinder.

- Mark

Oops.  Sorry. :D

@jesspinto,  no, I wouldn't say that Agile development techniques are contradictory to OSE.  However, I think that Agile is difficult to implement for hardware development.  It can be hard enough to do it for software, but hardware presents even more challenges (largely due to the amount of time needed in fabrication).  OSE proposed applying Agile techniques to the development of an Open Source Car.  WikiSpeed was retained to do this, led by Joe Justice.  Well, a year has gone by.  Where is the car?  Where is the design?  Where is ANY documentation?  While it may be possible to use an Agile approach to building open source hardware, OSE's experiences to date have not been positive, IMO.

I agree with Mark (mjn) Where is the car developed by WikiSpeed? Where is the complete technical documentation to build it. Wikispeed once in 2012 has published a very incomplete 3D CAD model. I've checked it a bit and found it poor and with design flaws. The turning radius of that car would be very large, not suitable for use in the city. The wheel hubs are designed in a matter that would make fabrication in industry difficult and expensive - for DIY impossible to fabricate. Sorry, but what Wikispeed has shown yet doesn't look promising.

@jesspinto I don't see that Agile principles are really adapted to open source hardware. Availability of good and complete documentation is of utmost importance for hardware. No one benefits from an open source machine that works exceptionally good, but can't be replicated due to missing or incorrect technical documentation. And response to change instead of following a plan is prohibitive with large hardware components - too high expenses for materials and labour + machine tools to fabricate them. Mike