KDE ist eines der wenigen selbst organisierten, großen OpenSource Projekten, dass wirklich gut und efficient funktioniert, und das merkt man auch. Da könnte sich sogar manche Firma noch was von abgucken. Klare Strukturen, klare Zuständigkeiten, efficiente Entscheidungsprozesse und klar abgesteckte Ziele vor Augen, nur so gehts. Direktdemokratie funktioniert in solch großen Projekten mit so vielen Unterschiedlichen Meinungen leider nicht mehr. Man braucht sich nur mal dieses Chaos was teilweise im Debian Projekt herrscht anzuschauen, das hat schon mehrfach zu großen Verzögerungen und auch Qualitätsproblemen geführt. Also von mir ein großes Daumenhoch und Weiterso!
Nur schade, dass KDE nicht auf einem politisch freien Toolkit aufbaut. Hätte Linux nur ein wichtiges GUI-Toolkit, wäre vieles Einfacher und eine Menge Firmen hätten portiert. Da aber QT GPL oder Pay-Ware ist, nehmen sie GTK. Ausserdem fühlt sich KDE wie ein abgeschotteter Aufsatz für Betriebssysteme an, was irgendwie nicht so sein sollte.
Von dat Pinguin seine Flüsterer am So, 12. Februar 2006 um 23:40 #
Ausserdem fühlt sich KDE wie ein abgeschotteter Aufsatz für Betriebssysteme an, was irgendwie nicht so sein sollte.
Eher ein Jail für den User! Chroot-et in KDE und vom wahren Schlarraffenland fern gehalten...
Aber ich kenne keine graphische Oberfläche, die noch das Unixfeeling "durchscheinen läßt". KDE ist nur die Monströseste...
Das ist jammerschade, denn so lernen die Mausschubser nie, was ihnen durch das GUI vorenthalten wird. Wieso setzen die ihr KDE eigentlich nicht gleich auf einen Windows-Kernel? Den Unterschied würden die ja doch nicht merken!
Ok... das ist vielleicht etwas übertrieben dargestellt, aber das muß ab und zu mal sein, damit der Denkanstoß rüber kommt...
Dieses "nicht Unix-Feeling" dürfte die Erklärung für den Erfolg von KDE sein. Aber statt KDE-Bashing zu betreiben, hilf dir mit einem flotten "init 3". Dann hast du Unix-Feeling pur.
>Aber ich kenne keine graphische > Oberfläche, die noch das Unixfeeling > "durchscheinen läßt".
twm vielleicht? Das ist so richtig hässlich, unbenutzbar und nerdy, wer das benutzt kann sich voll von diesen ganzen DAUs abheben.
"Unix-Feeling" braucht kein Mensch. Wozu? Außerdem: Alt+F2: "konsole". Da hast du dein Feeling. > Das ist jammerschade, denn so lernen die > Mausschubser nie, was ihnen durch das GUI > vorenthalten wird.
Was denn?
> Wieso setzen die ihr KDE eigentlich nicht > gleich auf einen Windows-Kernel? Den > Unterschied würden die ja doch nicht > merken!
Welchen Unterschied sollte man da als Anwender bemerken? Und warum will man das?
> Ok... das ist vielleicht etwas übertrieben > dargestellt, aber das muß ab und zu mal > sein, damit der Denkanstoß rüber kommt...
Welcher Denkanstoß? Wer KDE benutzt, dem entgehen tolle Beschäftigungstherapien? Nicht sehr gehaltvoll.
Ich weiss nicht was ihr habt, er hat doch recht! Es wird der Tag kommen an dem Trolltech absahnen wird, da müssen wir uns doch nichts vormachen. So funktionieren Frimen nunmal. Ist auch völlig legitim.
Stallmann selbst hat gesagt, daß man die LGPL nur benutzen solle, wenn es absolut nicht anders geht.
Aus der Sicht ist qt 'besser', denn es zeigt, daß es für ein widget nicht nötig ist, unter der LGPL zu stehen.
Außerdem fühlt sich gnome wie ein Sammelsurium vershciedener Apps an, die versuchen KDE nachzubilden ohne dabei gleichartig integriert zu sein. Erschwerend kommt hinzu, daß gnome dem Anwender Entscheidungen vorenthält und damit immer mehr wie windows wird.
.... bei OpenSource ist in der Tat, das aufgrund von unendlichen Diskussionen, vieles im Sande verläuft oder zu extrem zeitlichen Verzögerungen führt. Zumal neuerdings scheinbar über jedes Komma diskutiert wird und bei jeder Aktion das Ende der Community angekündigt wird.
Da sind die Mechanismen zur Entscheidungsfindung in der CSS Welt einfacher. Diskussion bis zu einen Punkt, und dann Feierabend.
Doch das ist mein Ernst. Ich behaupte ja nicht, das das Konzept CSS besser ist, oder bessere Software rausbringt, sondern das CSS im Regelfall von Unternehmen entwickelt wird, in der durch hirachische Strukturen eine Entscheidungsfindung gefördert wird, während in der OSS Szene, eher alles bis ins kleinste diskutiert wird, bis hin zu persönlichen Anfeindungen.
Beispiele:
- Streit/Diskussion über ReiserFS 4 im Kernel - MPlayer Entwicklung praktisch zu Ende durch interne Querälen - Novell entwickelt teilweise (aber GPL Konform) ohne Community Beteiligung, um Zeitpläne einzuhalten und nicht erst endlose Diskussionen führen zu müssen.
Man könnte die Liste noch weiter führen, aber ich beschränke mich mal auf die letzten paar Wochen.
Ich habe ja auch nicht behauptet, das es bei CSS keine Diskussionen gibt, sondern das bis zu einen gewissen Grad diskustiert wird, und DANN eine Entscheidung getroffen wird,während ich bei OSS die Befürchtung geäussert habe, das aufgrund von endlosen Diskussionen (weil eben keine Entscheidungsinstanz vorhanden ist) Entwicklungen extremen zeitlichen Verzögerungen ausgesetzt sind, oder gänzlich fallen gelassen werden, weil die Diskussion zu keinem Ergebniss führt.
Es mag sein, dass die Entscheidungsfindung tatsächlich eine längere Zeitspanne beansprucht. Allerdings ist dafür das produzierte Produkt (bzw. Produkte) wesentlich qualitativer. Der letzte Punkt ergibt sich aus der an 'der Diskussion' beteiligten Gruppierungen. Während in FOSS ein jeder (der Ahnung von dem jeweiligen Produkt hat) seine Meinung bekunden kann und damit zwangsläufig frühzeitig eine rege Diskussion zwischen Nutzern und Entwicklern stattfindet, beschränkt sich die Diskussion bei CSS auf Geschäftsführung und Marketing.
- Streit/Diskussion über ReiserFS 4 im Kernel - Novell entwickelt teilweise (aber GPL Konform) ohne Community Beteiligung, um Zeitpläne einzuhalten und nicht erst endlose Diskussionen führen zu müssen.
Kein offener Entwicklungsprozess => fragwürdige Qualität + längere Fehlerbereinigungszeit. Man mag also bei "closed source" schneller etwas vorweisen können. Die Qualität bleibt dabei allerdings auf der Strecke.
- MPlayer Entwicklung praktisch zu Ende durch interne Querälen
> Allerdings ist dafür das produzierte Produkt (bzw. Produkte) wesentlich qualitativer Eine Diskussion ob eine Funktion eingeführt wird, oder auch nicht, führt nicht automatisch dazu, das das Produkt qualitativ höherwertig ist und somit geht Dein Argument leider ins leere.
> beschränkt sich die Diskussion bei CSS auf Geschäftsführung und Marketing. Das ist mir zu pauschal ausgedrückt, sorry Die Diskussion innerhalb von CSS beschränkt sich nicht auf nur GF und Marketing, auch da sind im Hinterdrund die unterschiedlichen Entwickler fleissig am diskutieren. Allerdings haben die einen "Diskussionsleiter" der sich alle Argumente anhört, und dann eine Entscheidung trifft. Bei den meisten OSS Projekten fehlt dieser jedoch, und Diskussionen ufern endlos aus.
> Kein offener Entwicklungsprozess => fragwürdige Qualität + längere Fehlerbereinigungszeit. > Man mag also bei "closed source" schneller etwas vorweisen können. Die Qualität bleibt dabei allerdings auf der > Strecke. Nochmal, es geht hier nicht um die Qualität des Produktes, sondern um Organisation. Desweiteren sind Deine Aussagen zur Qualität von CSS doch eher zu pauschal verfasst und in keinster Weise belegt. Richtig ist, das OSS von jedem begutachtet werden kann und sich somit von der Güte überzeugen kann, wozu das führen kann (aber nicht muss) sieht man bei ReiserFS => Grosse Streiterei darüber, ob der Code nun gut oder schlecht ist, ohne das ein Ende der Diskussion in Sicht ist.
>> - MPlayer Entwicklung praktisch zu Ende durch interne Querälen > Das ist ein anderes Diskussionsthema Ich würde mal sagen das das kein anderes Diskussionsthema ist, sondern genau das widerspiegelt, was passieren kann. Durch lange Diskussionen frustrierte Entwickler, die aus Folge daraus, das Projekt verlassen, welches in diesem Fall faktisch zum erliegen gekommen ist.
Das ist mir zu pauschal ausgedrückt, sorry Die Diskussion innerhalb von CSS beschränkt sich nicht auf nur GF und Marketing, auch da sind im Hinterdrund die unterschiedlichen Entwickler fleissig am diskutieren. Allerdings haben die einen "Diskussionsleiter" der sich alle Argumente anhört, und dann eine Entscheidung trifft.
Das ist mir zu rosig ausgedrückt. So SOLLTE es sein, das heißt aber nicht daß es immer so ist - geschweige denn daß es mit Unternehmenszielen bzw. persönlichen Incentives zusammenpaßt oder gar individuellen Karrieriezielen entspricht.
Nein, in CSS passiert es durchaus häufig, daß Probleme totgeschwiegen (Unternehmen haben weder Redefreiheit noch Basisdemokratie) und "wahnwizige" Ziele einfach durchgedrückt werden.
Oder warum ist in allen Softwareprodukten die Version x.0 immer qualitativer Schrott?
Weil der Diskussionsleiter eine vernünftige Entscheidung getroffen hat oder weil das Produkt JETZT rausmußte und die halbausgegohrenen neuen Funktionen in den Produktprospekt ausgegeben werden sollten?
> Weil der Diskussionsleiter eine vernünftige Entscheidung getroffen hat oder weil das Produkt JETZT rausmußte und die halbausgegohrenen neuen > Funktionen in den Produktprospekt ausgegeben werden sollten? Nochmal, es geht hier nicht um die technische Umsetzung, sondern nur um die Entscheidung ob Funktion XYZ eingebaut wird oder nicht. Nichts weiter. Du schilderst Probleme, die halt nichts mit der eigentlichen Entscheidung zu tun haben, sondern mit deren Umsetzung.
hab jetzt auch Deine andere Postings gelesen. Sehe welchen Punkt Du ansprichst.
Ich glaube nicht, daß es eine grundsätzliche Entscheidungsschwäche in OSS-Projekten gibt!
Das hierarchische System bei CSS beruht darauf, daß jemand aus seinem Vorgesetztenverhältnis Entscheidungen trifft.
Bei OSS geht es genauso, nur daß es sich nicht um ein Vorgesetztenverhältnis sondern um ein Anerkennungsverhältnis handelt. Wer gut ist und viel beiträgt kann Entscheidungen treffen und dessen Entscheidungen werden auch anerkannt. Wer wenig kann oder nur sporadisch beiträgt hat faktisch nix zu melden. So funktioniert das bei KDE, dem Kernel, etc.
Ob nun der Vorgesetzte bei CSS bzw. bei OSS der Kernentwickler gut oder schlecht ist, ist bei beiden Systemen mit seinen Vor- und Nachteilen vorhanden.
Schwierig wird es nur wenn sich zwei Kernentwickler nicht einigen können - dann kann das dazu führen daß entweder erst keine Entscheidung getroffen wird oder daß es zu schlechter letzt zu einem Fork kommt. Das kommt aber eher selten vor.
Es gibt für mich bei OSS nur eine Schwäche die CSS nicht in diesem Sinne hat: Unpopuläre Aufgaben können bei OSS Jahre brauchen bis sie angegangen werden, bei CSS ist es eine einfache Delegation. Mag zwar dort den Mitarbeiter nicht gerade motivieren, aber er wird halt nicht nur für die schönen Sachen bezahlt.
Da kann ich mich meinem Vorredner nur anschliessen. Hab bis vor kurzem in der CSS-Entwicklung gearbeitet und weiss, dass eben nur bis zu einem bestimmten Punkt diskutiert wird, aus zeitlichen Gründen aber nicht weiter. Mit dem Resultat, dass die Endentscheidung jemandem obliegt, der meistens keine Ahnung davon hat. Da fällt mir als Beispiel spontan ELSTER ein... ;-) Dass OSS sich deswegen aber langsamer entwickelt, kann man so pauschal auch nicht sagen - wenn man sieht, welche Riesensprünge allein KDE in den letzten Jahren gemacht hat!
> Mit dem Resultat, dass die Endentscheidung jemandem obliegt, der meistens keine Ahnung davon hat. Diese Argumentation wird zu 90 Prozent von Leuten gebracht, die sich mit Entscheidungen nicht abfinden können, und oftmals auch keine Ahnung von der Gesamtsituation haben. Sorry, das hört sich für mich dann doch eher an, wie Stammtischparolen.
> Da fällt mir als Beispiel spontan ELSTER ein Wenn Du jetzt auch noch darlegen würdest, welche Teil bei dem Projekt zu kurz diskutiert wurde, und wer dann dort als Ahnungsloser eine Entscheidung getroffen hat. Das ganze bitte fachlich belegt, und nicht als Sch**sshausparole, dann würdest Du unwahrscheinlich an Glaubwürdigkeit gewinnen.
Nichts lag mir weniger im Sinn, als den Eindruck von Stammtisch- oder Sch**sshaus-Parolen zu erwecken! :-)
Ist ja auch nicht so, dass ich mich mit Entscheidungen nicht abfinden kann - gerade als demokratisch veranlagter Mensch hat man oft auch Entscheidungen zu akzeptieren, die nicht der eigenen Meinung entsprechen. Aber auch wenn ich manche Dinge nicht fachlich belegen kann (wie auch?), so kann ich zumindest von meinen persönlichen Erfahrungen aus der CSS-Welt sprechen, wo die Führungskräfte (meist Betriebswirte) gegenüber den Entwicklern (meist Informatiker) das letzte Wort haben. Das hat mich Parolen nichts zu tun.
Was speziell ELSTER betrifft: Wie so viele andere muss auch ich leider mit dem "tollen" ElsterFormular-Programm arbeiten, dass nicht mal in der Lage ist, aussagekräftige Fehlermeldungen zu präsentieren, wenn die Elster-Server überlastet sind und demnach auch der Anwender keine Schuld am Fehlverhalten hat. Die Elster-Hotline darf es dafür ausbaden. Bei diesem Projekt hab ich sehr stark den Eindruck, dass Konzept, Architektur und Implementierung ein bisschen den Open-Source-Gedanken (und vor allem die -Diskussion!) vermissen lassen. Mir drängt sich der Verdacht auf, dass jemand in der Finanzverwaltung, der vermutlich mehr Ahnung von Steuern als von Software-Design hat, sich einfach mal für Windows und Java entschieden hat, weil der Blick über den Tellerrand nicht so weit gereicht hat.
Just my "two cents", not meant as lavatory slogan...
> wo die Führungskräfte (meist Betriebswirte) gegenüber den Entwicklern (meist Informatiker) das letzte Wort haben. Wenn ein Unternehmen eine fachfremde ausgebildete Person zum Leiter einer technischen Abteilung macht, dann ist das Problem natürlich klar, wenn es um fachliche Entscheidungen geht. Bei funktionellen Entscheidungen könnte es jedoch klappen. Ich versuche ja schon die ganze Zeit, die Diskussion auf die Funktionen zu lenken, da ich in meinen Ausgangsposting genau angesprochen habe. Sprich, ich meine nicht eine Diskussion wie etwas programmiert wird, sondern ich meine das Diskussionen über den Funktionsumfang oftmals bei OSS übertrieben werden, was leicht eben dazu führen kann, das Funktionen nicht oder nur sehr langsam eingebaut werden, oder die Entwickler ganz einfach aus Frust von sich aus darauf verzichten.
Zu Elster kann ich im Moment nicht viel sagen (da muss mein Steuerberater mit arbeiten) aber,
> dass nicht mal in der Lage ist, aussagekräftige Fehlermeldungen zu präsentieren
auf nicht aussagekräftige trifft man im OSS Bereich auch wesentlich öfter als mir lieb ist.
* Gerade eben wieder: You have an error in you SQL-Syntax near ........., es fehlte ein ', warum sagt das die Fehlermeldung nicht? In your SQL-Syntax is an ' missng at ...... Das ganze unter MySQL, also einem OSS Produkt ;-)
Menno, wie oft soll ich es denn noch schreiben? Also nochmal für Dich: In der von mir angestrebten Diskussion geht es um die Unterschiede im Entscheidungsfindungsprozess zur Implementation neuer Funktionen zwischen OSS und CSS. ES geht NICHT um die Qualität der Programme! Es geht auch nicht darum ob OSS oder CSS besser ist.
So langsam mache ich mir wirklich Sorgen, das soviele Leute zwar bereit sind für OSS in die Bresche zu springen, aber gleichzeitig sehr gut dokumentieren, das sie weder lesen können, geschweige denn das gelesene zu verstehen. Bisher dachte ich eigentlich, das das Grundvorraussetzungen sind, um überhaupt mit OSS zu tun zu haben.
Von romantic gorilla am So, 12. Februar 2006 um 22:22 #
ist doch gar nicht so schwer zu verstehen:
> geht es um die Unterschiede im Entscheidungsfindungsprozess [...] zwischen OSS und CSS.
ja, und obwohl mysql oss ist, wird es hauptsächlich von einer firma entwickelt, deren entscheidungsprozesse dem klassischen css-modell entsprechen. insofern hast du mit mysql ein schlechtes beispiel gewählt. manche leute setzen halt oss mit os-community-entwicklung gleich, obwohl heutzutage viel oss in firmen entwickelt wird.
1. Das die Fehlermeldung war, die ich kurz vor dem posten hatte (Ich habe mir ja nix aus den Fingern gesogen) 2. Die Qualität der Fehlermeldungen nun aus meiner Sicht wirklich nichts mit Entscheidungsfindungsprozessen zu tun hat. 3. Es lediglich eine Entgegnung auf die zu den unverständlichen Fehlermeldungen des Programmes Elster aus den Vorposting ist, und somit eigentlich völlig Off Topic zu eigentlichen Thema zu werten ist
> Gerade eben wieder: You have an error in you SQL-Syntax near ........., > es fehlte ein ', warum sagt das die Fehlermeldung nicht? > In your SQL-Syntax is an ' missng at ......
Woher soll das Programm wissen was du willst? Ob da ein ' fehlt oder ganz was anderes, das weisst alleine du.
Ich behaupte mal, dass 80% der Unternehmen, die bankrott gehen, das genau aus denselben Gründen tun. Meinungsverschiedenheiten zwischen den beiden Gründern oder den Executives sind immer der Anfang vom Ende, egal ob dabei der Quellcode offen ist oder nicht oder ob die Diskussion öffentlich ist oder nicht.
Es gibt gute und schlechte CSS- und OSS-Software und b CSS oder OSS oragnisatorisch besser sind, sei dahingestellt, aber ein Vorteil von CSS ist in der Tat die hierarchische Organisation: die TERMINIERT nämlich in ENDLICHER ZEIT. Und dies tut es bei OSS manchmal nicht ;)
Was ich bei manchen OSS-Projekten vermisse ist eine Timeline mit einer Roadmap. Das macht es manchmal schwierig sich für ein Tool zu entscheiden, da hier keine Gewissheit über die Fortsetzung und deren Aussehen gemacht werden kann - das ist echt ein Problem.
Naja, die grossen OSS Projekte haben schon eine Timeline und eine Roadmap, an die sich im grossen und ganzen gehalten wird. OK, kleine Abweichungen können aber immer mal vorkommen. Das ist sogar verständlich.
Und kleinere Projekte, brauchen sowas nicht zwangsläufig, da kann man glaube ich auch als Anwender mit leben. Es würde allerdings für mehr Transparenz sorgen, wenn solche Teams z.B. auf Iher Homepage auch mal ankündigen würden ala: Hi Leute, habt Geduld, wir sind nur 3 Leute und im Moment schwer beschäftigt, aber in X Wochen hauen wir mal wieder kräftig in die Tasten um dann x, y und z in unser Programm einzubauen. Oftmals hat man eher den Eindruck, das Projekte eingeschlafen sind und dann tut sich doch wieder was.
Von romantic gorilla am So, 12. Februar 2006 um 22:44 #
> ein Vorteil von CSS ist in der Tat die hierarchische Organisation: > die TERMINIERT nämlich in ENDLICHER ZEIT. Und dies tut es bei OSS manchmal nicht
schonmal drüber nachgedacht, dass es bei css-projekten auch nicht viel anders ist, weil 60% aller css-projekte ihre deadline nicht einhalten können? im zweifelsfall wird dann das produkt halt als "fertig" deklariert, um den termin einzuhalten. dagegen ist der ansatz "es ist fertig wenn es fertig ist" wesentlich seriöser.
PS: ich hab manchmal den eindruck, dass viele, die sich hier über kommerzielle sw-entwicklung auslassen noch nie in einer sw-firma gearbeitet haben.
> dagegen ist der ansatz "es ist fertig wenn es fertig ist" wesentlich seriöser. Für mein Privatrechner kann ich damit absolut leben. Anders sieht es aus im beruflichen Bereich. Bei Funktionen die ich benötige bin ich da nicht bereit mich auf solch eine Aussage zu warten bis es denn fertig ist. Da gilt wenn CSS diese Funktion bereits hat, oder aber eine Ankündigung das diese Funktion mit veröffentlichung am xxxxxxxx zur Verfügung steht, dann wird eben CSS eingesetzt, und fertig Aber ich bevorzuge schon OSS, aber es muss eben machbar sein.
Oder eine andere OpenSource-Software. Was bringt es dir eigentlich, wenn eine Software in 2 Monaten veröffentlicht wird, die dafür aber noch 300 ungefixte Bugs enthält? Wartest du dann noch 1 Jahr ab, bis die gefixt sind, sodass die Anwendung endlich produktiv genutzt werden kann?
> Was bringt es dir eigentlich, wenn eine Software in 2 Monaten veröffentlicht wird, die dafür aber noch 300 ungefixte Bugs enthält? Wartest > du dann noch 1 Jahr ab, bis die gefixt sind, sodass die Anwendung endlich produktiv genutzt werden kann? Blödsinn ;-) Beispiel (schon etwas älter): Wir sind Dienstleister und erhalten von einigen Kunden tagtäglich mehrere Office Dokumente (die weiterbearbeitet werden, und auch wieder zum Kunden zurückgehen). Mit OOo 1.1.x war ein vernünftiges bearbeiten/austauschen nicht möglich. Die Version OOo 2.0 war damals noch sehr sehr frühes Beta, und ein Test mit dieser Beta hatte ergeben, das zu dem Zeitpunkt auch mit der OOo 2.0b die Probleme keinesfalls behoben sind.
Daher hatten wir folgende Möglichkeiten:
1. Mit allem Nachdruck den Kunden einen Wechsel auf OOo naheliegen. (Achtung: Wir verdienen unser Geld nicht dadurch, das wir IT-Dienstleistungen anbieten)
2. Den Kunden bitten, das er uns den Auftrag erst in einem Jahr erteilt, weil dann unsere IT-Umgebung so weit ist.
3. Unsere IT-Umgebung so anpassen, das wir den Bedürfnissen unseres Kunden gerecht werden.
Da wir (und andere Unternehmen auch ) es uns nicht erlauben können, aufgrund von IT-Kompatibilitätern Kunden zu verlieren, haben wir uns in diesem Fall dafür entschieden, 3 Arbeitsplätze von Linux zu Windows XP mit MS Office zu migrieren. (Bemerkung: Wir haben auch über wine nachgedacht, oder MS Terminalserver uns letztendlich aber eben für die o.a Migration entschieden)
Ich bezog mich auf die Entscheidungsfindung - nicht auf Produktionsdeadlines. Die kann jeder mal überschreiten, dann publiziert man diese und gut ist. Aber wenn wir schon bei Zahlen sind: 40% aller CSS-Projekte soll aufgrund von überzogenen Anforderungen/Spezifikationen, zu hohen Kosten und mangelndem Design scheitern. Ich glaube bei OSS liegt der Wert bei 80% - da wird vieles angefangen und dann wieder eingestellt. Dabei sind hier sicherlich nicht die Anforderungen und Spezifikationen zu hoch, sondern die Zeit der/des Entwickler/s eingeschränkt und das Projekt ist zu klein und unwichtig, als das es andere fortführen.
Aber ich wiedrhole mich: gebt mir ne Timeline und ne Roadmap, dann herrscht Planungssicherheit für die Anwender und Ruhm und Ehre sind dem Projekt sicher
der größte Teil der OSS-Projekte hat vorwiegend aus 2 Gründen keine Roadmap veröffentlicht:
1. Es ist nicht wirklich klar, wann das nächste Release stattfinden soll und was der Funktionsumfang sein wird. Die Termine und Inhalte ändern sich halt nach Lust und Laune.
2. Es gibt so gut wie keine Unterstützer, die die entsprechenden Seiten im Internet pflegen will (willst Du das übernehmen?). Wegen 1. ist es aber so, daß diese fast jeden Monat angepaßt werden müßten. Da das keiner machen will, macht man einfach gar keine Roadmap. Besser keine als ein alte/falsche.
Von Oberpinguin am So, 12. Februar 2006 um 16:13 #
Die sollten mal eine Dokumentationsgruppe ins Leben rufen, die die gesamte Technik mit dem "Wie und Warum" vollständig in deutscher Sprache, verfaßt in mehrbändigen Werken, dokumentiert. Zusätzlich benötigen wir auch eine Historygruppe, die abgelöste Bibliotheken, Programme und Konzepte dokumentiert und ihren Untergang begründet. Nur aus Fehlern kann man schließlich lernen.
Solange wie der Entwicklungsprozeß nicht vollständig in deutsch durchgeführt wird, werde ich mich im Übrigen nicht daran beteiligen. Ich hoffe, daß auch Ihr die Finger von solchen Communityprojekten lasst.
Bevor mir einer Ironie unterstellt: Alles in diesem Posting ist vollkommen ernst gemeint. Denkt mal drüber nach.
Was verstehst du unter "Entwicklungsprozess"? Ich verstehe dich so, dass du sämtliche Informationen rund um KDE in deutscher Sprache möchtest. Wenn ja: Was meinst du sagen spanische Entwickler dazu? Es ist zudem aufwändig, über alles Protokoll zu führen. Dies dann auch noch in mehreren Sprachen aktuell zu halten ist nahezu nicht möglich. Natürlich wäre es wünschenswert, ich verstehe aber nicht, warum man sich nicht an der Entwicklung beteiligen soll, wenn nicht alles in Deutsch gehalten ist.
Englisch ist im Computerbereich die übliche Sprache und zum verständigen zwischen Entwicklern aus aller Welt der kleinste gemeinsame Nenner.
> Alles in diesem Posting ist vollkommen ernst gemeint. Denkt mal drüber nach.
Dann lerne englisch, bleibe KDE/Gnome/bash/etc-Anwender, verkaufe deinen PC oder installiere Windows (mein ich ganz ernsthaft in dieser Reihenfolge). Punkt.
> Englisch ist im Computerbereich die übliche Sprache und zum verständigen zwischen > Entwicklern aus aller Welt der kleinste gemeinsame Nenner.
Englisch ist ein Krebsgeschwür und Produktivitätsbremse Nummer 1. Ich kann diese Ideologie der Einsprachigkeit einfach nicht ausstehen. Früher Latein, dann Französisch an den Höfen, jetzt Englisch. Typisch deutsch.
>> Alles in diesem Posting ist vollkommen ernst gemeint. Denkt mal drüber nach. >Dann lerne englisch, bleibe KDE/Gnome/bash/etc-Anwender, verkaufe deinen PC oder installiere >Windows (mein ich ganz ernsthaft in dieser Reihenfolge). Punkt.
Die Formulierung "alles in diesem Posting ist vollkommen ernst gemeint. Denkt mal drüber nach." ist eine typische Trollphrase, einfach nicht darauf eingehen. Ansonsten ist Deine Antwoert einfach kulturell ignorant.
> Englisch ist ein Krebsgeschwür und Produktivitätsbremse Nummer 1. Warum? Könntest Du das mal näher ausführen?
> Ich kann diese Ideologie der Einsprachigkeit einfach nicht ausstehen. Aha, es geht hier also um darum, das Du, als Mass aller Dinge, damit einfach nicht leben kannst.
Sollte also jeder Entwickler, gleichzeitig die Sprachen aller anderen Entwickler lernen? Oder sollen nur alle nichtdeutschen Entwickler, gefälligst Deutsch lernen?
> Englisch ist ein Krebsgeschwür und Produktivitätsbremse Nummer 1. [...] > Typisch deutsch.
Vielleicht hast Du es noch nicht mitbekommen, aber KDE ist eben kein deutsches Projekt. Es arbeiten zwar sehr viele Deutsche daran mit, trotzdem können mal mindestens 50% der Entwickler kein Deutsch. Englisch ist nunmal die Sprache, die alle KDE-Entwickler zumindest so gut können, dass sie sich gegenseitig gut verstehen.
Und Produktionsbremse: Wer soll denn bitte die ganzen Informationen a) in die verschiedenen Sprachen übersetzen und b) alles konsistent halten? _Das_ wäre eine Produktionsbremse. Entwicklerdokumentation in _einer_ Sprache ist schon ein Haufen Arbeit. Du kannst ja gerne das Projekt "deutsche API-Dokumentation ins Leben rufen und die tausende und Abertausende von Dokuzeilen ins Deutsche übersetzen.
> Ich hoffe, daß auch Ihr die Finger von solchen Communityprojekten lasst.
Deine Hoffnung ist vergebens HARHARRHARR :-)
Ach so zum Thema "COMMUNITY-Projekte - nimmŽ doch mal Dein personal handy aus dem bodybag und phone Dich mal durch Deine peergroup - wer so alles noch gedankenlos genug ist, in quasideutschem Neusprech die Errettung des teutschen Wesens vor dem Angelsachsentum zu fordern.
Englisch ist die lingua franca - Lokalisierung ist gut und richtig und auf Nutzerebene unverzichtbar - für die Entwicklerebene ist der Aufwand aber extrem hoch und ich habe vollstes Verständnis, wenn nicht jeder Quellcode noch einmal neu auf deutsch kommentiert wird. Verständliche Kommentare in ordentlichem Englisch sollten aber Standard sein.
Die folgenden Sprachen waren in Europa schonmal federführend (damit lasse ich dann Arabisch, Agyptisch, Mayanesisch und so aus ): Griechisch, Latein, Französisch, Italienisch, Deutsch, Englisch
Ich glaube das Problem in der Ironie erfasst zu haben: 1. In einigen Ländern ist Englisch erste Unterrichtssprache (Frage: wie war das in der DDR?). In einigen anderen nicht. Und in einigen kostet höherer Schulunterricht sogar Geld! Habt ihr euch nie gewundert, warum es so viele Deutsche Entwickler, aber so wenige Polnische, Spanische und Italienische in der OSS-Szene gibt?
2. Das Problem einer zweiten Sprache ist, dass man viel länger zum Verständnis braucht. Denn neben der Sachebene gibt es die Sprachebene die durchdrungen werden muss. Für die meisten Superentwickler hier is das ja kein Problem - aber für viele andere schon. Ich erinnere mich noch daran, dass ein Superentwickler mir darauf sagte, dass diese dann einfach nicht mitentwickeln können - es lebe die freie OSS-Szene... Apropos: wie definiert man eigentlich Mitglieder dieser Szene? Reicht die Benutzung der Software oder muss man selbst Entwickler sein - und ab wievielen Codezeilen ist man das?
>1. In einigen Ländern ist Englisch erste Unterrichtssprache (Frage: > wie war das in der DDR?). In einigen anderen nicht. >[...] > 2. Das Problem einer zweiten Sprache ist, dass man viel länger zum > Verständnis braucht.
Das stimmt schon, aber mach einen Gegenvorschlag, der in einem OSS-Projekt der KDE-Größe funktionieren würde.
Ich sehe folgende (theoretische) Möglichkeiten:
1. andere Sprache als Englisch, aber einheitlich: Dadurch ist wohl kaum etwas gewonnen, es gibt einfach keine Sprache die annähernd soviele (potentielle) OSS-Entwickler sprechen.
2. Jeder in seiner Sprache, keine Übersetzung. Vorteil: mehr leute können sich beteiligen. Nachteil: Zusammenarbeit über Ländergrenzen hinweg ist quasi unmöglich. Ein in portugiesisch geschriebener Programmcode ist für mich ziemlich nutzlos, da kann ich keinen Bug fixen und nichts wiederverwenden.
3. Jeder in seiner Sprache, plus Übersetzung und Sychronisation. Vorteile wie 2). Nachteile: realistisch nicht möglich, wer das fordert und glaubt das es möglich ist, kann mir das ja mal einem kleinen bis mittleren Projekt exemplarisch vorführen (sagen wir, mindestens fünf Sprachen) und dann sprechen wir uns nochmal. Es ist schon so schwer genug, die Entwickler-Doku in _einer_ Sprache komplett und aktuell zu halten. Außerdem könnte das auch nur für Doku funktionieren. Direkte Kommunikation zwischen Entwicklern wäre so vollkommen unmöglich. Oder sollen wir uns noch Dolmetscher für alle Sprachen suchen? (Dolmetscher: ich übersetz die Mail nächste Woche, habe gerade keine Zeit"). IRC wäre auch sehr nützlich so. Sehr produktiv
Ich wollte nur nochmal das Problem verdeutlichen. Und wenn die Spanischen Eroberer wieder ausziehen oder Deutschlands Armeen mal wieder Europa überrennen, die Franzosen Ihre Aufklärerheere gen Moskau schicken oder die Italiener mal wieder antreten, wirtschaftlich und kulturell die Macht an sich zu reissen, die Holländer keine neue Pflanzen züchten und der Portugiese nicht wieder um die Erde segelt, solange ist Englisch die erste Sprache. Mein Tip: die nächste Amtssprache wird Russisch oder Chinesisch. Ich selber hoffe ja auf Japanisch...
Wenn keine Armee der Welt alle anderen Nationen unterwirft, dann dürfte die beste Lösung des Problems aus dem Universalübersetzer aus StarTrek bestehen Solange sollten auch nicht englischsprachige "Commuinitymitglieder" rücksichtsvoll behandelt werden :)
>Die sollten mal eine Dokumentationsgruppe > ins Leben rufen, [...] vollständig in > deutscher Sprache, verfaßt in > mehrbändigen Werken, dokumentiert.
Ich liebe es, wenn völlig unbeteiligte Nutznießer sich anmaßen, mich Entwickler mit Arbeit versorgen zu müssen, an der man Jahre zubringen kann.
> Zusätzlich benötigen wir auch eine > Historygruppe
"Wir" ist schonmal die richtige Richtung. Werd noch etwas konkreter und sage "ich" (d.h. Du).
> Solange wie der Entwicklungsprozeß nicht > vollständig in deutsch durchgeführt wird, > werde ich mich im Übrigen nicht daran > beteiligen
Na dann. KDE soll also die vielen hundert talentierten, motivierten und produktiven nicht-deutschsprechenden Entwickler von der Entwicklung ausschließen, damit eine handvoll englischresistenter Entwickler wie Dir, die offensichtlich noch keine Zeile Code beigesteuert haben, zufrieden sind und sich erbarmen mitzuarbeiten. Eigentlich kannst Du noch überhaupt keine OSS-Erfahrung haben, ich kenne zumindest kein relevantes OSS-Projekt, dass auf Deutsch kommuniziert. Das ist kein so toller Deal (entschuldige den Anglizismus) für das Projekt, das wirst Du doch wohl zugeben müssen?
Wenn du wirklich deine Muttersprache in KDE unterstützen willst, arbeite an der deutschen Übersetzung mit.
KDE ist echt ein Segen bzw. auch ein Vorzeigeprojekt für Linux allgemein.
Eher ein Jail für den User!
Chroot-et in KDE und vom wahren Schlarraffenland fern gehalten...
Aber ich kenne keine graphische Oberfläche, die noch das Unixfeeling "durchscheinen läßt". KDE ist nur die Monströseste...
Das ist jammerschade, denn so lernen die Mausschubser nie, was ihnen durch das GUI vorenthalten wird. Wieso setzen die ihr KDE eigentlich nicht gleich auf einen Windows-Kernel? Den Unterschied würden die ja doch nicht merken!
Ok... das ist vielleicht etwas übertrieben dargestellt, aber das muß ab und zu mal sein, damit der Denkanstoß rüber kommt...
Jedes Programm macht nur eine Aufgabe, aber die richtig, wurde von KDE perfektioniert.
Nennt sich KParts.
Jedes Teil macht eine Sache und eine Applikation wie konqueror setzt sich aus den verschiedenen KParts zusammen.
Zudem ist KDE vollkommen scriptbar.
Ja, du hast richtig gelsen. Man kann KDE komplett per scripte steuern.
Nennt sich DCop.
Aber auch das hast du noch nicht begriffen, nicht wahr?
Wenn du was monströses erleben willst, nimm CDE.
Lahm, häßlich und schwer zu benutzen.
Aber rummaulen macht einfach spaß, nicht?
> Oberfläche, die noch das Unixfeeling
> "durchscheinen läßt".
twm vielleicht? Das ist so richtig hässlich, unbenutzbar und nerdy, wer das benutzt kann sich voll von diesen ganzen DAUs abheben.
"Unix-Feeling" braucht kein Mensch. Wozu? Außerdem: Alt+F2: "konsole". Da hast du dein Feeling.
> Das ist jammerschade, denn so lernen die
> Mausschubser nie, was ihnen durch das GUI
> vorenthalten wird.
Was denn?
> Wieso setzen die ihr KDE eigentlich nicht
> gleich auf einen Windows-Kernel? Den
> Unterschied würden die ja doch nicht
> merken!
Welchen Unterschied sollte man da als Anwender bemerken? Und warum will man das?
> Ok... das ist vielleicht etwas übertrieben
> dargestellt, aber das muß ab und zu mal
> sein, damit der Denkanstoß rüber kommt...
Welcher Denkanstoß?
Wer KDE benutzt, dem entgehen tolle Beschäftigungstherapien? Nicht sehr gehaltvoll.
Es wird der Tag kommen an dem Trolltech absahnen wird, da müssen wir uns doch nichts vormachen.
So funktionieren Frimen nunmal. Ist auch völlig legitim.
NikN
du hast keine Ahnung, was die GPL bedeutet
du bist ein uninformierter Troll.
Glückwunsch.
Im Gegensatz zu GTK.
Stallmann selbst hat gesagt, daß man die LGPL nur benutzen solle, wenn es absolut nicht anders geht.
Aus der Sicht ist qt 'besser', denn es zeigt, daß es für ein widget nicht nötig ist, unter der LGPL zu stehen.
Außerdem fühlt sich gnome wie ein Sammelsurium vershciedener Apps an, die versuchen KDE nachzubilden ohne dabei gleichartig integriert zu sein. Erschwerend kommt hinzu, daß gnome dem Anwender Entscheidungen vorenthält und damit immer mehr wie windows wird.
Da sind die Mechanismen zur Entscheidungsfindung in der CSS Welt einfacher. Diskussion bis zu einen Punkt, und dann Feierabend.
Beispiele:
- Streit/Diskussion über ReiserFS 4 im Kernel
- MPlayer Entwicklung praktisch zu Ende durch interne Querälen
- Novell entwickelt teilweise (aber GPL Konform) ohne Community Beteiligung, um Zeitpläne einzuhalten und nicht erst endlose Diskussionen führen zu müssen.
Man könnte die Liste noch weiter führen, aber ich beschränke mich mal auf die letzten paar Wochen.
Das findet nämlich hinter "Closed Doors" statt!
Gruß
Tuxracer
- Streit/Diskussion über ReiserFS 4 im Kernel
- Novell entwickelt teilweise (aber GPL Konform) ohne Community Beteiligung, um Zeitpläne einzuhalten und nicht erst endlose Diskussionen führen zu müssen.
Kein offener Entwicklungsprozess => fragwürdige Qualität + längere Fehlerbereinigungszeit.
Man mag also bei "closed source" schneller etwas vorweisen können. Die Qualität bleibt dabei allerdings auf der Strecke.
- MPlayer Entwicklung praktisch zu Ende durch interne Querälen
Das ist ein anderes Diskussionsthema
Eine Diskussion ob eine Funktion eingeführt wird, oder auch nicht, führt nicht automatisch dazu, das das Produkt qualitativ höherwertig ist und somit geht Dein Argument leider ins leere.
> beschränkt sich die Diskussion bei CSS auf Geschäftsführung und Marketing.
Die Diskussion innerhalb von CSS beschränkt sich nicht auf nur GF und Marketing, auch da sind im Hinterdrund die unterschiedlichen Entwickler fleissig am diskutieren. Allerdings haben die einen "Diskussionsleiter" der sich alle Argumente anhört, und dann eine Entscheidung trifft. Bei den meisten OSS Projekten fehlt dieser jedoch, und Diskussionen ufern endlos aus.
Das ist mir zu pauschal ausgedrückt, sorry
> Kein offener Entwicklungsprozess => fragwürdige Qualität + längere Fehlerbereinigungszeit.
> Man mag also bei "closed source" schneller etwas vorweisen können. Die Qualität bleibt dabei allerdings auf der
> Strecke.
Nochmal, es geht hier nicht um die Qualität des Produktes, sondern um Organisation. Desweiteren sind Deine Aussagen zur Qualität von CSS doch eher zu pauschal verfasst und in keinster Weise belegt. Richtig ist, das OSS von jedem begutachtet werden kann und sich somit von der Güte überzeugen kann, wozu das führen kann (aber nicht muss) sieht man bei ReiserFS => Grosse Streiterei darüber, ob der Code nun gut oder schlecht ist, ohne das ein Ende der Diskussion in Sicht ist.
>> - MPlayer Entwicklung praktisch zu Ende durch interne Querälen
> Das ist ein anderes Diskussionsthema
Ich würde mal sagen das das kein anderes Diskussionsthema ist, sondern genau das widerspiegelt, was passieren kann. Durch lange Diskussionen frustrierte Entwickler, die aus Folge daraus, das Projekt verlassen, welches in diesem Fall faktisch zum erliegen gekommen ist.
Das ist mir zu rosig ausgedrückt. So SOLLTE es sein, das heißt aber nicht daß es immer so ist - geschweige denn daß es mit Unternehmenszielen bzw. persönlichen Incentives zusammenpaßt oder gar individuellen Karrieriezielen entspricht.
Nein, in CSS passiert es durchaus häufig, daß Probleme totgeschwiegen (Unternehmen haben weder Redefreiheit noch Basisdemokratie) und "wahnwizige" Ziele einfach durchgedrückt werden.
Oder warum ist in allen Softwareprodukten die Version x.0 immer qualitativer Schrott?
Weil der Diskussionsleiter eine vernünftige Entscheidung getroffen hat oder weil das Produkt JETZT rausmußte und die halbausgegohrenen neuen Funktionen in den Produktprospekt ausgegeben werden sollten?
> Funktionen in den Produktprospekt ausgegeben werden sollten?
Nochmal, es geht hier nicht um die technische Umsetzung, sondern nur um die Entscheidung ob Funktion XYZ eingebaut wird oder nicht. Nichts weiter. Du schilderst Probleme, die halt nichts mit der eigentlichen Entscheidung zu tun haben, sondern mit deren Umsetzung.
hab jetzt auch Deine andere Postings gelesen. Sehe welchen Punkt Du ansprichst.
Ich glaube nicht, daß es eine grundsätzliche Entscheidungsschwäche in OSS-Projekten gibt!
Das hierarchische System bei CSS beruht darauf, daß jemand aus seinem Vorgesetztenverhältnis Entscheidungen trifft.
Bei OSS geht es genauso, nur daß es sich nicht um ein Vorgesetztenverhältnis sondern um ein Anerkennungsverhältnis handelt.
Wer gut ist und viel beiträgt kann Entscheidungen treffen und dessen Entscheidungen werden auch anerkannt.
Wer wenig kann oder nur sporadisch beiträgt hat faktisch nix zu melden. So funktioniert das bei KDE, dem Kernel, etc.
Ob nun der Vorgesetzte bei CSS bzw. bei OSS der Kernentwickler gut oder schlecht ist, ist bei beiden Systemen mit seinen Vor- und Nachteilen vorhanden.
Schwierig wird es nur wenn sich zwei Kernentwickler nicht einigen können - dann kann das dazu führen daß entweder erst keine Entscheidung getroffen wird oder daß es zu schlechter letzt zu einem Fork kommt. Das kommt aber eher selten vor.
Es gibt für mich bei OSS nur eine Schwäche die CSS nicht in diesem Sinne hat:
Unpopuläre Aufgaben können bei OSS Jahre brauchen bis sie angegangen werden, bei CSS ist es eine einfache Delegation. Mag zwar dort den Mitarbeiter nicht gerade motivieren, aber er wird halt nicht nur für die schönen Sachen bezahlt.
Dass OSS sich deswegen aber langsamer entwickelt, kann man so pauschal auch nicht sagen - wenn man sieht, welche Riesensprünge allein KDE in den letzten Jahren gemacht hat!
Diese Argumentation wird zu 90 Prozent von Leuten gebracht, die sich mit Entscheidungen nicht abfinden können, und oftmals auch keine Ahnung von der Gesamtsituation haben. Sorry, das hört sich für mich dann doch eher an, wie Stammtischparolen.
> Da fällt mir als Beispiel spontan ELSTER ein
Wenn Du jetzt auch noch darlegen würdest, welche Teil bei dem Projekt zu kurz diskutiert wurde, und wer dann dort als Ahnungsloser eine Entscheidung getroffen hat. Das ganze bitte fachlich belegt, und nicht als Sch**sshausparole, dann würdest Du unwahrscheinlich an Glaubwürdigkeit gewinnen.
Ist ja auch nicht so, dass ich mich mit Entscheidungen nicht abfinden kann - gerade als demokratisch veranlagter Mensch hat man oft auch Entscheidungen zu akzeptieren, die nicht der eigenen Meinung entsprechen. Aber auch wenn ich manche Dinge nicht fachlich belegen kann (wie auch?), so kann ich zumindest von meinen persönlichen Erfahrungen aus der CSS-Welt sprechen, wo die Führungskräfte (meist Betriebswirte) gegenüber den Entwicklern (meist Informatiker) das letzte Wort haben. Das hat mich Parolen nichts zu tun.
Was speziell ELSTER betrifft: Wie so viele andere muss auch ich leider mit dem "tollen" ElsterFormular-Programm arbeiten, dass nicht mal in der Lage ist, aussagekräftige Fehlermeldungen zu präsentieren, wenn die Elster-Server überlastet sind und demnach auch der Anwender keine Schuld am Fehlverhalten hat. Die Elster-Hotline darf es dafür ausbaden. Bei diesem Projekt hab ich sehr stark den Eindruck, dass Konzept, Architektur und Implementierung ein bisschen den Open-Source-Gedanken (und vor allem die -Diskussion!) vermissen lassen. Mir drängt sich der Verdacht auf, dass jemand in der Finanzverwaltung, der vermutlich mehr Ahnung von Steuern als von Software-Design hat, sich einfach mal für Windows und Java entschieden hat, weil der Blick über den Tellerrand nicht so weit gereicht hat.
Just my "two cents", not meant as lavatory slogan...
Wenn ein Unternehmen eine fachfremde ausgebildete Person zum Leiter einer technischen Abteilung macht, dann ist das Problem natürlich klar, wenn es um fachliche Entscheidungen geht. Bei funktionellen Entscheidungen könnte es jedoch klappen. Ich versuche ja schon die ganze Zeit, die Diskussion auf die Funktionen zu lenken, da ich in meinen Ausgangsposting genau angesprochen habe. Sprich, ich meine nicht eine Diskussion wie etwas programmiert wird, sondern ich meine das Diskussionen über den Funktionsumfang oftmals bei OSS übertrieben werden, was leicht eben dazu führen kann, das Funktionen nicht oder nur sehr langsam eingebaut werden, oder die Entwickler ganz einfach aus Frust von sich aus darauf verzichten.
Zu Elster kann ich im Moment nicht viel sagen (da muss mein Steuerberater mit arbeiten) aber,
> dass nicht mal in der Lage ist, aussagekräftige Fehlermeldungen zu präsentieren
auf nicht aussagekräftige trifft man im OSS Bereich auch wesentlich öfter als mir lieb ist.
* Gerade eben wieder: You have an error in you SQL-Syntax near ........., es fehlte ein ', warum sagt das die Fehlermeldung nicht? In your SQL-Syntax is an ' missng at ...... Das ganze unter MySQL, also einem OSS Produkt ;-)
...welches von einer firma in dem von dir geschilderten verfahren entwickelt wird.
So langsam mache ich mir wirklich Sorgen, das soviele Leute zwar bereit sind für OSS in die Bresche zu springen, aber gleichzeitig sehr gut dokumentieren, das sie weder lesen können, geschweige denn das gelesene zu verstehen. Bisher dachte ich eigentlich, das das Grundvorraussetzungen sind, um überhaupt mit OSS zu tun zu haben.
> geht es um die Unterschiede im Entscheidungsfindungsprozess [...] zwischen OSS und CSS.
ja, und obwohl mysql oss ist, wird es hauptsächlich von einer firma entwickelt, deren entscheidungsprozesse dem klassischen css-modell entsprechen. insofern hast du mit mysql ein schlechtes beispiel gewählt. manche leute setzen halt oss mit os-community-entwicklung gleich, obwohl heutzutage viel oss in firmen entwickelt wird.
1. Das die Fehlermeldung war, die ich kurz vor dem posten hatte (Ich habe mir ja nix aus den Fingern gesogen)
2. Die Qualität der Fehlermeldungen nun aus meiner Sicht wirklich nichts mit Entscheidungsfindungsprozessen zu tun hat.
3. Es lediglich eine Entgegnung auf die zu den unverständlichen Fehlermeldungen des Programmes Elster aus den Vorposting ist, und somit eigentlich völlig Off Topic zu eigentlichen Thema zu werten ist
in zukunft bitte beim thema bleiben. danke!
> es fehlte ein ', warum sagt das die Fehlermeldung nicht?
> In your SQL-Syntax is an ' missng at ......
Woher soll das Programm wissen was du willst? Ob da ein ' fehlt oder ganz was anderes, das weisst alleine du.
Fax
Was ich bei manchen OSS-Projekten vermisse ist eine Timeline mit einer Roadmap. Das macht es manchmal schwierig sich für ein Tool zu entscheiden, da hier keine Gewissheit über die Fortsetzung und deren Aussehen gemacht werden kann - das ist echt ein Problem.
Und kleinere Projekte, brauchen sowas nicht zwangsläufig, da kann man glaube ich auch als Anwender mit leben. Es würde allerdings für mehr Transparenz sorgen, wenn solche Teams z.B. auf Iher Homepage auch mal ankündigen würden ala: Hi Leute, habt Geduld, wir sind nur 3 Leute und im Moment schwer beschäftigt, aber in X Wochen hauen wir mal wieder kräftig in die Tasten um dann x, y und z in unser Programm einzubauen. Oftmals hat man eher den Eindruck, das Projekte eingeschlafen sind und dann tut sich doch wieder was.
> die TERMINIERT nämlich in ENDLICHER ZEIT. Und dies tut es bei OSS manchmal nicht
schonmal drüber nachgedacht, dass es bei css-projekten auch nicht viel anders ist, weil 60% aller css-projekte ihre deadline nicht einhalten können? im zweifelsfall wird dann das produkt halt als "fertig" deklariert, um den termin einzuhalten. dagegen ist der ansatz "es ist fertig wenn es fertig ist" wesentlich seriöser.
PS: ich hab manchmal den eindruck, dass viele, die sich hier über kommerzielle sw-entwicklung auslassen noch nie in einer sw-firma gearbeitet haben.
Für mein Privatrechner kann ich damit absolut leben. Anders sieht es aus im beruflichen Bereich. Bei Funktionen die ich benötige bin ich da nicht bereit mich auf solch eine Aussage zu warten bis es denn fertig ist. Da gilt wenn CSS diese Funktion bereits hat, oder aber eine Ankündigung das diese Funktion mit veröffentlichung am xxxxxxxx zur Verfügung steht, dann wird eben CSS eingesetzt, und fertig
Was bringt es dir eigentlich, wenn eine Software in 2 Monaten veröffentlicht wird, die dafür aber noch 300 ungefixte Bugs enthält? Wartest du dann noch 1 Jahr ab, bis die gefixt sind, sodass die Anwendung endlich produktiv genutzt werden kann?
> du dann noch 1 Jahr ab, bis die gefixt sind, sodass die Anwendung endlich produktiv genutzt werden kann?
Blödsinn ;-)
Beispiel (schon etwas älter): Wir sind Dienstleister und erhalten von einigen Kunden tagtäglich mehrere Office Dokumente (die weiterbearbeitet werden, und auch wieder zum Kunden zurückgehen). Mit OOo 1.1.x war ein vernünftiges bearbeiten/austauschen nicht möglich. Die Version OOo 2.0 war damals noch sehr sehr frühes Beta, und ein Test mit dieser Beta hatte ergeben, das zu dem Zeitpunkt auch mit der OOo 2.0b die Probleme keinesfalls behoben sind.
Daher hatten wir folgende Möglichkeiten:
1. Mit allem Nachdruck den Kunden einen Wechsel auf OOo naheliegen. (Achtung: Wir verdienen unser Geld nicht dadurch, das wir IT-Dienstleistungen anbieten)
2. Den Kunden bitten, das er uns den Auftrag erst in einem Jahr erteilt, weil dann unsere IT-Umgebung so weit ist.
3. Unsere IT-Umgebung so anpassen, das wir den Bedürfnissen unseres Kunden gerecht werden.
Da wir (und andere Unternehmen auch
) es uns nicht erlauben können, aufgrund von IT-Kompatibilitätern Kunden zu verlieren, haben wir uns in diesem Fall dafür entschieden, 3 Arbeitsplätze von Linux zu Windows XP mit MS Office zu migrieren. (Bemerkung: Wir haben auch über wine nachgedacht, oder MS Terminalserver uns letztendlich aber eben für die o.a Migration entschieden)
Aber ich wiedrhole mich: gebt mir ne Timeline und ne Roadmap, dann herrscht Planungssicherheit für die Anwender und Ruhm und Ehre sind dem Projekt sicher
der größte Teil der OSS-Projekte hat vorwiegend aus 2 Gründen keine Roadmap veröffentlicht:
1. Es ist nicht wirklich klar, wann das nächste Release stattfinden soll und was der Funktionsumfang sein wird. Die Termine und Inhalte ändern sich halt nach Lust und Laune.
2. Es gibt so gut wie keine Unterstützer, die die entsprechenden Seiten im Internet pflegen will (willst Du das übernehmen?).
Wegen 1. ist es aber so, daß diese fast jeden Monat angepaßt werden müßten. Da das keiner machen will, macht man einfach gar keine Roadmap. Besser keine als ein alte/falsche.
Zusätzlich benötigen wir auch eine Historygruppe, die abgelöste Bibliotheken, Programme und Konzepte dokumentiert und ihren Untergang begründet. Nur aus Fehlern kann man schließlich lernen.
Solange wie der Entwicklungsprozeß nicht vollständig in deutsch durchgeführt wird, werde ich mich im Übrigen nicht daran beteiligen. Ich hoffe, daß auch Ihr die Finger von solchen Communityprojekten lasst.
Bevor mir einer Ironie unterstellt: Alles in diesem Posting ist vollkommen ernst gemeint. Denkt mal drüber nach.
Ich verstehe dich so, dass du sämtliche Informationen rund um KDE in deutscher Sprache möchtest. Wenn ja: Was meinst du sagen spanische Entwickler dazu?
Es ist zudem aufwändig, über alles Protokoll zu führen. Dies dann auch noch in mehreren Sprachen aktuell zu halten ist nahezu nicht möglich.
Natürlich wäre es wünschenswert, ich verstehe aber nicht, warum man sich nicht an der Entwicklung beteiligen soll, wenn nicht alles in Deutsch gehalten ist.
Wahrscheinlich wird als nächstes gefordert, das einige Befehlssyntaxe ins Deutsche übersetzt werden
> Alles in diesem Posting ist vollkommen ernst gemeint. Denkt mal drüber nach.
Dann lerne englisch, bleibe KDE/Gnome/bash/etc-Anwender, verkaufe deinen PC oder installiere Windows (mein ich ganz ernsthaft in dieser Reihenfolge). Punkt.
> Entwicklern aus aller Welt der kleinste gemeinsame Nenner.
Englisch ist ein Krebsgeschwür und Produktivitätsbremse Nummer 1. Ich kann diese Ideologie der Einsprachigkeit einfach nicht ausstehen. Früher Latein, dann Französisch an den Höfen, jetzt Englisch. Typisch deutsch.
>> Alles in diesem Posting ist vollkommen ernst gemeint. Denkt mal drüber nach.
>Dann lerne englisch, bleibe KDE/Gnome/bash/etc-Anwender, verkaufe deinen PC oder installiere
>Windows (mein ich ganz ernsthaft in dieser Reihenfolge). Punkt.
Die Formulierung "alles in diesem Posting ist vollkommen ernst gemeint. Denkt mal drüber nach." ist eine typische Trollphrase, einfach nicht darauf eingehen. Ansonsten ist Deine Antwoert einfach kulturell ignorant.
Im Wintersport ist sie das noch heute.
Typisch deutsch....
Warum? Könntest Du das mal näher ausführen?
> Ich kann diese Ideologie der Einsprachigkeit einfach nicht ausstehen.
Aha, es geht hier also um darum, das Du, als Mass aller Dinge, damit einfach nicht leben kannst.
Sollte also jeder Entwickler, gleichzeitig die Sprachen aller anderen Entwickler lernen? Oder sollen nur alle nichtdeutschen Entwickler, gefälligst Deutsch lernen?
> Typisch deutsch.
Vielleicht hast Du es noch nicht mitbekommen, aber KDE ist eben kein deutsches Projekt. Es arbeiten zwar sehr viele Deutsche daran mit, trotzdem können mal mindestens 50% der Entwickler kein Deutsch. Englisch ist nunmal die Sprache, die alle KDE-Entwickler zumindest so gut können, dass sie sich gegenseitig gut verstehen.
Und Produktionsbremse: Wer soll denn bitte die ganzen Informationen a) in die verschiedenen Sprachen übersetzen und b) alles konsistent halten?
_Das_ wäre eine Produktionsbremse. Entwicklerdokumentation in _einer_ Sprache ist schon ein Haufen Arbeit. Du kannst ja gerne das Projekt "deutsche API-Dokumentation ins Leben rufen und die tausende und Abertausende von Dokuzeilen ins Deutsche übersetzen.
Deine Hoffnung ist vergebens HARHARRHARR :-)
Ach so zum Thema "COMMUNITY-Projekte - nimmŽ doch mal Dein personal handy aus dem bodybag und phone Dich mal durch Deine peergroup - wer so alles noch gedankenlos genug ist, in quasideutschem Neusprech die Errettung des teutschen Wesens vor dem Angelsachsentum zu fordern.
Englisch ist die lingua franca - Lokalisierung ist gut und richtig und auf Nutzerebene unverzichtbar - für die Entwicklerebene ist der Aufwand aber extrem hoch und ich habe vollstes Verständnis, wenn nicht jeder Quellcode noch einmal neu auf deutsch kommentiert wird. Verständliche Kommentare in ordentlichem Englisch sollten aber Standard sein.
Die folgenden Sprachen waren in Europa schonmal federführend (damit lasse ich dann Arabisch, Agyptisch, Mayanesisch und so aus
):
Griechisch, Latein, Französisch, Italienisch, Deutsch, Englisch
Ich glaube das Problem in der Ironie erfasst zu haben:
1. In einigen Ländern ist Englisch erste Unterrichtssprache (Frage: wie war das in der DDR?). In einigen anderen nicht. Und in einigen kostet höherer Schulunterricht sogar Geld! Habt ihr euch nie gewundert, warum es so viele Deutsche Entwickler, aber so wenige Polnische, Spanische und Italienische in der OSS-Szene gibt?
2. Das Problem einer zweiten Sprache ist, dass man viel länger zum Verständnis braucht. Denn neben der Sachebene gibt es die Sprachebene die durchdrungen werden muss. Für die meisten Superentwickler hier is das ja kein Problem - aber für viele andere schon. Ich erinnere mich noch daran, dass ein Superentwickler mir darauf sagte, dass diese dann einfach nicht mitentwickeln können - es lebe die freie OSS-Szene... Apropos: wie definiert man eigentlich Mitglieder dieser Szene? Reicht die Benutzung der Software oder muss man selbst Entwickler sein - und ab wievielen Codezeilen ist man das?
> wie war das in der DDR?). In einigen anderen nicht.
>[...]
> 2. Das Problem einer zweiten Sprache ist, dass man viel länger zum
> Verständnis braucht.
Das stimmt schon, aber mach einen Gegenvorschlag, der in einem OSS-Projekt der KDE-Größe funktionieren würde.
Ich sehe folgende (theoretische) Möglichkeiten:
1. andere Sprache als Englisch, aber einheitlich: Dadurch ist wohl kaum etwas gewonnen, es gibt einfach keine Sprache die annähernd soviele (potentielle) OSS-Entwickler sprechen.
2. Jeder in seiner Sprache, keine Übersetzung. Vorteil: mehr leute können sich beteiligen. Nachteil: Zusammenarbeit über Ländergrenzen hinweg ist quasi unmöglich. Ein in portugiesisch geschriebener Programmcode ist für mich ziemlich nutzlos, da kann ich keinen Bug fixen und nichts wiederverwenden.
3. Jeder in seiner Sprache, plus Übersetzung und Sychronisation. Vorteile wie 2).
Nachteile: realistisch nicht möglich, wer das fordert und glaubt das es möglich ist, kann mir das ja mal einem kleinen bis mittleren Projekt exemplarisch vorführen (sagen wir, mindestens fünf Sprachen) und dann sprechen wir uns nochmal.
Es ist schon so schwer genug, die Entwickler-Doku in _einer_ Sprache komplett und aktuell zu halten.
Außerdem könnte das auch nur für Doku funktionieren. Direkte Kommunikation zwischen Entwicklern wäre so vollkommen unmöglich. Oder sollen wir uns noch Dolmetscher für alle Sprachen suchen? (Dolmetscher: ich übersetz die Mail nächste Woche, habe gerade keine Zeit"). IRC wäre auch sehr nützlich so. Sehr produktiv
Wenn keine Armee der Welt alle anderen Nationen unterwirft, dann dürfte die beste Lösung des Problems aus dem Universalübersetzer aus StarTrek bestehen
Solange sollten auch nicht englischsprachige "Commuinitymitglieder" rücksichtsvoll behandelt werden :)
> ins Leben rufen, [...] vollständig in
> deutscher Sprache, verfaßt in
> mehrbändigen Werken, dokumentiert.
Ich liebe es, wenn völlig unbeteiligte Nutznießer sich anmaßen, mich Entwickler mit Arbeit versorgen zu müssen, an der man Jahre zubringen kann.
> Zusätzlich benötigen wir auch eine
> Historygruppe
"Wir" ist schonmal die richtige Richtung. Werd noch etwas konkreter und sage "ich" (d.h. Du).
> Solange wie der Entwicklungsprozeß nicht
> vollständig in deutsch durchgeführt wird,
> werde ich mich im Übrigen nicht daran
> beteiligen
Na dann. KDE soll also die vielen hundert talentierten, motivierten und produktiven nicht-deutschsprechenden Entwickler von der Entwicklung ausschließen, damit eine handvoll englischresistenter Entwickler wie Dir, die offensichtlich noch keine Zeile Code beigesteuert haben, zufrieden sind und sich erbarmen mitzuarbeiten.
Eigentlich kannst Du noch überhaupt keine OSS-Erfahrung haben, ich kenne zumindest kein relevantes OSS-Projekt, dass auf Deutsch kommuniziert. Das ist kein so toller Deal (entschuldige den Anglizismus) für das Projekt, das wirst Du doch wohl zugeben müssen?
Wenn du wirklich deine Muttersprache in KDE unterstützen willst, arbeite an der deutschen Übersetzung mit.
> beteiligen.
KDE gibt es in mehr als 50 Sprachen und Du willst wohl dass alles in sämtlichen Sprachen dokumentiert wird. *LOL* Studierst Du BWL?
Schön dass Du wegbleibst. Freut mich ungemein.
http://www.kde.nl/people/
Allerdings gehts hier weniger um den fachlichen Background, als um eine Vorstellung der Person, ihrer Rolle in KDE, Pläne, Privatleben...
Ansonsten gibts noch die Contributor-Blogs auf http://www.planetkde.org und persönliche Homepages.