SourceForge活用のススメ
オープンソースでの活動
オープンソースでの活動について、自分でも考えをまとめたかったのでちょっとまとまった文書を記述しようと思う。
一応事前に言っておくが今回は長い。特に興味がなければ読まないことをお薦めする。
フリーウェアを作成して、ソースを公開したいと思っているのであれば、次の知識が必要になる。
- ライセンス形態について
- ソースの公開方法について
さらに、共同開発を行いたいのであれば、共同開発そのものについての知識も必要だろう。
共同開発そのものについての知識とは、大体以下のようなもの。
- 共同でのソースコード管理
- 共同でのドキュメント管理
- 共同でのバグ管理
- 共同でのタスク（担当箇所）管理
- 共同でのコミュニケーション方法
結構考えるべき事柄が多いのがわかると思う。
一つ一つ片付けていこう。
ライセンス形態について
ライセンス形態については以下二つを私のオススメとして掲示したい。
前者は改変していいし、好きに使っていいよというもの。無保証だから使用は自己責任でね、という事も明記されており、いわゆるユーザーと製作者という観点は存在せず、製作者から見てもお気軽なライセンス形態と言える。
※無保証といっても改変要求を出すのがユーザーなので、ライセンスを振りかざさずに覚悟しておいた方がいいが。
昔は初版を開発した人物の署名をつけることを条件としていたが、現在はこの条項は削除されている。条項を削除したものを「修正BSDライセンス」、残っているものを「BSDライセンス」というのが厳密な表記だが、現在「BSDライセンス」というと修正BSDライセンスを指すと思ってほぼ間違いない。
ちなみに派生物のソースコードを非公開にも出来る。
で、この修正BSDよりも自由なライセンスは「パブリックドメイン」というもので、私もこれは検討したのだが、SourceForgeの見解によると日本では「著作人格権」というものがあり、法律上パブリックドメインは難しいのだそうだ。
よくわからんから好きに使っていいよ、というなら、とりあえず修正BSDにしておく事をお薦めする。
著作人格権については専門家に任せよう。要約すると著作権の対象を個人に特化させたようなもので、作った人に自動的に付与される法律的な権利である。
余談だが企業に特許権を没収されて、かつ就業規則に著作人格権の扱いに明示がない場合、この権利を盾に交渉することが出来る。開発者であれあｂ知っておいて損のない権利である。
GPLは曲者のライセンスで、GPLで公開されたソフトウェアを元に改変した場合、ライセンスをGPLにしなければならないというもの（正確にはちょっと違うが、こう覚えておけば大筋間違いではない）。
詳細は長くなるのでWikiぺディアさん辺りを見てほしいのだが、要するに作成したものを永続的にフリーウェア（本項では改変自由で無料のソフトウェアと定義付けておく）化したいのであれば、このGPLを適用することをお薦めする。
私は企業に仕えている人間なので、商用利用の際制限が強いこのGPLは正直使いづらいのだが、個人であれば適用する価値はあるだろう。
ソースの公開方法について
一般的にはCVSというものを使用するのだが、ぶっちゃけCVSはクライアントソフトを用意するのが面倒なのでお薦めしない。
あえてUnix文化に反対すると、区切り区切りでソースコードをZIP辺りで固めて一括で公表し、それを基に作業分担するのがいいのではないかと思う。
共同でのソースコード管理
共同での開発は以下のフローをお薦めする。
これが面倒くさいからCVSが生まれたのだが、こと日本においてはCVSの環境整備をするより、これで運用して責任者が手間をかぶるのが速いと思われる。
担当箇所のソースコードがぶつかった場合や、バグを発見した場合は逐次後述のコミュニケーションで連絡を取り合うのがいいと思う。
ちなみに２ちゃんねる等の匿名掲示板においては「アップロード板」というのがよく使われる。この運用方法はメールでのやり取りよりお手軽なので、参考にしてもいいかもしれない。
共同でのドキュメント管理
ソースコード管理と似たようなもの。
責任者がどこかにまとめサイトを作って、一覧性の高い形でWeb公開するのがベストだと思う。リリースはソースと同じように、やはり責任者がやることをお薦めする。
CVSで運用する事や掲示板での運用も可能だが、一覧性が低い事からお薦めはしない。
共同でのバグ管理
理想はバグトラッキングシステムと呼べるものを使うのがいい。
それが難しい場合は掲示板で代替運用するといい。出来ればツリー型の掲示板で、バグ一つにつきスレッド一つ、バグ修復状況はそのスレッドに対するレスポンスとして記述というのがわかりやすいと思う。
共同でのタスク（担当箇所）管理
これはとても難しい。
オンライン上での開発は「自発的な参加」が原則となるため、勝手に担当者を決めることは現実的に難しいのである。
個人的には責任者側で全部やっておいて、「ここやってくれませんか」と個別に依頼するのがいいと思う。それも名指しで指名するのではなく、「開発者募集中」のように不特定多数に依頼を出すのがいい。とんでもないのが応募してくる可能性もあるが、可能性は可能性として考慮した上で積極的に動かないと、オンラインでの開発はそもそも成り立たない。
バグであればバグトラッキングシステムが担当者や状態の管理も内包しているので、デバッグのタスクはバグトラッキングシステムで、その他の新規開発はタスク管理システムを使ってもいいのだが、掲示板などで柔軟に対処する方が手っ取り早いだろう。
責任の所在を明確にする意味でもとても重要視されるものなのだが、現状どのプロジェクトもここの管理は苦労しているように見受けられる。
共同でのコミュニケーション方法
無難なのは掲示板＋メールである。
お互いの考えをまとめて伝えやすく、後日万人から参照しやすく客観的な意見も得やすいという意味では、閲覧が自由である掲示板オンリーにする、というのが実は一番いいのかもしれない。メールの方がやりやすい場合もあると思うので、ここはケースバイケースで。SourceForgeでは過去ログ参照と会員管理が容易なメーリングリストでの運用を推奨している。
荒れやすいのを覚悟すればチャットなどを使うのもいいが、リアルタイムのコミュニケーションはまとめるのが大変なのであまりお薦めしない。やるなら少人数でテーマを絞ってやるのがいい。実体験を踏まえて言うが（汗）、定例会議をチャットでやるのは最悪である。参加者が不特定になる上議論を各自持ってくる形になるので収集がつかなくなる。
SourceForgeのススメ
で、これらをまとめると、プロジェクトを運用する上で必須なものは以下に分類されることになる。
- ソースをアップロード/公開する場所
- ドキュメントをアップロード/公開する場所
- 掲示板
また、記述し損ねたが、当然これも必要になる。
- 制作したものを公開する場所
SourceForgeというところは、これを全て持っている。
制作したものを公開する場所や、ドキュメントを閲覧出来る場所は、ホームページのスペースを貸し出してくれるのでこれで全て解決できる。
ソースをアップロード/公開する場所に関しては、ZIP圧縮であればリリースという形でバージョンごとに出すことが出来るし、CVSも貸し出してくれる。
この他、メーリングリストやバグトラッキングシステムもあるので、コミュニケーションやバグ管理も円滑に進むことだろう。
最も厄介なタスク管理についても、バグトラッキングシステム、掲示板、メーリングリスト、タスク管理システムと豊富なアプローチが用意されている他、開発者の募集をSourceForgeコミュニティ全体に出すことも出来る。
慣れる為の準備は色々必要だし、元がUnix文化だからWindows文化圏の開発者にはとっつきにくい部分もあるのだが、用意されている機能を触りだけ使うだけでも強力なサポートになることは間違いないので、食わず嫌いをせずに是非多くの開発者にSourceForgeを使ってほしいと願う次第である。
ちなみに本家のSourceForge.netは掲示板に日本語が使えないなどの問題があるらしいので、背伸びをしないでSourceForge.jpを使った方がいいとは個人的には思う。
サクラエディタはSourceForge.netであえて公開していて、開発は日本語の別サイトで進めるというやり方をとっている模様。これはサクラエディタが世界に発信したいという野望を持っているからであり（推測。外していたら申し訳ない）、その野望を実現するにはjp側では力不足だと感じた場合に、SourceForge.netを選択肢として検討するのもいいだろう。
私もまだ慣れていない部分が多々あり、余計なリリースポイントを作成したりと訳のわからん運用をしているが、慣れてくればそれだけで一つの武器になる。
今後も有難く使わせていただく予定である。
