「あっきぃてきとう日記」は移転しました

ひらめき諸事情により「あっきぃてきとう日記」は移転しました。

移転先は「http://hkzo.org/aktech/」となります。

2009年09月02日

オープンソースソフトウェアの育て方

最近 Twitter ばかりでブログポストが停滞気味のなおっちです。

オープンソースプロジェクトを立ち上げつつあるので、参考に以下のページを読み始めています。オライリーの本でありますが、無料で公開されているのでリンクしておきます。

オープンソースソフトウェアの育て方
フリーソフトウェアプロジェクトを成功させるコツ
目次

日本語版に寄せて
序文
この本を書いた理由は?
どんな人たちに読んでほしい?
情報源
謝辞
免責

1. 導入
歴史
独占的なソフトウェアとフリーソフトウェア
意識的な抵抗
無意識な抵抗
「フリー」と「オープンソース」の違い
現状
2. さあ始めましょう
手持ちのもので始めよう
名前の決定
明確な目標を掲げる
フリーであることを宣言する
機能一覧・要件一覧
開発の進捗状況
ダウンロード
バージョン管理システムやバグ追跡システムへのアクセス
連絡手段
開発者向けのガイドライン
ドキュメント
ドキュメントの公開方法
開発者向けドキュメント
使用例とスクリーンショット
公開場所
ライセンスの選択と適用
「何でもできる」ライセンス
GPL
ライセンスを適用する方法
うまく引っ張っていく
個人的な議論を避ける
炎上を阻止する
きちんとしたコードレビューの習慣
もともと非公開だったプロジェクトをオープンにするときには、
変化の大きさに気をつけよう
広報
3. 技術的な問題
プロジェクトに必要なもの
メーリングリスト
スパム対策
投稿のフィルタリング
アーカイブでのメールアドレスの処理
識別しやすいヘッダ
Reply-to はどうすべきか
私のふたつの夢
アーカイブ
ソフトウェア
バージョン管理
バージョン管理に関する用語集
バージョン管理システムの選択
バージョン管理システムの使用法
すべてをバージョン管理する
ウェブで閲覧できるようにする
コミットメール
ブランチの活用
情報の一元管理
承認
バグ追跡システム
議論の場としてメーリングリストを使う
バグ追跡システムをあらかじめフィルタする
IRC / リアルタイムに行なわれるチャットシステム
ボット
IRCの会話を保存する
RSS フィード
Wiki
ウェブサイト
ツールが一通り揃ったホスティングサイト
ホスティングサイトを選ぶ
匿名性とプロジェクト参加
4. プロジェクトの政治構造と社会構造
優しい独裁者
誰がよき「優しい独裁者」になれるか?
合意に基づく民主主義
バージョン管理を行なうと堅くならずに済む
合意に至らなければ投票する
いつ投票を行なうべきか?
誰が投票するのか?
世論調査 v.s 投票
拒否権
全てを記録しておく
5. カネに関する問題
プロジェクトへの関わり方
開発者を長期に渡って雇用する
企業の人間としてではなく、個人として振る舞う
動機を隠し立てしない
カネで愛は買えない
契約する
レビューを行い、変更をソースコードに取り入れる
ケーススタディ: CVS パスワード認証プロトコルの場合
プログラミング以外の活動を支援する
品質保証 (テストの専門家など)
法律上の助言、権利の保護
ドキュメントやユーザビリティの改善
ホスティングサイトや接続回線を提供する
マーケティング
見られていることを意識する
競合するオープンソースプロジェクトを攻撃しない
6. コミュニケーション
書いたことがすべて
構成や体裁
中身
口調
何が失礼にあたるのか

陥りがちな罠
目的のない投稿をしない
生産的なスレッドとそうでないスレッド
簡単な議題ほど長引く
宗教論争を回避する
"口やかましい少数派" について
扱いにくい人たち
扱いにくい人たちへの対応
実例
巨大化への対応
アーカイブを目に付きやすくする方法
全リソースをアーカイブと同様に扱う
しきたりの成文化
バグ追跡システムでは議論しない
宣伝・広報
セキュリティ脆弱性の告知
バグ報告を受ける
大至急それを修正する
CAN/CVE 番号
事前通知
修正を一般に公開する
7. パッケージの作成、リリース、日々の開発
リリースに番号を付ける
リリース番号の構成要素
単純なやり方
奇数/偶数 に意味を持たせるやり方
リリースブランチ
リリースブランチの使い方
リリースを安定させるプロセス
リリースオーナーによる独裁
リリースに含める変更を投票で決める
リリースを安定させるプロセスを管理する
リリースマネージャー
パッケージング
パッケージのフォーマット
パッケージ名とレイアウト
大文字にするか、小文字のままにするか
プレリリース版
コンパイルとインストール
バイナリパッケージ
テストとリリース
リリース候補
リリースを告知する
複数のリリースラインを管理する
セキュリティリリース
リリースと日々の開発
リリースの計画を立てる
8. ボランティアの管理
ボランティアを最大限に活用する
委任
作業依頼と担当者の決定を明確に区別する
委任したあとのフォロー
みんなの好みを知る
賞賛と批判
縄張り意識の回避
自動化の割合
自動テスト
すべてのユーザーの協力を得るために
技術的な作業だけでなく管理作業もみんなで
パッチマネージャー
翻訳マネージャー
ドキュメントマネージャー
バグマネージャー
FAQ マネージャー
引き継ぎ
コミッター
コミッターの選びかた
コミット権の剥奪
部分的なコミット権
休眠状態のコミッター
秘密主義を避ける
クレジット
プロジェクトの分裂
分裂の動きをうまく処理する
新しいプロジェクトを立ち上げる
9. ライセンス、著作権、特許
使用する用語
ライセンスの特徴
GPL とライセンスの互換性
ライセンスを選ぶ
MIT/X Window System ライセンス
GPL
GPL はフリーなライセンスなのか?
BSDライセンス はどうなの?
著作権の保有と譲渡
何も対処しない
貢献者ライセンス同意書(CLA)
著作権の譲渡
デュアルライセンスの仕組み
特許
さらなる情報源
A. フリーなバージョン管理システム
B. フリーなバグ追跡システム
C. なんで自転車置場の色まで気にしなきゃならないの?
D. バグ報告のやり方を説明した例
E. 訳者あとがき
F. 著作権表示
posted by かず at 22:36 | Comment(0) | TrackBack(0) | 日記

この記事へのコメント
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
この記事へのトラックバックURL
http://blog.sakura.ne.jp/tb/31814340
※言及リンクのないトラックバックは受信されません。

この記事へのトラックバック