realityking schrieb:
warum grade dieses Projekt die GPL Verwendet weiß ich nciht. Willst du mcih aufklären?
Wie Du sicher weißt, verkauft Sun auch eine angepasste Version von OpenOffice unter dem Namen StarOffice. Diese enthält einige Komponenten, die man in eine GPL-Anwendung nicht einbinden dürfte.
Patrick Luby, der Hauptautor von NeoOffice, war mal bei Sun angestellt, um eine OSX-Version von OpenOffice zu erstellen, die dann natürlich auch als Basis für ein neues Mac-StarOffice gedient hätte.
Irgendwann hatte Sun aber keinen Bock mehr auf eine OSX-Version (vermutlich weil Apple durch OSX zu einer Konkurrenz für Solaris geworden war oder so) und hat Luby rausgeschmissen. Luby hatte zu dem Zeitpunkt nur einige Ideen aufwerfen können, wie man OpenOffice am besten portieren könnte. Cocoa war damals wohl noch zu fehlerhaft – in wieweit er sich Carbon ansah, weiß ich jetzt nicht –, aber zu dem Zeitpunkt schien Java am aussichtsreichsten.
Luby wollte aber auch privat eine OpenOffice-Version für seinen Mac haben. Da ihn Sun aber rausgeworfen hat, hatte er (selbstverständlich, wie ich finde) keine allzu große Lust darauf, dass Sun eine StarOffice-Version für Mac verkaufen kann, die auf der Arbeit basiert, die Luby nach seinem Rauswurf bei Sun geleistet hat.
(Nun bin ich mir mit der Chronologie nicht mehr sicher, aber zumindest grob müsste das Folgende stimmen.)
Edward Peterlin hatte sich zur etwa gleichen Zeit an einem Cocoa-Port von OpenOffice versucht und NeoOffice ins Leben gerufen. NeoOffice derzeit hauptsächlich eine Spielwiese für ihn und Peterlin hatte AFAIK auch die Absicht, sollte aus dem Cocoa-Prototyp was werden, diesen Code auch bei OO einfließen zu lassen.
Peterlins NeoOffice kam aber nicht so rechtin die Pötte, weil Cocoa nicht so ausgereift war und C++ und Obj-C zu mischen war auch nicht so leicht möglich.
Irgendwie haben sich Luby und Peterlin dann getroffen.
Beide hatten die Absicht endlich mal eine anständige OSX-Version von OO auf die Beine zu stellen und Luby hatte mit Java auch eine praktikablere Lösung gefunden als Cocoa. Luby schloss sich also NeoOffice an und sein Ansatz wurde dann NeoOffice/J (der alte zu NeoOffice/C).
Ich kenne NeoOffice jetzt schon eine Weile und früher hatte die Website auch viele dankende Worte für die OO-Community als Ganzes. Luby und Peterlin waren beide zwar nicht so wirklich versessen darauf, dass ihr Code, den sie ohne Bezahlung geschrieben hatten, von Sun zu StarOffice umgemodelt werden kann. Sie sahen sich aber als Teil der OO-Community, dankten den OO-Mac/X11-Entwicklern für ihre Arbeit und stellten Support-Foren für OO Mac/X11 bereit.
Ich weiß nicht wie es dazu kam, aber irgendwann gab’s dann Stunk zwischen beiden Projekten. Zumindest mir kam OO-Mitglied Eric Hoch als Aufwiegler vor, der über Jahre hinweg auf eine eigene Cocoa-Portierung pochte und die Aussagen von Luby und Peterlin, Cocoa sei für OO einfach nicht geeignet, nicht beachtete. Vielleicht war Hoch frustriert, dass seine Cocoa-Ambitionen stets im Sand verliefen oder so.
Sollte ich Hoch Unrecht tun, tut mir das Leid.
Naja, zumindest halbwegs zur Besinnung sind die ja mittlerweile gekommen. Zwar denken die noch immer nicht daran, das beste für den einfachen Anwender zu tun, aber ihr eigener Port verwendet nun endlich mal Carbon.
Ich persönlich hätte es ja viel besser gefunden, wenn die Entwickler entweder einfach bei NeoOffice mitgemacht hätten. Noch besser hätte ich es gefunden, wenn die Basis von OpenOffice endlich mal überarbeitet wird. Selbst das normale OpenOffice unter Windows oder Linux ist lahm. Innovationen, die über das Dateiformat hinausgehen, findet man auch nicht so wirklich. Ich weiß nicht, ob Sun das blockiert oder ob der OpenOffice-Code einfach zu alt ist.
Deswegen bin ich ja auch so interessiert in KOffice 2. OpenOffice ist so wie vor einigen Jahren die Mozilla Suite. Ganz nett, aber eine große, lahme „All in one“-Anwendung. KOffice hat das Zeug zum Firefox unter den Office-Suites zu werden.