最近 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. 著作権表示
コメント