オープンソースソフトウェアが抱える問題
ブログをWordPress 2.8.1 へバージョンアップしました。WordPress 2.8.1では、先月公開された WordPress 2.8が抱えていた自動アップグレードを行うとWordPressを含むサーバー上のファイルが削除されるという致命的なバグが解消されています。
WordPress 2.8 がベータテストを終えた正式版であったにも関わらず、非常に初歩的かつ致命的なバグを抱えていたことは大きな問題となっていますが、これはオープンソースソフトウェアが抱える根本的な問題とも言えます。
しかし、シェアの高いオープンソースソフトウェアが常に安定しているとは限りません。今回問題となったWordPressは、世界トップシェアを誇るオープンソースのブログシステムです。そのシステムのベータテストを終えた正式版で、非常に初歩的かつ致命的なバグが発生しました。
通常、ソフトウェア開発時のテストは、テスト計画を作成した上で、すべての機能が正しく動作するか一通り検証します。
この後、システム動作環境の違いによる問題や想定しない動作による問題を発見するために、ベータテスト期間を設けてユーザーにテストを委ねることがありますが、これはあくまで機能テストが終わった後の話です。
しかし、無償で配布するオープンソースソフトウェアでは、製品のようにバージョンアップの度に開発者が十分な機能テストを行うことは難しいという状況があります。
そのため、新規に組みこんだ機能の機能テストは開発者により行われるものの、既存機能の機能テストはベータテストに委ねられることも多いのです。
今回、WordPressで、自動アップグレードという一般ユーザーがアップグレード時に必ず実行する機能に致命的なバグが残っていましたが、開発者が既存機能に対するテストを行っていれば簡単に発見されていたと思います。
しかし、そのテストをユーザーに委ねた結果、正式版を配布するまでバグが発見されませんでした。あくまで推測ですが、以下のような理由が考えられます。
オープンソースのベータテストに参加する人の大半は、プログラムに精通したエンジニアです。彼らのほとんどは、初心者向けの機能である自動アップグレードを使わずに手動でアップグレードを行ったのではないかと思います。
ベータテストのユーザーは、テスト計画に基づいたテストを行っているわけではないので、手動でアップグレードを済ませてしまえば、自動アップグレードの検証は行わないでしょう。
また、自動アップグレードで不具合が発生したユーザーも、WordPressほどのシェアを持つオープンソースソフトウェアが初歩的かつ致命的なバグを残しているとは思えず、とりあえず手動アップグレードを試したところ正常に動作したため、バグ報告はしなかったという状況だったのではないでしょうか。
このような問題を避けるためには、オープンソースソフトウェアも製品と同様に、既存機能の機能テストも開発者が行うか、もしくはテストのための明確なガイドラインと情報共有の仕組みを構築した上で、それをユーザーに委ねる必要があります。それを行っているオープンソースソフトウェアもありますが、ほとんどのものでは行われていません。
また、企業で導入する場合には、もう一つ大きな問題があります。上記のように、オープンソースソフトウェアは、テストが十分に行われていないことも多く、製品とは違い動作の保証もありません。
オープンソースソフトウェアを導入して、正常に動作せずに残念でしたと諦められる程度の案件であれば構いませんが、そうでない場合は、シェアの高いものであったとしても自社での動作テストは欠かせません。動作テストを行うということは当然コストがかかるわけで、そのコストは競合製品の価格を上回ることも少なくありません。
また、バージョンアップにより仕様が変更され、独自に追加した機能が動作しなくなるケースもあります。この場合、バージョンアップをしなければいいのですが、同時にセキュリティ修正が行われている場合はそうも言えず、追加した機能の再開発が必要となります。これも思わぬコスト増に繋がります。
オープンソースソフトウェアの導入は、安易に決定できるものではありません。メリットとデメリットをよく精査した上で導入する必要があるのです。
WordPress 2.8 がベータテストを終えた正式版であったにも関わらず、非常に初歩的かつ致命的なバグを抱えていたことは大きな問題となっていますが、これはオープンソースソフトウェアが抱える根本的な問題とも言えます。
オープンソースソフトウェアが抱える問題
オープンソースソフトウェアに対して、無料で完成度が高く、特にシェアが高いほど安定性もセキュリティ性も高いというイメージを持たれている方が多く、安易にオープンソースソフトウェアを導入する企業も増えています。しかし、シェアの高いオープンソースソフトウェアが常に安定しているとは限りません。今回問題となったWordPressは、世界トップシェアを誇るオープンソースのブログシステムです。そのシステムのベータテストを終えた正式版で、非常に初歩的かつ致命的なバグが発生しました。
通常、ソフトウェア開発時のテストは、テスト計画を作成した上で、すべての機能が正しく動作するか一通り検証します。
この後、システム動作環境の違いによる問題や想定しない動作による問題を発見するために、ベータテスト期間を設けてユーザーにテストを委ねることがありますが、これはあくまで機能テストが終わった後の話です。
しかし、無償で配布するオープンソースソフトウェアでは、製品のようにバージョンアップの度に開発者が十分な機能テストを行うことは難しいという状況があります。
そのため、新規に組みこんだ機能の機能テストは開発者により行われるものの、既存機能の機能テストはベータテストに委ねられることも多いのです。
今回、WordPressで、自動アップグレードという一般ユーザーがアップグレード時に必ず実行する機能に致命的なバグが残っていましたが、開発者が既存機能に対するテストを行っていれば簡単に発見されていたと思います。
しかし、そのテストをユーザーに委ねた結果、正式版を配布するまでバグが発見されませんでした。あくまで推測ですが、以下のような理由が考えられます。
オープンソースのベータテストに参加する人の大半は、プログラムに精通したエンジニアです。彼らのほとんどは、初心者向けの機能である自動アップグレードを使わずに手動でアップグレードを行ったのではないかと思います。
ベータテストのユーザーは、テスト計画に基づいたテストを行っているわけではないので、手動でアップグレードを済ませてしまえば、自動アップグレードの検証は行わないでしょう。
また、自動アップグレードで不具合が発生したユーザーも、WordPressほどのシェアを持つオープンソースソフトウェアが初歩的かつ致命的なバグを残しているとは思えず、とりあえず手動アップグレードを試したところ正常に動作したため、バグ報告はしなかったという状況だったのではないでしょうか。
このような問題を避けるためには、オープンソースソフトウェアも製品と同様に、既存機能の機能テストも開発者が行うか、もしくはテストのための明確なガイドラインと情報共有の仕組みを構築した上で、それをユーザーに委ねる必要があります。それを行っているオープンソースソフトウェアもありますが、ほとんどのものでは行われていません。
また、企業で導入する場合には、もう一つ大きな問題があります。上記のように、オープンソースソフトウェアは、テストが十分に行われていないことも多く、製品とは違い動作の保証もありません。
オープンソースソフトウェアを導入して、正常に動作せずに残念でしたと諦められる程度の案件であれば構いませんが、そうでない場合は、シェアの高いものであったとしても自社での動作テストは欠かせません。動作テストを行うということは当然コストがかかるわけで、そのコストは競合製品の価格を上回ることも少なくありません。
また、バージョンアップにより仕様が変更され、独自に追加した機能が動作しなくなるケースもあります。この場合、バージョンアップをしなければいいのですが、同時にセキュリティ修正が行われている場合はそうも言えず、追加した機能の再開発が必要となります。これも思わぬコスト増に繋がります。
オープンソースソフトウェアの導入は、安易に決定できるものではありません。メリットとデメリットをよく精査した上で導入する必要があるのです。
