Open Source ist besser als proprietärer Quellcode

Die Qualität der Codes, die in Open Source-Projekten entstehen, ist inzwischen besser als bei professionell entwickelter Software. Das zeigen aktuelle Statistiken des Dienstleisters Coverity. mehr... Quellcode, Code, Programmierung, Programmiersprache Quellcode, Code, Programmiersprache, Php, Source Code Quellcode, Code, Programmiersprache, Php, Source Code Free for Commercial Use / Flickr

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
"Die Qualität der Codes, die in Open Source-Projekten entstehen, ist inzwischen besser als bei professionell entwickelter Software." - Anmerkung für Moderation: BEIDE Code-Varianten sind professionell. Ob nun "Opensource" oder "Clodedsource". Der Unterschied (teils vorteilhaft, teils nachteilhaft) ist lediglich, dass bei "Opensource" jeder interessierte den Code einsehen, prüfen und verändern kann.
 
@Stefan_der_held: Das ist der große äußerliche Unterschied. Allerdings ist Opensource nicht nur das Merkmal, dass der Code offenliegt, sondern ein Gesamtkonzept. ______Um mal Felix von Leitner zu zitieren: "Open Source als Bewegung ist das Konzept, dass man Leute Code schreiben lässt, deren Herzensblut dranhängt. Die es eben nicht kurz herunterpfuschen, weil sie dafür bezahlt werden. Open Source ist die Beobachtung, dass manche Menschen es lieben, Code zu schreiben. Und wenn man sie nicht mit Deadlines und Deliverables und dem monatlichen Paycheck unter Druck setzt, dann nehmen sie sich die Zeit und machen ihr Projekt ordentlich. Viel ordentlicher jedenfalls als die durchschnittliche kommerzielle Software." _____ http://blog.fefe.de/?ts=adb29937
 
@Sturmovik82: das ist schon klar mit "Herzensblut" ;-) trotzdem sind aber beide Varianten professionel umgesetzt. Natürlich geht man mit mehr Elan an die Materie wenn - wie du zitiert hast - herzensblut dran klebt. und ja: einen Fehler bei Opensource zu übersehen ist - eine fachkundige Gemeinde der der Sourcecode auch ausreichend interessiert vorausgesetzt - schon weit aus unwahrscheinlicher als bei "ClodesSoruce". Was ich bei "OpenSource" nachteilig finde, ist dass - spätestens ab Punkt "X" - zuviele Köche den Brei verderben können. Aber alles hat im Leben seine Vor-und-Nachteile.
 
@Sturmovik82: er hat aber auch eine sehr romantische Sicht auf die dinge, denn vieles dieses "herzensblut" kommt rein aus einer Anforderung/Notwendigkeit/nachfrage und ist viel weniger Herzenssache wie er sich das wünscht/vorstellt...von echtem herzensblut muss da nicht viel dran hängen - mancher nimmt sich das auch einfach für die Dissertation als Objekt ;). Auch wenn ich seine Ansicht zu "werft Geld drauf und alles wird besser" teile.
 
@Sturmovik82: Dein 'Gesamtkonzept' ist leider Wunschdenken. OpenSource sollen besser sein, weil es mit Herzblut entwickelt wird und ClosedSource, weil man dafür bezahlt wird? Das eine hat mit dem anderen doch wohl wenig zu tun. Ich habe schon in mehreren große ClosedSource-Projekten selber mitgearbeitet (mehrere Mann-Jahre) und ich habe selber an OpenSource-Projekten mitgearbeitet. Glaubst Du, dass ich mal besser und mal schlechter programmiere, je nachdem unter welcher Lizenz das Ergebnis steht? Nein, sicher nicht. Schau Dir doch mal OpenSource-Software an. Es gibt viele sehr gute Projekte, aber es gibt auch Unmengen an echtem Schrott. Bei ClosedSource gibt es genauso auch gute Produkte und Schrottprodukte. Große Projekte haben den Nachteil, dass sie sehr komplex und spezialisiert sind, so dass nur wenige Leute das Fachwissen haben, um daran mitzuarbeiten. Der OpenSSL-Bug ist ein gutes Beispiel dafür. Er war 2 Jahre lang in ganz, ganz vielen OpenSource-Produkten, aber keiner hat ihn gefunden. Ein Betriebssystem-Prof hat mir mal gesagt, dass nach seiner Meinung auf der Welt vielleicht ein Dutzend Menschen in der Lage sind einen performanten Betriebssystemkern zu schreiben, mehr nicht. Das war seiner Meinung nach die beste Leistung von Linus Torwalds, den er sehr achtet. Fachwissen ist entscheidend für guten Code, nicht die Lizenz der Veröffentlichung. Ich halte die obige Meldung einfach nur für platzierte Werbung von Coverity. Die wollten sich mal wieder in Erinnerung rufen und da bot sich der aktuelle GAU an.
 
@Stefan_der_held: open source quellcode ist zwar einsehbar, aber wer garantiert, daß die compilierten binaries, die ich mir mit einem linux iso herunterlade, mit dem quellcode übereinstimmen? hatte nicht linus torvalds selbst von der nsa post bekommen, gegen geld eine hintertür in linux einzubauen? und weniger gefestigte chefentwickler von linux lassen so eine hintertür vielleicht auch zu. ich bin da skeptisch und sage, offener quellcode ist nicht besser, als proprietärer code. und das sage ich, als freund von linux mint.
 
Die bessere Fehlerbehebung von C/C++ Entwickler erkläre ich mir an der Grundstruktur der Sprache. C/C++ lässt längst nicht so viele Fehler zu wie Java. Exceptions und so ^^

Man wird also viel mehr zum mitdenken angeregt beim Programmieren. Das habe ich auch in meinem Studium so empfunden.
 
@AdlerWolf: Es ist aber auch deutlich einfacher, unbewusste kritische Fehler einzubauen, wenn man z.B. wild im Speicher rumfuhrwerkt, die man selbst nicht bemerkt.
 
@dodnet: Normalerweise muss man aber nicht wild im Speicher rumfuhrwerkerln. Dafür gibt es ja Entwicklungsumgebungen wie Microsoft Visual Studio.
 
@AdlerWolf: Also C/C++ (unmanaged) lässt allein durch die Art und Weise viel mehr Fehler zu als irgendeine managed Sprache. Allein das Thema Pointer. Der Vorteil kann auch ein Fluch sein. Java aber an sich ist schon ein Fehler.
 
@TurboV6: Da gebe ich dir recht.
 
@TurboV6: Hehe, kann ich nicht bestätigen. Ich komme gut mit Java zurecht und finde seit Java 6 hat sich die Sprache gut gemacht.
 
@mala fide: sie hinkt aber modernen Sprachen völlig hinterher; in Sachen Funktionalität, Sicherheit, Performance, Entwicklungsumgebung.... Java gehört eben nicht mehr der Community sondern dem langsamsten IT Unternehmen der Erde.
 
@AdlerWolf: Stimmt. Eine ArrayOutOfBunds-Exception ist auch viel gravierender als eine Speicherzugriffsverletzung oder ein überschreiben der falschen Werte.
Speicherleaks sind auch keine Fehler, die irgendwie interessant oder schwerwiegend wären.....<------------------------------------------->
Zur Sicherheit: Der schleche Ruf von Java liegt vor allem an Applets im Browser, die c# gar nicht anbietet (soweit ich weiß).
Wenn man Code aus unbekannter Quelle laufen lässt (und das sind Appletts nunmal) ist das immer ein Risiko, gal ob Java oder C++.
 
@DRMfan^^: Silverlight vereint quasi Applets (Java) und Flash-Anwendungen.
 
@DRMfan^^: XBAP, das wäre die .net Version ;)
 
Properitär ist nicht gleich professionell bzw. Open Source gleich unprofessionell. Siehe Google, vieles Open Source aber wohl alles andere als unprofessionell. Ich finde der Vergleich aus dem Artikel hinkt.
 
@links234: Wo steht da was von "professionell" bzw. "unprofessionell"? EDIT: gleich im ersten Abschnitt - hab ich überlesen, sorry ;D
 
Da denkt wohl jemand man muss etwas Marketing betreiben um das Image aufzupolieren und das nur wegen dem einen hansel....heidanei.
 
Das Ergebnis kann ich nur aus meinem Bauchgefühl und Erfahrung bestätigen. Es gibt einen grundsätzlich Unterschied: Opensource-Software wird von den Entwicklern aus eigenem Antrieb und mit Motivation entwickelt. Proprietärer Code wurde von Entwicklern geschrieben, die das machen sollten. Dort ist - extrem negativ betrachtet - die Code-Qualität nur durch strenge Kontrolle und zusätzlicher Manpower besser. Diese Mehrressourcen sind in einem unternehmen grundsätzlich sehr knapp. So bleibt die Qualität allzu oft auf der Strecke.
Ist im übrigen auch meine Erfahrung: Bananen-Software, die beim Kunden reift ist immer häufiger anzutreffen, weil kurzfristige Erlöse heute wichtiger sind als langfristige Kundenzufriedenheit.
Leider...
 
@hhf: Naja, der Kunde bekommt die unreife Banane halt, wenn der Vertrieb bzw. der Kunde sie endlich auf dem Markt bzw. in Händen haben wollen. Das Open Source - Projekt stünde einfach noch nicht zu Verfügung "oh sorry, hat länger gedauert als gedacht, wir sind noch am bugfixen, ausserdem sind uns noch drei tolle Features eingefallen die wir vor Freigabe einbauen wollen" oder "oh sorry, hatte was anderes zu tun". Beides in einem Lieferanten-Kundenverhältnis zwar nicht undenkbar, aber nur in begrenztem Maße machbar. Andererseits gibt es bei Open Source oftmals schon veröffentlichte Alpha- und Betaversionen, die quasi offiziell unfertig und fehlerbehaftet sind. Daher bin ich mir nicht sicher, ob man die Qualität der ersten Version, die ein Anwender tatsächlich in den Fingern hat, bei Closed Source und Open Source wirklich vergleichen kann.
 
@FenFire: Der Vergleich hinkt immer irgendwo - ganz richtig.
Aber in dem was Du sagts, zeigt sich eben auch wieder ein erheblicher Unterschied: bei Open Source Software gehen die Entwickler ganz entspannt mit den Begriffen Alpha und beta Version um. Da ist dann auch mal eine an sich ausgereifte und schon oft genutzte Lösung noch Jahre lang in Version 0.97.
Bei kommerziellen Produkten gibt es das eigentlich nie. Der Hersteller wird niemals dem Kunden offen zugeben, dass er ihm eine bessere Beta-Version verkaufte. Das sehen wir immer recht deutlich bei Computerspielen, die immer häufiger bis Release nicht wirklich bugfrei gemacht wurden (siehe Raumsimulation X-Rebirth). Dort wird ein Hersteller nur durch die rege Kommunikation des Frühstarts in der Nutzergemeinde sehr schnell die Frühgeburt deutlich.
Bei vielen Produkten (gerade im B2B-Bereich) wird dem Kunden sonstwas vorgegaukelt.
 
@hhf: Ich nicht, eher das Gegenteil. Bei Linux selber mag das anders aussehen, aber meine Erfahrungen mit Opensource (z.B. Messenger, FileSharing) Es gibt i.d.R. keine Projektleitung, viele Projektteilnehmer werkeln so vor sich hin und machen vieles nach eigenem Gutdünken. Dies führt dann meistens zu 1)Jeder kleiner Pups an Userwünschen wird eingebaut, bei der GUI blickt kein normaler Nutzer mehr durch. 2)Spagethiecode. Obwohl grundlegende Dinge eigentlich verbessert werden müssten, ist das nicht oder kaum möglich. 3)Bugreports, dann wird dann wieder rumgewerkelt. 4)"Das gefällt mir nicht, ich mach mein eigenes Ding". Ich will nicht sagen das Closedsource besser ist, OpenSource aber generell auch nicht. Ich kenne bei beidem gutes und schlechtes.
 
Wie kann denn eine Software durch scannen des Codes Softwarefehler finden? Oft sich es einfach Logikfehler, Ausnahmen mit denen nicht gerechnet wurde und und und. Fehler wie gerade im OpenSSL Projekt können mit Sicherheit nicht durch ein Computer Programm bestimmt werden. Möglicherweise als Warnung, dass sich ein Entwickler ein paar Zeilen noch einmal genau angucken muss. Deswegen ist eine automatischen Analyse von Quellcode echt nicht aussagekräftig.
 
@Sprachtot47: Naja, Du kannst durch Codescanning schon bestimmte Fehler finden (z.B. fehlende Fehlerbehandlungen o.ä.). Ob der Code zwar rechnet, aber eben nicht das was an sich gewünscht ist da sich schlichtweg in der funktionalen Logik ein Fehler/Denkfehler eingeschlichen hat, kann so ein automatisierter Scanner natürlich nicht erkennen. Insofern bezieht sich die Aussage der News nur auf bestimmte Arten von Fehlern.
 
@Sprachtot47: Genau nach unbehandelten Ausnahmen, Speicherzugriffsfehlern kann über entsprechende Tools sicher gut gesucht werden. Logikfehler finden sich so vermutlich nicht, aber das ist ganz bestimmt auch nicht das Ziel eines solchen Tests.
 
Da spielt die Zeit und menge Mensch wohl eine große Rolle: Proprietäre Software ist meist an eine "Deadline" gebunden und es steckt viel Risiko drin, falls was schief läuft (Insolvenz, Arbeitsplätze, ganze Existenzen) -- daher MUSS etwas bis zu einem Datum fertig werden - und zwar mit der festgesetzen menge Mensch (und falls es "unfertig" ist, wird der Kunde eben als Testuser missbraucht...) -- bei Opensource hat man meist wesentlich längere Testzeiträume, kann dadurch auch mehr an Weiterentwicklungen denken und den Code dynamischer gestalten...DAS ist ja auch gerade das Erfolgsrezept --> siehe z.B. Debian -- die können sich den Luxus erlauben einen neuen Kernel zu implementieren, wenn die Entwickler sicher sind, dass es stabil läuft - und genau das schätzen die User an Debian -- nicht immer brandaktuell, aber dafür minimale Fehleranfälligkeit....
 
@slashi: Deine Argumente stimmen nicht. Dein Beispiel Debian: Es wird ca. alle 2 Jahre ein Stable-Release veröffentlicht, das ist häufiger als bei Windows. Ein Stable-Release wird 1 Jahr weiter als Oldstable-release supportet, das ist weniger als bei Windows. Bei Fedora (auch ein OpenSource-Linux) erscheint alle 6 Monate ein Release. Bei Firefox (OpenSource-Browser) erscheint alle 6 Wochen ein Release. Es wird also dort genauso nach Terminplan gearbeitet und nicht nach Qualität veröffentlicht.
 
@Nunk-Junge: und deine antwort ist nichtssagen (bis hin zu blöde) .....ad 1: wäre schlimm, wenn open source entwickler kein zeitplan verfolgen -- sowas zähl ich aber zur projektarbeit und mach ich sogar beim aufräumen meiner wohnung.... ad 2: schau dir mal an, was die ergebnisse (und intentionen) der releasezyklen genau sind (gerade im hinblick auf debian....) -- einfach nur sinnlos und ohne verstand zahlen miteinander vergleichen halte ich für gefährlich bis total bescheuert....
 
Eine kurze Erläuterung was hier als "Fehler" betrachtet wird wäre hilfreich. Logische Fehler wohl eher kaum oder?
 
@nexo: Das mit den "Fehlern" ist mir bis jetzt auch schleierhaft und würde mich freuen wenn jemand kurz "anreissen" kann was "diese Tools" so machen, nämlich auf folgenden Punkten macht es für mich keinen sinn:
1. Syntaxfehler können es nicht sein, denn diese werden schon bei der Entwicklung in der IDE, bzw. spätestens durch den Compiler abgefangen.
2. Wie erkennt dieses Tool logische Fehler?
3. Warum wird dieses Tool zum suchen von Fehlern verwendet aber diese dann nicht gleich gefixt, was dazu führen würde, dass nach Einsatz des Tools jeder Code 0 Fehler hätte. Was aber nicht (so einfach) möglich ist, da die Parameter zu komplex sind um die Fehlerfreiheit zu beweisen.

Also entweder hab ich was übersehen oder das ist alles "Statistik-Zirkus" ^^
 
@nexo: Eben das dachte ich mir auch! Und wer ist so blöd, Code mit Kompilerfehler hochzuladen? Und Logikfehler entdecken kann so eine Software wohl eher auch nicht. Wär wirklich gut zu wissen, wie die "Fehler" definieren.
 
OpenSource Code muss auch besser sein! Weil ihn jeder einsehen kann. Wenn OpenSSL kein OpenSource gewesen wäre, sondern nur über vorkompilierte Binaries beziehbar, hätte auch kein Externer den Bug einfach so gefunden!
Bei OpenSource-Projekten nerven (manchmal) insbesondere Inkonsistenz bei Codeformatierung oder Dokumentation. Ich finde es schlimm Sourcen anzuschauen, in denen außer dem Header mit Versions- und Lizenzinformationen sonst kein einziges Kommentar zu finden ist. Was soll das? In meinem Code bekommt fast jede Zeile einen Kommentar ... Leute so schwer ist das wirklich nicht!
 
@holyfetzer: It was hard to code, it should be hard to read! :)
 
@holyfetzer: Soweit ich mitbekommen habe wurde der Bug in OpenSSL durch Penetrationstests entdeckt...nicht durch einen Codereview...die Entdeckung selbst hat also recht wenig damit zu tun dass der Code einsehbar ist. Das trifft übrigens auf fast jede "in the wild" Sicherheitslücke zu egal ob closed oder open source...
 
@holyfetzer: Wieviele Leute arbeiten ernsthaft am SSL Code, dass es Jahre dauert bis so ein Bug auffällt? Sei mir nicht bös, aber die Mär vom sichereren Open Source Code glaubt doch niemand mehr! Es gibt sicher Teile von Open Source Projekten an denen viele arbeiten. Die mögen sicher sein. Aber ein Großteil des Open Source Codes wird aber von ganz wenigen Leuten wirklich angesehen. Nur weil man "rein theoretisch schauen könnte ob Fehler drin sind", behebt das keinen einzigen Bug. Firmen die Geld mit Software verdienen, MÜSSEN genügend Leute in hochkritische Bereiche einsetzen, selbst wenn der Code "relativ" einfach ist. Bei Open Source arbeiten soviele dran wie grad wollen. Der wirklich große Unterschied ist, dass diejenigen, die Interesse am Ausnutzen von Sicherheitslücken haben, ebenso den Fehler finden können. Ich würde fast wetten, dass sich mehr "böse" (Inkl Geheimdienste) sich mit dem Sourcecode von fürs Internet relevanten (Open) Sourcecodes auseinandersetzen als "Gute". Weil die "bösen" damit Geld verdienen! Auch wenns so klingt: Ich sage NICHT dass Open Source unsicher ist. Aber dass er pauschal sicherer sein soll als Closed Source ist wohl ein großer Unsinn, der nur jetzt verbreitet wird um das Vertrauen in Open Source wieder herzustellen.
 
@Tintifax: "Firmen die Geld mit Software verdienen, MÜSSEN genügend Leute in hochkritische Bereiche einsetzen, selbst wenn der Code "relativ" einfach ist."
Ersetze das "MÜSSEN" durch "müssten und sollten sie eigentlich, tun sie aber in den meisten Fällen trotzdem nicht, da dies eben Geld kosten würde und Geld ist immer knapp".
 
@Fonce: Wenn Du Dir z.B. das ultimative Feindbild der OS Community anschaust: Mit dem Sicherheitsdesaster Windows XP hat MS MASSIV in die Source-Sicherheit investiert.
 
@Tintifax: es lässt sich hier trotzdem keine generelle aussage treffen, fonce hat schon recht mit müssten und sollten...denn in der Realität sieht das anders aus, auch wenn MS in dem punkt ziemlich vorbildlich ist so sieht vieles einfach aus wie kraut und rüben und da is eigentlich egal ob man open source oder closed source anschaut
 
@0711: Eben, sag ich ja: Generelle Aussage lässt sich nicht treffen! Open Source sagt nichts darüber aus wieviele Leute am Code arbeiten, wieviele sich den ansehen. Und vor allem "wie ist das Verhältnis zwischen denjenigen die Lücken im Code suchen um sie zu stopfen, und denjenigen die Lücken im Code suchen im sie auszunutzen. Vermutlich sind die große Mehrheit der Open Source Projekte Ein-Mann-Projekte, die von Usern als "Gratis" wahrgenommen werden. Deshalb ist die Aussage "Open Source ist sicherer" der ultimative Unsinn. Ungefähr so wie "Rote Autos sind sicherer"...
 
@Tintifax: dass aber im Umkehrschluss bei closed source zwangsweise mehr gewicht in Sicherheit o.ä. gesteckt wird ist aber ebenso Unsinn... ;)
 
@0711: Natürlich ists nicht automatisch richtig. Aber einerseits ist da ein kommerzieller Gedanke dahinter (zumindest bei den Firmen die es verstanden haben, dass Sicherheit wichtig ist. Und demnach werden Resourcen freigeschaufelt, und nicht "wenn jemand Zeit hat"...) Und es hat zumindest den Vorteil, dass nur "die guten" den Source sehen. :)
 
@Tintifax: genau der kommerzielle Gedanke verhindert das oft genug, auch bei firmen die verstanden haben dass Sicherheit wichtig ist gibt es eben immer Deadlines und co die Entwickler unter druck setzen....ich sehe da schlicht keinen vorteil
 
@0711: Wenn ein Projekt gutgeplant ist, dann nicht.
 
@Tintifax: ist in vielen Situationen einfach utopisch, das hat nichts mit schlecht geplant zu tun
 
War ja klar dass so etwas jetzt nach dem OpenSSL Desaster kommen musste...
 
@Tintifax: Niemand hat behauptet, das Open-Source-Software keine Fehler hat. Nur hat bei Open-Source-Software jeder die Chance sie zu finden und zu beheben. In Closed-Source-Software kann man zwar Sicherheitslücken finden, aber nicht ohne Hilfe des Herstellers beseitigen. Bei heimlich eingebauten Backdoors steht man bei Closed-Source noch weit dümmer da. Da kann man fast nur entdecken, wenn NSA und Co. diese aktiv benutzen und man seinen Datenverkehr protokollieren lässt, während man in OSS-Software den Quelltext nach entsprechenden Funktionalitäten durchsuchen kann. ____

Open-Source-Software ist aber schon deshalb besser als kommerzielle Closed-Source-Anwendungen, weil man schon durch den Wegfall irgendwelcher Kopiersperren/Lizenzgehampel ein viel weniger Lebenszeit stehlendes, variabler einzusetzendes Produkt hat. ____

Ich bin heute auf jeden Fall verdammt froh, das ich MS Office schon in den 90ern wegen Instabilitäten in der Formatierung grosser Dokumente mit Fliesstext und an Seiten geankerten Bildern satt hatte und zuerst auf Lotus und dann auf StarOffice/OpenOffice umgestiegen bin. So sitze ich heute nicht auf MS Office mit Abo-Falle fest, sondern kann meine Dokumente direkt samt von mir einmal konfiguriertem Office-Paket auf einen USB-Stick packen und auf jedem beliebigen Rechner mit Windows, Linux und sogar auf Solaris-Maschinen bearbeiten. Hätte ich heute stattdessen zehntausende MS-Office-Dokumente, sässe ich in der MS-Falle, denn die alle garantiert funktionsfähig zu konvertieren würde vermutlich Jahre dauern.
 
Coverity wurde 2006 in Zusammenarbeit mit dem U.S. Department of Homeland Security ins Leben gerufen! Angeblich soll es seit 2008 eigenständig sein. Diese Tatsache lassen ich einfach mal hier wirken ......
 
@Rumulus: Ich hab mich beim lesen der News gefragt, wie die obigen, statistischen Daten eigentlich erfasst wurden. Will sagen: haben div. Leute ihre Software an die Firma geschickt und die haben es bei sich analysiert, oder wird deren Software verkauft, läuft und analysiert beim Programmierer selber und telefoniert dann das Ergebnis nach Hause = dadurch entsteht die Möglichkeit, obiges auszusagen? Oder wurde da sogar ungefragt / unerbeten einfach mal div. auf dem Markt befindliches "durchgejagt" ?
 
Genau die richtige Überschrift nach Open Heartbleed 1a!
Kommentar abgeben Netiquette beachten!

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.

Folgt uns auf Twitter

WinFuture bei Twitter

Interessante Artikel & Testberichte

WinFuture wird gehostet von Artfiles