Distributed Collaboration

From Open Source Ecology
Revision as of 01:57, 21 February 2012 by Matt Maier (talk | contribs)
Jump to navigation Jump to search

The internet has created a brand new opportunity for people separated by distance, but united by goals, to work together. The "distributed collaboration" idea has a strong element of assumed volunteerism in it. Professionals, united by a fiduciary responsibility (and the hierarchy that implies), don't need any help. It is the people who want to help a worthy cause in their spare time that need help.

Volunteers, by definition, are nearly universally unable to produce good work on a regular schedule. They tend to work when they can, or when they feel like it, so they need a system that isn't broken by newbies making mistakes or old-timers disappearing suddenly.

The following process attempts to achieve that goal. Each step is well defined and really only a small part of the process depends on a core team of employees. The rest of the process is a way for volunteers to expand a small piece of crucial work into a diverse array of useful tools.

Benefits

  • This process clearly defines which steps are necessary and who is responsible for them.
  • The entire process is transparent and easy to understand.
  • Feedback mechanisms are built into the structure.
  • Any number of alternative definitions, projects and reports can exist side-by-side.
  • Every step which can practically be done over the internet has a method for doing that.
  • Each step is flexible enough to allow people to come and go as necessary without crippling the process.

Concepts

  • Self-evident
    • Something meets this standard when the way the thing is described requires no additional information. It is the smallest indivisible unit of a machine.
    • In practice, this goal is achieved when a part or step is so simple that a mere title or illustration is sufficient to fabricate or execute it.
    • For example: a picture of part A and part B held together with matching bolt holes lined up with a title like "bolt together" is self-evident. It requires no additional explanation. On the other hand, a picture of a fully assembled machine would not be self-evident. Additionally, a picture of the bolt first going through part A, then through part B, would probably be unnecessary.
    • This standard is not objective; it requires a bit of an intuitive touch...or a lot of feedback. The distributed collaboration process is designed to maximize feedback so that intuition is unnecessary.

Definitions

Each machine is designed and prototyped by one person or, at most, a small team.

The prototypers "define" the machine. They generate descriptions, sketches, illustrations, CAD, models, etc. Technically, as long as they record everything coherently an experienced fabricator could figure out how to reproduce the machine. This is the bare minimum necessary. Without this material the prototype machine might as well have never been built.

Prototypers have three responsibilities in this distributed collaboration process:

1) They must define the machine in discrete steps, each of which is simple enough to be "self-evident."

2) They must post their definitions in a way that is publicly accessible and coherently organized.

3) They must remain available for, and responsive to, requests for additional or rephrased definitions.

Projects

Each machine is documented by remote volunteers (or anyone).

The documenters create "projects" based on the definitions. They generate a database that contains the steps, resources and time-frame necessary to replicate the machine. This is a powerful augmentation to the definitions. With this material replicators have all the information they need to start immediately and proceed without any surprises.

Documenters have three responsibilities in this distributed collaboration process:

1) They must refer directly to the machine definitions in a way that is "self-evident."

2) They must seek out, clarify and record all the information relevant to fabricating the machine.

3) They must work in a standardized, shared format without keeping any relevant information to themselves.

At the moment, project management software is the preferred tool for building the projects. It is a database that already has a GUI and reports. There are plenty of free, open-source project management programs available online. OpenProj was used to test the distributed collaboration process and functioned adequately.

How To Do It

1) Find the machine definitions. If they aren't broken up into self-evident parts then have a way to do that or ask the prototyper to do it.

2) Isolate one part.

3) Create one or more steps to shape the part.

  • First, create a "resource" in the PM software. The name of the resource should be the dimensions of the cut piece of stock material. For example, <4" x 4" x 1/4" by 3' angle> could be a resource name. Additionally, create a resource for any tools necessary to accomplish the step. For example, <metal saw> could be a resource name.
  • Second, create a "step" in the PM software. The name of the step should be the action necessary to shape the material. For example, <Cut To Length> could be a step name.
  • Third, assign the resource(s) to the step. Additionally, assign any tools necessary. Now the complete entry could be read <Cut 4" x 4" x 1/4" angle To 3' Length using metal saw>.
  • Fourth, create any other steps necessary to shape the part. If holes are necessary, you could create <drill hole using 13/16" bit and drill>. The best thing to do is refer to a definition image that shows the correct hole locations, their dimensions, and how to locate them on the part.
  • NOTE: create a different resource for every individual piece that uses different overall dimensions. It is not necessary to make two entries for parts that are both <4" x 4" x 1/4" by 3' angle>. It is necessary to make two separate entries for a parts that are <4" x 4" x 1/4" by 3' angle> and <4" x 4" x 1/4" by 4' angle>. This will ensure that the BOM is both complete and intuitive. You don't know how the replicator is going to want to obtain the correct amount of raw material. Providing them with exactly the outside dimensions of all the parts allows them the most flexibility in sourcing. For example, if there are 12 square tubes of various lengths, all under 8 feet, do not list <12 x 8' square tube> in the BOM. That is misleading. Instead, list <2 x 8'> and <4 x 7.5'> and <6 x 6.75'> so the replicator can figure out for themselves how to combine the parts to minimize waste or maximize efficiency or whatever.

Reports

Each machine is published by remote volunteers (or anyone).

The publishers create "reports" based on the projects. They generate a finished document that presents the information in the project and definitions in a professional, authoritative manner. This step is necessary to open up machine replication to as many people as possible. With this material replicators have a universally accepted tool for communicating their endeavor to team members, investors and interested parties.

Publishers have three responsibilities in this distributed collaboration process:

1) They must refer directly to the machine project and definitions in a way that is "self-evident."

2) They must communicate to as broad an audience as possible, without ambiguity, bias or omission.

3) They must grant the world permission to obtain, utilize, copy and distribute the report freely.

Credentials

Matt_Maier

I graduated from the Air Force Academy with a degree in Systems Engineering Management. Now I work as a satellite ground system engineer.

References

"The data of the GVCS truly constitutes its value, and as such cannot be trusted to a single, centralized source. An additional hurdle is the disconnected, intermittent and limited (DIL) connectivity of some users of the global SoS" - N Bollweg, A System of Systems Analysis of the Global Village Construction Set