よく、ソースの公開されたソフトウェアの利点として、多くの利用者からのフィードバックが期待出来て、バグフィックスが効果的に進むという点が挙げられる。これは Squeak に関しても成り立つだろうか？
Linux 等のプロジェクトでこれが成り立つのは、利用者が開発者であるという特徴があるからだと言われる。利用者がバグ報告を行い、場合によっては自らパッチを投稿する事によって利用者と開発者双方の利益になる。Squeak で、特に etoys の部分のバグフィックスがなかなか進まないのは開発者が etoys を使わないからだろう。実際に、Squeak でも開発環境の部分ではバグで困った経験はあまり無い。
Nihongo7 をリリースする際。リリース日に近くなるとバグ報告の数が減り、内容も細かい物が多くなったという印象がある。少なくとも昨日書いたような致命的な問題は無いと思ってリリースした。やはり使わない部分のテストを行うというのは限られたリソースでは難しい。
もう一つの問題は、バグと言う物が単体ではなく、複数の機能の組み合わせで起こるという事だ。機能を追加すればするほどバグの組み合わせは増える。
複合的なバグを抑えるには、初心者の為にあえて機能限定版の Squeak を使うという事が考えられる。今回関西大学のワークショップで使った Squeak は、初心者モードを搭載し、ある程度は役に立ったと思う。入門編は初心者モードだけで間に合った。ここで失敗した点は、デフォルトを中級者モードにした事だ。これは「初心者モードにした」事を印象付けるためにワークショップの最初でモード変更の動作をわざと行うという配慮のつもりだったが、そもそもこのモードが必要な学生はモードを変更する事自体に混乱してしまうのだった。
しかし逆に、バグを減らすためにはあえて実験的なバージョンを現場に投入するという事も行わなくてはいけない。これが難しいのが、Squeak のようなソフトウェアの場合、全てのワークショップが「本番」であって、練習ではありえないという事。商用ソフトウェアのようにバグ要員に給料を払ったりはしない(そういえば、前の会社ではバグ要員に奇遇にも関大の優秀な学生を使っていた)。バグに当たって Squeak が嫌いになる学生が居たらいやだなあと正直思うし、そんな事言ってたらバグが減らないというジレンマ。
複雑だ。
