OpenSource hat den besseren Code

[Avalox]

Der Coverity Scan Report ist veröffentlicht worden, in welchen umfassend proprietäre und OpenSource Software auf die Fehlerdichte getestet wird.

Erfreulicherweise schneidet OpenSource Software deutlich besser ab, als ihre ClosedSource Gegenspieler.
So erzielt ClosedSource Software rund 0,72 Fehler auf 1000 Zeilen Code, während die Fehlerdichte von OpenSource Software auf rund 0,59 Fehler pro 1000 Zeilen attestiert wird.

http://thevarguy.com/open-source-application-software-companies/041614/coverity-scan-says-open-source-code-better-quality

[Godmode]

Je mehr Augen den Code sehen, desto mehr Fehler werden entdeckt. Interessant wäre es, wie es bei großen vs kleinen Projekten aussieht.

[Avalox]

Je mehr Augen den Code sehen, desto mehr Fehler werden entdeckt. Interessant wäre es, wie es bei großen vs kleinen Projekten aussieht.

Das gab es auch Zahlen. Der Bericht unterscheidet die Projekte an ihrem Codeumfang.

Der Linux Kernel liegt mit 0,61 Fehler auf 1000 Zeilen als großes Projekt ausgesprochen gut im Rennen, z.B.

Ich glaube der Report wird kostenfrei angeboten, man muss sich registrieren.

Die Namen der getesteten proprietären Software hat man aus Datenschutzgründen nicht bekannt gegeben, allerdings soll diese sehr repräsentativ sein.

[Watson007]

gleich wird phuv energisch widersprechen :-)

den linux-kernel kann man aber nicht ganz mitzählen da untypisch, weil viele bezahlte kräfte daran mitwirken

[Avalox]

den linux-kernel kann man aber nicht ganz mitzählen da untypisch, weil viele bezahlte kräfte daran mitwirken

Untypisch würde ich das nicht nennen ich denke, dass in allen größeren Projekten bezahlte Entwickler die Mehrheit bilden.

[Exxtreme]

den linux-kernel kann man aber nicht ganz mitzählen da untypisch, weil viele bezahlte kräfte daran mitwirken
In sehr vielen größeren Opensource-Projekten machen von Unternehmen bezahlte Entwickler mit.

[Shink]

Irgendwie wundert mich das bei den OpenSource-Strategien mancher Firmen.

Z.B. gibt es jede Menge RedHat-Produkte, bei denen die "freien" Varianten mehr oder weniger Beta-Versionen sind. Support und Fixes gibt es dann (zumindest früher oder später) nur bei den kommerziellen Varianten.

Wenn dann mehrere Partner beisteuern (z.B. Linux Kernel, Eclipse), ist es wiederum halb so schlimm. Aber bei "Nischenprodukten" wie JBPM, Drools oder auch den Fedora-eigenen Tools bin ich nicht ganz überzeugt von deren Qualitätssicherung...

[lumines]

Z.B. gibt es jede Menge RedHat-Produkte, bei denen die "freien" Varianten mehr oder weniger Beta-Versionen sind.

Das Community-Äquivalent zu RHEL sind CentOS und Scientific Linux, nicht Fedora. Fedora ist eher so etwas wie Debian testing in Form einer eigenen Distribution mit festen Release-Zyklen.

[Shink]

Das Community-Äquivalent zu RHEL sind CentOS und Scientific Linux, nicht Fedora. Fedora ist eher so etwas wie Debian testing in Form einer eigenen Distribution mit festen Release-Zyklen.
Wie gesagt: Bei manch anderen Produkten von RedHat gibt es keine "Community-Äquivalente".

[sei laut]

Die Fehlerdichte ohne Gewichtung der Fehler sagt erstmal nichts aus in meinen Augen.
Es mag sein, dass OpenSource den besseren Code hat, aber ich halte das für schwierig zu prüfen.

[ShadowXX]

Die Fehlerdichte ohne Gewichtung der Fehler sagt erstmal nichts aus in meinen Augen.
Es mag sein, dass OpenSource den besseren Code hat, aber ich halte das für schwierig zu prüfen.
Speziell würde mich mal interessieren wo Sie den Source-Code der Closed-Source-Software herhatten....

Davon abgesehen halte ich beide Fehlerzahlen für viel viel viel zu niedrig. Unter einem Fehler pro Tausend Codezeilen? Das klingt extrem unglaubwürdig (sowohl für Open- als auch Closed-Source).

[Avalox]

Speziell würde mich mal interessieren wo Sie den Source-Code der Closed-Source-Software herhatten....

US Homeland Security, entsprechende Tests werden vorgeschrieben, für den der seine Software öffentlichen Bereichen anbieten will.

Ich kann mich vor Jahren erinnern, da galt eine annehmbare Codequalität von 1 Fehler auf tausend Zeilen Code. Entsprechende Meßgröße existiert wohl seit Urzeiten.

[ravage]

Als Laie hätte ich da mal zwei Verständnis Fragen:

1) Was für Fehler werden da gefunden? Syntax Fehler werden doch wohl schon vom Compiler erkannt.
2) Wenn es dieser Firma möglich ist per Software nach Fehlern zu suchen, wieso machen das nicht auch die Code Ersteller um erst gar keine Fehler aufkommen zu lassen?

[Avalox]

Als Laie hätte ich da mal zwei Verständnis Fragen:

1) Was für Fehler werden da gefunden? Syntax Fehler werden doch wohl schon vom Compiler erkannt.
2) Wenn es dieser Firma möglich ist per Software nach Fehlern zu suchen, wieso machen das nicht auch die Code Ersteller um erst gar keine Fehler aufkommen zu lassen?


Das Verfahren im speziellen ist patentiert (Forschung), setzt jemanden voraus, der es bedient (Aufwand).
Entsprechende Verfahren sind aber durchaus in Abstufungen gängig und werden auch eingesetzt und dadurch entsprechende Fehler identifiziert.

In der Software Qualität ist es aber überhaupt nicht üblich alle Fehler zu beseitigen.
Fehler müssen erkannt werden, dann müsste aber diesen Fehler jemand auch abstellen. Da das aufwändig und teuer ist, wird so etwas nicht pauschal getan, sondern hat einen Workflow der erstmal den Nutzen der Fehlerbeseitigung bewertet und diesen im Bezug zum Aufwand stellt. Viele Fehler werden als so gering durch die Entwickler bemessen, dass sich niemand dran tut um diese überhaupt zu beseitigen.

Dramatisch, wenn die Auswirkung solch einen geringen Fehlers falsch eingeschätzt wurde und sich später größere Konsequenzen ergeben.

[Simon]

Als Laie hätte ich da mal zwei Verständnis Fragen:

1) Was für Fehler werden da gefunden? Syntax Fehler werden doch wohl schon vom Compiler erkannt.
Das ist eine statische Code-Analyse. Die findet zum Beispiel Memory Leaks, Overflows bei Berechnungen, Buffer Overflows, Race Conditions, etc.
Logik-Fehler werden damit auch nicht gefunden.

2) Wenn es dieser Firma möglich ist per Software nach Fehlern zu suchen, wieso machen das nicht auch die Code Ersteller um erst gar keine Fehler aufkommen zu lassen?
Coverity ist ein Tool der Firma und dieser Report ist Teil des Marketings dafuer. Und damit ist auch klar, warum die Code Ersteller das nicht machen: Coverity kostet (ordentlich) Geld.

[ravage]

Danke für die Erklärungen. Gerade der Punkt Marketing macht natürlich sinn :)

[PatkIllA]

Coverity ist ein Tool der Firma und dieser Report ist Teil des Marketings dafuer. Und damit ist auch klar, warum die Code Ersteller das nicht machen: Coverity kostet (ordentlich) Geld.
Selbst die Tools die man hatwerden meist schon nicht eingesetzt.
Beim VS ist ja schon einiges dabei und trotzdem lassen das nur die wenigsten bei uns durchlaufen.
Zum einen fehlt die Zeit und ein nicht gerader kleiner Teil versteht schon die deutlich einfacheren Compilerwarungen teils nicht. Die lassen wir mittlerweile aber nicht mehr zu.

Und ich habe auch schon öfters die Sätze gehört, dass der Entwickler vor der Open Source Veröffentlichung den code noch mal aufrämen will oder nicht veröfftlichen willl, weil der Code so strubbelig ist.

[ShadowXX]

Ich kann mich vor Jahren erinnern, da galt eine annehmbare Codequalität von 1 Fehler auf tausend Zeilen Code. Entsprechende Meßgröße existiert wohl seit Urzeiten.
Dann kannst du die Zahlen bzw. die Messmethode aber auf den Misthaufen werfen....selbst nur ein Fehler pro 1000 Zeilen Code ist utopisch wenig.

Ich habe nun schon in verschiedenen Softwarefirmen gearbeit, darunter Softwarehäuse mit 2000++ Programmieren, Software die von 1000senden Menschen benutzt wird.....und ich gebe dir Brief und Siegel darauf das wir da eher von 2-5 Fehlern pro 100 Zeilen Code ausgehen können.

Davon abgesehen: wenn diese Software tatsächlich nur auf sowas wie Memleaks, Buffer Overflow & co. guckt, ist das sowieso nur ein Bruchteil der Wahrheit und die Zahlen endgültig nicht die Bytes wert die Sie an Speicher verbrauchen.

[Eco]

Vor allem schneidet OSS "deutlich" besser ab (hat sogar den "besseren" Code), weil sie 0,13 Fehler weniger pro 1000 Zeilen hat. :rolleyes:
Meiner Meinung nach ist der Test aus den bereits genannten Gründen für die Tonne.

[Avalox]

Dann kannst du die Zahlen bzw. die Messmethode aber auf den Misthaufen werfen....selbst nur ein Fehler pro 1000 Zeilen Code ist utopisch wenig.


Es ist immer die Frage, ob die Fehler durch die Metrik überhaupt erfasst werden. Wenn mich nicht alles täuscht, ist die Definition solcher Metriken sogar standardisiert.
Qualität ist damit messbar.
Dass es darüber hinaus noch Code nicht so funktioniert, wie er funktionieren sollte, ist ganz gewiss so, aber reduziert natürlich die Kernaussage nicht.

@Topic
Coverity Scan ist übrigens kostenlos für OpenSource Produkte, da dieses Produkt von der US Homeland Security unterstützt wurde.

[PatkIllA]

Dass es darüber hinaus noch Code nicht so funktioniert, wie er funktionieren sollte, ist ganz gewiss so, aber reduziert natürlich die Kernaussage nicht.
Meiner Erfahrung nach sind die Funktionsfehler aber deutlich häufiger.
Bei den statischen Analysen werden auch einige die gefunden, die im konkreten Fall keinerlei Auswirkungen haben. Das hat dann aber Potential bei Änderungen Probleme zu geben.

[Coda]

Es geht nur um Fehler gefunden durch SCA? Die Studie ist also noch sinnloser als ich beim bloßen lesen des Thread-Titels auf Anhieb gedacht habe :)

[Demirug]

Dann kannst du die Zahlen bzw. die Messmethode aber auf den Misthaufen werfen....selbst nur ein Fehler pro 1000 Zeilen Code ist utopisch wenig.

Ich habe nun schon in verschiedenen Softwarefirmen gearbeit, darunter Softwarehäuse mit 2000++ Programmieren, Software die von 1000senden Menschen benutzt wird.....und ich gebe dir Brief und Siegel darauf das wir da eher von 2-5 Fehlern pro 100 Zeilen Code ausgehen können.

Ich weiß nicht woher die Zahlen kommen vermute aber mal stark es ist die gleiche quelle mit der ich im Zusammenhang von ISO 9001 zu tun hatte. Dort wurde auch von 1 bis 3 Fehlern pro 1000 Zeilen Code gesprochen. Das entschiedene dabei war aber das es sich um "Bekannte Fehler im ausgelieferten Code" handelte.

[Laz-Y]

Solche Statistiken sind doch nur wichtig für Zertifizierungen und für 'Entscheidungsträger' die sich daraus schöne Diagramme basteln können und sagen überhaupt nichts aus.
Das ist genauso sinnlos wie die Statistik 'der Entwickler mit 1000 Codezeilen ist doppelt so produktiv wie der Entwickler mt 500 Codezeilen'.

[1668mib]

Wer versucht aus statistischen Analysen samt Metriken Aussagen über die Qualität von Quellcode zu machen, spricht sich den Sachverstand doch selbst ab.

Die Einhaltung von Regeln sagt wenig über Qualität oder fachliche Korrektheit aus. Siehe Sprache:
- Ich kann einen grammatikalisch korrekten Satz sagen, aber Marco Reus wird uns einfach in Brasilien fehlen.

Statistische Analyse sagt: passt!
Der Leser sagt: wie bitte? Das passt doch nicht.

Mag ja sein, dass über solche Analysen Codestellen gefunden sind, die nicht wirklich "gut" sind. Aber was sagen sie über fachliche Korrektheit aus? Der OpenSSL-Bug war vermutlich auch astrein was die statischen Analysen angeht...

Meiner Meinung nach: Guter Code sollte wartbar und ausdrucksstark sein und getestet (z.B. über Unit-Tests), um mal ein paar Dinge zu nennen. Selbst für Tests gibt es doch kaum eine vernünftige Metrik, Mag ja sein, dass mir Tools die Testabdeckung im Quellcode zeigen. Wenn ich aber darauf verzichte, ungültige Parameter zu erkennen und die Methode damit zu testen, dann habe ich halt dennoch eine tolle Line Coverage...

[exxo]

Mal davon abgesehen, das nicht die Anzahl an Fehlern interessant ist, sondern was für Fehler vorhanden sind.

Da so manches hochrelevantes OSS Projekt chronisch unterfinanziert ist, siehe OpenSSL oder OpenBSD, würde ich ich nicht blind daran glauben das der verfügbare Sourcecode automatisch zu mehr Sicherheit führt.

Anscheinend schauen sich doch eher wenige die Sourcen an und noch weniger verstehen dann bis ins kleinste Detail warum der Code mist ist. Siehe Heartbleed...

Der Vorteil von OSS ist nicht die höhere Sicherheit sondern das jeder den Code fixen kann und nicht darauf gehofft werden muss das der Vendor der applikation das Problem irgendwann einmal behebt.

[Terrarist]

Das größte Problem ist die Einstellung der Entwickler und Nutzer, ob open source oder closed source, programme die größer sind als 10k Zeilen Code kann kein Mensch mehr 100% verstehen. Objektorientiertheit verschlimmert das Ganze noch. Damit muss man leben und seine persönlichen Konsequenzen draus ziehen, z.B. seine Existenz nicht davon abhängig machen.

[Coda]

10k Code? Errwat? Natürlich versteht das noch jemand ;)

Bei 100k können wir anfangen zu reden.

[PHuV]

gleich wird phuv energisch widersprechen :-)

Warum? Kann doch stimmen. Nur ist die Frage, wie die Studie zu bewerten ist, wie einige hier schon hinterfragt hatten.