Hallo Lutz,
Lutz Falkenburg (irrsinn.de gmbh) schrieb:
Na, ein Open Source Projekt unterstützt man ja nicht nur wegen einer
Einzelanpassung sonder er schrieb ja KUNDEN und damit ist vermutlich
gemeint, dass die 2.500 € für mehr als einen Kunden investiert wurden
bzw. auch zukünftigen Kunden zu Gute kommen sollten, was nun nicht
mehr so sein kann/wird.
Du meinst, er darf das jetzt bei zukünftigen Kunden nicht mehr einsetzen?
Ich wüßte nicht, warum.
Das wäre dann ärgerlich für Dich. Allerdings nur, wenn das neue System
nicht durch bessere Strukturen Erweiterungen und Anpassungen mit viel
weniger Aufwand möglich macht. Denn erst, wenn Du mehr willst, als
heute,
müßtest Du ja umsteigen, bis dahin kannst Du ja die vorhandene
Software
einsetzen.
Dann ist es aber auch kein Problem zu einem Projekt mit neuem Namen zu
wechseln 
Technisch wäre das kein Problem. Nachdem die Anzahl der Entwickler, die an
eGroupware arbeiten, aber ohnehin eher klein ist, wäre es ein ziemlicher
Blödsinn, die ohne Not zu verkleinern.
Der Rest ist doch schon wieder die blanke Hoffnung.
Wenn Du Sicherheit haben willst, mußt Du bezahlen.
Das ist so natürlich auch nicht richtig. Für das investierte Geld
gibt’s ja
eine konkrete Gegenleistung. Und die bleibt ja.
Nicht, wenn, wie oben geschrieben ein Multiplikationseffekt erwartet
wurde, der nun zunichte gemacht wird.
Der wird wodurch zunichte gemacht? Daß bisherige Entwickler nicht mehr an
der aktuellen eGroupware weiterentwickeln? Möglich, aber wohl auch nicht
dadurch zu ändern, daß man dafür sorgt, daß sie auf Dauer in ein anderes
Projekt abwandern. Andere Gründe, die nichts mit dem Abwandern der
Entwickler zu tun haben? Sehe ich eher nicht.
Läßt sich auch weiter
nutzen. Darüberhinaus zeigt die Erfahrung, daß einmal implementierte
Dinge
sich mit sehr viel weniger Aufwand erneut implementieren lassen,
wenn es
von denselben Personen gemacht wird.
Bei einem völlig neuem Code? Mit völlig neuem Konzept? Wo es u.U.
gewisse Funktionalitäten wie eTemplates oder SiteManager nicht mehr
geben wird?
Ja. Was nicht heißt, daß das in diesem konkreten Beispiel so sein wird,
schließlich weiß ich nicht, wie gut das Design der Neuimplementation ist.
Aber es gibt genügend Beispiele, wo es genauso war.
Wenn man merkt, das Software miserabel ist, ist regelmäßig wegwerfen
und
neuschreiben der vernünftigste Weg.
Ja, am besten ohne Abwärtskompatibilität!
Das hat damit nun gar nichts zu tun. Und gerade bei Mailsoftware eher ein
kleines Problem.
Ob man in der Zwischenzeit die alte
Version weiter pflegt, hängt sicherlich auch davon ab, ob das a)
überhaupt
geht
… und ob man bereit ist Verantwortung zu übernehmen.
Du meinst also, wer nicht langfristig die Verantwortung für seine Software
übernehmen will, sollte besser keine Open-Source-Software machen? Ich sehe
es genau anders herum. Wer langfristig keine Verantwortung übernehmen will,
sollte seine Software wenigstens offenlegen. Du kannst doch nicht
verlangen, daß jemand nur dann freie Software erstellt, wenn er bereit ist,
sie langfristig zu pflegen.
und ob man b) dazu geeignet motiviert wird. Ich an seiner Stelle wäre
dazu zwischenzeitlich nur noch sehr gemäßigt motiviert.
Na, selbst Mist zu bauen, den sich vorhalten zu lassen um dann zu
sagen “nu’ bin ich nicht mehr motiviert” wäre ja imho die totale
"Eigendisqualifizierung".
Davon redet keiner. Aber wenn man so heruntergemacht wird, wie Du es hier
regelmäßig tust, Dann demotiviert das.
Das Problem kann Dir natürlich niemand abnehmen. Wobei es da aktuell
wohl
auch keinerlei Entscheidungsbedarf gibt.
Doch natürlich - selbst bei Dir geht das Konzept auf. Auch bei Dir ist
das Prinzip-Hoffnung (in einer 2.0 Version wird alles besser)
angesprungen, welches Du hier unreflektiert lebst.
Das ‘selbst bei Dir’ nehme ich mal als Kompliment. Der Rest ist schierer
Blödsinn.
Nach zwei Jahren passt der Sourcecode
wieder mal nicht und dann? Ich habe Anfang des Jahres bestimmt
einen Tag in
die Planung einer Erweiterung für die Stundenzettel investiert und
Sponsoren
über die Liste organisiert. Ich hatte von Lars Kneschke eine feste
Zusage
die Erweiterung innerhalb einer bestimmten Zeit für einen
bestimmten Betrag
zu realisieren. Ich bin erst immer wieder hingehalten worden. Zum
Schluß hat
Lars weder auf meine Anrufe noch auf meine Emails reagiert.
Sowas ist unschön.
Unschön? Interessante Äußerung…
Nachdem ich keine Details kenne, werde ich mich hüten, dazu irgendwelche
weitergehenden Äußerungen zu machen.
Aus dem Projekt
ist dann nie was geworden. Ich habe das auf der Liste nie erwähnt
um nicht
öffentlich zu kritisieren. Ich sage das hier jetzt nur um zu
untermauern das
ich als Anwender mich bei dem neuen System nicht ernstgenommen
fühlen kann
und mich einer absoluten Willkür ausgesetzt sähe.
Ich wäre auch bereit dafür Geld auszugeben… sehr schade, dass
gewisse Leute nicht mal mit Geld zu motivieren sind und sich in
solcher Form von einem Projekt abwenden, welches Sie mal selbst
gegründet haben.
Das ist schade. Aber sicherlich kein Grund, ihnen Vorwürfe zu machen. Geld
ist nicht alles.
Solange Du den kompletten Sourcecode hast, ist absolute Willkür völlig
ausgeschlossen.
Vorausgesetzt, Du kannst selbst programmieren und bist nicht nur
Anwender / Administrator von eGroupware, dann bist Du nämlich
ausgeliefert.
Unsinn. Es gibt sicher außer mir noch einen Haufen anderer Leute, die sich
ohne weiteres zutrauen würden, die Pflege solcher Software zu übernehmen.
Das Metawaysprojekt wird nie kompatibel zu eGroupWare. Am Anfang
wurde noch
was von Datenbankmodellkompatibilität gesagt. Das ist jetz
hinfällig. Jetzt
wird was von Migrationshilfen gesagt. Ich denke resultieren wird
vielleicht
ein Adressimport oder so.
Das sind aber eben nur Vermutungen.
Ja, wie Deine eigenen, die Du hier laufend äußerst.
Klar. Aber ich verlange keine Entscheidungen, gestützt auf diese
Vermutungen.
Das ist eine Frage der Definition von ‘zu hoch’. Und natürlich auch,
ob man
wirklich in allen Punkten 100%ige Kompatibilität will. Das wiederum
bezweifle ich, sonst gäbe es ja keine Anforderungen, eGW zu erweitern,
ändern, verbessern.
LOL - natürlich kann man annähernd 100%ige Kompatibilität herstellen
bzw. Kontinuität. Das kriege selbst kleinere Projekte hin.
Dazu müßtest Du erstmal definieren, was Du unter 100%iger Kompatitibilität
verstehst. Meist macht man ja Änderungen, weil man neue Funktionen oder
Leistungen braucht (oder zu brauchen glaubt). In dem Moment ist man
zwangsläufig nicht mehr 100% kompatibel.
Nur HIER
war es vornherein nicht gewollt!
Das habe ich anders gelesen.
Das kann so sein, muß aber nicht. Wenn man eine bestehende Software
komplett neu schreibt, geht das erfahrungsgemäß drastisch schneller,
als
die Ersterstellung. Vorausgesetzt allerdings, die bestehende
Software war
denen, die neu schreiben gut bekannt, idealerweise von ihnen
mitentwickelt.
Genau und in Bezug auf eTemplate stellte Lars erst kürzlich klar, dass
Ihm das “zu hoch” war aber genau die Anpassbarkeit von der echten
eGroupware ist unschlagbar.
Dann muß das eben jemand anders machen. Wo ist das Problem? Hat Lars die
eTemplates ursprünglich entwickelt und niemand anderes blickt da durch?
Doch wohl eher nicht. Klar ist das mit den eTemplates wirklich eine schöne
Sache. Das Stundenzettelformular hat unser Azubi problemlos um Knöpfe zum
setzen der Start- und Endzeit erweitern können. Um dann allerdings die
Konfigurationswerte zu finden, damit die Minutenliste auch Minutenschritte
anbietet, war dann doch gemeinsames Buddeln im Quellcode nötig. Da ist also
durchaus auch noch Verbesserungspotential.
Damit es noch eine weitere quelloffene Groupware gibt und die
vorhandenen
Resourcen für solche Systeme noch weiter verzettelt werden? Kann man
machen, muß man aber nicht.
Na, ich denke gerade die Vielfalt sei der Schlüssel bei OpenSource.
Bis zu einem gewissen Grad, ja. Aber im Bereich der Groupware gibt es
inzwischen eine Unmenge Projekte, die alle einige Sachen besonders gut und
viele andere gar nicht oder schlecht können. Da wäre Konzentration
nützlicher.
Und eben, muss man nicht, nicht im allgemeinen in beide Richtungen und
offenbar hat Metaways kein Interesse an der eigentlichen eGroupware
sonst hätte man per frühzeitiger Diskussion und Planung erst
abgestimmt und dann gehandelt - das hier ist kopfloser Aktionismus,
der nicht helfen sondern schaden soll - auch DAS haben Conny und Lars
so schon dargelegt.
So ganz verstehe ich den Satz nicht. Und den letzten Teil solltest Du
belegen können.
Wenn es wirklich dauerhaft zwei völlig verschiedene Systeme bleiben,
brauchen sie natürlich auch verschiedene Namen.
Nein, brauchen sie JETZT schon um dem Treiben ein Ende zu machen. Im
Moment wird dem Projekt geschadet !
Das ist Quatsch. Geschadet wird dem Projekt allenfalls durch diese
Diskussion. Und sicherlich langfristig, wenn von den ohnehin schon wenigen
Entwicklern noch welche vertrieben werden.
Daran geht kein Weg vorbei.
Doch, professionelles Vorgehen.
Wie jetzt? Wenn man professionell vorgeht, können das dauerhaft völlig
verschiedene Systeme bleiben, aber trotzdem denselben Namen behalten? Ich
glaube, Du meinst nicht, was Du da schreibst, oder Du hast meine Aussage
völlig falsch verstanden.
Prove of Concept vorstellen, zur
Abstimmung stellen
Eine Proof of Concept wollen sie ja im nächsten Jahr vor- und zur
Abstimmung stellen. Also genau das, was Du erwartest.
und eine mögliche Niederlage oder einen Sieg
hinnehmen können.
Hinnehmen in dem Sinne, daß es dann nicht als eGroupware weitergehen kann,
sicherlich. Hinnehmen in dem Sinne, daß sie alles wegwerfen, auch wenn sie
weiterhin davon überzeugt sind, daß ihr Konzept besser ist, kann man wohl
nur verlangen, wenn man der ist, der zahlt.
Hier wird versucht vorab Tatsachen zu schaffen und
das mit Mitteln die absolut unter der Gürtellinie sind
Das empfindest Du so, weil Du die ganze Zeit schon auf 180 bist. Wenn Du
Dir das in ein oder zwei Jahren mal durchliest, wirst Du Dich fragen,
worüber Du Dich so aufgeregt hast.
Daß man aber eine Software nicht komplett neu schreiben darf, ohne
ihren
Namen zu ändern, wäre schon ziemlich töricht.
Das ist doch eine völlig falsche Bemerkung. Innerhalb des bestehen
Projektes, nach den Regeln dieses Projektes darf man das natürlich
aber nicht einfach losrennen und machen… Merkt hier denn keiner was?
Ich merke, daß Du auf Argumente nicht eingehen willst. Du hast oben
geschrieben, der richtige Weg wäre, einen Proof of Concept zu erstellen und
dann darüber abstimmen zu lassen. Ich nehme mal an, daß Du die Regeln
insoweit kennst, daß ich annehmen kann, daß dies Vorgehen regelgerecht
wäre. Also ist doch bis zu der Abstimmung nach der Vorstellung des Proof of
Concept alles im grünen Bereich. Wann jemand einen Proof of Concept für
vorstellungsreif hält, muß man ihm ja nun zwangsläufig selbst überlassen.
Ansonsten könnte man ja auch fünf Minuten nach Ankündigung einen solchen
Proof zur Abstimmung stellen. Und weiß dann sicher, daß er abgelehnt wird.
Also sollte man eine solche
Entscheidung nicht überstürzen, denn wenn die neue Version nachher
tatsächlich stabiler / wartbarer / leichter anpassbar ist, dann wird
man
eben doch umsteigen wollen. Und dann ist es für alle Beteiligten
sinnvoll,
wenn man das unter einem eingeführten Namen machen kann.
Genau darum geht es ja - Metaways will einzig und allein die Nutzer
und Reputation des Namens eGroupware alles andere ist denen egal -
damit lässt sich nämlich kein Geld verdienen - die können
wahrscheinlich nicht mal die alte Version ordentlich Supporten, somit
ist es nicht ungeschickt zu versuchen sich derart der Altlasten zu
entledigen - aber unprofessionell bleibt es, das kann man drehen und
wenden wie man will!
Kann ich nicht beurteilen. Ist aber auch völlig egal, solange Du dafür
keinen Beleg bringst.
Da es expressis verbis als Weiterentwicklung von eGW gedacht ist,
fehlt mir
in Deiner Gedankenkette irgendwo ein Glied.
Eben wie Du schon sagst - irgendwer stellt sich hin und sagt “WIR SIND
DIE ZUKUNFT” und erwartet alle schreien HURRAA und kommen in Scharen
gelaufen
Erwartet das jemand? Dann ist er dumm. Kommen Scharen gelaufen? Dann sind
die dumm.
- das ist aber falsch - PER DEFINITION kann man das behaupten
aber per Constitution des Projektes ist dies Blödsinn.
Blödsinn ist, neue Ideen nicht die Chance zur Reife zu geben. Ablehnen kann
man es dann ja immer noch.
Gruß Martin
Bitte nicht an der E-Mail-Adresse fummeln, die paßt so.
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german
