I first saw the above image in a briefing on FIST by Dan Ward.  It struck me as very important at the time (and still does) as a metaphor for how open source can make the transition to hardware (open design).  In open source software development, often the participants need only be connected virtually.  Everyone has a computer they use for development or testing, and they can communicate and collaborate over internet services (web forums, mailing lists, code repositories, wikis, etc).  And everyone can take the source code and build the software on their own machine.  Think about it for a moment.  Someone can download the instructions and materials for building the Apache web server from the internet and then build it from scratch in a matter of minutes (if they are familiar with the process) to hours (for a first time hacker wanting to build their web server from source).  Physical products just don’t work like that.  Even printing an open e-book requires having enough paper to print on, and some tools to prepare and bind it (and I for one don’t have anything more complicated than a three-ring binder).  Something like a basic circuit board requires transistors, resistors, the board itself, and tools like a soldering iron, and this is still something that one person could do on their own.  What about the kind of projects we are contemplating?  Face it, building space ships is not a hobby you want to do alone in your own garage.

Which brings me back to the image above.  Building complex works of engineering (and a space ship, no matter how simple is a complex machine) takes working in a team and specialized tools.  The collaboration needs to happen on a new level, between teams (individual collaboration is still important, but now it is the glue that holds teams together, instead of the glue that holds the greater group together).  So, I think we need to foster the kind of connections between groups captured above.  This is where the idea for hosting a team based design contest for Aurora came from.  But I think we need to do more, I think our concept of the long range development of Mach 30 needs to keep this in mind.

Periodically, we brain storm/dream about what the Mach 30 headquarters should include.  We talk about where it should be to support flight operations.  We talk about what facilities it should include as a place to build, test, and fly space ships (Greg just did a very nice summary on his blog the other day).  Yet, in thinking back on this work (all of it, going back to when there were only four of us, or when it was just me), I think there has been an underlying assumption of doing things old school.  Of having the one great headquarters to rule them all, of having the one place where all the engineering really happens instead of about how to distribute the work in an open design oriented way.  I think this is mostly because the loose federation is a newer concept and has not been fully explored (especially as to how it might affect previous work) or even adopted.

I just saw an article on wired.com that made me think about all of this, and that I think has some impact on how we may want to work.  It is about something called Hacker Spaces.  These are self organized groups that come together to share project space and experience.  They are organic (people come and go as they please, work on what they want, meet up when they need to, work alone or in groups as the need arises) and are part of an evolving community.  And, they seem to be focusing on supporting the type of projects that result in physical constructs, though software development does also happen in Hacker Spaces.  In short, I think there is much we could learn from this movement.  And there may even be a place for us within it.

And I wonder what the Mach 30 HQ would look like if instead of trying to be the One True HQ, it was part of a network that was made of of places like the Hacker Spaces.  What would its functions be?  What features would it need to support those functions?