Following up on the threads of the past couple of weeks, I decided to
sit down and write up what I've concluded from looking at the
possibilities of amateur collaborations making a real contribution to
space settlement.

I started looking at this issue in real detail about three years ago,
when I realized that my dream of mining asteroids required dramatic
reductions in launch costs. The starting point for discussions of
collaborative technology development has to be Eric Raymond's
_The_Cathedral_and_The_Bazaar_, which is online (full text) here:
http://www.catb.org/~esr/writings/cathedral-bazaar/>. Anyone planning
collaborative noncommercial technology development should read this.
Twice. And once more just to be sure :-)

The main point of Raymond's book is that open source software
developers are motivated by two factors: the personal utility of their
work product, and the respect of their peers. The fact that other
people are able to use the product is a unique feature of software that
has made noncommercial software incredibly successful, since others can
modify the code without interfering with its use in the original form.
There is no way to take this model over to hardware completely intact.

The open development model is still applicable, though. As Linus
Torvalds puts it "many eyes make shallow bugs." If I develop some
hardware and it doesn't quite behave as expected, I can get feedback
and insights from people by publishing my results. This is the avenue
that John Carmack has been following. He freely discusses his work on
the Arocket and ERPS mailing lists, and solicits advice and input,
which he applies to his X-Prize vehicle development. He'll freely
acknowledge that the free advice he's received has greatly sped up his
work. Clearly open development can be helpful.

So the question is then what kinds of things can amateurs collaborate
on to help bring the dream of a true spacefaring civilization closer to
reality? I think one of the major problems is that people look too far
down the road, and look at space in too abstract a manner. As long as
we are talking about some hypothetical future, perhaps realized only
after we are long dead, there's a lack of urgency and a willingness to
indulge in outlandish fantasies. When we focus on concrete goals such
as personally traveling into space or building a probe that lands on
the moon we make the vision concrete. Only a concrete vision with real
(though ambitious) goals can really hope to make progress.

I suggest that for amateur collaborations for have any real impact they
need to be ambitious enough to be difficult but tractable enough to
have a plausible chance of success. They also need to focus on
concrete physical things rather than viewgraphs and studies. My
feeling is that the most obvious such goal is to build a suborbital
manned spacecraft such as the X-Prize competitors. There's also the
possibility of building a microsatellite, but getting launched is
tricky unless you're affiliated with an educational institution.

One might argue that building microsats or suborbital spacecraft is not
a major contribution to creating a spacefaring civilization. I
disagree. For one thing, the experience gained is directly relevant to
more ambitious projects. For another, any activity in space by
nongovernmental groups contributes to a paradigm shift in how the
public (and investors) view space. We can't be sure exactly when the
tipping point will arrive, or what the last straw will be, but we can
work to bring it closer.

......Andrew

> The main point of Raymond's book is that open source software
> developers are motivated by two factors: the personal utility of their
> work product, and the respect of their peers. The fact that other
> people are able to use the product is a unique feature of software that
> has made noncommercial software incredibly successful, since others can
> modify the code without interfering with its use in the original form.
> There is no way to take this model over to hardware completely intact.

I agree with your suggestions that relatively small projects
microsatellites or a lunar rover could be good starts for open and free
collaboration.

Here are two more issues to consider in your analysis: simulation and
freedom.

Frankly, I expect most of the collaboration to be about developing
simulations together. That essentially is programming of a sort, and
then the development model related to software then applies to virtual
hardware. I know simulations have their limits (all too well, I spent
years making one that still has numerous flaws), so your statement has
truth to it. Still, there is a lot that can be done in simulation --
especially when using a PC or PC network you can now simulate
interactions on a small scale at the quantum level and at a large scale
of systems with billions of components (just not both at the same time.
:-) Obviously, simulations are more accurate if calibrated periodically
with real world experiments, but still, there is so much real world data
out there on the physical properties of materials that initial
simulations can be developed without an immediate need for experiment.
Also, there is a whole category of simulations related to logistics (to
make a bolt you need a lathe, to make a lathe you need a casting, etc.)
which gives another place to start as well. Obviously, taking your
microsatellite example, at some point you want to do simulations of
radiation interacting with your simulated processor, etc. which might
take a lot of CPU if done in detail...

The other issue relates to freedom, and Eric Raymond, who is more
commercially oriented, doesn't quite do this justice (even the name
"open source software" was put forward as more business friendly than
"free software"). See Richard Stallman
http://www.gnu.org/philosophy/free-software-for-freedom.html
http://www.oreilly.com/openbook/freedom/
http://www.stallman.org/
for another take on this. I'm not so sure the freedom issue is unique to
software; I'd tend to feel it may have shown up there first in the USA
(in large part due to Richard Stallman's tireless efforts at promotion
of the idea as a cause), but it can apply to all sorts of works. People
create for a whole host of good and bad reasons beyond utility and
recognition. Two of these are self expression (think of all the essays
and artwork on the web, accessible at no charge) and charity (e.g. those
habitat for humanity houses), but you can name any virtue or vice and
come up with a rationale of how it could drive creativity. I'll agree
that utility and recognition are perhaps the biggest drivers right now
for software. Still, even given that, the creation of something like
GNU/Linux by emergent stigmergic processes (collaboration coordinated by
an artifact) would not be possible without the use of free licenses such
as the GPL license or BSD license or Public Domain disclaimers.
Regardless of intentions, it is the commitment of work to be issued
under such licenses or disclaimers that allow the works to be developed
collaboratively by volunteers. So the big issue here is "freedom" to
use, redistribute, change, and publish changes.
http://www.gnu.org/philosophy/free-sw.html
Without these freedoms, collaboration is not possible on a volunteer
basis. So, what we are ultimately talking about here is changing the
culture of at least some of space engineering -- from one focused on
proprietary works (even at NASA!) to one focused on free works. And
there is nothing about freedom that says it has to be for no price or
non-commercial -- doctors and lawyers and accountants and engineers use
free information and free standards every day to craft custom solutions
for clients for which they charge hefty fees.

--Paul Fernhout

For a counter example just to show the more typical situation and why
upfront agreement to free licenses are so important, many years ago as a
contractor I developed software to make GUIs easier to build in
VisualWorks Smalltalk for a insurance company, but much as I'd like to
continue to view and use and improve and distribute that code, I can't
because of restrictive licensing agreements resulting in my not having
access to it or any right to do such things. Sure, I might try to
reinvent all those many months of work and refinement (including by
others) but I don't have the time or energy for doing it over... While
at some point the company might release the code back to me when it is
of no big value to them anymore, at that point, it may not be of much
value to anyone else, as alternatives replace it. So in this case, the
spirit is willing, but the license is weak. :-) [By the way, note that
if I lived in some European countries, my rights as an author would have
been better protected (if I understand that correctly) and I might still
have been able to retain access to some of the code; the difference is
also one of culture in terms of what are expected in contract
negotiations.]

One difference between then and now is that had I developed that code
now, the company I did it for might have been more willing to consider
an argument for freeing the source code to reduce their maintenance
costs, because these ideas of voluntary collaboration have spread among
programmers and their managers as a culture.

[And now for some gratuitous NASA bashing from frustration!]

Eventually that free culture may spread completely through NASA, and we
won't be faced with the paradox of a government agency losing engineers
(according to a slashdot post I read long ago) because they can't stand
to see their work put on a shelf and the patents and copyrights they
produce kept proprietary and sold off.

Two examples:

http://tech-transfer.larc.nasa.gov/patent.htm
"NASA owns over 1,000 patents and patent applications which protect
[from whom? from what? from use?] inventions in hundreds of different
subject-matter categories. ... All NASA licenses are individually
negotiated with the prospective licensee, and each license contains
terms concerning commercialization (practical application), license
duration, royalties, and periodic reporting."

http://www.openchannelfoundation.org/cosmic/
Example license excerpts for "DET MPS: The GSFC Energy Balance Program,
Direct Energy Transfer/Multimission Spacecraft Modular Power System"

"This software requires that you print out a license agreement, sign
it, and fax it to Open Channel Foundation [before downloading]"

"Specifically regarding the right to modify the Software, RECIPIENT
may make Modifications to the Software only for non-commercial, private
internal purposes."

So, the software is a dead end for all practical purposes even when you
can get the source code after a hassle. It is not free. All those tax
dollars and late nights by engineers giving their all to help humanity
get into space -- and it's pretty much wasted as it produced an artifact
that can't evolve. [It's not entirely wasted as some learning went
on...] And if I try to write something similar after agreeing to that
license and purusing the source code to get some ideas, I've set myself
up at risk for a copyright infringement lawsuit, because copyright is so
broadly construed these days to include anything similar in structure
etc., way past the original intent in the US Constitution.

All NASA had to do was put the darn thing on a web site in the public
domain or GPL or another free license, but instead they pay probably pay
megabucks to a "non-profit" and retard space sttlement in the process.
Why? It's just so sad -- it's a mindset. Maybe NASA is so busy trying to
ensure it can prove it is useful from patent revenue and signed licenses
that it is ensuring it is useless.

In any case, I think a tangent to a collaborative effort could be to get
NASA and other public agencies to make their R&D freely available.
NASA's got useful knowledge if it can just be pried out of the
orgnaization and set free.

--Paul Fernhout

>
> I agree with your suggestions that relatively small projects
> microsatellites or a lunar rover could be good starts for open and free
> collaboration.
>
> Here are two more issues to consider in your analysis: simulation and
> freedom.

Simulation I think is possibly good, but it requires discipline to
remain relevant. There's a danger of wandering off into video-game
land. Ideally simulation is tightly coupled to experiments. If small
scale experiments are used to validate the results of the simulation,
then the results from simulation of larger scale devices are worth a
lot more.

> Regardless of intentions, it is the commitment of work to be issued
> under such licenses or disclaimers that allow the works to be developed
> collaboratively by volunteers. So the big issue here is "freedom" to
> use, redistribute, change, and publish changes.

This is a good point. I'm concerned about the fact that a lot of
spaceflight technologies are dual-use, with significant military
applications. This is particularly true of anything related to
rocketry. This isn't a purely theoretical concern for me since I'm
actively involved in collaborative development of rocketry related
technologies (specifically a rocket engine igniter and a cold gas
thruster system). I don't know what the solution is other than to
proceed with caution and try to avoid publication of things that might
make it simple to use the collaborative work to cause harm.

......Andrew

>
>>The main point of Raymond's book is that open source software
>>developers are motivated by two factors: the personal utility of their
>>work product, and the respect of their peers. The fact that other
>>people are able to use the product is a unique feature of software that
>>has made noncommercial software incredibly successful, since others can
>>modify the code without interfering with its use in the original form.
>>There is no way to take this model over to hardware completely intact.

I should also add that if/when we do get nanotech replicators, all
hardware will essentially be a program which tells the replicator how to
make it. :-) As it is now, CNC machines etc. take programs that tell
them how to make things. As do photolithography system (well, more like
a series of bitmaps for them...), etc. So in practice, most manufactured
things depend on programs plus directions for assembly (another
program). Now it is true many of those programs are designed as
blueprints, and the programs for many older items exist only as
blueprints... I know I'm stretching the concept of what is normally
thought of as a "program" but that's actually my point. The major
difference is that a computer program typically runs entirely on the
machine (or maybe interacts with one use in a symbiotic fashion) whereas
a blueprint type program to make something often require multiple people
and various types of equipment to be excecuted, and also often relies on
lots of unstated information assumed by the people takign part in
running the physical program (like how to drill a hole etc.).

--Paul Fernhout

> This is a good point. I'm concerned about the fact that a lot of
> spaceflight technologies are dual-use, with significant military
> applications.

This is actually the single biggest issue that has stopped me from
putting up a live web site and such related to this project, such as
prototyped in text on this web page:
http://www.kurtz-fernhout.com/oscomak/prototype.htm
Designs for explosives, weapons, poisons, and illegal drugs are the
biggest immediate worries that come to mind. In that paper prototype I
have an example of someone adding a "stink bomb" design and it being
deleted.

[The second big issue is policing such a site for illegal or immoral
digital content others might deposit on it like Madonna MP3 files etc.
or handling offensive Spam -- but in practice that is probably more
controllable, as just about every public web site has that same problem.]

I don't think there is a very easy solution to the dual-use problem to
such a system if it is open to the world. Still, here are three
approaches to this, and all are strengthened by various disclaimers not
to misuse the information and to use it at your own risk, etc.

1. Self Censorship. Just state at the start that nothing related to
obvious explosives, weapons, or poisons will be allowed. If specific
information is entered, it is immediately deleted (see the "stink bomb"
example above). Designs might reference explosives and poisons (for
agriculture?) and weapons (magnetic rail guns?) as subcomponents, but
the designs for the key dangerous subcomponents would not be in the
system. That is similar to how newspaper reports or movies about of
suicides often leave out key information. This gets onto shaky ground
for many reasons, but still might be a workable initial policy. So you
can discuss rocket guidance design but not propellants. Maybe that
rocket example is a bad example. :-) But maybe 90% of manufacturing
could be talked about. Of course, NASA's 1980 summer study relied
heavily on a hydrofluoric acid leach process for mineral separation, and
HF is nasty stuff (say if somebody wanted to throw it in someone's
face), so it is hard to know where to draw the line. Still, it might be
possible to have a self-censorship policy, and discussions about this,
that allowed such a project to proceed -- at least up to some point.
Deleting content does pose problems for a couple of reasons.
Technically, if a system allows complete deletion of information it will
not maintain a complete archive and so this feature may be intentionally
or unintentionally used to cripple the site (unlike a Wiki with all old
histories which can be used to reconstruct in case of vandals). IANAL,
but from what I read, legally, it seems a site that decides to actively
censor become more responsible for content that remains in the case of
even one slip up than one that like Slashdot http://slashdot.org/ that
just claims it is more like a common carrier and employs some form of
up/down moderation to hide offensive or offtopic stuff.

2. Collaborative private workgroups (making a cell structure for the
coworkers). There already exists software that allows peer-to-peer data
sharing where all the people are know to each other in some way (even if
they might sometimes remain unidentifiable as far as true name) -- and
one could add a provision at the creation of a workgroup that all the
information shared or developed by the workgroup would be under a
specific free license. Then the decision to share some or all of the
information to another workgroup or publish it on a world readable web
site is made consciously by someone in the workgroup at some point in
time. In this way, the human aspect of the system sort of can control
some part of the distribution -- essentially saying, yes this
information is under a free license if you get it, but we still only
give it to people we trust to use it well if we think it is sensitive
for some reason. Some information which is generally thought to be low
risk (hydroponics?) might be more openly distributed. (Of course,
marijuana growers sometimes employ hydroponics...) Designs for cruise
missiles you can build in your home might be less readily shared (not
that you can't already find that kind of info pretty easily...)
http://www.interestingprojects.com/cruisemissile/
So, this is sort of the "Star Trek" prime directive philosophy of "we
won't share our technology unless we think you are ethically advanced
enough (but once you get the technology we'd never restrict what you can
do with it)". These workgroups might even be local web sites accessible
only on an intranet, such as in a school where a local teacher is
responsible for censoring the content, and then the end results might
get passed onto a larger public archive site. So, these workgroups could
feed results into the option #1 above of self censored web sites.

3. Peer-to-peer free for all. In such an approach, potentially anonymous
contributors submit designs for anything at all to a peer-to-peer
network, perhaps with a system of plausible deniability (such as using
multiple XOR'ed random chunks to store a plan) helps protects users and
intermediate distributors of content. Since, like Usenet, such a system
woudl have substantial productive value to make useful things,
presumably it could not easily be shut down. It would not be clear who
the liability was on for misuse of information or where the jurisdiction
of liability was. Ultimately, this is the sort of system one might
expect will emerge, but it may have various public faces such as in
options #1 and #2 above. There are already numerous peer-to-peer systems
for distributing content (Gnutella, etc. ),
http://www.openp2p.com/
so this system might piggy back on one or more of them. Or this system
could piggyback on Usenet somehow as a new newsgroup, with or without
encoding of designs. Still, there are technical issues for avoiding such
a system getting polluted with junk and so on, especially since any well
functioning system would probably have some form of trust or other
valuation ratings associated with contributions and/or contributors.

Note in all cases, national border crossings of internet data also
create potential headaches, especially for people in the USA dealing
with export restrictions, and other contributors from various countries
might argue over what was sensible to make available. Self-censorship
tries to avoid the problem (although you never know what may be illegal
in some jurisdiction -- maybe syringe designs in places with a lot of
heroin users...). Private workgroups tries to finesse the problem.
Peer-to-peer plausible deniability tries to brute force route around the
problem. Likely some combination of all three (plus other ideas) will
emerge long term.

Still, this liability issue is another reason why for liability reasons
an existing non-profit or operating foundation might be loathe to take
on this sort of project in its entirety (as opposed to collaborating on
or donating to specific subparts). A non-profit with other activities
might put at risk other efforts they engage in (like the SSI conference
if SSI gets sued over a cruise missile design someone puts into the
system). So this is a reason for SSI not to bring such work in house
unless it was 100% dedicated to the new direction. The money to make a
non-profit is as far as I am concerned not an issue (I can donate $1K or
so to cover those initial expenses) but it is hard to start a new
organization from scratch, especially one facing these sorts of extreme
dual-use liability issues (where you can be assured someone sooner or
later will get hurt and blame it on the organization). So, in some ways
I'm leaning more and more to having no organization at all, especially
since a lawyer (I paid) advised me that essentially non-profit liability
protection doesn't really extend to the people doing the actual work.
For example, I, as a board member, would remain at personal risk for any
content contributions I make to such a system, even if I had limited
liaiblity for larger operating decisions. Although, perhaps, I might be
protected to some extend by laws related to limiting the liability of a
volunteer actign in good faith. Still, a non-profit allows for somewhat
easier fund raising using tax-deductable donations, provides a
convenient place to hang one's hat in social interactions, provides some
credibility in presenting a project to the rest of the world, and so on,
as well as maybe reduces some obvious liabilities (while bringing about
other ones of dealing with other board members actions, disagreements, etc.)

--Paul Fernhout

> One might argue that building microsats or suborbital spacecraft is not
> a major contribution to creating a spacefaring civilization. I
> disagree. For one thing, the experience gained is directly relevant to
> more ambitious projects. For another, any activity in space by
> nongovernmental groups contributes to a paradigm shift in how the
> public (and investors) view space. We can't be sure exactly when the
> tipping point will arrive, or what the last straw will be, but we can
> work to bring it closer.

There are several activities that I thought about in relation to the
Biosphere 2 effort (which I am still working on):
1. The work breakdown structure. This would greatly expand the
matrix that SSI started years ago.
2. Visual Inspection robots.
2a. Visual scene to database base model.
2b. WiFi and GPS integration to remote control.
2c. Remote Control user interface with database augmentation.
These are all mostly software projects that only need a server, which I
have, to start. There are a number of small USB cameras that could be
integrated to a small mobile platform so that there could be something
where developers could quickly see some fruit of their labors. Also
these are easier to start and do than microsats or rocketry.

I am a little more concerned with being ready for low cost access to
space than with doing something about low cost access. If one of the
technologies like "Liftport" works out in the next ten years, what are
we going to send up to do the work? I would like to see every possible
piece of equipment of a raw material to space habitat assembly line
tested out on Earth before we actually have the resources to send the
seed into space.

Mitchell James
mejames@...
www.InnerTransit.org (Home base for collaborative engineering on the web)