-
Notifications
You must be signed in to change notification settings - Fork 1
/
index.html
210 lines (189 loc) · 12 KB
/
index.html
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
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
<!DOCTYPE html>
<html>
<head>
<meta charset='utf-8'>
<meta http-equiv="X-UA-Compatible" content="chrome=1">
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">
<link href='https://fonts.googleapis.com/css?family=Architects+Daughter' rel='stylesheet' type='text/css'>
<link rel="stylesheet" type="text/css" href="stylesheets/stylesheet.css" media="screen">
<link rel="stylesheet" type="text/css" href="stylesheets/github-light.css" media="screen">
<link rel="stylesheet" type="text/css" href="stylesheets/print.css" media="print">
<!--[if lt IE 9]>
<script src="//html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
<title>gdo by stevegt</title>
</head>
<body>
<header>
<div class="inner">
<h1>gdo</h1>
<h2>Governance of Distributed Organizations</h2>
<a href="https://github.com/stevegt/gdo" class="button"><small>View project on</small> GitHub</a>
</div>
</header>
<div id="content-wrapper">
<div class="inner clearfix">
<section id="main-content">
I originally threw this site together
for discussions with
<a href=https://makezine.com/2016/08/31/makerspace-organizers-convene-at-the-white-house/>
a couple hundred close friends
</a>
at the White House in August of 2016 -- that meeting led to a joint effort to move the
<a href=https://obamawhitehouse.archives.gov/nation-of-makers>Nation of Makers</a> functions
out of the executive branch and into <a href=https://nationofmakers.us/>an independent non-profit</a>
three months later. For now I seem to have become the unofficial and defacto "RFC
editor" for this new organization -- more on that in a moment.
<hr/>
<p/>
I've always thought that, for better or for worse, systems and organizations shape each other. A federated
system supports a community and tends to be described in terms of format, algorithm, and protocol. Anyone
can participate in development, and resources are mutually shared; no single person can veto an experiment
in innovation or growth. This is a powerful idea.
<p/>
Contrast this with a centralized system, which today tends
to be described in terms of a URL, a server, and the single organization that owns it. In a centralized system,
the owning organization must ultimately make the decisions and pay all the bills. Sole ownership creates an
unavoidable time and funding bottleneck, stifling independent innovation and growth.
We see these limitations play out over and over again in large enterprises, and most
startups, whether for-profit or not, fail due to these natural limits on execution. Conversely, those startups
that do succeed tend to be those that rely in some way on network effects.
<p/>
The Internet's early developers stumbled into a system and organizational design where anyone can contribute,
where decisions are made by rough consensus, and where both innovation and expenses are distributed. The
<a href=https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force>Internet Engineering Task Force</a> is
the organization that loosely steers the development of the Internet, and is
an unincorporated all-volunteer community with <a href=https://www.ietf.org/newcomers.html>no membership
list</a>. The IETF uses the <a href=https://en.wikipedia.org/wiki/Request_for_Comments>RFC</a> process for
decision-making. For those things that absolutely must be centralized, such as renting conference venues,
IETF members formed the non-profit <a href=https://en.wikipedia.org/wiki/Internet_Society>ISOC</a>
to act as their legal and financial representative.
<p/>
I've spent a few decades trying to figure out how to apply these lessons learned to small projects and companies
("small" being defined as anything smaller than the Internet). A useful question is: <b>If we were to start an IETF-like organization today, using current technologies,
what would it look like?</b> The answer to this question has been a moving target as long as I've been asking
it, mostly because of the rapid evolution of technology itself. But I think two related events form cusps in
the target's trajectory: First, strong cryptography was demilitarized by <a href=https://www.gpo.gov/fdsys/pkg/FR-1996-11-19/pdf/96-29692.pdf>
Executive Order 13026</a>. Next, the resulting
innovations in cryptography then enabled practical
distributed systems, ranging from secure use of the web to
decentralized financial systems. For all of the attention
the latter has been getting in recent years, I believe we
are still seeing a technology in its infancy.
<p/>
Despite the hype currently surrounding cryptocurrencies, I think it's safe
to say that, if an IETF-like organization were established today, it's entirely possible it would use a
distributed ledger with crytographic hash chaining to preserve and
provide storage of record for both docs and code, as well
as for hosting the workflow of
consensus formation and decision-making.
Many of the protocols and procedures
which make up the Internet would be completely different
if created today -- easy examples are the registration
systems for
<a href=https://tools.ietf.org/html/rfc1466>IP addresses</a>,
<a href=https://tools.ietf.org/html/rfc1032>domain names</a>, and
<a href=https://tools.ietf.org/html/rfc1422>SSL certificates</a>. Making these more decentralized has
always been a struggle, because we did not historically
have a legal foundation allowing the cryptography needed
to build secure distributed systems.
<p/>
Our hypothetical blockchain-based IETF might do much of its own computing using
<a href=https://en.wikipedia.org/wiki/Ethereum#Ethereum_Virtual_Machine>distributed virtual machines</a>, with
libraries of algorithms implemented as "serverless" <a href=https://aws.amazon.com/lambda/>lambda</a> functions
hosted on a blockchain. It's likely that the reference implementations of common protocols would be executed
directly this way.
<p/>
Last but not least, the IETF is already a rudimentary
<a href=https://en.wikipedia.org/wiki/Decentralized_autonomous_organization>decentralized autonomous organization</a>,
held together by the RFCs as well as <a href=https://www.ietf.org/tao.html>customs and courtesies</a> that are
generally accepted
by the community. If re-implemented today, much of this workflow could likely be implemented as
<a href=https://en.wikipedia.org/wiki/Smart_contract>smart contracts</a>. As of today we may not know how to
overcome the security concerns that exist in complex persistent contracts; a lot of people are working
on this though. I have some ideas myself, and plan to describe some of them here.
<p/>
The chicken-scratchings in this git repository are my own feeble attempts to answer these "what if"
questions
for my own businesses, as well as for the other organizations I am involved with and may be able to
foist this stuff upon.
The original repo contents came from me pulling
together code from various directories on my hard drive, putting most of
it in the <a href="https://github.com/stevegt/gdo/tree/master/lab">lab directory</a> for now.
If you are interested in either helping to develop
or in being a guinea pig for this project, then interact with
the github project in some way, or ping me @stevegt on twitter. If
you are one of the NoM folks, you should also be able to reach me
via slack.
<h2>
<a id="roadmap" class="anchor" href="#roadmap" aria-hidden="true"><span aria-hidden="true" class="octicon octicon-link"></span></a>Roadmap</h2>
<p>A distributed-ledger system suitable for hosting smart contracts and
running on IoT devices. A few example applications:</p>
<ul>
<li>Organizational governance</li>
<li>Workflow</li>
<li>Training and certification</li>
<li>Accounting</li>
<li>Inventory control</li>
<li>Door access control</li>
<li>Machine lockout</li>
<li>Membership</li>
<li>Reservations</li>
<li>Data storage and backups</li>
<li>Operating system and disk image management</li>
<li>IoT </li>
</ul>
<p>We accomplish all this using a (relatively) simple model: Distributed
applications (dapps) running in Linux containers managed by a
distributed ledger, hosted in a distributed version control system
that performs content-defined chunking to store and ship around large
blobs, including the container images themselves.</p>
<p>The development roadmap, then, is (relatively) straightforward:
Implement things in reverse order of the above paragraph. Beg,
borrow, and paste where possible, take advantage of existing code and
libraries such as libcontainer, ledger-cli, and libgit2, and become
self-hosting early.</p>
<p>Compared to e.g. Ethereum or HyperLedger, we target more of
a git-like version control model, allowing forking and interbranch
consensus, rather than a single linear blockchain. For
turing-complete smart contracts, we simply use Linux containers --
this allows dapps to be written in any language executable on Linux.</p>
<p>We'll use test-driven consensus (proof of merge), where new blocks are
tested by one or more dapps, rather than use a hardcoded proof-of-work
algorithm. Not requiring a compute-intensive proof of work means
single-board computers such as BeagleBone or Raspberry Pi can host
full nodes.</p>
<h2>
<a id="example" class="anchor" href="#example" aria-hidden="true"><span aria-hidden="true" class="octicon octicon-link"></span></a>Example</h2>
<p>Maker space door access control, for instance, could be based on an
existing open source project such as
<a href="https://github.com/makeitlabs/doorbot">https://github.com/makeitlabs/doorbot</a>, living in a container, with
modifications to have it communicate with membership, accounting, and
certification dapps, each in their own containers. All of this runs on localhost, as opposed to talking
to a central SQL db on a server somewhere else. Each door can have
its own Raspberry Pi-sized host. These will check and log access
events as usual even during network outages, and the
distributed consensus protocol will merge records when the network
comes back up.</p>
<h2>
<a id="references" class="anchor" href="#references" aria-hidden="true"><span aria-hidden="true" class="octicon octicon-link"></span></a>References</h2>
<p>Shares a few concepts with HyperLedger, Ethereum, Docker, Ledger-cli,
git, and git-annex. Builds on earlier work and prototyping at
github.com/stevegt/librabinpoly and github.com/stevegt/git-devops.</p>
</section>
<aside id="sidebar">
<a href="https://github.com/stevegt/gdo/zipball/master" class="button">
<small>Download</small>
.zip file
</a>
<a href="https://github.com/stevegt/gdo/tarball/master" class="button">
<small>Download</small>
.tar.gz file
</a>
<p class="repo-owner"><a href="https://github.com/stevegt/gdo"></a> is maintained by <a href="https://github.com/stevegt">stevegt</a>.</p>
<p>This page was generated by <a href="https://pages.github.com">GitHub Pages</a> using the Architect theme by <a href="https://twitter.com/jasonlong">Jason Long</a>.</p>
</aside>
</div>
</div>
</body>
</html>