gistfile1.txt

* Look at how systems researchers look at primarily competitive aspects and assume maliciousness
* Look at "fairness" metrics.
* Distributed systems show us that scaling-up is problematic (inherently centralized). We need to scale-out.
* Trust.

* Perhaps discuss open source politics (gpl-hate)

* Goal: Some technical problems are social problems... therefore some social problems in our community have technical solutions.

Open with social issue stuff, social problems.

There is a social/technical problem that people are scaling-up (technical solution gone awry?)
and losing sight of what is at the bottom. At the bottom is a shrinking community that has
seeded us a particular approach that parallels the types of problems present in modern
software. We believe that there is a strong relationship between the communities of software
creators and the organization of that software itself. (For instance, Linux.) A cultural issue
that promotes a hierarchy of leadership that limits our understanding of how software can
affect a diverse community of potential users and the problems they wish to solve.

Another example is tying funding with "heavy" systems research. DARPA/NSF funding and the
drop-off of nano/exo research. Amount of kernels discussed at major conferences. Amount of
incremental improvements, seeing incremental as low-risk over re-imagining.

The internet has given us a means of organization that radically differs from primarily
centralized models. While the open source community has attempted to embrace this with tools
that do not assume a centralized model, the organization of developers tend to still promote
centralized management. Often this is in part motivated by a lack of trust in terms of skill
where developer skill is assumed to be poor or malicious intent at injecting faulty code or
security backdoors.

A decentralized software infrastructure helps our communities solve problems more effectively.
There are many situations where centralized organizations, of people and code, tend to assume
particular sets of problems or environments. Therefore, when your needs or environment differ,
these systems may act inefficiently or antagonisticly. We do agree with the typical idea that
efficiency is important, however we do not value this metric over the availability of
computation to all.

We believe that to provide an open environment conducive to all solutions we must
drastically reinvision our software infrastructure. These sweeping changes must be at the
bottom casting a shadow on not only all of software built on top but also the social structures
responsible for creating such software. The small, simple and stateless XOmB kernel is merely a
reflection of the underlying hardware and it imposes no undue centralization upon the software
that uses it as a foundation.

We look at the open source culture as one that is ripe for remix, but disappointingly most
code modification is done within the structures and conventions established by the original
authors. Simply taking XOmB and replacing the existing foundation (Windows/Linux) is not our
goal, but to replace the entire software stack. The prevailing fear is that this task can only
be completed by rewriting all of software, yet this is a misunderstanding based upon a cultural
refusal to remix parts of existing code.

While it seems strange, many open source authors are very possessive and resent radical
reappropriation of their code. Authors aggresively fight against requests for improved
flexibility due to the expectation that the authors must then support these changes as additional
work. Also, contributors are often very respectful of those bounds, especially those enforced by                   
copyright. Since these software and organizational bounds are difficult to overcome, users then
create new projects or clone existing ones and establish new goals. Although the effort suggests
that this process is productive, the culture still sees this act as aggressive and competitive.

What we will do is provide the software infrastructure on top of our unintrusive foundation to promote remixed solutions.
Particularly, this will promote radical experimentation that would otherwise require an
infeasible amount of effort to simply get to the point where the project's efficacy can be
evaluated.
The infrastructure will promote minimal computational behaviors over coarsed-grained product
goals.
This is done by initially taking large codebases, cutting out the smallest possible functional
units, giving them a common name, and placing them in a distributed version control.
Now, competing projects may share their common behaviors and simply use the version of either
that are most performant, thus creating an environment of cooperation.
Furthermore, these small pieces of code will be available to all, ensuring that useful code
hidden behind the buerocratic wall of an unrelated project can be used to promote a more diverse
set of solutions.

Close with tie to social solutions.


The software project is divided into two components: a low-level kernel and a set of code that
defines a set of computational behaviors and their expectations. The low-level component,
called XOmB, is a small stateless kernel that makes up initial code your computer executes.
It assumes nothing about your purpose and exposes only the hardware that your machine has
available, hence the pronunciation of 'zombie.'

Our presentation will demonstrate the traditional expectations of such software, in that a
kernel is typically a program that is responsible for delegation of authority for actions
taken by other software. We will take a look at how this constitutes an unreasonable lack
of trust in software and how this becomes an obstacle to experimentation with alternative
means of organizing software and driving diverse solutions through general computation.

We will not shy from explaining the technical workings but we will do so with the aid of
illustrations that are easy for the uninitiated to understand. Our presentation will cover
the bridge between hardware and software and discuss the fine line between security and
efficiency and the logical path from power-up to running a program you have written.

Once you are at the stage where your system can run an arbitrary program written by another,
our next component comes into play. We wish to use most of our existing tools in order to
lower the difficulty of finding existing code by the average user. To that end, we will
establish a organizational model for software that strives to define software not by its
end-goal, as it would be for a product, but rather by the set of behaviors it uses to
accomplish that goal. Our software infrastructure is simply a set of behaviors, what inputs
they expect, and the expectation of their output.

This organization effectively separates code into its smallest functional unit. Now, useful                        
code that typically exists within obtrusively large codebases is available to you. These
large codebases can now be built using a set of these smaller units.

We intend to present using a hypermedia slidedeck. Considering the strong coupling between the
social and technical content, we could make use of two projectors/screens to make this more                        
visual, but this is not essential.