Reciprocal help for security

JP/CERT は、 X2/XCL のあるモジュールのセキュリティホールを指し示した。我々の課題は、コミュニティがいかにそのようなセキュリティホールを扱うかである。

全ての開発者がセキュリティホールのミスを避けることは、不可能である。開発者がセキュリティホールに何も感じないことは、悪い傾向だ。しかし、開発者がミスや開発を恐れることは、同じく悪い傾向だと言える。誰かが開発者を支えなければ、有志の開発者は、フリーウェア開発から去るかもしれない。

JP/CERT は、セキュリティホールを指摘すると同時に、修正方法も開発者に送る。従って、我々は、 JP/CERT が指摘するモジュールのセキュリティホールの取り扱いに関してはあまり心配しなくて構わない。我々の考える課題は、コミュニティではそれと同じことができない点である。

私は、可能な範囲内で、コミュニティがソースコードをチェックし、パッチを送るべきではないかと考える。XOOPS Cube は、開発者がお互いにサポートする"フリーウェアのよき風習"の復活を必要とする。それのために我々が乗り越えなければならない２つの問題がある。

1) 罵倒
セキュリティホールを作ってしまった開発者は、傷ついている。そのため、しばしば攻撃的になり、修正パッチを送ってくれた支持者に悪態をついたり、逆ギレすることがあった。これは、コミュニティが開発者の相互扶助を失った原因のうちの１つである。パッチを送ろうとする人は、強い心を持っていなければならない。そして、他の開発者は、アドバイスを送る人を（いろいろ耐えられるように）助けるべきだろう。

2) 義務
開発者がお互いに支え合うことは素晴らしいことだ。しかし、 XOOPS Cube は市民のプロジェクトなので、そのような支え合いもまた有志である。残念なことに、コミュニティはしばしば開発者の善意の相互扶助を、組織上の義務や制度に変えようと試みる。このことは、パッチを送る能力を持つ開発者たちを"ぐったり"させる原因のひとつとなった。開発者の精神的負担を軽減するためにも、プロジェクトはさらに「これは有志のプロジェクトだ」という「フィーリング」を一層プッシュするべきだろう。そしてもしコミュニティがこのフィーリングをポピュラーなものに押し上げてくれれば、それは大きい。


フリーソフトウェア活動は、楽しめるものでなければ、活動を続けることは難しい。セキュリティホール、上記のような罵倒、及び、義務は、苦痛でしかない。苦痛は、開発者にソフトウェア開発を中断する道を選択させるだろう。コミュニティは、しばしば大きく、そしてシステマティックな組織になることを望む。しかし、コミュニティは、そもそもフリーソフトウェア活動とは一体なんであるかをよく考える必要があるだろう。XOOPS Cube は、それをアナーキーと定義している。私は、我々がセキュリティホールのための相互扶助を復活させることができると思う。なぜなら、 XOOPS Cube は、アナーキーであるからだ。ここには少なくとも義務はない。

アナーキズムは秩序の強制こそ否定するが、自発的な秩序を否定するものではない。