あるFLOSSプロジェクトが失敗する運命にあるか判別する方法

以下の文章は、Red Hat による The Open Source Way の第12章 How to tell if a FLOSS project is doomed to FAIL の日本語訳である。

（本文は元々 Tom 'spot' Callaway によって書かれたものであり、CC BY SA 3.0 の条件下で利用されている。その「フリーソフトウェアやオープンソースソフトウェアのプロジェクトが失敗する運命にあるか（そうでなくても少なくとも成功が阻害されてるか）知る方法）」は元々以下の URL に公開されたものだ：）

http://spot.livejournal.com/308370.html

この文章は、最近 Chromium を調べたことに端を発するものだが、何年にもわたり広く観察してきた危険信号の一部に過ぎない。

サイズ

• ソースコードが 100MB をこえる [失敗度5ポイントプラス]
• ソースコードを圧縮しても 100MB をこえる [失敗度5ポイントプラス]

ソース管理

• ソース管理レポジトリが公開されていない（例：cvs, svn, bzr, git） [失敗度10ポイントプラス]
• ソース管理レポジトリは公開されているが：
  • それをウェブで閲覧できない [失敗度5ポイントプラス]
  • 新規ユーザにその利用法を指南する文書がない [失敗度5ポイントプラス]
  • このコードのために独自のソース管理ソフトウェアを書いている [失敗度30ポイントプラス]
  • 実は既存のソース管理ソフトウェアを使っていない [失敗度50ポイントプラス]

ソースのビルド

• ソースをビルドする方法を指南する文書がない [失敗度20ポイントプラス]
• ソースをビルドする方法を指南する文書があっても、それが機能していない [失敗度10ポイントプラス]
• ソースが手書きのシェルスクリプトで設定される [失敗度10ポイントプラス]
• ソースがテキストファイルの設定ファイルを編集して設定される [失敗度20ポイントプラス]
• ソースがヘッダファイルのコードを手で編集することで設定される [失敗度30ポイントプラス]
• ソースが設定できない [失敗度50ポイントプラス]
• ソースのビルドに GNU Make 以外のものを使う [失敗度10ポイントプラス]
• ソースのビルドにプロプライエタリなビルドツールを使わないといけない [失敗度10ポイントプラス]
• このコードのために独自のビルドツールを書いている [失敗度100ポイントプラス]

バンドリング

• 依存する他のコードプロジェクトが同梱されているだけ [失敗度20ポイントプラス]
• バンドルされてるコードをまずビルドしないとソースコードがビルドできない [失敗度10ポイントプラス]
• そうしたバンドルされてる他所のコードを修正している場合 [失敗度40ポイントプラス]

ライブラリ

• コードが静的ライブラリでのみビルドする [失敗度20ポイントプラス]
• コードは共有ライブラリでもビルドできるが、非公式バージョンのみである [失敗度20ポイントプラス]
• 現在あるシステムのライブラリを利用しようとしない [失敗度20ポイントプラス]

システムのインストール

• /opt や /usr/local 配下にインストールしようとする [失敗度10ポイントプラス]
• "make install" を持たない [失敗度20ポイントプラス]
• ソースディレクトリ外だとうまくいかない [失敗度30ポイントプラス]

コードの偏り

• Windows の改行コード（「DOS フォーマット」ファイル）を使用する [失敗度5ポイントプラス]
• 特定のコンパイラの機能に依存する [失敗度20ポイントプラス]
• 特定のコンパイラのバグに依存する [失敗度50ポイントプラス]
• Microsoft Visual なんとかに依存する [失敗度100ポイントプラス]

コミュニケーション

• プロジェクトがメーリングリストにリリースをアナウンスしない [失敗度5ポイントプラス]
• プロジェクトがメーリングリストを持たない [失敗度10ポイントプラス]
• プロジェクトがバグトラッカーを持たない [失敗度20ポイントプラス]
• プロジェクトがウェブサイトを持たない [失敗度50ポイントプラス]
• プロジェクトが Sourceforge ベイパーウェア（訳注：Sourceforge には登録しているが、実体がないに等しいという意味？） [失敗度100ポイントプラス]

リリース

• プロジェクトがちゃんとバージョン番号をつけて（メジャー、マイナー）リリースしない [失敗度10ポイントプラス]
• プロジェクトがバージョン番号をつけてリリースしない [失敗度20ポイントプラス]
• プロジェクトがリリースを行わない [失敗度50ポイントプラス]
• プロジェクトがウェブフォーラムへの投稿に添付する形でしかリリースを行わない [失敗度100ポイントプラス]
• リリースが .zip フォーマットのみ [失敗度5ポイントプラス]
• リリースが Mac OSX の .zip フォーマットのみ [失敗度10ポイントプラス]
• リリースが .rar フォーマットのみ [失敗度20ポイントプラス]
• リリースが .arj フォーマットのみ [失敗度50ポイントプラス]
• 自分が考案した圧縮方式フォーマットでしかリリースしない [失敗度100ポイントプラス]
• 展開したらトップレベルのディレクトリにバージョン番号が付く形（例：glibc-2.4.2/）でリリースしない [失敗度10ポイントプラス]
• 展開したらトップレベルのディレクトリができる形（例：glibc/）でリリースしない [失敗度25ポイントプラス]
• 展開したらアホなくらい深くディレクトリができる形（例：home/johndoe/glibc-svn/tarball/glibc/src/）でリリースする [失敗度50ポイントプラス]

歴史

• コードが別のプロジェクトからの分岐（fork）である [失敗度10ポイントプラス]
• 主要開発者がその親プロジェクトに関わってなかった [失敗度50ポイントプラス]
• オープンソース化されるまで、コードがプロプライエタリだった期間が：
  • 1〜2年 [失敗度10ポイントプラス]
  • 3〜5年 [失敗度20ポイントプラス]
  • 6〜10年 [失敗度30ポイントプラス]
  • 10年以上 [失敗度50ポイントプラス]

ライセンス

• ファイル毎にライセンスがない [失敗度10ポイントプラス]
• ライセンス固有の非互換性がある [失敗度20ポイントプラス]
• ライセンスの意図に関する警告がない [失敗度30ポイントプラス]
• コードにライセンス文書のコピーが入ってない [失敗度50ポイントプラス]
• ライセンスを持たない [失敗度100ポイントプラス]

ドキュメンテーション

• コードに ChangeLog がない [10ポイントプラス]
• コードにドキュメンテーションがない [20ポイントプラス]
• ウェブサイトにドキュメンテーションがない [30ポイントプラス]

失敗度測定

• 失敗度0ポイント：完璧です！ どう見ても成功しますよ！
• 失敗度5〜25ポイント：うまくやっているようですが、もっとよくできるでしょう。
• 失敗度30〜60ポイント：あなたのコードがダウンロードされるたび赤ちゃんが泣いてます
• 失敗度30〜60ポイント：あなたのコードがダウンロードされるたび猫が死んでます
• 失敗度95〜130ポイント：ブッブー。難破船がきたぞ！
• 失敗度135ポイント以上：あんまり失敗が多すぎるから、あなたのコードは中にリアリティーテレビ番組を飼ってるに違いありません。