Debianでふりかえる Open Source Project あれこれ Debianにかかわって、もう3年半(*1)にもなろうとしている。 これをふりかえりつつ Open Source Project とはどういうものかを 私なりの考察をだらだらと書いてみようと思います。 ある程度は過去の情報を調べていますが、ほとんど記憶に基づいて書いているので 間違っている可能性もなきにしもあらずです:) ■Debian JP Projectのはじまり Debian JP Projectがはじまったきっかけは、今はなき linuxメイリング リストで、数名が「Debian でも日本語環境があるといいね」「その作業用 のメイリングリストとかあるといいなぁ」という話をしだした頃でした。 ちょうどその頃には、個人的にもDebianを使いはじめていたりしたので その話にのったわけです。当時 Debian を使いはじめた理由としては 確か、 * DebianはGNUもからんでいて将来有望 * 利用者が少ない とかいう理由だったような気がする。後者の理由についてもう少し説明してみると 利用者が少ないので、新しい発見があったりして楽しいかも:)とか思っていた ような気がする。当時他のディストリビューションとしては Slackware とか RedHatが出始めた頃だったわけだけれども、Slackwareはみんなが使ってる みたいでおもしろくなかったし、そもそも Slackware の構成がいまいちしっくり こなかったという気持ちもあったりした。RedHatはとりあえずよくわからなかった のであまり使おうと思っていなかったような気がする。まぁ そういうわけで Debianを使いはじめていたところに、メイリングリストが欲しいとかいう話が でたので作ってみたのだった。当時 riccia.linux.or.jp のアカウントは もっていた(*2)のでdebian-devel@linux.or.jp をやってみることに。 その頃、riccia.linux.or.jpは たしか Red Hat + αで、メイリングリスト サーバとしては CML がインストールされていたので、それを使ってみることに した。「作ってみましょう」といいつつ、CMLを使うのははじめてだったので 最初は試行錯誤で設定したわけだけど、とりあえず動かすことに成功。 debian-devel@linux.or.jp は 7人のメンバーでスタートすることになる。 ○ 最初は FAQな質問をしまくる 最初は、みんな Debian のことをよくわかっていなかったりしたので 今となっては FAQになっているような質問がばんばんとびかっていたり した。また dselect に関する不満は既にこの時から続出で、私も 「dselectは依存チェックが欝陶しい」などと発言している。しかも 最初のインストール時にしか既に使っていなかったらしい(笑) おそらく dpkg をそのまま使っていたのだろう。 ○ とりあえずできそうかことからどんどんやる 後はとりあえず JE にあるような日本語パッケージを作っていこう ということで動きだす。蓋をあけてみると既に やなぎはらさん、中原さんが かなりのパッケージを作成ずみで、これをどこに集めておくかねぇ という 話がでてくる。その話がでた時には riccia.linux.or.jp はまだディスクが 少なく、ちょっと置けないなぁ という話だったのだが、ちょうどいいタイミングで riccia.linux.or.jp のディスクが増設、その場所をdebian-jpで使うことにする(*3)。 debian-jp といいだしたのは私らしい[debian-devel:00038]のだが、なぜ debian-jp なのかは既に記憶にない(笑) この後、やなぎはらさんが Debian-JP Project Home Page を作りだし [debian-devel:00178] この名前が定着したらしいです。 ○ やりだした/つづけている理由? 最初は試行錯誤 & 手作業で upload されていたのを配置しなおしていたので いろいろ大変だった。特に riccia.linux.or.jp の回線がかなり細くトラフィックが 多い時などは非常に作業が困難だった。なんで大変なのにやっていたかというのが わかると Open Source Projectに参加する理由というのがわかるのだと思う。 しかしながら、ふりかえってみるとその理由というのはよくわからないもので、 まぁ きっと自分が作業した方がなにかと特だと思っていたのではないかなぁ。 ただ、当時はできるだけパッケージは作らないで、uploadされてきたパッケージの 配置およびメイリングリストの管理に専念しようとしていたふしがありますね。 ○ いかにやってくれそうな人をまきこむか? そうこうしているうちにメンバーも増えパッケージも増えてくるようになりました。 最初の頃は fj.os.linux とかでも、Debian使ってる人をみかけては ひきずりこむように勧誘したりしていたような気がする。Open Source Project をはじめる場合、最初のうちはこのように、興味をもっている人をひきずりこんだり 簡単な質問とかも積極的に出して FAQになるようなものを作りだしていくのが よいような気がします。あと誰/何がどう動いているかをこと細かく伝えていく ことも重要でしょう。とりあえず Project について理解している人を 増やしていくことで Project をリードしていく人そのものが新規メンバーを 教育していく負担を減らしていくことも大事な感じがします。作業のすすめ方に ついてドキュメント化することも重要でしょう。毎回毎回説明するのは大変なので 「これを読め」ですませるようにしていけばいろいろと負担が減ります。 ただ、これもそのうち風化していくみたいなので時々、リフレシュというか 再教育が必要になるものなのかもしれません。ある程度、Projectのすすめ方が 決まってきたら、作業報告メールはディスカッション用のメイリングリストとは 別にするか、ひかえた方が議論がスムースになると思います。 ○ 試行錯誤をおえたら自動化して省力化しないと また、最初のうちは手作業でいろいろな処理をして試行錯誤するのはいいことだと 思います。試行錯誤してみないことには、何をどう自動化すればいいのかが理解 できていないことがあるからです。しかしながら、そのうちルーチンワーク化して きたらスクリプトなどを書き自動化にむけて作業するべきでしょう。 そうしないと堕落できません(笑)。自動化できたら今までその作業にかけていた マンパワーを新しいことにかけることができるようになるわけです。 これがうまくできないと topics-ml のように途中で破綻してしまうことに なってしまいます(苦笑) まぁ そういう場合は、さっさと手放して 他にやりたい人がいるのならその人にやってもらうようにするのが いいでしょう。自分でやらないのに他にやりたい人がでてきても 「そのうちやるので、それを待て」とかいいつつ牽制するのはよくないでしょう。 「そのうちやるので」が事実だとしても、その間に他にやってくれる人がいるの ならその人にとりあえずやってもらって、後でその作業をマージするのが、 よい方法だと思うわけです。 また、きっちりドキュメント化して、他の(それなりにツールについて知っている) 人でも代わりができるような体制にしておくべきなのかもしれませんが、 自分の作業をふりかえってみると、自分が続けられそうな範囲ではあまり やってないですね、反省。 ○ ドキュメント化は重要 ドキュメント化というのは結構重要なファクターなのでしょう。Debianでも Debian Policy Manualをはじめ Packaging Manualやさまざまな細かなルールや guidelineなどがドキュメント化されています。ドキュメントの元になる情報は 最初はメイリングリストなどに流れているコメントとかなわけですが、メイリング リストに流れたままだとたとえアーカイブしていても後から参照するのは 簡単ではありません。検索エンジンをつかっても「これだ」というのを一発で 見つけるのは困難だったりするわけです。ドキュメント化しておくことで 後から見ても「これはこうすればいいのだ」ということがわかるわけです。 また、やり方がかわったらドキュメントもそれにあわせて更新していかないと 駄目です。古い間違ったドキュメントは利益よりも害が多いといえるでしょう。 ドキュメントはどんどん更新していく体制にしておくべきです。 ■ debian-usersの作成 そうこうしているうちに Debian もユーザが増え、developerじゃないような 人もでてくるようになりました。しかしパッケージの作成作業もどんどん すすんでいっているわけで、debian-devel@linux.or.jp というメイリングリスト では、なんとなく利用に関する質問がしずらいような雰囲気がただよいはじめます。 そんな中、数人が 「debian-users メイリングリストが欲しい」という発言が でてきたので「debian-users メイリングリスト」を作成することになります(*4)。 か今みると、この時にこんな発言をしていますね(笑) ================================================================ Subject: [debian-devel:00620] Re: debian JP user ML Date: Fri, 14 Feb 1997 12:21:51 +0900 From: Kikutani Makoto Subject: [debian-devel:00619] Re: debian JP user ML Date: Fri, 14 Feb 1997 12:14:51 +0900 (JST) > > そこで、debian-devel ML 設立当時話しが出ていたユーザーMLを > > 作ってもいいのではないかと思うのですが、みなさんどうでしょう？ > > さんせー。 ううむ、わたしゃ いまたちあがったばっかりの linux-users@linux.or.jp をのっとる というのがいいかも と思ってました(笑) # 何をインストールしたらいいでしょう といってる初心者に # Debianを洗脳していく とか(笑) > 本家のdebian-MLに一瞬入ってましたが、あまりの流量にすぐ抜けました。 > 日本にあるとありがたいです。 つくるのなら debian-users@linux.or.jp ですかねぇ 要望がたくさんありそうならつくります。 # ので「欲しい」って人は表明してね(^^) ================================================================ 蓋をあけてみると 既に -users なメイリングリストはかなり需要が あったらしく、どんどん subscribe する人が増えていきました。 ■Debian分裂の危機 当時はまだ Debian Projectのメンバーではなかったので詳細は不明ですが この頃、Debian内部でProject分裂の危機がおとずれたらしいです [debian-devel:00830] ================================================================ ここ最近、Debian Project でいろいろな口論があり(途中の経緯を 理解していませんが)、なんと、 プロジェクトの再組織化のため、１週間ほどプロジェクトを 停止する。 という発言や、 Debian Projectを民主的なリーダーシップのものと 古い独裁主義的なものと、二つのプロジェクトに 分かれるだろう。その際、どちらのプロジェクトが Debianと呼ばれるかは、Ian Murdockが決定すべきだ。 という発言が出ています。 ================================================================ 当時は Debian はまだ普通(?)の free software project で、 まだ「Open Source」という言葉も「Debian Constitution」なども 定まっていない頃です。普通の free software project を考えてみると、 そこでは softwareの作者というのが絶対権力をもっているわけです。 他人がなんといおうと softwareの作者が認めない限り、そのsoftwareに 反映されることはないわけです。その点 Debian の場合、Debian Project 自体が software の作者というのとはちょっと違います。 Debian はディストリビューションですから、他の作者が作ったものを 単によせあつめて、うまくインテグレーションしているにすぎないとも 言えます。もちろん Debianで開発されている software もいくつかあり それらが Debian の core part になっているわけですが、それが 全てではないわけです。そのようなこともあり Debian の運営という ものは他の free software project とはかなり違うものだと言えるの かもしれません。 結局 Debianは分裂することなく、民主的なリーダシップのもと 運営がすすめられていくことになります。 ■Debian Social Contract および Debian Free Software Guideline Bruce Perens のリーダシップのもとに、策定されたもので 最も重要なのが Debian Social Contract であり、後に Open Source Definition のベースとなった Debian Free Software Guideline でしょう。 Debian Social Contract は、Debian Project がどういうことをする 活動グループなのかをうたいあげたものです。 http://www.jp.debian.org/social_contract これにより、Debian は ・フリーソフトウェアであること/ありつづけること ・フリーソフトウェア全体をよくしていくこと ・フリーソフトウェアでないものはDebianではないが ユーザの便宜を考えてサポートはすること をのべています。Debianの開発者は今後、これを指針として行動していく ようになりました。 Debian Free Software Guildeline は 巷にあふれているさまざまな 自称フリーソフトウェアの中で Debian はどれを実際にフリーソフトウェアと して扱うかの基準を説明しています。これに従うと、従来の感覚では フリーソフトウェアだと思っていたものが Debian ではフリーではない 扱いをうける場合があります。特にありがちなのが ・改変の自由が明示的にあたえられていない ・商業利用/営利目的の利用/配布禁止 あたりでひっかかっているソフトウェアです。あと Unix系ではほとんど ありませんが、Windows系などではバイナリ配布しかしていないようなものでも フリーソフトウェアなどといっている世界もあるようです。 さて、この Debian Free Software Guideline ですが、よく考えると これは Debianを守るためのガイドライン という見方もできます。 このガイドラインに沿っているものならば、Debian のようなディストリ ビューションを作成、配布、利用するのに障壁とはならないからです。 このあたりのライセンスのややこしい話をさけるために、Debian Free Software Guideline があるのかもしれません。だいたいにおいて Debian Free Software Guideline にひっかかるようなライセンスの場合、 Debian的パッケージング、およびその成果を自由に配布・利用するときに なにかしらひっかかってくるような感じです。 Debian Free Software Guideline は単に「Debian にとってのフリー ソフトウェアとは何か」を決めたものだったのですが、Bruce Perens の 精力的な活動により、これは Open Source movement の重要な役割を果して いくことになります。結局、この「Debian が考えているフリーソフトウェア」 に「Open Source」という名前がつけられ、世に広まっていくことになるのです。 そういった意味では Debian Project は Open Source 発祥の Project で あると言えるのかもしれません。 ただ、世の中には GPL原理主義者や GPLには自由がないというBSDな人も いっぱいいたりして、ライセンスがらみの話題はつきませんね。 ■ Debian Bug Tracking System Debian JP も人が増えてきて、それにつれてパッケージも増加していくに つれ、そのバグへの対処が問題になりはじめてくるようになりました。 当初は人手で作業していたわけですが、やはりよほど気合いと根気の ある人でないと、そんな作業は続けていくことはできないわけです。 Debian の方では、かなり昔から Bug Tracking System が使われていました。(*5) *BSD方面では GNATS というシステムが PR (Problem Report)の処理システムと して以前から使われていましたが、Linuxディストリビューションで Bug Tracking System がまともに使われだしていたのは Debian が最初 なんじゃないんでしょうか? (*6) 従来的な方法ではバグレポートもプロジェクトに関する議論もあらゆる メイリングリスト(もしくはニュースグループ)でおこなうのが一般的 でしたが、Bug Tracking System によりそのやりかたがかなりかわってきた ような気がします。Bug Tracking System を使えば ・それぞれのバグに ID をつけ、後でその ID で参照できる ・それぞれのバグが現在どう扱われているか ・バグの重要性やバグをもっているパッケージ/メンテナ による分類 などができるようになるわけです。うまく使えば、それぞれの バグごとに小さなMLのような感じで使うことができます。 バグがレポートされクローズされるまでの間だけ、それに興味の ある人がやりとりできる小さなMLとして働くわけです。 また、内容は自動的に Web にのるので、誰でも参照できるように なっています。このようにアーカイブされているおかげで、 後になって どれを処理して、どれが未処理かが Web を見るだけで わかるような状態になっているため、メンテしている人にとっては 非常に便利です。ただ、あまりバグをためすぎるとどれがどれだか わからなくなってしまうので注意が必要です。20を越えると全てを 追跡するのが、かなりつらくなるかんじです。またバグが報告された 時にできるだけすみやかに反応しないと、どんどんバグは溜まって くるので危険です:) 逆にユーザの観点から言うと気付いた時に バグレポートはした方がいいでしょう。ただし既に同じバグレポートが されていないかどうかはチェックしてあげた方がメンテナにとっては 親切です。新たにバグをオープンするのではなく追加情報を なげておくのもいいでしょう。もちろんそのバグをなおす方法を 報告してあげるのがベストであることはいうまでもありません(^^; 後、古いバグで単にcloseしわすれで既に直ってるという場合も 報告してあげるとよろこばれるでしょう。Bug Tracking System を経由することで、Debian のメンテナにならなくても Debian を作りあげていく一員になることができるわけです。むしろある意味、 そうやって Bug Tracking System に bug report や patch を なげているだけの方が気楽なのかもしれません。なまじメンテナ になってしまうと大量のバグレポートをうけとって大変な目に あったりするかもしれないわけですし… :) ■ CVS の利用 *BSDでは全面的に利用されている CVS (Concurrent Versions System; 今 Open Source Project で最もよく使われているバージョン管理システム) ですが、Debian においても CVS は一部ではありますが採用されています。 現在 CVS を使って複数が管理しているものとしては * boot-floppies * www.debian.org * apt * dpkg * lintian * debian-policy * snapshot * ftp maintaince tool などがあります。特に Project において mission critical な 部分は CVS を使って複数による管理体制にしておかないと もし、その部分を管理している人が(本業が忙しいなどの理由で)作業 できない状況になってしまった場合、Project の活動が止まって しまうことになってしまいます。そのような作業は CVSが使えるのなら CVS を使うのが今のところ最も便利であると言えるでしょう。 CVS を使えば network ごしに複数の人間による version 管理を おこなうことができるからです。そういう意味においても既に CVSは Open Source Projectにおいては基本ユーティリティの一つで あると言えるでしょう。今時 CVS の使い方が全くわからないようでは 駄目なような気もします。もちろん CVS も奥が深いわけなので その全貌を理解する必要はありません。しかし commit, checkout, diff, update あたりは使えないと困ります。 ■ とりあえずまとめ なんとなくまとめに入ってしまいますが(^^; Open Source Project をすすめていく上で大事だと思うのは * 最初は 人を集める ある程度の集団にならないとやはり駄目でしょう 興味をもっていそうな人がいたらどんどんひきずりこんでいくことが 最初は、やることでしょう。この段階で はじめての人が疑問に思い そうなことを一杯だしておくのも有効でしょう。FAQ listをつくって しまえば、後から参加してきた人にとっても有用です。 * 動きだしてしまった人が主導権を握れる Open Source な community においては実際に活動している人が 一番の権力を握ることになります。他の肩書なんかこの世界では 通用しません:) 最初は他の活動をしていた人からいろいろあるかも しれませんが、ずっと続けていればそのうち主導権は握れるように なるものです。 * 続ける or ゆずる というわけで、単発的な作業も重要ですが、やはり続けていくのが重要 または自動化してしまってほっておいても動くようにしてしまうのもよいですね。 ただし、続けられない時は明示的に管理を放棄した方が、他の人がその管理を ひきつぎやすいのでよいでしょう。そうでなければその Project は闇に 消えていくことになります。また不活発な時期があるとその間に community の人たちは去っていってしまうことになりがちですので、活発に活動してくれる 人がいるのなら、動けない間だけでもその人たちにまかせてしまう方がいい でしょう。 * やり方/指針の浸透させる いくらたくさんの人があつまっても、毎度細々とした指示をしなければ いけないようでは人をあつめた意味がありません。 あつまってくれた人が自主的に動いていけるようにするための行動指針を ひろめるのが重要でしょう。ドキュメント化ですね。 * 複数が同時作業できるツールを使いこなす Bug Tracking System とか cvs とかですな。 こういうツールが使いこなせないと、多人数での作業をスムースに やるのが困難になります。 * feedback はできるかぎりうけとめる まぁムッとするようなこと書いてくる人もいますが ほとんどの場合、有用であることがあるんでまぁ無視しないように したほうがいいですね。 * 楽しむ(笑) やっぱり楽しいと思うことじゃないと長続きしません。 負担に思うようなら、がんばる必要はないでしょう。 つらい と思ったら、やや距離を置いてみるのもいいのかも。 また、どんな作業においても「楽しみ」を見いだすのがポイントですね。 というわけで Open Source Projectにも限らないような話のような気がしつつ、 なんとなく終わるわけです。 つづくのか? --- *1 debian-develメイリングリストを作成したのが 1996年8月29日。 *2 当時 classless な 逆引きがまだ広まっていない頃で、 なんか provider の NSとかいろいろ調べて、「こう設定すればいいんじゃ?」 とか ogochan とメールとtalkでいろいろやった記憶。 その頃は irc は使っていなかったな。 *3 ちなみに当時 debianフルセットが 800Mだったらしい。 *4 debian-usersメイリングリストを作成したのが 1997年2月19日 [debian-devel:00636] *5 いつこれが使われだしたのか記憶にない。かなり初期の頃からあったはず。 気付いたら既にあったという感じ *6 単に他を知らなかっただけかも(^^;