Community-Reviews

Letzte Woche haben wir mal wieder ein Stück Software zusammengeschraubt. Ist nichts ungewöhnliches, wenn man Softwareentwickler ist, schätze ich mal. Dieses Stück aber schon ein bisschen. Es soll als Grundlage dienen für weitere Projekte, die darauf aufsetzen werden. Natürlich will man die Architektur und die Schnittstellen in so einem Fall besonders gut konzipieren. Über das Entstandene lässt man dann Kollegen drüber schauen und bewerten. Meist findet man dann noch ein paar kleine Schwachstellen, aber im großen und ganzen ist es gut so.

Wenn ich ehrlich bin, dann reicht mir das nicht immer. Je mehr Leute einen Blick drauf werfen, desto besser wird es. Das Problem beim internen Review ist vielleicht auch, dass alle mit einer sehr ähnlichen Sichtweise auf die Lösung schauen. Da es eine Neuentwicklung ist, kann es sein, dass es für alle Neuland ist. Warum lässt man also nicht mal die PHP-Community drüberschauen. Einfach mal die Architektur aufzeichnen, ins Internet stellen und bewerten lassen.

Jetzt werden viele sagen: „das geht doch nicht, sowas muss geheim bleiben!“. Aber warum? Ich arbeite für einen großen Verlag (hab ich das eigentlich schon mal erwähnt?) unsere Kernkompetenz sind Inhalte. Qualitätsjournalismus sozusagen. Unsere Technologien sind keine Hexenwerke und unsere wichtigste Einnahmequelle schon mal gar nicht. Und ich denke, so wird es vielen gehen. Würde es uns irgendwie schlechter dastehen lassen, wenn die „Konkurrenz“ vom Spiegel zum Beispiel die gleiche Schnittstelle zu ihrem CMS hat? Nöööööö.

Warum gehen wir immer so geheimnisvoll mit unseren Technologien um? Betreiben wird wirklich Raketenwissenschaften? Ein schönes Gegenbeispiel ist wohl Facebook. Aus deren Softwareschmiede kommen immer wieder neue Tools an die Öffentlichkeit und ich denke mal, sie profitieren davon.

Naja vielleicht bohren wir ja mal phphatesme so auf, dass wir eine Art Architektur-Review-Plattform draufsetzen. Dann könne jeder hier ein wenig Feedback einholen. Aber erstmal klären wir, wie ihr das seht? Würdet ihr eure Architektur öffentlich machen, wenn ihr die Entscheider wärt?

13 Comments

Es kommt drauf an, was das Script für Aufgaben erfüllt. Wenn dieses Script das Potenzial dazu hat, mehrere tausende Euros zu verdienen, würde ich es nicht veröffentlichen. Sollte es ein kleines Projekt sein, wo der kommerzielle Gedanke im Hintergrund ist, würde ich natürlich den Sourcecode veröffentlichen. Ich betreibe selber mehrere Projekte, wo der Sourcecode öffentlich zur Verfügung steht.

Man sollte sich eher den Gedanken machen, bietet das Script einen wirklichen Mehrwert und besteht die Möglichkeit damit Geld zu verdienen. Wenn das Script eine kleine Spielerei ist, dann ist wahrscheinlich mehr Geld damit verdient es kostenlos anzubieten. Da man durch kostenlose Scripte auch sehr viel PR Wirkung erzielen kann.

Also ich persönlich finde die Idee hervorragend, auch wenn der Vergleich hinkt, aber die Architektur von Linux ist ja auch offen. Aber wozu? Ich meine Linux ist ein OS, der einsatzzweck ist klar, bei der erwähnten Schnittstelle vom CMS nicht so ganz, außer es geht sich nur darum, möglichst viel Feedback zu erhalten.

Find ich ne tolle Idee! Solange man den Code danach nicht verkauft, sehe ich nur Vorteile, wenn man ihn veröffentlicht.

Na, und wo ist nun das Stückchen Code, das wir reviewen sollen? 🙂

Die Idee ist gut. Aber 2-3 Sorgen hätte ich dabei:
Zum einen bringt es meines Erachtens weniger wenn man nur die Architektur aufzeigt und bewerten lässt, es müsste schon der ganze Quelltext sein. Beim Reviewen sollte man ja auch bewerten können, ob der Architektur sinnvoll realisiert wurde. Also sollte man Quelltext und Doku veröffentlichen können.
Zum andren die Qualität der Reviews die nur aus Mühe und Gründlichkeit resultieren kann. Eine komplett-Review ganzer Module/Projekte/Libraries dauert und kostet Mühen. Fraglich ob jmd Zeit und Lust hat, das nebenbei oder in der Freizeit zu erledigen.
Nicht falsch verstehen, es wird sich Feedback finden, aber eher nach und nach und immer ein bisschen und kaum umfassendes Feedback.
Der Effekt würde glaube ich dem fast gleich kommen, es unter GPL zu veröffentlichen. Nach und nach kommt auch dann was aber der Umfang des Feedbacks und die Qualität läßt sich nicht vorhersagen.
Zu guter Letzt stellt sich die Frage nach der Kompetenz des Reviewers. Wenn man unterqualifiziertes Feedback aussortieren muss so könnte wie bei einem GPL Projekt einfach Aufwand anfallen die Spreu vom Weizen zu trennen und das könnte die ganze Sache unrentabel machen.
Eine andre Idee wäre, sich Partner zu suchen mit denen man Review-Arbeitsstunden austauscht und von deren Qualifikation mach sich überzeugen kann. So erhält man auch ein unvoreingenommenes Feedback aus der Sicht eines außenstehenden, hat aber mehr Steuerungsmöglichkeiten.

An sich finde ich die Idee nicht schlecht. Aber man muss auch die Kehrseite der Medaille sehen:

Viele Köche verderben den Brei. Man bekommt auf einmal 1000 Meinungen. Man kann viele Dinge eben nicht nur auf eine Art machen, sondern auf verschiedene Wege. Je mehr Leute drüber schauen um so mehr persönliches Befinden kommt da auch rein. Ebenso muss man beachten, dass nicht alle die drüber schauen auch auf einem Senior-Level sind. Man bekommt so also auch ggf. viele „sinnlose“ Hinweise.

Was mir noch so einfällt wäre, dass man damit auch Schwachstellen offen aufzeigt. Wenn es (nehme wir mal an) eine Schwachstelle gibt, jemand findet sie aber meldet sie nicht. So könnte er sie dann ggf. ausnutzen. Sicherheit by Obscurity ist sicher der schlechteste Ansatz, aber das ist eben ein Gedanke, den man auch mal durchspielen muss… 😉

Ich glaube, wenn man gleich den ganzen Source-Code rausgibt, dann hat man viel mehr Probleme mit den Schwachstellen. Die Architektur sollte nicht so leicht mit potentiellen Angriffsmöglichkeiten assoziiert werden.

@Nico: Ich arbeite nicht an einem konkreten Projekt, bei uns ist es nur wichtig, dass die Inhalten möglichst schnell ausgeliefert werden können. Ob nun mit Java im Backend oder PHP ist für den Gewinn ganz egal. Wir machen einfach nur Webseiten. Ok, wir haben 20 Mio. Seitenabrufe am Tag, aber das kann man auch über die Anzahl der Server skalieren.

Naja ich finde den Gedankenansatz recht gut, es ist nur die Frage welcher Code Online gestellt wird. Einen ähnlichen Gedanken Ansatz habe ich ja bei meinem Projekt. Dort habe ich die Script Testberichte eingeführt, dort kann man verschiedene Scripte testen und bewerten. Natürlich verstehe ich auch deinen Ansatz, wenn man für Eclipse eine schöne Java Erweiterung schreiben würde, könnte man dies ähnlich wie bei den SVN commit umsetzen. Dann könnte man gewisse Codesegmente online stellen, die dann einzelne User bewerten oder entsprechende Kommentare schreiben.

Bloß was hat jemand davon, bei einem solchen Projekt mitzuwirken?
Genauso ist es bei mir mit dem Script Testberichten, ich Suche krampfhaft nach einer Lösung, dass jemand sich daran beteiligt. Was für Anreize könnte man zur Verfügung stellen, dass sich jemand daran beteiligt? Bei meinem Projekt geht es darum, fertige Versionen zu testen und entsprechend eine Bewertung zu verfassen. Es sind bereits bei mir in der Datenbank über achtzig Bewertungen geschrieben wurden, bloß dies ist noch Recht wenig.

Hier mal die URL: http://www.php-space.info/scripte/testberichte.php zu meiner Testberichte Sektion.

Also irgendwie kann ich die Kommentare nicht ganz nachvollziehen. Wer spricht den hier von der Bewertung von konkretem Code? So wie ich das verstanden habe, geht es nur um die Schnittstellen und Architekturen. Schnittstellen könnte man einfach die Interfaces posten, die dann implementiert werden und bei Architekturen bietet sich UML viel mehr an… Da ist kien konkreter Code.

Naja manchmal sollte man den Beitrag zweimal lesen, ich hatte heute Morgen den Beitrag nach dem ich aufgestanden bin gelesen. Beim zweiten Kommentar hatte ich einfach eine Antwort geschrieben. Da sieht man mal, dass man vielleicht das ein oder andere zweimal lesen sollte. Ich hatte heute Morgen irgendwie in meiner Morgenmuffligkeit ein wenig unaufmerksam gelesen. Wenn ich da durch ein wenig Verwirrung geschafft habe möchte ich mich vielmals bei allen entschuldigen.

Wenn man nur die Architektur und die Schnittstellen veröffentlichen möchte, dann ist dies sicherlich nicht unbedingt ein Problem. Man sollte es halt mit den obersten Leuten absprechen. 🙂

Codereview ist Arbeit, ich gehe zumindest nicht davon aus das ihr das zu Hause in eurer Freizeit macht. Stellt sich die Frage wer für euch eure Arbeit macht, am besten noch für Umme?

Es wurde ja schon mehrfach hier angesprochen: Die Qualität des Reviews dürfte nicht zu hoch angesetzt sein. Diejenigen die eine qualitativ hochwertige Review machen können, sehen es als Arbeit an. Und Arbeit muss bezahlt sein. So lange es sich um Open Source handelt, dürfte sich noch der eine oder andere finden der den Review aus Enthusiasmus macht. Aber wenn ein Unternehmen Freiwillige sucht die ihre Arbeit für Lau erledigen, dürfte der Andrang eher gering ausfallen. Ansonsten könntest du auch gleich die Architektur ins Netz stellen und fragen ob die Community nicht den passenden Code dazu schreiben könnte.

Ich denke es hakt nicht so sehr an der Geheimniskrämerei, sondern eher daran das man niemanden findet der die Arbeit machen will. Für ein Unternehmen will nun einmal kaum jemand umsonst arbeiten.

@Ralf: Ja du hast Recht. Code Reviews, wenn sie gut sind, sind Arbeit. Für mich ist es aber eine Arbeit die Spaß macht. Ich schaue mir gerne mal Lösungen von anderen Projekten an und kann dabei auch dies und das für mich mitnehmen.
Wenn ich zusätzlich noch weiß, dass wenn ich ein Problem habe, mir die anderen auch helfen, dann sieht das doch ganz anders aus. Ich denke nicht, dass es nur ein Erfolg sein kann, wenn man Open-Source-Projekte bespricht.

Ist so ein wenig wie Karma, tue gutes und dir wird gutes widerfahren.

Vernachlässigt mal die Monetarisierung des Skripts, sondern legt mal ein Augenmerk auf die Anfälligkeit bei Angriffen. Ein offenes Skript kann von jedem Angreifer bis ins kleinste Detail zerpflückt und analysiert werden. So findet er garantiert eine Schwachstelle um ins System einzudringen.