Hello guys. First, here is what I sent to Elifarley that got


me into this mess:

“We [Crystal and Mikkel] feel that the ideas are great but
there seems to be a lot missing on the project management end for truly making
it a global collaborative effort. Several people that are currently working on
projects that fit well into the GVCS feel the same way and while they share the
aims it is unclear how they can get involved in their own fashion. We have a
few ideas to propose about how to manage the project management side and I have
the skills necessary to architect any system on the technical side. Would you be
interested in hearing about them and seeing if there is a clear way to
contribution on either our ideas or more generally? Thanks for getting this
started, we think it could become extremely important.”

He asked me to post on this forum and copy the email, so
here it is. The purpose of this post is to try to briefly explain these
suggestions.

First here is what we are NOT proposing. We are not
proposing a replacement of any technology that seems to be being used at the
moment (wiki, pivotal, so on and so forth). In addition, we are not proposing a
centralized uberstructure that tries to manage all efforts simultaneously. We
strongly agree with the sentiments that Eerik posted in a comment that was
linked to me by Elifarley.

What we are proposing is fairly simple: a standardized
framework that people can use to do project management and quickly look at the
overall progress of GVCS. It is unclear to me at this point how much GVCS has
thought specifically about how to foster the creation of an innovation
ecosystem from top to bottom. This includes providing vision on the
technologies that are useful (done very well already) to internal development
of those technologies (looks like it is progressing fair enough, but highly
focused around Factor e Farm), while enabling the creation of different flavors
and progress by a widely dispersed team and finally providing some integrated
vectors to commercialization on some level such as regional micro-manufacturers
and servicers.

Perhaps these things have been articulated and we are
missing them (although we did read nearly every publically available page we
could find) and perhaps some of this is outside the present scope of GVCS, if
so I apologize.  That said, we know a lot
of people trying to do cool things in this vein, and we hope to as well, and
the following is an idea of how to support that with a tool suite and process.
If this is successful, then it should be able to support the idea the aneiren
suggested here about how to better utilize talent and labor available to this project.

We agree that every project should have a PM. However, we
take it one step further and suggest that “projects” are actually a sublevel
below technologies. GVCS refers to 50 different technologies but the
implementation of each technology can have varying forms based on location,
resources, budget, etc (as Eerik said in the comment linked above, in open
source hardware each build team can have its own ‘personality’). As such, our
first step is to define the broad Functional, Technical and Design
specifications on the Technology level that all projects to implement that
technology would reasonably share. We think there is a reasonably good job of
this already on the wiki pages for several  technologies.  This is the vision part that it seems GVCS
could play a dominant role.

Once a technology has a vision fleshed out, then groups (either
Factor e Farm or outside groups) may register to implement a flavor that that
technology through a project. When this occurs, they get their own location to
run their project, including fleshing out the functional, technical and design
specifications that are specific to their project. By default, all Technology
specifications are included, and if they want, they can even link to other
projects and/or Technologies if they want to replicate those specs. Here is an
example with a “Toy Car Technology” that has two projects that implement it in
slightly different ways of “inexpensive” and “quality.” Notice that the general
Technological specifications flow through to each project.

From there on, they can follow a process of their choosing,
although I think it’s in GVCS’ interest as an organization to provide tools to
enable each stage in a coherent manner. Below is an example of a process flow
that takes a project from its original technological conception to end level
support.

It is important that each project have clearly defined
functional and technical specifications. There should be care to make sure that
each functional specification is directly implemented by one or more technical
specifications. A summary could be as follows:

As for the implementation, we think a possibility is to have
a data entry manager where specifications are defined, and then have different
views that are projections onto the data based on usage. For example, the first
and last diagrams above could be automatically generated views that allow
people to explore the underlying data. An example entry could be something
like:

Multiple views on the same data would be particularly useful
as roles become differentiated. I have no hands on manufacturing experience and
would try my best not to end up in the hospital if tasked to build something,
but I have a lot of potentially interested parties both in terms of a customer
and investor base. If I worked closely with a PM to help define and relay
Functional specifications, then I could start the process of looking for funding
to drive the R&D as well as general publicity in parallel with the
prototyping process. In addition, when projects have completed this process
ensures that they have sufficient information to “live on” and be replicated,
as well as being used to generate end level user documentation for each
feature. Distilling low level information into high level information is
crucial for these kinds of tasks.