Von Mario Scheel am Mo, 15. Dezember 2003 um 20:00 #
Erst dchte ich ja das da ein User aus der Windows-Welt was ablässt. Aber ich wurde eines besseren belehrt. Die Aussagen kann ich nur unterschreiben sehe ich genauso.
Eine sehr provokante Aussage und vor allen Dingen sehr allgemein. Für die meisten Projekte mag das zutreffen, da eben sich nur das wenigste durchsetzt. Das was sich aber durchsetzt funktioniert auf dieser offenen Basis aber sehr gut. Z.Beispiel OpenOffice,apache,mysql um nur einige sehr gute Sachen zu nennen.
Klar kann jeder diese Allgemeinplätze unterschreiben.
Ich kenne jedoch kaum Freie Software Entwickler, die dem beschriebenen Irrglauben verfallen sind. Der ganze Artikel selbst basiert auf dem Irrglauben, dass Freie Software Entwicklung wildes Gebastel sei. Natürlich gibt es auf SourceForge fragwürdige Projekte, auf die die Thesen zutreffen mögen, aber das ist keine Konsequenz aus dem Entwicklungsmodell Freier Software.
Nach Studien (http://www.osdn.com/bcg , http://www.dwheeler.com/oss_fs_why.html) ist der durchschnittliche FS-Entwickler 28 Jahre alt und hat 11 Jahre Programmiererfahrung - Zeit genug, selbst zu den im Artikel beschriebenen Erkenntnissen zu gelangen. Nahezu ein Viertel der FS-Entwickler arbeiten professionell an Freier Software, ein weiterer Teil arbeitet in der Freizeit an Freier Software, hat aber einen professionellen Hintergrund.
Der Artikel ist letztlich wenig hilfreich und wirft eher ein schlechtes Licht auf die Entwicklungsmodelle Freier Software
und woher kommen die 11 Jahre Programmiererfahrung? Genau, weil im Durchschnitt die Leut mit 17 Jahren angefangen haben OpenSourceProjekte zu betreiben. Und im Durchschnitt zu diesem Zeitpunkt die meisten Fehlgänge gemacht werden.
...na ja. Es gibt Leute die arbeiten an ihren Ideen (bzw. Traum) und es gibt Leute die reden gerne über die Arbeit anderer und hätten alles ganz anders gemacht.
Linux aus dem Nichts entstanden. *BSD baut auf alten Code auf - Was ist besser?
Qt begann als es noch keine vernünftige C++ STL gab und wird stetig weiter entwickelt Gnome wird mit Mono noch mal bei Null anfangen - Was ist besser?
Als SUN den Code von StarOffice zum Download frei gab war der Teufel los. Auf meine Projekte bekomme ich nur wenig Resonanz. - Was ist jetzt daraus abzuleiten?
Software-Entwicklung steht auch immer in einem Sozialem-Kontext. Ich denke an dem Entwickler hängt garnicht soviel. Da spielen viel andere Faktoren auch noch eine Rolle.
- Ist das Projekthema gerade "modern". - Gibt es Konkurrenz-Projekte. - Wie groß ist die potenzielle Ziel-Gruppe. - Kann damit Geld verdient werden. - Hat es ein gutes Image. - Gibt es ein Forum zu Selbstdarstellung. - Hat der Entwickler "Charisma". - Wird das Thema von der Presse gepusht. - Hat der Entwickler selbst ein gutes soziales Umfeld (Familie, Freunde...). - Ist der Entwickler finanziell abgesichert. - Gibt es Rechts-Unsicherheiten. Usw....
Von Jan Arne Petersen am Mo, 15. Dezember 2003 um 20:54 #
Da GNOME nicht auf Mono basieren wird, wird es auch nicht bei Null anfangen. Die bestehenden Libraries und Anwendungen werden nicht in Mono umgeschrieben werden. Es wird nur Zukunft noch einfacher GNOME Anwendungen in Mono, C++, Perl, Python, Ruby zu entwickeln (siehe dazu auch das neue Projekt 'GNOME Development Platform language-bindings', welches API/ABI Kompatibilitaet und an die GNOME D&DP angepasste Releasezeiten garantiert). Inwieweit solche (nicht in C oder C++ geschriebenen) Anwendungen dann zur 'GNOME Desktop and Developer Platform' gehoeren werden bleibt abzuwarten.
Sehe ich genauso. Ein gutes Projekt muss ein gewisses Sex-appeal (schreibt mans so? ) haben. Das ist halt nicht bei jedem gegeben. KDE kam aus dem fast nichts (halt abgesehen von QT), ebenso GNOME. Andere starteten mit fertigen Vorlagen.
Was ist am besten? Keiner kanns sagen, wichtig ist das der Einstieg einfach sein muss, oder es extrem bekannt sein muss. Nur so geht es. Oder es findet sich ein Spezialgebiet as einige wenige brauchen, dann aber sehr brauchen. Gibt es auch.
Hat recht. Am wichtigsten ist, dass man darauf achtet, dass eigene Ergebnisse von anderen nutzbar sind. viele Projekte scheitern, kreatives Scheitern heisst: Ich habe einen Teil gelöst, ich muss nicht alles hinbekommen. Man denke etwa an die Versuche einen Basic Compiler für Linux zu schaffen, alles mehr oder weniger scheisse, weil alle bei null begannen und sich keine gedanken drüber machten, ob ihre Ergebnisse von anderen benutzt werden können.
Nunmehr wäre das gar kein Problem mehr, weil ja das Mono Projekt VisualBasic Klassen implementiert. Sobald man da was braucht, wird es auch implementiert werden.
Von stefan3??? am Mo, 15. Dezember 2003 um 21:03 #
Moin.
ob ihre Ergebnisse von anderen benutzt werden können.
Tja, die Frage ist, ob der Code "der Anderen" in einer Form ist (Kommentare, Doku, Lesbarkeit), dass andere ihn nutzen können. Manchmal sieht es da (nicht nur bei freien Prokekten) eher bescheiden aus, weil man vor lauter "Projekt schnell voranbringen" die Doku vernachlässigt.
Um mehr Entwickler und User für sein Projekt zu locken muss man auch/gerade bei Open Source Werbung machen. d.h. einträge in den enrsprechenden Webseiten wie freshmeat, Artikel schreiben, news veröffentlichen, ordentliche Webseite mir Screenshots...
eine echte Community ist nötig mit geringen Partizipationsbarrieren. So etwas wie KDE-Look, mit dem die Leute aus der Höhle geholt werden. Die Zauberformel von FOSS ist die Maximierung des Feedbacks
Von 0xdeadbeef am Mo, 15. Dezember 2003 um 21:27 #
Was User angeht, mag er in Teilen recht haben. Und mit Sicherheit wird die Offenlegung des Quellcodes nicht zwingend alle neuen Entwickler, die etwas zu dem Projekt beitragen könnten, heranziehen. Ich denke außerdem, dass das nicht der größte Vorteil der Offenlegung ist - der ist m.E., dass das Vertrauen in das Projekt erhöht wird. Allerdings gibt es Entwicklern, ohne große Bindungen etwas zu einem Projekt beizusteuern - und das ist auf jeden Fall ein Vorteil, der auch neue Entwickler heranzieht. In welchem Maße das der Fall ist, mag ich nicht abschätzen.
Ähnliches gilt für die Feature-Freeze-Hypothese. Sicher, Bugs sollte man auch beim Schreiben vermeiden, aber während eines Feature freezes schaut man sich notwendigerweise große Teile des Codes nochmal an, wobei auch Fehler gefunden werden. Das selbe gilt für die "Jetzt aber richtig"-Geschichte, wie ich aus eigener Erfahrung bestätigen kann. Man mahct sich bei Projekten zwar einen Plan im Voraus, aber bei der Umsetzung ergeben sich zwangsläufig Probleme, die Änderungen des Plans notwendig machen. Wenn man diese Probleme schon einmal durchgekaut hat, kann man sie beim zweiten Durchlauf eleganter behandeln oder gar umgehen - und da spreche ich aus Erfahrung. Das gilt insbesondere, wenn man ein bestimmtest API zum ersten mal verwendet, ist aber auch sonst von Bedeutung.
Ich habe den Eindruck, dass hier ein User spricht, der zwar die Bedürfnisse und Erwartungen von Benutzern ganz gut überschauen kann, aber von Softwareentwicklung herzlich wenig Ahnung hat.
Das Thema scheint ja evtl. Entwickler anzuziehen, die auf SourceForge arbeiten... Gibt es eine deutsche Anleitung/Tutorial, wie man auf SourceForge ein Projekt eröffnet/pflegt? Ich kann zwar Englisch, aber zum Einstieg in eine unbekannte Materie bevorzuge ich Deutsch, sonst verliere ich zu schnell den Boden unter den Füßen und weiß nicht mehr, was ich nicht weiß...
Von maestro alubia am Mo, 15. Dezember 2003 um 23:01 #
Meiner Ansicht ist der Autor mit seiner Kritik teilweise zu weit gegangen. Natürlich zieht ein OpenSource-Projekt nicht automatisch neue Entwickler an, aber eine Software-Firma bekommt schließlich auch keine Mitarbeiter, wenn sie sich nicht selbst nach außen präsentiert und Entwickler umwirbt. So muss auch ein Projekt möglichst viel Publicity betreiben um die gewünschte Resonanz zu erhalten - sowohl in Form von Entwicklern als auch Anwendern. Zum Anderen muss ein freies Projekt, noch mehr als eine komerzielle Software, darauf achten, dass der Markt nicht bereits gesättigt ist. Wenn bereits ähnliche, gute Software frei verfügbar ist, dann lohnt es sich schlichtweg nicht, noch eine weiteres Programm aus der Taufe zu heben. Der Community wäre in diesem Fall viel mehr Nutzen entgegengebracht, wenn sich diese(r) Entwickler dem bereits vorhandenen Projekt konstruktiv anschließt. Sollte es eine Software für den Zweck, in der Form und für diese Plattform noch nicht geben, so muss ein OpenSource-Entwickler zuerst, wie ein komerzielles Unternehmen auch, die Nachfrage nach der Software sowie das Angebot an Entwicklern, mit den nötigen Begabungen, welche auch die entsprechende Hardware besitzen, überprüfen. Sobald diese Faktoren zutreffen müsste sich das Projekt zügig entwickeln - und das ohne die Markteinflüsse, denen Unternehmer ausgesetzt sind. Ferner kann auch eine Einzelperson ein Projekt in Eigenregie aufziehen und trotzdem den Quellcode freigeben, wovon wiederum andere Projekte profitieren können. In diesem Punkt kann ich den Autor nur bestätigen, denn Zeit ist Geld, bzw. Zeit ist wertvoll - in großem Maße auch für die freien Projekte, die auf den tatkräftigen Zeiteinsatz von Entwicklern angewiesen sind. Auch der Anwender, der Einsicht in die Arbeit hat, kann herausfinden, wie das Programm funktioniert und somit seine Informatik-Kentnisse aufbessern oder einfach nur das gute Gefühl besitzen, nicht hintergangen zu werden. Der Feature-Freeze ist in meinen Augen sehr sinnvoll, denn soweit ich weiß bezeichnet dieses nicht den Stillstand der Entwicklung von neuen Funktionen sondern nur die Dead-Line für Implementationenen in ein bestimmtes Release. In dieses Release fließen dann nur noch die Bug-fixes ein. Neue Features werden dann eben in die nächste Entwickler-Version eingebracht. Die Ansicht, man könne Fehler auch beim Schreiben vermeiden gleicht dem Versuch, einem Torhüter zu sagen, er solle keine Tore reinlassen. Jeder macht, meist unabsichtlich und unbemerkt, Fehler, die einem nicht direkt auffallen und vielleicht erst einer anderen Person auffallen. Ich sehe auch die beste Möglichkeit darin, ein Projekt kennen zu lernen, indem man dessen Code liest und evtl. Fehler behebt. Darauf basiert schließlich das OpenSource-Prinzip und durch Interesse am Projekt gelangt man zum Interesse am Code und schließlich zum Bug-fixing. Der Code ist die Basis eines jeden Programmes und nur wenn man den Code liest, kann man die Anwendung auch von Grund auf kennen lernen und verstehen.
wir haben bei FreeCNC einige Entwicklungen nur bekommen, weil der Quellcode frei ist. Genauso bei holaCMS. Es war dienlich, dass einer einen testing-Tree geöffnet hat und drin rumprogrammiert hat. Letztendlich gingen die guten Sachen in den Haupttree zurück. Also aus meiner Erfahrung gibt es natürlich einen starken Mangel an Entwicklern, aber wie heisst es noch so schon: "heutzutage findet man einfach kein gutes personal mehr *g*".
"Warnings sind OK..." Nach dieser Device scheinen viele vorzugehen, denn sonst kann ich mir nicht die vielen "variable might be used uninitialized" Warnings in manch einer (auch grossen) Applikation erklaeren. Gerade aber solche Warnings sind fuer eine Reihe suspekter und schwer zu findender Fehler zustaendig, die das Leben eines Anwenders schwer machen koennen.
Aber wenn keiner mehr Fehler mach, kann auch niemand aus ihnen lernen. Es mag ein Irrglaube sein, das Bugs vermeiden von der ersten Zeile Code an funktionieren kann. Besonders, wenn ich daran denke das in ein Projekt meist auch die Arbeit aus anderen Projekten mit einfließt. Wer schreibt schon für ein simples FrontEnd was benötigt wird den Unterbau oder seine eigene GTK QT oder was weiß ich Bibliothek ,wenn die frei verfügbar ist?
Vor allem ist die Formulierung total bescheuert. Einen Bug kann man doch nur beim _Schreiben_ des Codes vermeiden. Ein Bug, der durch _Suchen_ gefunden wird, wurde eben nicht vermieden.
Für die meisten Projekte mag das zutreffen, da eben sich nur das wenigste durchsetzt. Das was sich aber durchsetzt funktioniert auf dieser offenen Basis aber sehr gut.
Z.Beispiel OpenOffice,apache,mysql um nur einige sehr gute Sachen zu nennen.
Ich kenne jedoch kaum Freie Software Entwickler, die dem beschriebenen Irrglauben verfallen sind. Der ganze Artikel selbst basiert auf dem Irrglauben, dass Freie Software Entwicklung wildes Gebastel sei. Natürlich gibt es auf SourceForge fragwürdige Projekte, auf die die Thesen zutreffen mögen, aber das ist keine Konsequenz aus dem Entwicklungsmodell Freier Software.
Nach Studien (http://www.osdn.com/bcg , http://www.dwheeler.com/oss_fs_why.html) ist der durchschnittliche FS-Entwickler 28 Jahre alt und hat 11 Jahre Programmiererfahrung - Zeit genug, selbst zu den im Artikel beschriebenen Erkenntnissen zu gelangen. Nahezu ein Viertel der FS-Entwickler arbeiten professionell an Freier Software, ein weiterer Teil arbeitet in der Freizeit an Freier Software, hat aber einen professionellen Hintergrund.
Der Artikel ist letztlich wenig hilfreich und wirft eher ein schlechtes Licht auf die Entwicklungsmodelle Freier Software
Genau, weil im Durchschnitt die Leut mit 17 Jahren angefangen haben OpenSourceProjekte zu betreiben. Und im Durchschnitt zu diesem Zeitpunkt die meisten Fehlgänge gemacht werden.
Bei Leuten wie Dir ist doch alles "wenig hilfreich" was irgendwie das 'Open Soße'-Modell kritisiert.
Nichts Neues.
Es gibt Leute die arbeiten an ihren Ideen (bzw. Traum) und es gibt Leute
die reden gerne über die Arbeit anderer und hätten alles ganz anders gemacht.
Linux aus dem Nichts entstanden. *BSD baut auf alten Code auf - Was ist besser?
Qt begann als es noch keine vernünftige C++ STL gab und wird stetig weiter
entwickelt Gnome wird mit Mono noch mal bei Null anfangen - Was ist besser?
Als SUN den Code von StarOffice zum Download frei gab war der Teufel
los. Auf meine Projekte bekomme ich nur wenig Resonanz. - Was ist jetzt
daraus abzuleiten?
Software-Entwicklung steht auch immer in einem Sozialem-Kontext.
Ich denke an dem Entwickler hängt garnicht soviel. Da spielen viel
andere Faktoren auch noch eine Rolle.
- Ist das Projekthema gerade "modern".
- Gibt es Konkurrenz-Projekte.
- Wie groß ist die potenzielle Ziel-Gruppe.
- Kann damit Geld verdient werden.
- Hat es ein gutes Image.
- Gibt es ein Forum zu Selbstdarstellung.
- Hat der Entwickler "Charisma".
- Wird das Thema von der Presse gepusht.
- Hat der Entwickler selbst ein gutes soziales Umfeld (Familie, Freunde...).
- Ist der Entwickler finanziell abgesichert.
- Gibt es Rechts-Unsicherheiten.
Usw....
Es wird nur Zukunft noch einfacher GNOME Anwendungen in Mono, C++, Perl, Python, Ruby zu entwickeln (siehe dazu auch das neue Projekt 'GNOME Development Platform language-bindings', welches API/ABI Kompatibilitaet und an die GNOME D&DP angepasste Releasezeiten garantiert).
Inwieweit solche (nicht in C oder C++ geschriebenen) Anwendungen dann zur 'GNOME Desktop and Developer Platform' gehoeren werden bleibt abzuwarten.
Sehe ich genauso. Ein gutes Projekt muss ein gewisses Sex-appeal (schreibt mans so?
) haben. Das ist halt nicht bei jedem gegeben.
KDE kam aus dem fast nichts (halt abgesehen von QT), ebenso GNOME.
Andere starteten mit fertigen Vorlagen.
Was ist am besten? Keiner kanns sagen, wichtig ist das der Einstieg einfach sein muss, oder es extrem bekannt sein muss. Nur so geht es.
Oder es findet sich ein Spezialgebiet as einige wenige brauchen, dann aber sehr brauchen. Gibt es auch.
Nunmehr wäre das gar kein Problem mehr, weil ja das Mono Projekt VisualBasic Klassen implementiert. Sobald man da was braucht, wird es auch implementiert werden.
ob ihre Ergebnisse von anderen benutzt werden können.
Tja, die Frage ist, ob der Code "der Anderen" in einer Form ist (Kommentare, Doku, Lesbarkeit), dass andere ihn nutzen können.
Manchmal sieht es da (nicht nur bei freien Prokekten) eher bescheiden aus, weil man vor lauter "Projekt schnell voranbringen" die Doku vernachlässigt.
Bye
Stefan
Ähnliches gilt für die Feature-Freeze-Hypothese. Sicher, Bugs sollte man auch beim Schreiben vermeiden, aber während eines Feature freezes schaut man sich notwendigerweise große Teile des Codes nochmal an, wobei auch Fehler gefunden werden. Das selbe gilt für die "Jetzt aber richtig"-Geschichte, wie ich aus eigener Erfahrung bestätigen kann. Man mahct sich bei Projekten zwar einen Plan im Voraus, aber bei der Umsetzung ergeben sich zwangsläufig Probleme, die Änderungen des Plans notwendig machen. Wenn man diese Probleme schon einmal durchgekaut hat, kann man sie beim zweiten Durchlauf eleganter behandeln oder gar umgehen - und da spreche ich aus Erfahrung. Das gilt insbesondere, wenn man ein bestimmtest API zum ersten mal verwendet, ist aber auch sonst von Bedeutung.
Ich habe den Eindruck, dass hier ein User spricht, der zwar die Bedürfnisse und Erwartungen von Benutzern ganz gut überschauen kann, aber von Softwareentwicklung herzlich wenig Ahnung hat.
Ich kann zwar Englisch, aber zum Einstieg in eine unbekannte Materie bevorzuge ich Deutsch, sonst verliere ich zu schnell den Boden unter den Füßen und weiß nicht mehr, was ich nicht weiß...
Natürlich zieht ein OpenSource-Projekt nicht automatisch neue Entwickler an, aber eine Software-Firma bekommt schließlich auch keine Mitarbeiter, wenn sie sich nicht selbst nach außen präsentiert und Entwickler umwirbt. So muss auch ein Projekt möglichst viel Publicity betreiben um die gewünschte Resonanz zu erhalten - sowohl in Form von Entwicklern als auch Anwendern. Zum Anderen muss ein freies Projekt, noch mehr als eine komerzielle Software, darauf achten, dass der Markt nicht bereits gesättigt ist. Wenn bereits ähnliche, gute Software frei verfügbar ist, dann lohnt es sich schlichtweg nicht, noch eine weiteres Programm aus der Taufe zu heben. Der Community wäre in diesem Fall viel mehr Nutzen entgegengebracht, wenn sich diese(r) Entwickler dem bereits vorhandenen Projekt konstruktiv anschließt.
Sollte es eine Software für den Zweck, in der Form und für diese Plattform noch nicht geben, so muss ein OpenSource-Entwickler zuerst, wie ein komerzielles Unternehmen auch, die Nachfrage nach der Software sowie das Angebot an Entwicklern, mit den nötigen Begabungen, welche auch die entsprechende Hardware besitzen, überprüfen. Sobald diese Faktoren zutreffen müsste sich das Projekt zügig entwickeln - und das ohne die Markteinflüsse, denen Unternehmer ausgesetzt sind. Ferner kann auch eine Einzelperson ein Projekt in Eigenregie aufziehen und trotzdem den Quellcode freigeben, wovon wiederum andere Projekte profitieren können. In diesem Punkt kann ich den Autor nur bestätigen, denn Zeit ist Geld, bzw. Zeit ist wertvoll - in großem Maße auch für die freien Projekte, die auf den tatkräftigen Zeiteinsatz von Entwicklern angewiesen sind. Auch der Anwender, der Einsicht in die Arbeit hat, kann herausfinden, wie das Programm funktioniert und somit seine Informatik-Kentnisse aufbessern oder einfach nur das gute Gefühl besitzen, nicht hintergangen zu werden.
Der Feature-Freeze ist in meinen Augen sehr sinnvoll, denn soweit ich weiß bezeichnet dieses nicht den Stillstand der Entwicklung von neuen Funktionen sondern nur die Dead-Line für Implementationenen in ein bestimmtes Release. In dieses Release fließen dann nur noch die Bug-fixes ein. Neue Features werden dann eben in die nächste Entwickler-Version eingebracht. Die Ansicht, man könne Fehler auch beim Schreiben vermeiden gleicht dem Versuch, einem Torhüter zu sagen, er solle keine Tore reinlassen. Jeder macht, meist unabsichtlich und unbemerkt, Fehler, die einem nicht direkt auffallen und vielleicht erst einer anderen Person auffallen.
Ich sehe auch die beste Möglichkeit darin, ein Projekt kennen zu lernen, indem man dessen Code liest und evtl. Fehler behebt. Darauf basiert schließlich das OpenSource-Prinzip und durch Interesse am Projekt gelangt man zum Interesse am Code und schließlich zum Bug-fixing. Der Code ist die Basis eines jeden Programmes und nur wenn man den Code liest, kann man die Anwendung auch von Grund auf kennen lernen und verstehen.
wir haben bei FreeCNC einige Entwicklungen nur bekommen, weil der Quellcode frei ist. Genauso bei holaCMS. Es war dienlich, dass einer einen testing-Tree geöffnet hat und drin rumprogrammiert hat. Letztendlich gingen die guten Sachen in den Haupttree zurück.
Also aus meiner Erfahrung gibt es natürlich einen starken Mangel an Entwicklern, aber wie heisst es noch so schon: "heutzutage findet man einfach kein gutes personal mehr *g*".
Die beste Möglichkeit, Bugs zu vermeiden ist nicht, diese zu suchen, sondern Bugs bereits beim Schreiben zu vermeiden.
Tolle Erkenntnis. Da wäre ich nie selber drauf gekommen
Aber wenn keiner mehr Fehler mach, kann auch niemand aus ihnen lernen. Es mag ein Irrglaube sein, das Bugs vermeiden von der ersten Zeile Code an funktionieren kann.
Besonders, wenn ich daran denke das in ein Projekt meist auch die Arbeit aus anderen Projekten mit einfließt. Wer schreibt schon für ein simples FrontEnd was benötigt wird den Unterbau oder seine eigene GTK QT oder was weiß ich Bibliothek ,wenn die frei verfügbar ist?