ach das mit dem kritisch und am lautesten Schreien kann man ganz anschaulich erklären.
Ich lebe in Baden-Württemberg und bei uns im Ländle wird da so ein kleines Bahnhofsprojekt gemacht. Ich selbst lebe im Badischen bin also nicht direkt betroffen und habe auch nur mitbekommen was man so aus den Medien hörte und dergleichen.
Auf jeden Fall gab es letztes Jahr dann einen Volksentscheid zu dem Bahnhof. Ich hatte damit gerechnet nach all den Demonstrationen und dergleichen die selbst im entfernten Baden zu spüren waren, dass der Bahnhof abgelehnt wird oder dass das Quorum nicht erreicht wird.
Stattdessen wurde das Quorum erreicht und eine Mehrheit selbst im betroffenen Stuttgart hat dafür gestimmt.
Nicht immer sind die, die am lautesten schreien auch in der Mehrheit. Deshalb lasse ich mich in meiner Wahl welche Bugs ich bearbeite nicht vom laut schreien beeinflussen, sondern analysiere ganz objektiv den Bugreport.
Ach ja und dann ist da noch so ein kleines Problem namens Motivation. Natürlich bin ich nicht motiviert einen Bug zu bearbeiten, bei dem die Entwickler beleidigt werden oder elendig lang herumdiskutiert wird.
Das ganze hat überhaupt nichts mit Befangenheit oder Kritikunfähigkeit zu tun. Zu sagen, dass ein Bug nicht so wichtig ist, wie der Nutzer meint, bedeutet nicht, dass man nicht in der Lage ist Kritik anzunehmen. Genaugenommen ist der Nutzer nicht kritikfähig, denn er kann nicht das große und ganze erkennen (Bug betrifft nur ihn im Vergleich zu anderem Bug der tausende von Nutzern betrifft).
Ach Martin, ich kann Dich nur für Deine Geduld bewundern, die Du bei solchen Kommentaren an den Tag legst. Wer ernsthaft kommerzielle Software und Bug Reports in den Mund nimmt, der ist per se imho schon nicht ernst zu nehmen. Und dass man sich nicht von irgend jemanden vorschreiben lässt, was man in seiner Freizeit zu tun hat, sollte eigentlich auch selbstverständlich sein. Wenn es danach ginge würde ich dem Kommentator vorschreiben, dass er das Posten hier unterlassen soll - ihm fehlt ja offensichtlich die Distanz zu seinen Kommentaren
@All: Leute denkt doch mal erst nach, bevor ihr solchen Unsinn verzapft! Wie kann man ernsthaft annehmen, dass man als Benutzer über Dinge an einer OS Software bestimmen kann? Ich kann Vorschläge machen oder daran mitarbeiten oder einen Fork erstellen - den Entwicklern kann ich doch keine Befehle erteilen! Mann mann mann... habt ihr so ein Anspruchsdenken auch in eurem übrigen Leben?
> Wer ernsthaft kommerzielle Software und Bug Reports in den Mund nimmt, der ist per se imho schon nicht ernst zu nehmen.
Nicht jeder spielt nur Computerspiele, daher wäre es sinnvoll wenn du mal aus deiner Welt herausbrichst und dir professionelle Software z.B. für Supercomputer oder der Anlagenindustrie anschaust, dann wirst du auch (hoffentlich) erkennen, wo dein Fehler in deiner Argumentation liegt.
Wir reden hier aber nicht von Spezialsoftware o.ä. sondern von Desktop Software. Kann ich bei MS einen Bug Report für MS Office einreichen? Und diesen dann ggf. noch als kritisch einstufen? Oder bei Apple, wenn mein iDings spinnt? Werden die reagieren, wenn ich damit "drohe" keine Apple-Produkte mehr zu kaufen?
Aber ich gehe dennoch auch gerne auf Deine These ein, dass das im B2B-Bereich anders abläuft. Denn selbst bei B2B-Software stuft nicht der Supportnehmer die Wichtigkeit eines Fehlers ein, sondern darüber entscheidet ein Kompetenzträger der jeweiligen Fachabteilung des Software Anbieters. Zumindest habe ich das in der Berufswelt bisher nicht anders erlebt - aber ich lasse mich da gerne belehren. Du kannst mir gerne ein Beispiel nennen, wo das so wie von Dir postuliert der Fall wäre!
Also muss nicht ich meine Argumentation überdenken, sondern Du nicht mit Haarspalterei daher kommen.
Von Softwareversteher am So, 19. August 2012 um 14:08 #
Man was war das früher schön, als niemand Software als Gott gegeben wahrnahm. Es gibt viel mehr Menschen die Software kaufen und mit den Fehlern leben als Menschen die Meckern und drohen und kein Cent gegeben haben. Ich finde es immer lustig, wenn Bugs in Macsoftware nach Updates nur von vereinzelten in Foren angeprangert werden, aber das Zeug doch gekauft wird. Vielleicht sollten OS Entwickler Geld fürs angemeckert werden bekommen. Dann hätten die in kurzer Zeit mehr Geld als M$ un Aplle zusammen. Es müsste wirklich mal festgehalten werden, wieviel Zeit in einem Projekt zur Entwicklung und wieviel zu Fehlerbehebung verbraucht werden. Und jeder Bug sollte durch ein Spenden oder Bezahlsystem in seiner Wertigkeit steigen. Einfach bei jedem Bug eine Spendemöglichkeit einrichten und sehen wem es etwas Wert ist zur Behebung bei zu tragen. Wenn ich nicht Programmieren kann um es selber zu beheben, dann Zahle ich um genau den Bug interessanter für Programmierer zu machen. Die dann Ihr Geld damit verdienen können.Dazu muss nur sicher sein, das das Geld nicht in ein Bugtopf kommt, sondern das gezahlte genau dem Bug hilft wofür es gezahlt wurde. Ich denke, das so viel geziehlter ein wirklicher Bug behoben wird und wenn ich sehe das niemand für den Bug bezahlt, dann kann er auch nicht so wichtig sein. Selbst wenn jeder nur 50 Cent Zahlt, hängt es nur noch an der Zahl der Betroffenen, um viel Geld zusammen zu bekommen.
Das würde nur dazu führen, dass keine Bugs mehr reportet würden. Langfristig gesehen, könnten die Entwickler dann Ihre Software für sich alleine benutzen.
Wenn ein Projekt einen Bug aus irgendwelchen Gründen nicht fixen kann oder will, dann schreibt man nach ein paar Wochen eben "WONTFIX" hin und schließt das Ganze. Zumindest weiß der Nutzer dann, woran er ist.
Und jeder Bug sollte durch ein Spenden oder Bezahlsystem in seiner Wertigkeit steigen. Einfach bei jedem Bug eine Spendemöglichkeit einrichten und sehen wem es etwas Wert ist zur Behebung bei zu tragen
Deine sicher nett gemeinte Idee hat leider einen Fehler in der Umsetzung.
Wenn man so ne Open Source Seite für das Fixen von Bugs erstellen würde, so wie z.B. bei Frage_einen_Anwalt.de, wo dann jeder user einen Bug melden und nen Preis ausschreiben kann, dann werden viele Entwickler sich auf den gleichen Bug stürzen und da ein Bug nicht gleich, so wie ein Anwaltsschreiben fertig ist, werden viele Entwickler im privaten Kämmerlein ihre Zeit am gleichen Bug verschwenden und die Arbeit somit doppelt und dreifach erledigen und nur einer, in der Regel der schnellste, seinen möglicherweise dahingerotzen Bugfix online stellen, während die anderen nicht nur lehr ausgehen, sondern auch ihre Zeit verschwendet haben. Denn wenn jeder am gleichen Problem arbeitet, hilft das niemand und zu allem Übel kommt dann noch hinzu, daß höchstwahrscheinlich der am schnellsten fertige Bugfix in die Software aufgenommen wird und nicht der qualitativ eleganteste Bugfix.
So ein System kann also nur nach Auftragsarbeit funktionieren, bei dem dann ein Bugs einem bestimmten Entwickler der sich dafür meldet zugewiesen wird und der dann genug Zeit bekommt in aller Ruhe das Problem alleine zu lösen. Solange steht dann das Geld auf halde. Damit sich aber ein Entwickler nicht alle Bugs für sich alleine reserviert oder gar den Bugfix auf die lange Bank schiebt, so daß der Bug über Monate ungelöst bleibt, währen hier unter Umständen entweder eine Frist in der der Bug zu lösen ist notwendig, was auch nicht optimal ist, da dadurch der Bugfix in Verzug gerät, wenn dann 5 inkompetente Entwickler der Reihe nach daran werkeln, oder man führt Vertragsstrafen ein, so wie es bei Auftragsarbeiten üblich ist, aber dann wird man auch weder Entwickler haben die sich darauf einlassen wollen.
Im großen und ganzen wäre das größte Problem von diesem Konzept aber, daß die klassischen Entwickler, die neue Features in die Software einbauen oder die Software zu einem besseren Grunddesign komplett umbauen und damit in der Regel leer ausgehen, sich verarscht fühlen müssen.
Und da es schon bezahlte Entwickler z.B. bei Debian gab, was zu erheblichem Neid und Streitigkeiten führte, ist klar, daß so ein Konzept bei OS Software nicht wirklich funktionieren kann, bzw. der Open Source Software eher schadet.
die Idee ist gut und auch nicht neu, nur leider würde sie auch nicht funktionieren.
Als erstes und größtes Problem sehe ich, dass Anwender zu den Schlüssen kommen würden, dass die Entwickler absichtlich Bugs einbauen um sie danach beheben zu können. Und ganz ehrlich würde ich das für denkbar halten, falls Entwickler davon leben wollen können.
Ein anderes Problem ist, dass bei gut funktionierender Entwicklungsmodelle mehrere Entwickler an einem Bugfix beteiligt sein sollten. Wie ist der Reviewer zu beurteilen und der Maintainer, der es absegnet.
Dann ist die Frage wie damit umgegangen wird, wenn der Bugfix schlechte Qualität hat oder sogar Regressions verursacht? Muss der Entwickler das dann beheben oder soll sich die Community darum kümmern?
Ein weiteres schwerwiegendes Problem sind die Gehaltsgefälle. Das was für einen indischen Entwickler viel Geld ist, dafür würde ein deutscher Entwickler nicht mal die Tastatur berühren - ein ernsthaftes Problem auch bei GSoC.
Ich denke, dass solch ein Modell nicht funktionieren kann, da es das Potential hat eine Community zu zerstören. Es führt zu einer zwei Klassen Gesellschaft von deren die Geld mit der Software verdienen und derer die es freiwillig machen.
Wir reden hier aber nicht von Spezialsoftware o.ä. sondern von Desktop Software.
Auch da findest du qualitativ hochwertigen Code.
Von Software nach Maß bis zu Mathematika und NI Multisim findest du dort überall kommerzielle Software mit qualitativ hochwertigem Code und das ist alles Desktop Software.
Kann ich bei MS einen Bug Report für MS Office einreichen?
Als Firma hat man mit MS in der Regel einen Supportvertrag und da kann man das durchaus weiterreichen.
Denn selbst bei B2B-Software stuft nicht der Supportnehmer die Wichtigkeit eines Fehlers ein, sondern darüber entscheidet ein Kompetenzträger der jeweiligen Fachabteilung des Software Anbieters.
Wenn deine Firma groß genug und dein Supportvertrag finanziell bedeutend genug ist, dann wird die Softwarefirma sogar unwichtige Features schnellstmöglich einbauen, wenn du es forderst.
Es gibt auch Firmen, die dir Supportverträge für OpenSource Software anbieten. Was hier anscheinend immer wieder vergessen wird, ist dass es bei OpenSource darum geht, dass der Quellcode offen ist und nicht darum, dass die Produkte kostenlos sind.
Von Open Source Software das zu erwarten im Support Bereich was kommerzielle Anbieter leisten ist nun ja naiv. Aber Open Source macht es möglich, dass es Firmen gibt, die kommerziellen Support anbieten und auch noch darum konkurrieren können anstatt dass du eine einzige Firma hast, die Preise diktieren.
Im Umfeld des KDE Umfelds kenne ich mehrere Firmen, die dir auch Fehler in KDE Software beheben. Ich selbst biete das kommerziell auch an (wobei ich es nicht bewerbe und es nicht gerade viel einbringt).
Also wer will, kann seinen kommerziellen Support bekommen und dann sieht das genauso aus wie bei normaler unfreier Software.
"Im Umfeld des KDE Umfelds kenne ich mehrere Firmen, die dir auch Fehler in KDE Software beheben. "
Als Privatnutzer lohnt sich das im Hinblick auf Kmail2 bestimmt nicht, da es hierfür zur Zeit andere, bugfreiere Emailsoftwareangebote gibt. Falls ich Kmail2 jemals benutzt und solche Probleme, wie sie hier anscheinend augetaucht sind, damit gehabt hätte, dann wäre mir nur die Option geblieben, möglichst viele Emails zu "retten" und eine andere Software zu benutzen. Gnome2-Evolution funktioniert ganz gut, für Privatnutzer reicht Thunderbird ganz bestimmt meist aus, für KDE-Fans bieten der OBS genauso wie open SUSE 12.1 Main noch KMail1 an.
Und Firmen sollten vor einer Umstellung auf Kmail2 entsprechende Tests gemacht haben. Von daher glaube ich kaum, dass hier überhaupt irgendwelche "Schäden" aufgetreten sind.
Verbiege doch nicht alles in Deinem Sinne! Es ging um die Tatsache, dass man als 0815 User bei kommerzieller Massenware idR. eben keinen Bug direkt melden und schon gar nicht diesen priorisieren kann. Das war der Knackpunkt. Von Qualität war da gar nicht die Rede.
Und auch beim letzten Punkt stimmst DU mir ja zu: Ich kann einen Bug als Großkunde sicher melden und monieren, aber ich kann ihn nicht *direkt* priorisieren. Indirekt mag das über meinen Supportvertrag und dessen Lukrativität für die Anbieterfirma natürlich eine große Rolle spielen, direkt beeinflussen kann ich es nicht. Und nun zeige mir doch mal den Unterschied zu einem OS Projekt auf? Neben monetären Anreizen - wie es Martin ja schon aufzeigte - kann man da den Entwickler eben eher durch Stichhaltigkeit und Nutzen seines Reports motivieren. Wo ist hier also noch ein Problem? Unterm Strich hast Du hier sogar *mehr* Möglichkeiten!
ach das mit dem kritisch und am lautesten Schreien kann man ganz anschaulich erklären.
Ich lebe in Baden-Württemberg und bei uns im Ländle wird da so ein kleines Bahnhofsprojekt gemacht. Ich selbst lebe im Badischen bin also nicht direkt betroffen und habe auch nur mitbekommen was man so aus den Medien hörte und dergleichen.
Auf jeden Fall gab es letztes Jahr dann einen Volksentscheid zu dem Bahnhof. Ich hatte damit gerechnet nach all den Demonstrationen und dergleichen die selbst im entfernten Baden zu spüren waren, dass der Bahnhof abgelehnt wird oder dass das Quorum nicht erreicht wird.
Stattdessen wurde das Quorum erreicht und eine Mehrheit selbst im betroffenen Stuttgart hat dafür gestimmt.
Nicht immer sind die, die am lautesten schreien auch in der Mehrheit. Deshalb lasse ich mich in meiner Wahl welche Bugs ich bearbeite nicht vom laut schreien beeinflussen, sondern analysiere ganz objektiv den Bugreport.
Ach ja und dann ist da noch so ein kleines Problem namens Motivation. Natürlich bin ich nicht motiviert einen Bug zu bearbeiten, bei dem die Entwickler beleidigt werden oder elendig lang herumdiskutiert wird.
Das ganze hat überhaupt nichts mit Befangenheit oder Kritikunfähigkeit zu tun. Zu sagen, dass ein Bug nicht so wichtig ist, wie der Nutzer meint, bedeutet nicht, dass man nicht in der Lage ist Kritik anzunehmen. Genaugenommen ist der Nutzer nicht kritikfähig, denn er kann nicht das große und ganze erkennen (Bug betrifft nur ihn im Vergleich zu anderem Bug der tausende von Nutzern betrifft).
Ach Martin, ich kann Dich nur für Deine Geduld bewundern, die Du bei solchen Kommentaren an den Tag legst. Wer ernsthaft kommerzielle Software und Bug Reports in den Mund nimmt, der ist per se imho schon nicht ernst zu nehmen. Und dass man sich nicht von irgend jemanden vorschreiben lässt, was man in seiner Freizeit zu tun hat, sollte eigentlich auch selbstverständlich sein. Wenn es danach ginge würde ich dem Kommentator vorschreiben, dass er das Posten hier unterlassen soll - ihm fehlt ja offensichtlich die Distanz zu seinen Kommentaren
@All: Leute denkt doch mal erst nach, bevor ihr solchen Unsinn verzapft! Wie kann man ernsthaft annehmen, dass man als Benutzer über Dinge an einer OS Software bestimmen kann? Ich kann Vorschläge machen oder daran mitarbeiten oder einen Fork erstellen - den Entwicklern kann ich doch keine Befehle erteilen! Mann mann mann... habt ihr so ein Anspruchsdenken auch in eurem übrigen Leben?
> Wer ernsthaft kommerzielle Software und Bug Reports in den Mund nimmt, der ist per se imho schon nicht ernst zu nehmen.
Nicht jeder spielt nur Computerspiele, daher wäre es sinnvoll wenn du mal aus deiner Welt herausbrichst und dir professionelle Software z.B. für Supercomputer oder der Anlagenindustrie anschaust, dann wirst du auch (hoffentlich) erkennen, wo dein Fehler in deiner Argumentation liegt.
Wir reden hier aber nicht von Spezialsoftware o.ä. sondern von Desktop Software. Kann ich bei MS einen Bug Report für MS Office einreichen? Und diesen dann ggf. noch als kritisch einstufen? Oder bei Apple, wenn mein iDings spinnt? Werden die reagieren, wenn ich damit "drohe" keine Apple-Produkte mehr zu kaufen?
Aber ich gehe dennoch auch gerne auf Deine These ein, dass das im B2B-Bereich anders abläuft. Denn selbst bei B2B-Software stuft nicht der Supportnehmer die Wichtigkeit eines Fehlers ein, sondern darüber entscheidet ein Kompetenzträger der jeweiligen Fachabteilung des Software Anbieters. Zumindest habe ich das in der Berufswelt bisher nicht anders erlebt - aber ich lasse mich da gerne belehren. Du kannst mir gerne ein Beispiel nennen, wo das so wie von Dir postuliert der Fall wäre!
Also muss nicht ich meine Argumentation überdenken, sondern Du nicht mit Haarspalterei daher kommen.
Man was war das früher schön, als niemand Software als Gott gegeben wahrnahm. Es gibt viel mehr Menschen die Software kaufen und mit den Fehlern leben als Menschen die Meckern und drohen und kein Cent gegeben haben.
Ich finde es immer lustig, wenn Bugs in Macsoftware nach Updates nur von vereinzelten in Foren angeprangert werden, aber das Zeug doch gekauft wird. Vielleicht sollten OS Entwickler Geld fürs angemeckert werden bekommen. Dann hätten die in kurzer Zeit mehr Geld als M$ un Aplle zusammen.
Es müsste wirklich mal festgehalten werden, wieviel Zeit in einem Projekt zur Entwicklung und wieviel zu Fehlerbehebung verbraucht werden. Und jeder Bug sollte durch ein Spenden oder Bezahlsystem in seiner Wertigkeit steigen.
Einfach bei jedem Bug eine Spendemöglichkeit einrichten und sehen wem es etwas Wert ist zur Behebung bei zu tragen. Wenn ich nicht Programmieren kann um es selber zu beheben, dann Zahle ich um genau den Bug interessanter für Programmierer zu machen. Die dann Ihr Geld damit verdienen können.Dazu muss nur sicher sein, das das Geld nicht in ein Bugtopf kommt, sondern das gezahlte genau dem Bug hilft wofür es gezahlt wurde.
Ich denke, das so viel geziehlter ein wirklicher Bug behoben wird und wenn ich sehe das niemand für den Bug bezahlt, dann kann er auch nicht so wichtig sein.
Selbst wenn jeder nur 50 Cent Zahlt, hängt es nur noch an der Zahl der Betroffenen, um viel Geld zusammen zu bekommen.
Das würde nur dazu führen, dass keine Bugs mehr reportet würden. Langfristig gesehen, könnten die Entwickler dann Ihre Software für sich alleine benutzen.
Wenn ein Projekt einen Bug aus irgendwelchen Gründen nicht fixen kann oder will, dann schreibt man nach ein paar Wochen eben "WONTFIX" hin und schließt das Ganze. Zumindest weiß der Nutzer dann, woran er ist.
Deine sicher nett gemeinte Idee hat leider einen Fehler in der Umsetzung.
Wenn man so ne Open Source Seite für das Fixen von Bugs erstellen würde, so wie z.B. bei Frage_einen_Anwalt.de, wo dann jeder user einen Bug melden und nen Preis ausschreiben kann, dann werden viele Entwickler sich auf den gleichen Bug stürzen und da ein Bug nicht gleich, so wie ein Anwaltsschreiben fertig ist, werden viele Entwickler im privaten Kämmerlein ihre Zeit am gleichen Bug verschwenden und die Arbeit somit doppelt und dreifach erledigen und nur einer, in der Regel der schnellste, seinen möglicherweise dahingerotzen Bugfix online stellen, während die anderen nicht nur lehr ausgehen, sondern auch ihre Zeit verschwendet haben.
Denn wenn jeder am gleichen Problem arbeitet, hilft das niemand und zu allem Übel kommt dann noch hinzu, daß höchstwahrscheinlich der am schnellsten fertige Bugfix in die Software aufgenommen wird und nicht der qualitativ eleganteste Bugfix.
So ein System kann also nur nach Auftragsarbeit funktionieren, bei dem dann ein Bugs einem bestimmten Entwickler der sich dafür meldet zugewiesen wird und der dann genug Zeit bekommt in aller Ruhe das Problem alleine zu lösen.
Solange steht dann das Geld auf halde.
Damit sich aber ein Entwickler nicht alle Bugs für sich alleine reserviert oder gar den Bugfix auf die lange Bank schiebt, so daß der Bug über Monate ungelöst bleibt, währen hier unter Umständen entweder eine Frist in der der Bug zu lösen ist notwendig, was auch nicht optimal ist, da dadurch der Bugfix in Verzug gerät, wenn dann 5 inkompetente Entwickler der Reihe nach daran werkeln, oder man führt Vertragsstrafen ein, so wie es bei Auftragsarbeiten üblich ist, aber dann wird man auch weder Entwickler haben die sich darauf einlassen wollen.
Im großen und ganzen wäre das größte Problem von diesem Konzept aber, daß die klassischen Entwickler, die neue Features in die Software einbauen oder die Software zu einem besseren Grunddesign komplett umbauen und damit in der Regel leer ausgehen, sich verarscht fühlen müssen.
Und da es schon bezahlte Entwickler z.B. bei Debian gab, was zu erheblichem Neid und Streitigkeiten führte, ist klar, daß so ein Konzept bei OS Software nicht wirklich funktionieren kann, bzw. der Open Source Software eher schadet.
die Idee ist gut und auch nicht neu, nur leider würde sie auch nicht funktionieren.
Als erstes und größtes Problem sehe ich, dass Anwender zu den Schlüssen kommen würden, dass die Entwickler absichtlich Bugs einbauen um sie danach beheben zu können. Und ganz ehrlich würde ich das für denkbar halten, falls Entwickler davon leben wollen können.
Ein anderes Problem ist, dass bei gut funktionierender Entwicklungsmodelle mehrere Entwickler an einem Bugfix beteiligt sein sollten. Wie ist der Reviewer zu beurteilen und der Maintainer, der es absegnet.
Dann ist die Frage wie damit umgegangen wird, wenn der Bugfix schlechte Qualität hat oder sogar Regressions verursacht? Muss der Entwickler das dann beheben oder soll sich die Community darum kümmern?
Ein weiteres schwerwiegendes Problem sind die Gehaltsgefälle. Das was für einen indischen Entwickler viel Geld ist, dafür würde ein deutscher Entwickler nicht mal die Tastatur berühren - ein ernsthaftes Problem auch bei GSoC.
Ich denke, dass solch ein Modell nicht funktionieren kann, da es das Potential hat eine Community zu zerstören. Es führt zu einer zwei Klassen Gesellschaft von deren die Geld mit der Software verdienen und derer die es freiwillig machen.
Auch da findest du qualitativ hochwertigen Code.
Von Software nach Maß bis zu Mathematika und NI Multisim findest du dort überall kommerzielle Software mit qualitativ hochwertigem Code und das ist alles Desktop Software.
Als Firma hat man mit MS in der Regel einen Supportvertrag und da kann man das durchaus weiterreichen.
Wenn deine Firma groß genug und dein Supportvertrag finanziell bedeutend genug ist, dann wird die Softwarefirma sogar unwichtige Features schnellstmöglich einbauen, wenn du es forderst.
Es gibt auch Firmen, die dir Supportverträge für OpenSource Software anbieten. Was hier anscheinend immer wieder vergessen wird, ist dass es bei OpenSource darum geht, dass der Quellcode offen ist und nicht darum, dass die Produkte kostenlos sind.
Von Open Source Software das zu erwarten im Support Bereich was kommerzielle Anbieter leisten ist nun ja naiv. Aber Open Source macht es möglich, dass es Firmen gibt, die kommerziellen Support anbieten und auch noch darum konkurrieren können anstatt dass du eine einzige Firma hast, die Preise diktieren.
Im Umfeld des KDE Umfelds kenne ich mehrere Firmen, die dir auch Fehler in KDE Software beheben. Ich selbst biete das kommerziell auch an (wobei ich es nicht bewerbe und es nicht gerade viel einbringt).
Also wer will, kann seinen kommerziellen Support bekommen und dann sieht das genauso aus wie bei normaler unfreier Software.
"Im Umfeld des KDE Umfelds kenne ich mehrere Firmen, die dir auch Fehler in KDE Software beheben. "
Als Privatnutzer lohnt sich das im Hinblick auf Kmail2 bestimmt nicht, da es hierfür zur Zeit andere, bugfreiere Emailsoftwareangebote gibt.
Falls ich Kmail2 jemals benutzt und solche Probleme, wie sie hier anscheinend augetaucht sind, damit gehabt hätte, dann wäre mir nur die Option geblieben, möglichst viele Emails zu "retten" und eine andere Software zu benutzen. Gnome2-Evolution funktioniert ganz gut, für Privatnutzer reicht Thunderbird ganz bestimmt meist aus, für KDE-Fans bieten der OBS genauso wie open SUSE 12.1 Main noch KMail1 an.
Und Firmen sollten vor einer Umstellung auf Kmail2 entsprechende Tests gemacht haben. Von daher glaube ich kaum, dass hier überhaupt irgendwelche "Schäden" aufgetreten sind.
Verbiege doch nicht alles in Deinem Sinne! Es ging um die Tatsache, dass man als 0815 User bei kommerzieller Massenware idR. eben keinen Bug direkt melden und schon gar nicht diesen priorisieren kann. Das war der Knackpunkt. Von Qualität war da gar nicht die Rede.
Und auch beim letzten Punkt stimmst DU mir ja zu: Ich kann einen Bug als Großkunde sicher melden und monieren, aber ich kann ihn nicht *direkt* priorisieren. Indirekt mag das über meinen Supportvertrag und dessen Lukrativität für die Anbieterfirma natürlich eine große Rolle spielen, direkt beeinflussen kann ich es nicht. Und nun zeige mir doch mal den Unterschied zu einem OS Projekt auf? Neben monetären Anreizen - wie es Martin ja schon aufzeigte - kann man da den Entwickler eben eher durch Stichhaltigkeit und Nutzen seines Reports motivieren. Wo ist hier also noch ein Problem? Unterm Strich hast Du hier sogar *mehr* Möglichkeiten!