Degrees of openness

From RepRap
Revision as of 10:36, 29 June 2010 by ErikDeBruijn (talk | contribs) (Created page with 'Openness can be differentiated into several criteria that fall into two basic categories, the ''subject'' and the ''process'' by which it is developed. In the case of this open d…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Openness can be differentiated into several criteria that fall into two basic categories, the subject and the process by which it is developed. In the case of this open design project, the RepRap 3D printer is the subject and it is developed by a community through a distributed process. The development process to a large extent determines the openness of the creative work (subject).

(e.g. source code, CAD files, drawings and schematics and documentation).

Openness of the subject or work

Openness of the license

This can be applicable to source code, (CAD) or other design files and schematics and relevant documentation. Needless to say there is more to openness than just attaching a GPL license to your work.

Up-to-date-ness

Up-to-date-ness of the code, design files and relevant documentation made publicly available.

Replicability

  • can the work be replicated based on what is publicly available
  • To what degree is it codified and/or documented are CAD files available or just pictures
  • Replicability is also dependent on the choice of modules, are they exotic or ubiquitous. Are they sold separately or only through full kits.

Level of openness

Is it an open design based on mostly closed parts vs. open design with many open parts (are control electronics commercial off-the-shelf or open).

Open standards

does it comply with open standards and to what degree (e.g. RapMan uses G-Code, how compatible are the two? Open systems should allow you to use OSS toolpath generation software to control it).

Openness of the development process

Transparency

  • A project can be fully open source but decisions made internally without others being involved, e.g. complete closed governance (e.g. Google Chrome is controlled by Google unlike Chromium which is more under community control). Does the vendor blog about their developments.

Centrality of control vs. distributed contributions

  • Are the majority of contributions centralized. I have the feeling that Fab@Home is developed more centrally (mostly at Cornell) than RepRap (quite a share of the development done beyond core team), but I'm probably too biassed to really judge this.
  • This could be a result of barriers to contributions, for practical reasons, such as as PDF manual instead of a wiki or because of a different segment that the vendor addresses. For example, professional engineers and artists (e.g. Stratasys' & EOS' customers might be less willing to contribute, they want to use the machine as it is and don't feel the need (or FLOSS' cultural imperative of sharing) to modify and collaborate in doing so.

Other metrics and concepts that are associated with openness

A modular architecture also improves the 'hackability'. This makes a "different" product rather than a "better"/"worse" product because benefits of either depend on what you want to do with it. The modular architecture is not directly related to openness, but it is easier and people are more likely to contribute if they can work indepedently/concurrently. On the other hand, e.g. BitsFromBytes have a single monolithic PCB (and no FLOSS CAD files, but that aside) and this has benefits (no need to wire up different PCBs). Modularity and stable interfaces can make it easier to integrate the work of others and get the real 'distributed collaboration' going that is typical of healthy open source projects.

Patents

A work can be patented but by this process become fully disclosed. In a way it is open yet it cannot freely be used. For the purpose of collaboration this may can create limitations.