Revision as of 21:52, 6 August 2006

A-connect ist der (vorläufige) Name eines Vernetzungsprojekts, das mittels über das Internet verteilter Datenbanken (mit von lokalen Kollektiven betriebenen Knotenpunkten) das Teilen von Ressourcen (Gütern, Fertigkeiten, Zeit, ...) erleichtern und so zur Überwindung von Warenökonomie und Entfremdung im täglichen Leben beitragen will. Auf lange Sicht sollen die Informations- und Kommunikationswerkzeuge des Projekts auch eine Organisation der Versorgung (Produktion und Transport) jenseits der Warenökonomie ermöglichen.

Projektübersicht

Projektidee

Dieses Projekt wurde beim A-Camp06 geboren. Die Ideen dazu waren schon verschiedentlich vorhanden.

Frei definierbare Datenstrukturen

Die bisherigen Internet-Projekte, die sich mit Umsonstökonomie beschäftigen (s. Liste verwandter Projekte unter Weblinks), verwenden eine fest vorgegebene Datenstruktur, d.h. im wesentlichen sind es Tabellen, deren Spalten fest vorgegeben sind. So kann mensch beispielsweise in einer Mitfahr'börse' den Start- und Zielort und den Startzeitpunkt eingeben, oder danach suchen; sucht mensch aber z.B. auch eine Schlafgelegenheit, so muss mensch derzeit in einer anderen Datenbank suchen, denn die Tabelle hat eine andere Spaltenstruktur. Die grundlegende Idee ist nun, den BenutzerInnen die Freiheit zu geben, die Tabellenstrukturen nach ihren Bedürfnissen selbst zu definieren und für frei wählbare Gruppen von BenutzerInnen zum Lesen/Schreiben freizugeben. - Zur Orientierung sollen von den NutzerInnen allgemein anerkannte Definitionen in einem peer-review-Verfahren ausgearbeitet werden.

Netzwerk

Ausserdem sollen die Daten nicht auf einem zentralen Server liegen, sondern auf mehreren von den Knotenrechnern, die übers Internet zu einem Netzwerk zusammengeschlossen sind, und jeweils vom lokalen Kollektiv betrieben werden.

Projektziele

• Programmierung
• nutzbringende Datenbasis
• Ãœberwindung des (abstrakten) Werts in vom Kapitalismus zugestandenen Freiräumen
• gesellschaftliche Umwälzung (ja, anspruchsvoll, aber ist ja langfristig)

FAQ

TBD (schreib deine Frage, und wenn du die antwort weisst, auch die!)

Projektplan

Schritt 1: Vorbereitung

• Konzept ausarbeiten (hier auf dieser Seite)
• Suche nach Leuten, die mitmachen wollen
• Lizenzfrage klären
  • Liste mit skills erstellen, die für das Projekt gebraucht werden.
• Kommunikations- und Entwicklungsinfrastruktur einrichten
  • Projekt bei sourceforge.net anmelden
  • mailinglisten, zunächst eine, via sourceforge
  • bei Bedarf evtl. chat
  • als Einstiegspunkt vorerst diese anarchopedia-Seite
  • Versionierungssoftware verwenden (subversion oder cvs)
  • Dokumentation: im Code und in einem wiki
  • bugtracking tool von sourceforge nutzen
  • Projekt-Terminologie im wiki erklären (Einstieg leicht machen)
• Datenmodell sorgfältig ausarbeiten
  • Theorie der Wissensrepräsentation: Möglichkeiten und Grenzen von objektorientierter Herangehensweise, Rolle von Relationen, ...
  • evtl. ExpertInnen zu Rate ziehe
  • erwartete Performance (bei späterer Verwendung einer verteilten Datenbank) diskutieren und abschätzen
  • Datenmodell gut dokumentieren
• grundlegende Funktionalitäten spezifizieren
  • Einloggen
  • Eingabemöglichkeiten
  • Suchmöglichkeiten
  • automatische Benachrichtigung bei Treffern (watchlist)
• soziale Funktionalitäten spezifizieren
  • Vertrauensmodell, -netzwerk: Vertrauen soll keine Ersatzwährung werden!
  • Bewertungen von NutzerInnen (aud einer Art Schulnoten-Skala o.ä.) soll es nicht geben, dafür die Möglichkeit, Volltext-Kommentare zu formulieren, bzw. bestehenden inhaltlichen Kommentaren einfach per Knopfdruck zuzustimmen.
  • Kommunikationsfunktionen: zunächst per email, später auch Funktionen für gemeinsame Diskussionen/Entscheidungsfindungen/Abstimmungen? : Forum mit Datenbank verknüpfen? Oder mehr Funktionalität?
  • peer review Verfahren: Eine gewisse Anzahl (50?) zufällig ausgewählter NutzerInnen entscheidet darüber, ob ein Vorschlag für eine allgemein anerkannte Definition akzeptiert wird. Die Entscheidung betrifft nur die Verknüpfung einer Definition mit einem Begriffsnamen, hat somit keine erhebliche inhaltliche Bedeutung.

Schritt 2: Programmierung ohne verteilte Datenbank

• modularer Aufbau
• Client (webbrowser-GUI): PHP
• Server: C++
• DB: Postgres (oder MySQL)
• Target system: Debian GNU/LInux
• Projektsprache: Englisch
• Schritte
  • Software-Spezifikation
  • Interface-Definitionen
  • Objekt-Design
  • Test-Design
  • User-Interface
  • Pseudocode
  • Programmierung
  • mehrfache Wiederholung der letzten 4 Schritte
  • Fehleranalyse und -beseitigung
• Version 1.0 sollte stable und feature complete in Bezug auf Schritt 2 sein.

Schritt 3: Eingabe von Daten

• Objektdefinitionen eingeben: Zunächst nicht als allgemein anerkannte Definitionen, sondern als Definitionen einer 'init'-Gruppe; später können die Definitionen allgemein anerkannt werden.
• Objektinstanzen eingeben: Erst wenn eine kritische Menge von Informationen im System ist, ist der Nutzen (und darum geht es ja) für NeueinsteigerInnen größer als der Aufwand (suchen ohne Treffer ist nicht erheiternd).

Schritt 4: Veröffentlichung

• Bekanntmachung in interessierten Kreisen
• Suche nach weiteren InteressentInnen bei der Programmierung

Schritt 5: Programmierung mit verteilter Datenbank als Backend

• _
• Version 2.0 sollte stable und feature complete in Bezug auf Schritt 5 sein.

Schritt 6: breite Veröffentlichung

• Bekanntmachung in breiten Kreisen (am besten im Schneeballsystem)
• 'signifikante' gesellschaftliche Auswirkungen
• schrittweise Umstellung der Versorgung (Transports und Produktion)

Roadmap and Milestones

2006-07-17

Projekt gestartet

2006-10-01

Schritt 1 sollte fertig sein

2007-04-01

Schritt 2 sollte fertig sein

2007-06-15

Schritt 3 sollte fertig sein

2007-07-01 bzw. zum A-Camp2007

sollte Schritt 4 passieren

Datenmodell

Objekte: Klassen und Instanzen

Die Herangehensweise, die Welt in voneinander getrennte, unabhängige Objekte einzuteilen, hat sicher ihre Grenzen, ist aber andererseits auch nützlich und hat den Vorteil, dass Rechenmaschinen (Computer) Objekte mit den gleichen Eigenschaften gleich behandeln können. - Und das ist ja genau das, wofür Computer da sind: den Menschen die unkreativen, seriellen Tätigkeiten abnehmen. Entscheidend ist, dass die Menschen die Kontrolle über die Maschinen behalten. Dafür ist eine klare, durchschaubare Struktur der Software nötig.

Objektklassen

Eine Objektklasse ist sozusagen eine Schablone, die die wesentlichen Eigenschaften eines Gegenstands beinhaltet. Z.B. bei einer Flasche das Volumen und die Farbe; welche Eigenschaften mensch als wichtig ansieht, hängt vom angestrebten Nutzen/Zweck ab. Ein anderer (nicht-materieller) Gegenstand wäre z.B. ein Projekt, das ein Ziel und TeilnehmerInnen als Eigenschaften hat.

Objektinstanzen

Während die Objektklasse nur eine Schablone ist, sind die Instanzen die eigentlichen einzelnen Gegenstände, die in die Schablone passen, z.B. die blaue 1-Liter-Flasche oder das Flüchlingsprojekt von Anna, Bernd, Claus und Doris.

Vererbung

Da mensch sowohl aus Tassen als auch aus Gläsern oder Bechern trinken kann, macht es Sinn, ein Trinkgefäß zu definieren, das die gemeinsamen Eigenschaften aller drei Klassen hat. Tassen, Gläser und Becher sind dann abgeleitete bzw. Kind-Klassen der Klasse Trinkgefäß und erben die Eigenschaften von Trinkgefäß.

vordefinierte Eigenschaften

Jedes Objekt hat diese Eigenschaften:

• zeitlicher Gültigkeitsbereich
• räumlicher Gültigkeitsbereich
• thematischer Zusammenhang

Damit lassen sich Objekte bei einer Suche schon mal stark eingrenzen.

Relationen

TBD

Gruppen und Zugriffsrechte

Alle BenutzerInnen sollen die Möglichkeit haben, für ihre Zwecke (oder auch für andere) BenutzerInnen zu Gruppen zuzuordnen und diesen Gruppen Lese- oder Schreibrechte für einzelne Objektklassen oder -instanzen zu geben. (vgl. das Konzept von phpgacl)

Kommunikationsfunktionen

TBD

Nutzung bestehender Datenquellen

Die Struktur der Software ist so beschaffen, dass sie den NutzerInnen möglichst viele Freiheiten beim Speichern, Abrufen und Teilen ihres Wissens lässt. Daher sind kaum fest vorgegebene Datensammlungen nötig. Ausnahmen sind etwa Geodaten oder Sprachdaten für die GUI. Denkbar ist es auch, etwa die allgemeinen Objektdefinitionen mit Einträgen in Wikipedia zu verknüpfen.

freie Datenbanken

• Geodatenbanken (Recherche nötig)
• freedict
• Kategoriensysteme für Güter? (vgl. ebay)
•  ?

Mashups

Hier ist eine unvollständige Liste möglicher [Mashup]s, die wir (anfangs) mitnutzen könnten:

• google maps
• wikipedia
• anarchopedia
• wordnet
• amazon (Datenbank für Literatur, die mit ISBN veröffentlich ist)
•  ?

siehe auch

• Solidarökonomie
• Umsonstökonomie

Weblinks

Projekte mit ähnlichen Zielen

• [Nutzigems (NutzerInnenGemeinschaften)]
• [geldlos.at (Ressourcenpool und Kostnixladen)]
• [alles-und-umsonst.de]
• [bye-buy]
• [Umsonstnetzwerk Berlin] [s.a. hier]
• [leihnetzwerk.de (nutzt software von DLP, distributed library project)]
• [OpenDB (Open Media Lending Database)] [demo (test:test)]
• [autoorganisation.org] Liste von Umsonstökonomie-Initiativen und -Projekten

s. ausserdem:

• [Couchsurfing]
• [Bücherwiki]
• [Buchwelle]
• [infoanarchy] Ideen zu P2P
• [borrowme.com] kommerzielles Leihsystem

Informatik

Client-Server-Systeme

verteilte Datenbanken

• [GOODS (objektorientiertes, verteiltes Datenbanksystem)]
• [Network distributed databases]

Kategorie:Internet Kategorie:Wertkritik Kategorie:Ökonomiekritik Kategorie:Emanzipation Kategorie:Revolution Kategorie:Alltagsleben