Re: [ox] Konstruktives Forking
- From: Jan Krüger <anubis tzi.de>
- Date: Mon, 04 Apr 2005 18:52:51 +0000
Hi,
Erstmal ein Hallo an alle Leute hier auf der Liste. Ich bin vor einiger
Zeit auf das Oekonux Projekt gestoßen, aber bin nie dazu gekommen mich
wirklich mal in Diskussionen einzuklinken, obwohl ich das ganze Projekt
recht Spannend finde.
Da ich mit Benjamin vorhin über das Thema per IM diskutiert habe, nehme
ich das einfach mal zum Anlass mich hier etwas zu beteiligen.
On Mon, 2005-04-04 at 18:08 [PHONE NUMBER REMOVED], Benjamin Teuber wrote:
Nehmen wir als Beispiel einmal die Wiki-Problematik:
Verschiedene Leute haben verschiedene Vorlieben, die für sie anscheinend
so wichtig sind dass sie bereit waren dafür zu Forken (was mir nach wie
vor unverständlich ist - aber egal). Das Ergebnis kennen wir alle:
Lauter verschiedene, halbfertige Wikis an denen verschiedene Grüppchen
den gleichen Content jeweils neu schreiben.
Die eleganteste Lösung für das Dilemma wäre wohl, zwischen
Wiki-Funktionsweise und Content zu differenzieren und die vier Wikis in
irgendeiner Form zu synchronisieren, so dass nur die Eingabe- und
Anzeigeformen sich unterscheiden, der Inhalt aber identisch bleibt.
Wie du weißt stimme ich der Idee grundlegend zu, sehe aber eine
Problematik bei der Sache. Das ganze funktioniert nur sehr schwer
rückwirkend. Hast du erstmal mehrere Forks fehlt dir irgendwann die
gemeinsame Grundlage. Im Falle der Wikis wäre das z.B. die
unterschiedliche Art, in der diese ihre Daten ablegen. Natürlich könnte
man hier einen gemeinsamen Standard ansteuern, obwohl dabei die Frage
wäre ob die Unterschiedliche Funktionalität hier nicht schon eine
gemeinsame Datenbasis ausschließt.
Noch besser als nachträgliche Integration wäre aber, sich vor dem Forken
zu überlegen, was genau man eigentlich anders machen will als der Rest -
und wo man bei der gemeinsamen Linie bleiben will. Die Organisation
sollte dann so gestaltet werden, dass man nur haargenau da forkt wo man
es will (hier das Wiki-Interface), wogegen in allen anderen Punkten
(hier der Content) die Gruppe vereint bleibt.
Auch hier wieder das Problem, dass dein Vorschlag nur so lange Boden
hat, wie der/die Fork/s noch auf einer gemeinsamen Basis fußen können.
Eine Herangehensweise wäre in diesem Beispiel vielleicht die
Contentdaten in einer Art und Weise bereitzustellen die allen Forks
gerecht wird. Das löst zwar nicht das Problem der unnötigen
Datendublikation, aber immerhin das der Contentdublikation.
OK, ich muss zugeben, der Lösungsvorschlag ist sicher etwas
unrealistisch, aber zur Demonstration der Idee reicht es ja.
Wäre eine Organisationsstruktur, die auf solche "Partialforks"
ausgerichtet ist, nicht DIE Lösung schlechthin für alles (Wikis,
Parteien etc.)?
Von dem Wikibeispiel abgehoben finde ich allerdings schon, dass die Idee
was hat ;)
--
Jan Krüger <anubis tzi.de>
Universität Bremen
________________________________
Web-Site: http://www.oekonux.de/
Organisation: http://www.oekonux.de/projekt/
Kontakt: projekt oekonux.de