-
Notifications
You must be signed in to change notification settings - Fork 4
/
README.adoc.liquid
64 lines (45 loc) · 3.53 KB
/
README.adoc.liquid
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
= {{architecture.package.description}}
{{architecture.package.author}}
:revnumber: v{{architecture.package.version}}
:revdate: {{architecture.generationDate}}
// github specific things
ifdef::env-github[]
:tip-caption: :bulb:
:note-caption: :information_source:
:important-caption: :heavy_exclamation_mark:
:caution-caption: :fire:
:warning-caption: :warning:
:imagesdir: https://raw.githubusercontent.com/Mach30/dof/master/dist/images
endif::[]
// non-github specific things
ifndef::env-github[]
:imagesdir: ./dist/images
endif::[]
== Introduction
Mach 30 launched https://opendesignengine.net[Open Design Engine] (ODE) in 2012. Since then we have run our own OSHW projects on ODE, observed other groups host OSHW projects on ODE and other sites, and held numerous conversations on and offline about the nature of hosting OSHW projects. Our conclusion after all these years and experience is the same one we held back in 2012: the OSHW community is still searching for a project hosting solution that meets the needs of hardware projects (where documentation is part of the source code).
What has changed is our approach to addressing OSHW project hosting. This time we are starting with the development of a tool independent methodology for developing and sharing OSHW, the Distributed OSHW Framework (DOF). What do we mean by methodology?
The Distributed OSHW Framework will be a systematic approach identifying:
* What needs to be shared
* How it should be shared
* The relationships between the various kinds of shared content
Note how developing a methodology is different from identifying best practices, covering case studies, and creating definitions. A methodology is something one follows; it is a fully defined process. And by targeting tool independence, we can aim for developing a solution that will stand the test of time, just as version control methods have lasted through cvs, svn, and now git.
== The Pillars of the DOF
The Distributed OSHW Framework (DOF) is built upon {{architecture['1-StakeholderNeeds'].size}} pillars. All design decisions for DOF are ultimately derived from one or more of these pillars.
{% for need in architecture['1-StakeholderNeeds'] %}
.{{need.id}}: {{need.name}}
****
{{need.statement}}
****
{% endfor %}
== Methodology Documentation
The methodology is being modeled in a series of YAML files under the `architecture` folder. A script is then used to generate this readme and the DOF architecture document (located in the `dist` folder). See the `docs` folder for material on the format of the architecture YAML files.
Please feel free to join the conversation by posting questions/comments as issues in the http://dof.sliderule.io[DOF repository].
== Related Projects
.Mach 30 Related Projects
* https://opendesignengine.net[Open Design Engine] - legacy OSHW project hosting portal built on https://www.redmine.org/[Redmine]
* http://sliderule.io[Sliderule] - Reference implementation of DOF, being developed in stages
** https://github.com/7BIndustries/sliderule-cli[Sliderule CLI] - Initial component of Sliderule, a command line interface implementation of DOF developed by https://github.com/7BIndustries/[7BIndustries]
.Sources of Inspiration
* http://github.howstr.com/[Howstr] - A project by Matthew Maier to capture how to capture, share, and discover tangible projects
== Further Reading
* https://www.pearson.com/us/higher-education/product/Gibb-Building-Open-Source-Hardware-DIY-Manufacturing-for-Hackers-and-Makers/9780133373905.html[Building Open Source Hardware: DIY Manufacturing for Hackers and Makers] by Alicia Gibb