2007年のOSS

「最初は後ろ向きでした。」 ~OSS開発参加のきっかけとこれから

現場のニーズからNamazu for Win32に出会う

大学時代にソフトウェア開発のアルバイトをさせてもらっていたのですが、会社のファイルサーバの容量が日に日に増えて、自分の読みたい社内文書を見つけるのがだんだん難しくなってきていました。

そこで全文検索エンジンを導入してみようという話になり、当時Webで実績の多かったNamazu図1を使ってみることにしました。フリーソフトウェアで導入に特別なお金もかからないし、ソースコードも無償で公開されていたので、途中で何か不具合があっても自分で何とか対処できるだろうという根拠のない自信と安心感があったのが、Namazuを選んだ理由です。

文書ファイルのインデクサの部分はPerlで「早く」作って開発スピードを上げ、検索用のnamazu.cgiはCで「速く」作って性能を上げるといった合理的な開発ポリシーも個人的に気に入っていました。しかし実際に運用してみると、Windows環境ではまだ動作がこなれていなくて、Office文書のフィルタやWindows上の日本語ファイル名の扱いについて一部問題があることがわかりました。そこでNamazu本体のプログラムを修正して対処しました。

図1 Namazuオリジナル開発者の高林さんの書いたイラスト
図1 Namazuオリジナル開発者の高林さんの書いたイラスト

GPLに対する誤った認識がOSS開発参加へのきっかけに

このとき自分で作ったパッチを開発コミュニティに還元したほうが良いのかなぁと思って、Namazuの開発者向けメーリングリストにパッチを投げていました。

正直に告白しますと、当時私はGPLv2のライセンスの中身を完全には理解できていませんでした。些細なGPLのライセンス違反でも、一度見つかるとコミュニティが騒いでなんか怖いなぁというイメージがあったので、とりあえず修正パッチを公開していれば怒られないで済むだろうという、後ろ向きの理由でプログラムの差分を公開していました。

そうこうしてNamazu開発者の方々とコミュニケーションをとっているうちに、Namazu for Win32のメンテナをやってみないかというお誘いがあり、気付くといつの間にかコミッタになっていました。

これが私がOSS開発に参加することになったきっかけです。実に後ろ向きです(笑⁠⁠。

OSSとバッドノウハウ

今思い返すと、NamazuはOSS開発の学習には最適な教材だったと思います。商用UNIXやLinux、FreeBSD、WindowsなどのいろんなOS上で動作させるために、GNU Autotools化が徹底されていて、CVSで複数人とソースコードの共有が行われていました。

日本語と英語のメーリングリストがあり、日本語形態素解析器との連携や、gettextを使ったi18nのコードなどもあり、ソフトウェアの国際化を強く意識するきっかけにもなりました。

プログラムの行数もそんなに長くなくて、全部のソースコードに目を通すことができたことも大きかったと思います。実体は環境依存と後付けばかりで、 本当にバッドノウハウだらけでしたけど(笑⁠⁠。現在は寺西さんと臼田さんがNamazuのメンテナとして活躍されています。

JavaScriptは現代のオープンソース?

現在、筆者が参加している技術コミュニティの1つとして、Shibuya.jsがあります。

最近ITビジネスの現場でも、AjaxやWeb 2.0といったキーワードが使われるようになり、Webブラウザ上で動作する「JavaScript」が優れた技術として再評価されてきました。JavaScriptのソースコードはそのままWebブラウザ上で実行されますので、コードを隠すことが難しく、半強制オープンソースのような状態になっています。

ここ数年でJavaScriptを駆使したWebサービスが続々と公開されるとともに、PrototypeMochiKitなどのライブラリも登場し、JavaScriptを使ったプログラミングの敷居が一気に下がりました。

今は多様性が認められている時代ですが、サーバサイドでPerlやPHP/Ruby/Python/Javaなどのプログラミング言語を使っても、Webアプリを開発するエンジニアがこの先、生きのこるためには、JavaScriptを使ったプログラミングも必要になってきています。

サーバサイドでもJavaScriptを!

そこで、どうせならサーバサイドでもJavaScriptを使ったWebアプリの開発ができればもっと楽しくなるのではないか、ということで、現在AJAJA(あやや)という処理系図2を、オープンソースで開発しています。

ピュアな環境へ急に移行することは難しいので、過去の資産、レガシーを継承できるようにしておくことも重要です。 AJAJAプロジェクトでは、西田さんがSpiderMonkeyを拡張する形でIISのASPライクな記法を使えるようにし、樋口さんのPMConnectで、JavaScriptから既存のPerlのCPANモジュールを動的に呼び出すことができるようになっています。

図2 サーバサイドJavaScript処理系AJAJA
図2 サーバサイドJavaScript処理系AJAJA

2007年の展望

今後は、JavaScriptやPerl、PHP、Python、RubyなどのLL(Lightweight Language)のスクリプト言語処理系を複数組み合わせて、問題を解決するパターンが増えてくるのではないかと思っています。 自分は、特定の言語技術にこだわらない幅広い視点を持っていきたいと思います。

おすすめ記事

記事・ニュース一覧