Anerkennung ist die hauptsächliche Währung in der Welt der freien Software. Was immer Leute über ihre Motive für die Beteiligung an einem Projekt sagen, ich kenne keine Entwickler die glücklich damit wären, ihre ganze Arbeit anonym zu verrichten, oder unter dem Namen von jemand anderem. Es gibt hierfür konkrete Gründe: Der Ruf innerhalb von einem Projekt diktiert ungefähr wievile Einfluss man hat, und die Beteiligung an einem Open Source Projekt kann auch einen indirekten Finanziellen Wert haben, weil manche Arbeitgeber bei einer Bewerbun mittlerweile danach ausschau halten. Es gibt auch vielleicht sogar noch stärkere immaterielle Gründe: Menschen wollen einfach geschätzt werden, und suchen instinktiv nach Zeichen, dass ihre Arbeit von anderen anerkannt wird. Das Versprechen von Anerkennung ist desshalb eines der besten Motivationen, die ein Projekt hat. Wenn kleine Beiträge anerkennung finden, kommen Leute zurück um mehr zu machen.
Einer der wichtigsten Funktionen von Software für die gemeinschaftliche Entwicklung (siehe Kapitel 3, Technische Infrastruktur) ist dass es genaue Protokolle darüber führt, wer was wann gemacht hat. Überall wo es möglich ist, sollten Sie bereits vorhandene Mechanismen benutzen um sicher zu stellen, dass diese Anerkennung genau verteilt wird, und seien Sie spezifisch, über die Natur des Beiträgs. Schreiben Sie nicht einfach "Danke an H. Mustermann <hmustermann@beispiel.de>" wenn Sie statt dessen "Danke an H. Mustermann<hmustermann@beispiel.de> für die Bug Meldung und die Anleitung zur Reproduktion" in einem Kommentar schreiben könnten.
Bei Subversion haben wir eine informelle aber stetige Richtlinie, denjenigen der den Bug gemeldet hat entweder in dem zugehörigen Ticket zu würdigen oder wenn nicht, in dem Commit Kommentar der Änderung die den Bug behebt. Eine kurze Stidie der Kommentar in der Subversion Repository ergibt, dass mit 14525 ungefähr 10% der Änderungen jemanden beim Namen und Email Adresse würdigt, üblicherweise die Person, welche den Bug gemeltet oder untersucht hat welcher durch die Änderung behoben wurde. Achten Sie darauf, dass diese Person eine andere ist als der Entwickler ist, derjenige welcher den Commit gemacht hat, dessen Name bereits automatisch vom Versionsverwaltungssystem erfasst wird. Von den parr in die 80 Voll- und Teil- Commit berechtigten die Subversion heute hat, wurden 55 in den commit Kommentaren (meistens mehrere male) vor sie selber Committer wurden, gewürdigt. Das beweist natürlich nicht, dass die Anerkennung ein Grund für die weitere Beteiligung war, baut aber zumindest eine Atmosphäre auf, in dem Leute darauf zählen können, dass ihre Beiträge gewürdigt werden.
Es ist wichtig zu unterscheiden, zwischen gewöhnliche Anerkennung und besondere Danksagungen. Wenn ein bestimmter Codeteil, oder irgend ein anderer Beitrag den jemand geleistet hat, diskutiert wird, ist es in ordnung ihre Arbeit zu würdigen. Wenn Sie zum Beispiel sagen "Die kürzlichen Änderungen von Daniel an dem Delta Code bedeuten, dass wir jetzt Funktion X implementieren können" hilft es Leute zu erkennen, um welche Änderungen es sich dreht, und es würdigt gleichzeitig die Arbeit von Daniel. Es dient andererseits keinen direkten praktischen Zweck, Daniel nur für seine Änderungen an dem Delta Code zu danken. Es fügt keine Informationen hinzu, da das Versionsverwaltungssystem und andere Mechanismen die Tatsache aufgezeichnet hat, wer die Änderungen gemacht hat. Jeden für alles zu danken, wäre ablenkend und würde letztendlich frei von Informationen, da Danksagungen in so weit effektiv sind, wie sehr sie aus den üblichen positiven Kommentaren herausragen, welche die ganze Zeit ablaufen. Das bedeutet natürlich nicht, dass Sie niemals Leuten danken sollten. Sorgen Sie einfach dafür, dass Sie es auf Arten tun, die nicht zu einer Inflation der Anerkennung führen. Diese Richtlinien zu folgen, wird helfen:
Je flüchtiger das Forum, desto freier sollten Sie Ihren Dank ausdrücken. Jemand zum Beispiel im Vorbeigehen, während einer Unterhaltung im IRC, für ihren Bugfix zu danken, ist in Ordnung, genau so wie eine beiläufige Erwähnung in einer Email die hauptsächlich anderen Themen gewidmet ist. Schreiben Sie aber keine Email alleine um jemanden zu Danken, es sei denn es ist für eine wirklich ausergewöhnliche Leistung. Sie sollten gleichermaßen, nicht die Webseiten des Projekts mit Ausdrücken von Dankbarkeit verunstalten. Wenn Sie erst einmal damit anfangen, wird es nie klar sein, wan oder wo man aufhören soll. Und schreiben Sie niemals Danksagungen in den Kommentaren des Codes; das würde nur von dem hauptsächlichen Sinn der Kommntare ablenken, nämlich zum besseren Verständniss des Codes.
Je weniger jemand mit dem Projekt zu tun hat, desto angemessener ist es sie für etwas zu danken, was sie gemacht hat. Das mag sich nicht eingängig anhören, passt aber mit der Einstellung zusammen, dass Sie Lob ausdrücken sollten, wenn jemand mehr beiträgt als Sie es gedacht hätten. Es würde desshalb eine geringere Erwartung an Personen ausdrücken, als sie selber an sich haben, wenn Sie sich ständig für regelmäßige Beiträge bedanken, die sie normerweise machen. Wenn überhaupt, wollen Sie das engegengesetzte Ergebnis erzielen!
Es gibt ab und zu Ausnahmen zu dieser Regel. Man kann jemanden dafür danken seine Rolle zu erfüllen, wenn diese Rolle von Zeit zu Zeit temporäre, intensive Anstrenungnen erfordert. Das kanonische Beispiel ist der Versionsverwalter welcher in einen hohen Gang wechselt, ungefähr um die Zeit der Veröffentlichung einer neuen Verion, ansonsen aber untätig ist (zumindest untätig als Versionsverwalter—er kann auch als Entwickler aktiv sein, aber das ist eine andere Angelegenheit).
Genau so wie Kritik und Anerkennung, sollte Dankbarkeit so spezifisch wie möglich sein. Danken Sie Leute nicht einfach dafür, dass sie Toll sind, selbst wenn das der Fall ist. Danken Sie sie für etwas, dass ausergewöhnlich war und es gibt zusätzliche Punkte, wenn Sie auch noch genau sagen warum was sie gemacht haben so toll war.
Im allgemeinen, gibt es immer eine Spannung dazwischen zu gewärleiten, dass die einzelnen Beiträge anerkannt werden, und sicher zu stellen, dass das Projekt eher eine gemeinsame Anstrenung ist als eine Ansammlung einzelner Prachten ist. Bleiben Sie einfach im Klaren über diese Spannung und versuchen Sie sich auf die Seite der Gruppe zu halten, und Sachen werden nicht ausarten.