tabateeの日記： implicit tasks

下記のリストはオープンソースのソフトを作ってた時の経験を内輪で議論した時の資料で、資料としてはウケが良かったのでメモ的に公開しときます。(作るソフトの内容やユーザ層によっては意味のない項目も含んでいます)
自分としては、アマチュアとしてソフトウェアの開発を楽しみたい人が(ソフトの種類や開発者の気分によって異なりますが)どういう所を活動の場とすると良いのかに興味を持って議論していました。ありそうな選択肢としては、(1)sourceforge等にあるようなOSSとして、(2)vector.co.jp等、(3)コミケ等のイベント、(4)ウェブアプリ等、が思い浮かびます。

• ソフトウェアの名前は十分に考えてつける
• 一貫性のあるバージョン番号付けをする
• 定まったリリースプロセスを持つ
• 気まぐれに開発を終わらない
• READMEやCOPYINGといったファイル名の慣習に従う
• 公開リポジトリを持つこと
• 各commitは論理的に一つの変更であること
• 各commitには説明的なlogがあること
• セキュリティ問題が発生した時には標準的なプロセスに従って迅速に対応する
• API/ABIはむやみに変更しない
• API/ABIを変更するときは前もって移行プランをアナウンスをする
• API/ABIの変更時には適切なバージョン付けをする
• リリース時には変更点の説明を付ける
• 同じ名前でリリースしたものをさしかえない
• 開発に参加する人向けの公開MLを作る
• エンドユーザが参加できる公開MLを作る
• MLで誰も返事しない質問には返事する
• バグの対応方針をすぐに言う
• 隣接レイヤーの開発者に負担をかけていないか確認する
• ディストリビューションの担当者とのコミュニケーションを取る
• 評判を適宜検索し、報告されていない問題がないか確認する
• 一般的なスペックの環境でそれなりに動くようにする
• メジャーでないOSでも動くようにする
• メジャーでないCPUでも動くようにする
• メジャーでない環境で動かせるようにする変更を受け付ける
• リソースの消費は同等機能を持つ商用ソフトの数倍以内が望ましい
• マイナーなライブラリ等への依存を避ける
• パッケージのどのファイルにもライセンスを記載する
• ソフトウェアを作るのに使うデータ、ツールもオープンソースで入手可能なものを選ぶ

(適当に過不足があるので真に受けないでください。アマチュアの場合は全部やるのは無理っぽいので、どれを省くかの選択も重要になってくるかと思います)

あのぉ…

[Anonymous Coward]

• ソフトウェアの名前は十分に考えてつける
• 気まぐれに開発を終わらない

これはtabateeが挙げたの?

どれを省くかの選択

の結果、上に挙げたものが省かれたのがanthyということでしょうか。 とはいえ、anthyには大変お世話になっております。ありがとうございました。 # SKKもいいかな、と思い始めているのでAC