新しい観点から見たオープンソース

オープンソース・ソフトウェアは、もはやコンピューター専門家だけのものではありません

例えば、コスト削減の必要に迫られているとします。けれども、あなたは管理者ではなく、ソフトウェア開発者またはコンピューターに詳しいユーザーであるか、あるいは単に、自分の給与に見合った最終収益を維持しなければならない立場にいます。このような状況は、オープンソース・ソフトウェアのソリューションを導入するにはまさにぴったりです。オープンソース・ソフトウェアのソリューションを導入するとなると、これから 3 週間はプログラミングの方法や makefile の作成方法を覚えるために費やすことになると思うかもしれませんが、そうはなりません。この記事を読んで、作業環境に効率性をもたらすには、オープンソースがいかに柔軟で、いかに有効な手段となるかを理解してください。

Brett McLaughlin, Author and Editor, O'Reilly & Associates

Photo of Brett McLaughlinBrett McLaughlin は、今日のエンタープライズ・プログラミングにおける第一人者の一人です。Nextel Communications および Allegiance Telecom, Inc. でエンタープライズ・ソリューションの設計、構築、実装に携わり、Lutris Enhydra のオープンソース版J2EE アプリケーション・サーバーの開発にも協力しました。XML、Java、データ・バインディング、そしてエンタープライズ・アプリケーションに関する本を執筆した他、エンタープライズ・プログラミングを話題にこれまで 50 以上の記事を書いています。さらに、現在使用できるオープンソース J2EE アプリケーション・サーバー (JBoss、Enhydra、および OpenEJB) にもコミュニティー・メンバーとしても貢献しています。Apache Turbine プロジェクトである Java および XML 対応の JDOM API の発起人の一人である彼は、他の多数のオープンソース・プロジェクトにも関わっています。現在彼は、世界屈指の技術出版社、O'Reilly & Associates でライター兼エディターとして活躍しています。



2010年 4月 20日

2010年のオープンソース

最初に断っておきますが、この記事はオープンソース連合の尊大な声明文ではありません。どちらかと言えば、オープンソース連合によるまさにその類の多くの声明文によって生まれた神話を一掃することを意図しています。皆さんがこれから考え始めなければならないことがあるとしたら、それは、オープンソースはオール・オア・ナッシングの選択ではなくなったということです。別の言葉に置き換えると、私はこの記事で皆さんに Windows® を放棄して GNU Linux® をインストールするべきだと主張するつもりもなければ、Adobe を非難したり、Apple に対する憎悪をあらわにしたりするようけしかけるつもりもありません。

この記事の意図はそれよりも遥かに謙虚なもので、一部の問題はオープンソース・ソフトウェアによって解決できること、そして皆さんが抱える問題には大抵の場合、オープンソース・ソフトウェアで解決できる問題があることを確信させることです。例えば、Internet Explorer® を使っていて問題がある場合や、適切なコードの統合開発環境 (IDE) を探している場合、あるいは PhotoShop への支払いにうんざりしている場合、そして単にほぼリアルタイムのサポート・システムが欲しいだけの場合でも、まさにオープンソースがうってつけのソフトウェア・スタックとなる可能性があります。

ハイブリッド方式はほぼ間違いなく最善の手法です

例えば、あなたがオープンソースに関心がないとします。それは単にそのような価値観を持っているからなのですが、だからと言って、オープンソースを使った方法の良さがわからないのだろうと言っているわけではありません。あなたは、今直面しているソフトウェア問題を解決するための実際的な代替手段を検討している、と言っているだけです。このような場合は、「完全オープンソース」の候補にはならないと思います。おそらく一部のソフトウェア (さらには所有しているソフトウェアの大多数) に「クローズド・ソース」のソフトウェアが使用されることになるでしょう。クローズド・ソースとは、市販のソフトウェアや、ソース・コードにはアクセスできないソフトウェアのことですが、オープンソース・ソフトウェアとオープンソースではないソフトウェアを混在させたとしても、それはそれで構いません。それが適切な形態であることを示す証拠は何もないからです。

実のところ、オープンソースと非オープンソースを混在させるというハイブリッド方式は最善の選択肢です。この手法では、例えば Windows を使用していて Internet Explorer にイライラさせられているといったような、現在使用している環境での問題が 1 つや 2 つ見つかった場合、Firefox に切り替えます。これはオープンソースのハイブリッド方式ということになります (知らなかったかもしれませんが、Firefox はまさにオープンソース・ソフトウェアをベースとしています)。Windows のような市販のソフトウェアに、Firefox のようなオープンソース・ソフトウェアを組み合わせることによって、どちらか一方の世界にだけに囚われることなく、両方の世界の長所を生かすというわけです。

オープンソース・ソフトウェアと非オープンソース・ソフトウェアとの釣り合いは完全に自由に決められるので、Firefox 以外のオープンソース・ソフトウェアは一切使用しないことにしても構いません。その一方、Sterling Ball 氏が提言する Ernie Ball 社の手法に傾くという可能性もあります (「参考文献」に記載した CNET の Ernie Ball 社に関する記事へのリンクを参照)。Ernie Ball 社ではほぼ一貫してオープンソース・ソフトウェアを使用しています。いずれの方針を取るにしても、あるいはその中間の立場を取るにしても、何が必要なのかを基にして決断できるという利点があります。

オープンソースは開発者だけのものではありません

10 年近くオープンソース・プロジェクトに取り組んできた開発者として、私は多くのオープンソース・コミュニティーがこれまで閉ざされた世界であり、お高くとまったコミュニティーであったことを十分承知しています。例えば、ユーザー・リストに関して別の誰かが 8 ヶ月前に質問したことを繰り返すと、「アーカイブを読めばわかるはずだ」と、新入りは冷ややかにあしらわれます。機能要求を提出すれば、「文句を言うのは止めて、さっさと自分で何とかしろ。それが、オープンソースだ。」と一喝されることさえあります。これらのコミュニティーは、恐ろしく傲慢で開発者中心のオープンソース手法を取っています。

ありがたいことに、このような気風を持つプロジェクトの多くは消滅したか、あるいは劇的な変化を遂げています。少しでも良識のある開発者たちがこのような態度に抵抗してきたか、そうでなければプロジェクトを去っていったからです。2010年の現在、大部分のオープンソース・プロジェクトでは、協力的な開発者たちが大勢のユーザーからなるユーザー・リストを管理しているだけでなく、Facebook、Twitter、LinkedIn などが追加の通信チャネルとして統合されています。また、オープンソース・プロジェクトにはバグ追跡システムがあるのが当然となり、攻撃されることを恐れずに機能を要求したり、バグを報告したりすることができます。実際、優れたプロジェクトはこのような報告を喜んで受け入れることによって、改善を進めています。

一例として、XML プロセッサー/トランスフォーマーの Xalan-J には、問題の対処方法を詳しく説明しているページがあります (図 1 を参照)。

図 1. 問題を報告する方法について詳しく、わかりやすく説明している Xalan-J のページ
Web ページからバグを簡単に報告できることを示すスクリーン・ショット

このページでは手順を説明しているだけでなく、サポートを求めるためのユーザー・リストも明記されています。ページではバグの修正を試みるよう推奨していますが、注目すべき点は、Xerces-J は本来かなり下位レベルのコードのプロジェクトであるにも関わらず、JIRA を使用してバグを報告する手順が記載されていることです。JIRA は、あらゆる機能を完備したバグ・レポート API です (図 2 を参照)。つまり、バグ・レポートの作成や機能要求を行う場合、異様なテキストだけの UI と複雑な手順に従うのではなく、ユーザーが簡単に従うことができるように作成されたドキュメントに基づいて行えるようになっているということです。

図 2. JIRA の堅牢なバグ・レポート機能。ユーザーに対して完全に公開され、アクセスできるようになっています
JIRA で未解決および修正済みのバグを報告する方法を示すスクリーン・ショット

コミュニティーは価値ある存在です

上記で説明したようなやりとりは最終的に、コミュニティーと呼べる形に発展します。サポートを求めるリクエストを送信した後、またはバグ・レポートを送信した後に、再びユーザー・リストに身を潜めることも可能ですが、通常そのようにはしません。ソフトウェア・プロジェクトのメーリング・リストに登録したユーザーのほとんどは、そのままメーリング・リストを利用し続け、同じ問題領域に取り組んでいたり、別の領域で同じような問題に直面していたりする他のユーザーを見つけるものです。

単純で理想的にさえ聞こえるかもしれませんが、コミュニティーは、メーリング・リストとサポート・サイトのなかから形成されていきます。メーリング・リストやサポート・サイトを介して、会ったこともない人々からソフトウェアの問題に関連するアドバイスを受けたり、あるいは見知らぬ相手にアドバイスを提供したりすることができます。前述の Ernie Ball 社についての記事に話を戻すと、Sterling Ball 氏のオープンソースでの経験は、彼のビジネスを改善しただけではありません。この経験で、彼は同じような状況にいる他の人々に、まさに現実の問題に自分たちがどのように対処し、その問題をどのように克服したかを知ってもらいたいと考えるようになりました。その結果、今では他の数多くの企業が Sterling 氏と Ernie Ball 社のソリューションをさまざまな形で適用しようとしています。

オープンソース・ソフトウェアは、こうした類の共同イニシアチブを生み出すきっかけとなるようです。こうしたイニシアチブが生み出される理由が、公開メーリング・リストを使用しているためであろうが、オープンな環境のなかではソフトウェアがすぐに進化するためであろうが、いずれにしても対話は発展するようです。確かに、たとえ営利目的の会社であっても、対話そのものに真剣に反対する人はいないように思われますが、オープンソース・ソフトウェアの場合には、ユーザー同士の対話はなおさらのこと、対話がさらに対話を発展させるようです。これが、オープンソースならではの利点なのです。


オープンソース・ソフトウェアはオープンです

私は本のタイトルや記事のセクション・タイトルをはじめ、何にしても気の利いたタイトルは付けないようにしていますが、このセクションはこうせざるを得ません。オープンソースの「オープン」は重複しているわけでも、重要でないわけでもないからです。例えば、管理職と企業の利害を前にしているとしたら、この記事の最初のセクションの意味を詳しく説明しないわけにはいきません。

けれどもこれは IBM® developerWorks の記事なので、ここでは別の前提を設定します。それは、読者が少なくとも考え方の上では開発者であるという前提です。自分の思い通りのコードを作成できるようになるまでには至らないとしても、開発者のように考えることは賢明なことです。また正直なところ、開発者の観点から考えてこそ、オープンソースは一層輝きを増してきます。ハイブリッド方式とコミュニティーについて理解できたところで、皆さんの関心はより技術的な側面に向いていることでしょう。オープンソースは、技術的な懸念のほとんどに極めて有効に対処します。

自己文書化は時代遅れなことが多いですが、それでも役に立ちます

最初に悪い知らせから言うと、開発者はコードのドキュメントを作成することが苦手なことで有名です。つまり、Sourceforge.net で Xalan-J や Firefox、あるいはお気に入りのプロジェクトを調べるとしても、実際に役立つドキュメントが必ず見つかるわけではありません (これらのプロジェクトへのリンクはすべて、「参考文献」セクションに記載しています)。initParser() という名前のメソッドに、「パーサーを初期化する」といったまるで役に立たないコメントが付けられているという話もちらほら耳にします。これではほとんど参考になりません。

けれどもプロジェクトとそのコード・ベースが成熟するにつれ、文書も改善されていく傾向があります。JDOM プロジェクトを例にとると、このプロジェクトは誕生してから数年が経ちます (「参考文献」を参照)。JDOM は、SAX や DOM よりもユーザー・フレンドリーな構文解析用のオープンソース API です。実際、NASA や Sun Microsystems (現在は Oracle) に至るまで、多くの人たちが JDOM を使用しています。JDOM がよく使用されている理由の 1 つは、API が十分にドキュメント化されていることです。例えばリスト 1 に記載するコードは、Element インターフェースに含まれるたった 1 つのメソッドを説明するためだけのものです。

リスト 1. JSON 内部文書の例
/** * This protected constructor is provided in order to support an Element * subclass that wants full control over variable initialization. It * intentionally leaves all instance variables null, allowing a lightweight * subclass implementation. The subclass is responsible for ensuring all the * get and set methods on Element behave as documented. * <p> * When implementing an Element subclass which doesn't require full control * over variable initialization, be aware that simply calling super() (or * letting the compiler add the implicit super() call) will not initialize * the instance variables which will cause many of the methods to throw a * NullPointerException. Therefore, the constructor for these subclasses * should call one of the public constructors so variable initialization is * handled automatically. */
protected Element() { }

開発者にとって、これは大いに参考になります。このように説明されていれば混乱することがなくなり、このクラスをずっと簡単に使用できるようになります。当然、Java™ 言語を含むほとんどの言語では、この類のコード・レベルのドキュメントをさらに使いやすい形に変換することが可能です。図 3 に、上記のコードのドキュメントから直接生成されたElement インターフェースの JavaDoc を示します。

図 3. コード・レベルの文書をわかりやすく表示する JavaDoc
コードのコメントから自動的に生成されたドキュメント

大きなコミュニティーには、それだけ多くのサポート・スタッフがいます

コード・レベルのドキュメントの作成を具体的に考えてみてください。まず開発者が何らかのドキュメントを作成します。その後、プロジェクトの他の人々がそのコードに手を加え、自分たちでコードのドキュメントを改良するか、あるいはその文書を作成した開発者に改良させます。これで、ドキュメントは改善されます。

次に、ユーザーがそのコードについて調べます。一部のユーザーは問題を見つけて報告します。なかには問題の修正に貢献するユーザーもいるはずです。これで、ドキュメントはさらに充実します。

ユーザー基盤が大きくなるにつれ、別の事態も発生します。ユーザーのなかに、極めて詳細を重視する A 型行動様式のユーザーが出てくるという事態です (私はその 1 人なので、これは確実に言えることです)。これらのユーザーはコード・ベースの詳細を探り、ドキュメントを改善していきます。A 型行動様式の人間はそうすることが性分なので、改善せずにはいられません。そのようなユーザーはコードの機能を変更することがないとしても、少なくともコードのドキュメントは改善していくことになります。

このプロセス全体をとおして、ユーザー・コミュニティーはサポート・コミュニティーへと成長していきます。そして大きくなっていく関係者のグループによって回答が提示されます。これらの関係者の多くは報酬を受けることもなければ、元のソース・コード・ベースと関わっていることさえありません。その一例として、Eclipse プロジェクトの新参者向けフォーラムにアクセスしてください (「参考文献」を参照)。これが、オープンソースの開発環境です。さまざまな投稿をスクロールして見ていくと、いかに多くの投稿に、Eclipse.org のメール・アドレスを持たない人々が回答 (しかも完全な内容で回答) しているかに驚くはずです。これらの回答は、IBM のスタッフがこっそり送っているものではありません。このことから、オープンソース・コミュニティーが短時間のうちにサポート・コミュニティーの役割を果たすようになることがわかります。しかもこれは営利目的のソフトウェアではないはずです。

本当に直接 Microsoft にメールを送れますか?

お察しのとおり、これはちょっとした嫌味ですが、この問題は現実のものです。会社が大きくなればなるほど、品質サポートを受けるのが困難になってきます。Excel® や Mac OS X での問題に個人的に対処してくれていると感じたメールを最後に受け取ったのはいつだったか思い出してみてください。個人的なメールを受け取ったとしても、その内容は、実際のサポートと宣伝がほとんど半々といったところでしょう。サポート契約を購入することは確かに可能ですが、問い合わせの電話に誰が出るかは、時の運に任せるしかありません。

ここではっきり言っておきますが、確かに私は素晴らしいサポートを受けた経験があります。私の経験では、登録期限が切れているにも関わらず、サポート・スタッフがそれを無視して助けてくれたことがあります。電話を切って数分してから非常に適切で言葉を選んだ説明をメールで受け取り、さらにフォローアップのための電話ももらいました。このように、営利会社が優れたサポートを提供できないわけでは決してありません。

さらに、多くのオープンソースのソフトウェア・プロジェクトには、そのプロジェクトをサポートするために成長した企業も関わっています。このような企業を利用するプロジェクトもあれば、利用しないプロジェクトもあります。したがってサポートは、クローズド・ソース環境での場合と同じく、オープンソース環境でも単なる「営利目的」にもなり得るということです。ステレオタイプはほとんど役に立たず、大抵は自分や自分と同じ立場を取る人々を愚かに見せるのがおちです。

その一方、これまでに説明した内容を考えてみてください。サポートはもはや、対価を支払った人々だけの領域ではありません。コード・ドキュメントはサポートを提供します。コード・ドキュメントを読めば知識が増え、多くの場合は自分で問題に対処できるようになります。ユーザーのグループは、さらに大規模なサポート・コミュニティーを形成します。結局は、FAQ がいかに素晴らしく、いかに詳説されているとしても、お金を払って誰かに読んでもらう FAQ よりは、自分が格闘しているバグと同じバグを徹夜で追いかけ回した本人からのアドバイスのほうを私は信頼します。


オープンソース・ソフトウェアは反復型です

よく話題にのぼる反復型という言葉は、特にソフトウェア開発の世界で耳にする言葉です。オープンソース・ソフトウェアでの反復型とは、大まかにはソフトウェアが頻繁にリリースされる傾向があることを意味します。実際、早い段階でリリースし、頻繁にリリースするというのがオープンソース・ソフトウェアの中核的な概念であり、メジャーリリースの合間に 15 や 20 のリリースがあることも珍しくありません (例えば、2.0、2.1、2.1.1、2.1.2、2.2 などのリリースがあり、最終的に 3.0 に至るなど)。

市販のソフトウェアは同じようには頻繁にリリースされないと言っているわけではありません。けれども市販のソフトウェアでは多くの場合、頻繁なリリースは一般ユーザーから隠されます。Windows や Mac OS X のようなソフトウェアでさえ、更新は頻繁に行われるものの目立たないように行われ、画面下端の控えめなスライド・イン/アウトや最小化されたウィンドウで示されるだけです。これはなぜかと言うと、ほとんどの市販のソフトウェアでは、改訂は誤りを修正することとして受け止められるからです。改訂の回数が多ければ、修正の必要がある誤りが多いということになってしまいます。

オープンソース・ソフトウェアの場合には、その逆が当てはまります。コードは公開されているため、誤りがあれば、誰でもその誤りに気付きます。JDOM や Xalan-J、あるいは Eclipse や Firefox のユーザー・リストに登録してみてください。バグを秘密にしていないことは、JIRA でお気に入りのプロジェクトにログオンすれば、誤りを修正するためのリリースと改訂が多いことからわかります。何も隠す必要はありません。このように頻繁なリリースがあるからこそ、ユーザーが得をすることになるからです。

機能要求を管理するのは、あなた自身です

ソフトウェアが繰り返しリリースされる場合、「隠された」バグがなければ、コード・ベースは絶えず進化することになります。そうなれば当然、機能のアップグレードは容易なことです。毎月 1 回またはそれ以上の頻度でリリースを実践しているならば、バグを修正するだけでなく、ソフトウェアに機能を追加しない手はありません。

しかし考えてみてください。ユーザー・コミュニティーは、バグの検出と修正を行うサポート・コミュニティーです。開発者たちは自分たちもユーザーであることから、自らが開発したソフトウェアのユーザーと関わり合っています。それでは一体誰が、機能要求を管理するのでしょうか。どこかの管理者がその権限を持つのでしょうか。それとも株主委員会やプロジェクト・マネージャーが管理するのでしょうか。いずれも違います (ただし、これらの人々が何らかの段階で関わる可能性はあります)。機能要求を管理するのは開発者自身です。開発者はユーザーであり、いろいろな意味で株主でもあります。

突き詰めるところ、頻繁にリリースされるということは、頻繁に改善されることを意味します。バグの修正は 1 つの改善ですが、機能におけるアップグレードも同じく改善です。そして開発は公開されていることから、開発者が大きな影響力を持ちます。JDOM (私はこのプロジェクトの発起人の 1 人で、長年活動を続けていました) では、主要なソフトウェアの変更の大多数はユーザーからの要求に応えて行われたものです。インターフェース主導型サポートを強化したバージョンに移行した際に、その先駆者となったユーザーは、このプロジェクトとの「公的」関係はまったくなく、たまたま関与しただけのことでした。Eclipse は主に、コード・ベースの新しいユーザーを考え出す賢いプログラマーたちによって、その方向が決定されています。

オープンソース・ソフトウェアはユーザーに応じて (多少なりとも) 自然に調整されていきます

オープンソース・ソフトウェアは最終的に、そのソフトウェアを長いこと使用しているユーザーたちのニーズに合わせて調整されていきます。ユーザーは一言も喋らず、メーリング・リストにも参加せず、品質だけを唯一の決定要因にさせておくこともできます。Ernie Ball 社の主な駆動力となったのは、そのようなユーザーでした。その一方、オープンソース・ソフトウェアに関与するということは、ソフトウェアの主導権を握るということです。自分が考える機能要求を伝えられるだけでなく、独自の機能を追加する権限さえも与えられます。

それと同時に、ユーザーもソフトウェアに自分を適応させていくことになります。これは悪いことではありません。ソフトウェアを頻繁に使用し、オープンソースが提供するコード・ベースをある程度理解することによって、ソフトウェアが最大限の力を発揮できるように作業の方法を調整することが可能になります。ユーザー・リストに登録し、さらにはコードの作成に協力した当然の結果として、ソフトウェアの内部構造を理解すればするほど、ソフトウェアを最適に使用するための決定を下せるようになります。フックを知り、上手く機能する条件を知り、問題のある場所を知ることで、最終的にはその知識を生かして作業効率を向上させる結果となります。


まとめ

最近のオープンソースに関する記事のほとんどは、オープンソースを崇拝する言葉の羅列であるか、実用的な面に焦点を当てて書かれているとしても、その文章の根底にはある種の情熱が込められています。長年の間、オープンソースの支持者たちは神学論争によって自分たちの正当性を裏付けてきました。彼らはユーザーであるよりも改宗者であることを望んでいるように見えます。けれどもこのような論争は、開発者ではない人々にとってだけではなく、コンピューターの横にオープンソースの旗を掲げる暇のない多くのプログラマーにとっても、かなり興ざめなものです。

けれども、こうしたプロパガンダのようなものによってわかりにくくなっているのが、オープンソース・ソフトウェアの本当の利点なのです。オープンソース・ソフトウェアを賢明に使用すれば (「何でもかんでもオープンソースを使おうとするな!」と言うよりは、けんか腰に聞こえない言い方です)、コストを削減できるだけでなく、場合によっては機能を実際に改善することさえできます。前述のとおり、Firefox は一般的なユーザーにとって最も顕著なわかりやすい例で、Firefox の基本方針がオープンソースであることを知ってインストールしているユーザーはほんのわずかしかいません。ユーザーが知っていることは、Firefox が有用なブラウザーであり、他のすべてのブラウザーを合わせたよりも多くのプラグインがあることです。その理由は、Firefox はアクティブで活気に溢れるコミュニティーによってサポートされているからです。

ハイブリッド環境でオープンソース・ソフトウェアを使用することを検討する場合、それを支持する最も有力な根拠は、おそらく IBM そのものにあります (もちろんこの記事は IBM のサイトで公開されるものですが、それでも、この文の内容は変わりません)。IBM は、商用オファリングで収支を合わせることに成功しているようですが、それでもまだ、Apache や Eclipse、その他への貢献によって、巷に出回っている一連のオープンソース・ソフトウェアへの関与を堅調に続けています。このように、意味をなす場合にはオープンソースを使用するという手法が、皆さんに推奨する手法です。

Gimp は好みではなく、PhotoShop を使うのが最も手堅い方法であるという人もいれば、デスクトップと iPhone のブックマークを Safari で同期するのが最善のソリューションであるという人もいるでしょう。それはそれで構いませんが、近視眼的な怒りにまかせて他のすべてのオープンソース・ソフトウェアも一切否定することだけはしないでください (この一文は大袈裟に聞こえますが、この文が表している行動も同じく大袈裟です)。短期間のアップグレード・サイクルと最新の機能が必要ならば、オープンソースによる代替手段を探してください。年に何万ドルも投じることなくサポートを受けたいのならば、特定の領域でオープンソースが提供するはずのサポート内容を調べてください。そして何を行うにも、情報に基づいて行ってください。適切な情報を基に賢い選択を行うことで、誰もがより幸せになります。皆さんが選択した特定のオープンソース・オファリング、そして却下したオープンソース・オファリングと、その理由をお知らせください。それでは、オンラインでお会いしましょう。

参考文献

学ぶために

製品や技術を入手するために

  • Eclipse は巷に出回っている優れた IDE の 1 つで、広範なプラグイン・アーキテクチャーを備えています。そして何よりも、Eclipse は完全なオープンソースです。
  • Xalan-J は、オープンソースの XML プロセッサーです。その構成のベースおよび中心となっているのは、すべてオープンソースのパーサーおよびツールです。
  • JDOM は、既存の API でのフラストレーションから生まれたオープンソースのパーサー API です。JDOM はその根本からしてオープンソースなので、何かが壊れたら修復してください。
  • 最良の Web ブラウザーの 1 つ、Mozilla Firefox を調べてください。信頼性の高いオープンソース・ソフトウェアを検討するには最適な出発点となります。
  • IBM ソフトウェアの試用版を使用して、次のオープンソース開発プロジェクトを革新してください。ダウンロード、あるいは DVD で入手できます。
  • IBM 製品の評価版をダウンロードするか、あるいは IBM SOA Sandbox のオンライン試用版で、DB2®、Lotus®、Rational®、Tivoli®、および WebSphere® などが提供するアプリケーション開発ツールやミドルウェア製品を試してみてください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Open source, Linux
ArticleID=491748
ArticleTitle=新しい観点から見たオープンソース
publish-date=04202010