クレジット^[35] は、 フリーソフトウェアの世界における通貨のようなものです。 プロジェクトに参加する動機が何であれ、 匿名や他人の名前で仕事をして喜んでいる開発者を私は知りません。 これには明確な理由があります。 プロジェクトで尊敬されているかどうかは、そこで行使できる影響力をも左右します。 そして、オープンソースプロジェクトに参加していることを履歴書で評価する経営者もいるので、 そのことが直接ではないにしろ開発者の市場価値に反映されるかもしれないからです。 もっと明確で、説得力のある理由がもう一つあります。人は他人から評価されたいですし、 無意識のうちに他人が自分の仕事をわかってくれる証を求めるからです。 よって、クレジットはプロジェクトに対するもっとも強い動機付けのひとつになります。 小さな貢献をプロジェクトが認めてくれると、 認められた人はもっと大きな貢献をするために戻ってくるのです。

共同で開発するソフトウェア(3章技術的な問題 を参照してください) が持つ重要な特徴のひとつとして、誰がいつ、 何をしたかを正確に記録していることがあげられます。 可能ならいつも、この記録をクレジットを適切に記す目的に使うようにしましょう。 そして、行った貢献の種類を明確にしておきましょう。 "ありがとう、J. Random <jrandom@example.com>" のような書き方はせず、 "バグ報告と再現手順を教えてくれた J. Random <jrandom@example.com>、 ありがとう" と記すようにします。

Subversion プロジェクトでは、記録されているバグ報告や、 記録がなくてもコミットログに残っている報告者にクレジットを与えるやり方について、 非公式ですが一貫したポリシーがあります。 リビジョン 14525 までの Subversion のコミットログをざっと調査したところ、 10%のコミットに対して名前と電子メールアドレスを記録するクレジットを与えていました。 クレジットを与えられたのは、バグを報告したり、 そのコミットで修正されたバグを分析したりした人であるのが普通です。 クレジットを貰う人たちは、実際にコミットを行った開発者とは違いますし、 開発者の名前はいつも自動的にバージョン管理システムに記録されていることに注意してください。 Subversion プロジェクトでは、80数人のコミッターのうち55人が、 自身がコミッターになる前に(通常は複数回)コミットログでクレジットを貰っていました。 クレジットを貰うことが、 継続して開発に参加してくれることを保証してくれるわけではもちろんありません。 しかし少なくとも、 プロジェクトが貢献を認めることを期待できる雰囲気を作り出すことはできます。

貢献に対してお礼をいうことと、特別なお礼は区別することが重要です。 特定のコードや、コード以外の貢献を議論するときは、それらの仕事に対して 感謝の意を示すとよいでしょう。たとえば、"我々が機能Xを実装できるのは、 ダニエルさんが最近してくれたデルタコードに対する修正のおかげだ" というと、 彼の仕事のどの修正について話しているかが同時にわかるようになります。 一方で、ダニエルに単にお礼を言う電子メールを出すだけでは、実際すぐに役に立ちません。 単に電子メールでお礼を言うだけでは、情報がなにもわかりません。 なぜなら、バージョン管理システムなどの仕組みが、 変更を行った事実を既に記録しているからです。 何に対してもお礼を述べてしまうと、人々の興味が分散してしまい、 最終的には価値がなくなってしまいます。なぜなら、 お礼は普段している前向きなコメントより目立つほど効果が大きいものだからです。 もちろん、これはお礼を述べていけないということではありません。 与えるクレジットが多すぎて洪水を起こさないようにしましょう。 以下に示す基準が役に立つでしょう。

「プロジェクトが個別の貢献を認めること」と、 「個別の貢献を賞賛して積み重ねず、集団全体で努力すること」はいつも対立するのが普通です。 この対立関係を理解し、集団の中で試行錯誤するようにすれば、 収拾がつかなくなることはないでしょう。