Askemos

Dan Bricklin:

The structure and culture of a typical prepackaged software company is not attuned to the long-term needs of society for software that is part of its infrastructure. This essay discusses the ecosystem needed for development that better meets those needs.

---

Dan Bricklin on the motivation, goals and software-ecologic principles. Recommended read! Quoting the original:

The needs of Societal Infrastructure Software

Let us look at the needs for societal infrastructure software. They include the following:

• Meet the functional requirements of the task.
• Robustness and long-term stability and security.
• Transparency to determine when changes are needed and that undesired functions are not being performed.
• Verifiable trustworthiness of all three of the above.
• Ease and low cost of training for effective use.
• Ease and low cost of maintenance.
• Minimization of maintenance.
• Ease and low cost of modification.
• Ease of replacement.
• Compatibility and ease of integration with other applications.
• Long-term availability of individuals able to train, maintain, modify, determine need for changes, etc.

In short:

The Askemos adheres to those principles. Example: It comes with two competing implementations right from the start. Why? Thereby it escapes the trap to depend on it's own implementation. (Which has the nice side effect to shift the inevitable crowd of software bugs where it belongs: out of the system and over to it's implementation: see ball.askemos.org .)

THE REST IS UNDER CONSTRUCTION: expanding the topics

Meet the functional requirements of the task

The task at application level is to model "interacting processes akin to citizens". Individuals care to keep and exchange information. At least one process (Actor) is exclusively controlled by each user. Actors communicate by message exchange. Transactions as executed according to (machine readable) contracts are non-repudiable.

This covers a broad range of possible applications. No further restriction on the type of contracts are desirable. Therefore the language for contracts must be a general purpose programming language. Otherwise this actors-passing-messages model is simple, well understood and widely deployed.

(Thread model: There is a "current trusted system" the user utilizes to communicate. Assuring that this device/connection is actually under control of the user is out of scope wrt. functional requirements.)

Robustness and long-term stability and security.

1. No dependency on a single implementation including the complete tool chain to build the system. That's why there is not only a single implementation.

   Not to be detailed here: to get rid of any relevant unique dependency on compiler, library or license and test-operate a heterogeneous network made of those variations has taken most of the initial development time.

2. Contracts are to be written once and possibly re-understood a after long time by different individuals. Simplicity and implementation independent definition are therefore of high priority when deciding on the application level language. (Outright to be avoided is the idea to define yet another language. See also "ease and low cost of training and effective use"; any complex language would be just too complex.)

   There is no final decision on any language to me made ever. Any language may be used to write applications. However is an "initial language" required to at least specify the effective language. Or - alternatively - be the effective language. Scheme was selected for it's merits as the hashbang here: it is a very small language - simple to learn; defined by a standard as opposed to any reference implementation; close to the semantics of the functional requirements; simple to implement; does not impose any programming paradigm.

Transparency wrt. Changes - No Undesired Functions

At application level all relevant contract code is also kept in the system as a static document. Replacement procedures may be defined in the contract code, making this as clear as desired. Otherwise there is no change of code.

Changes at the infrastructure/implementation might still break applications. By virtue of most actors running on multiple peers in agreement the damage is mitigated. This allows to test changes better.

Verifiable trustworthiness of all three of the above.

In Plain English

Besides Askemos codifying the "scientific record"… which would be a subclass of "archival record", the art of coding an extensibe, universal ontology for those goes by the names RDF, Dublin Core and derivatives.

That is standard best practise.

Having the majority based integrated audit wrt. updates only enables those "common sense" based safety claims wrt. falsification.

But really proud I am about the modelling of the cultural achievement of self-ownership. This is about 350 years old only in our European tradition. By the ruling that only a strict subset/subprivilege of a privilege can be granted from one entity to another, there is this initial set a user has to start with. It contains the unique permission for this users. Given the subset rule, this cannot be tranfered anywhere by the network.

Now the whole system's security hinges on this fact. And we are pretty well using this unique permission to model the users self-ownership (which in turn is the foundation to derive both the idea of human rights and responsibilty).

My dad once wrote a culture-history essay tracing this back to J.J.Rousseau The Social Contract Or Principles Of Political Right (1762).

This is what Askemos is really about. Requirements and constraints how things should work for the sake of ethics. The software is just for illustration.

---

Just keywords…

Ease and low cost of maintenance.

at dev time a handful persons

Minimization of maintenance.

initial language is avail as in "heterogeneous security" (simple and often implemented)

Ease and low cost of modification.

few changes per decade only…

Ease of replacement.

a.k.a. ease of implementation/modification

ease of testing modifications without risking serious harm

Compatibility and ease of integration with other applications.

"Standard is better than better" - ease of communication trumps personal preferences eventually

Long-term availability of individuals … to …survive.

About 350 years by now. ;-)