アーカイブ

OSS

論理思考ツール、「マインドマップ」。これをハンドリングするソフトウェアは数々ありますが、オープンソースのFreemindは、シンプルすぎるほどのインターフェースで用途を選びません。また、Windows、Mac、Linuxをサポートしているのでユーザの環境の自由度も高いソフトウェアです。リサーチャ、エンジニア問わずマインドマップ使いには必携ツールの地位にあると言っていいでしょう。

FreeMind
http://freemind.sourceforge.net/wiki/index.php/Main_Page

Wikipedia “FreeMind”の項
http://ja.wikipedia.org/wiki/FreeMind

Freemind 活用クラブ(日本語)
http://www.freemind-club.com/

私は、2005年に出た安定版の0.8.0以来、アップデートもケアしてこなかったのですが、最近このソフトにはまっているマーケの末吉師とのやりとりをきっかけにひさしぶりに見ると、2007年2月に0.9.0 beta9 が出ていました。(ダウンロードページ)

早速インストールし、ざっと見てみました。カレンダー、スケジュールなどの時系列データのハンドリング機能、MindManager形式(.mmap)の読み込み(MindManagerのほうにはFreemindを読み込むプラグインがある)など、いろいろと機能拡張、問題修正が施されているようです。

(FreemindとPowerpointのアウトラインとの連動方式を模索しているのですが、そこには直接的な打ち手は追加されていないのはちょっと残念。いい案あったら教えてください)

なにより、本アップデートの最大のインパクト印象を残すものは、アイコンデザインと起動画面です。え?そんなこと?いえいえ、ぱっと見とってもかっこよくなっているだけではないんです。

ちょっとこのページみてみてください。

Freemindのイメージを変えようって議論です。

以前の蝶のモチーフは盛り上がったマインドマップの形状を想わせました。

新しい、電球のモチーフ、しかもよーく見るとそのフィラメントの部分は蝶の形になっているところにこだわりを感じます。

Talk:Light_bulb_and_butterfly
http://freemind.sourceforge.net/wiki/index.php/Talk:Light_bulb_and_butterfly

Discussion Forums: Open Discussion
https://sourceforge.net/forum/forum.php?thread_id=1686869&forum_id=22101

それぞれに言い分があります。「電球っていいよね」「焼き切れちゃう上に「自由」というイメージのない電球なんてヤダ」「すんげーアイデアを象徴する電球っていいじゃん。だから電球も蝶もあわせたのがイイ」みたいな具合です。

それぞれが、いつのまにか「Freemindは自分にとって何か」という感覚を醸し出してくるのです。この議論、もっと盛り上がるといいなあ。

単に「広く募集」とか「投票」みたいなものはいくらでもあります。そこから一歩突っ込んで、こういうマーケティング的なテーマでアツイ議論が見られるのはOSSプロジェクトならでは、です。とっても面白い。

OSSプロジェクトはもちろんのこと、リアルのプロジェクトでも試しにこういうのやってみちゃうのはどうでしょうか。

広告

マイクロソフトとノベルの提携に関する一人ブレスト。

Moglen教授のオープンソースライセンスとの兼ね合いなどを懸念する声もあれば、OSDLのオープンソースの重要性への評価だとか、Redhatの勝利宣言とかもあり、オープンソース関連情勢には大きな波紋を呼んだ。

しかし、この提携はマイクロソフトのオープンソースへの評価を意味しているとは言えないんじゃないか。むしろ、どちらかと言えばリスクが高まったかもしれない。(エンドユーザのリスクについてはもう少し考えたいと思う。)

今回の提携で日本での報道ではあまり表に出ない、重要性のある言葉、それは「相互運用性-interoperabilityのための提携」という部分だ。

欧州はじめ、e-Goverment戦略の中で、相互運用性を確保できる技術でないと採用することに問題があるという声は世界中で高まっている。日本もしかり。それに関してマイクロソフトに対し、もっとも厳しく、かつわかりやすい策を打ってきたのはEU政府だ。このキーワードに関連して、EU連合政府はマイクロソフトの技術の閉塞性に対し、巨額の罰金を課してきた。

この状況はマイクロソフトにとってEUはじめe-Govermentというマーケットを大幅に減じかねない巨大なリスクだ。ここで抜本的に改革されるように見える、かつ、EUの策をおさめるのにつじつまがあうような策を講じる必要があったわけだ。

マイクロソフトは、自社のアドバンテージを損なわず、欧州が剣を収められるような、そう、少なくとも相互運用性を確保できるように見えるスキームはないものかと策を練っていたはずだ。自社のソフトウエアをオープンにする以外の選択肢でなければならない。

こういう問題は、企業戦略の観点からは別に難しくない。敵陣営の適格者と戦略提携し、そこをグルーとして使えばいい。世界史、日本史上でも日本の戦国時代でも良く見られた手法だ。

Linuxディストリビューション会社との提携をグルーの役割とするという戦略として、相手はRedhatではなくSUSEというところがポイントだ。欧州出身という色もあり、欧州でのシェアも高い。しかも、傾きかけた自社ディストリビューションのマーケット拡大の動機もある。(八田氏のいうとおり、結果的にSuSEはばばくじを引いたことになるという観測もあって当然だ。)

実際、この提携は広くオープンソース陣営にとって何か情報拡大を意味するわけでもないし、たとえばGoogleのように開発力の提供を得るわけでもない。Novell SUSEとて、たいした技術提携を得られるわけでもない。むしろ、マイクロソフトに技術力を吸い取られる(5年間で35万インシデントも!)こと、双方向にパテント関連で訴訟しないことなど。

(この提携の存在そのものが、オープンソースソフトウェアにすでにパテント侵害問題があることをNovellが勝手に認めてしまったことになりはしないか?これは調べてみる必要がありそうだ。)

相互運用性のための戦略提携ということは、「オープン標準」策定プロセスにおいて、マイクロソフトの発言力を上げることにもつながるだろう。それを実装する担当としてNovell SUSE、キミががんばれよ、と札束で顔をはたかれたという構図にさえ見えるのだ。

かくして、マイクロソフトは順調に市場を広げ、欧州でのリスクをおそらくは大幅に軽減し、かたや、求心力を失いかけていたSuSEのプロモーターが増えるものの、大してオープンソース側はそれによって何かが伸びるわけではない、というオチではないか、と。

以上、オープンソースソフトウェアとマイクロソフトの構図が大きく変わったわけではなく、むしろリスクが高まったのではないかとの備忘録。

日経BP ITPro Watcher「OSSセンター談話室」というblog(?)に、「Linuxを政府標準に!? KIPAで見た韓国のOSS推進強化アプローチ」という写真つきの記事を寄稿しました。ぜひご覧ください。

今日日本HPの宇佐美さんと話したところによると、Linuxワークステーション市場はメディアではあまり注目を浴びませんが、日本でも一度に数百台単位の組織的導入例が、右肩上がりで着々と進んでいるそうですよ。問題は売り手側の、「パソコン市場だとの思い込み」による思考停止なのかもしれませんね。

道具は売り手ではなく、使う人によって成長する。ビジネスプランニングで陥りやすいパターンの一つとして覚えておきたいと思います。

もう何年も前の話です。ある人に、「オープンソースの関連の話も文書もニュースも、それをちゃんと読むためにはもう一歩踏み込んだ解説が必要だよ、okdt。大事そうなのはなんとなくわかるけど、正直言って読んでいてさっぱりわからない。」と言われたことがあります。なるほど…。確かに、基本的なことひとつ取って見ても、日本語で調べられるツールになりそうなものはないんですよね。オープンソース関連を解説する辞書みたいなものがあればいいのかしら。でも、作るとなると…。そんなことを思った記憶があります。

そんなわけもあり、2006年5月15日、IPA OSSセンターが、オープンソース情報データベースOSS iPediaを公開したのをとっても喜んでいます。OSSの性能情報OSS導入事例、そしてナレッジベースとしてQ&A用語解説ディレクトリを盛り込んでいます。

OSS普及拡大の観点からすると、これが、「オープンソースはわかりにくい」という声に応える、リーディングツール(reading tool)になることと、ここ最近のエンジニア、例えばミッションクリティカル系のエンジニアで、OSSに関する理解を得なければならない状況に置かれている方々にとっては、有用なリファレンスのひとつになるんじゃないかと思います。

本サイトは、昨年の秋よりIPA内に設置された、データベース検討委員会、後のOSSセンターのデータベースWGにて主にアレンジされました。この委員会はNTTデータ玉置さんがまとめ役をしてくださったんですが、これに参画させていただいたのはとてもエキサイティングな経験になりました。このサイトが 非常に多くの方々の協力によるものであることが「謝辞」のページに記載されています。

5月15日、フェーズ1の公開を素直に喜んでいますし、すでに「ライセンス関連の情報が役立った」などの声も寄せられていて、とてもうれしいです。もっともっと「使える」ものとしていけたらと思っています。

そのためにも、まずは自分が読んで勉強せねば。

http://ossipedia.ipa.go.jp/

朝っぱらから、ash.氏と「IT飽きたって言ってたんだよ」なんて話をメッセージでやりとり。

ITアーキテクト業がだんだん面白くなくなるのはなぜだろう。

ひとつには、「おれってもしかして天才?」と思える、「あの」瞬間を感じる頻度が減っていくからではないかな。上流工程のマネージメントにいけばいくほど、つまり、いわゆるシステム構造設計、あるいはプロジェクトマネージメントという職種では、あの感覚を得にくくなる。一般化してゆき、月並みになってゆき、その上、out-of-control マターが多すぎる割りに、成果もツマラナイのだ。ある程度儲かりはするが、ツマラナイ何か・・・。

そう、あれだ。

構造設計といえば、今話題の某建築士の事件を指差して非難できるITアーキテクトってそれほど多くないぞ。彼は、ちゃんとやる方法とコストもわかった上で、外圧で鉄筋を抜いた。もちろん不正は不正だが。一方、ITの世界だとそれが「不正」とも定義されていないから、ちゃんとやる方法さえわかっていなくても、現時点でつぶれてなければさらしものにされない。「工法が安定すればITの世界でもそうなっていく」との意見もあるが(紀氏)。

要はそれがないのをいいことに、外圧だろうが無知の設計だろうがITの世界はなんでもアリで、鉄筋を抜いてあるどころか存在すらしない設計が普通にまかりとおってしまう。でもって、「震度5強」のような、過負荷がかかって出た不具合を、サーバ、ディスクの「寿命」なんて呪文をとなえてさらに高額のリプレースを正当化し、投資をさらにひっぱる・・・。

ニコラス・G・カー著 DOES IT MATTER?(「ITにお金を使うのはもうおやめなさい」)という本は、HBRで、”IT Doesn’t Matter.”という論文として掲載されたものがベースになっている書籍だ。うまいタイトルだ。ITは役に立たない、というそもそも論を展開するものでも、情報そのものや使う人自身の有効性を否定しているものでもない。むしろ、多くの局面において、思い切って「金食い虫」のIT投資をやめてみろという。

ITの世界で喜びを見出そうとする人にとって、これは必ずしもマイナスにはならない。持ち家のメンテナンスが建替えに終始しないのと同様、ITの世界でも「ビフォー・アフター」はありえる。きちんとした設計とそうでないものはやがてはっきりする。今あるものを活用、改善することが不可欠になるからだ。設計だろうと、実装コーディングだろうと、きちんと作れる、直せるみたいな、その種の「快感」がよみがえってくる現場が増える可能性がある、匠の世界。そこがオープンソースの真骨頂かもしれないと思いきや・・・。

>「だからいま binary 2.0 なんですよ。」(ukai氏)

はっ、そうくるかー。(@_@; ソースコードのハックに飽き足らず・・・。
確かに、under control領域が拡がると、快感も増すものだよね。うむうむ、と、うなずきつつ、一週間続いている偏頭痛をlivepatchできないものかと薬局へ・・・。

「コードも書かない人に言われたくはない」 正直で、エモーショナルな言葉。それゆえに、共感、反発、共に大きな反響を呼んでいます。でもこの議論、「言われたくはない」、何を言われたくないのか、なぜ言われたくないのか、もっとそこを議論したいと思いました。

発言者の三浦さんの原文では、

「だからこそ、CodeFestを日本で開く応援をしたい、推進派になった。人材育成とか、日本発のOSSとか、コードも書かない人に言われたくはない。一緒に取り組んでいる仲間を増やすこと、同じ空間と時間を共有して、フリーソフトウエアの世界を確かに広げた実感を共有すること、それこそが醍醐味ではないか。 」

人材育成と日本発のOSSが例に挙げられています。これはよく考え抜かれた指摘ですね、要するに誰と一緒に仕事をするか、そこで何を成果として作るか、これをコードも書かない人に言われたくない、と。 仲間と共感でき、そこで意欲的に成果がでることがサイコウにうれしい、と。ここは事実提示です。

すると、コードを書かない人に「言われたくない」ことがあるとすればそれは、開発組織における「共感」や、成果物への「意欲」が度外視されるケースだということでしょうか。(小飼さんの「コードだけでOSSの世界が回ると思ってんのか」は、そりゃそうなんですが突っ込みポイントはそこじゃない、という感想です。) 昨今の三浦さんのご活躍の現場で、何度となく彼自身が板ばさみに会い、まさに苦悩ゆえの発言だと連想されます。

さて、その「仲間との共感」「成果物への意欲」は、ものづくりの立場にとっての軸と、要件を出す立場にとっての軸とは表現も価値観も異なります。けれど、そこの問題を提起するのであれば、「その溝はもう埋めたくありません」と言ってしまうと、そこの問題解決による発展の可能性を低めるというリスクがありますね。 共感や意欲を共有できるかどうかは主に、外的要因よりも内的要因のほうが大きいからです。内的要因でシャットアウトされると手の出しようがなくなります。

ですから、OSS開発では、開発者もユーザも一体になってはじめて意欲的な成果物に成長する、というシナリオを目指します。そして、成功しているプロジェクトに「コードを書かないプロデューサ」がいることは珍しくありません。OSSにおいては、なおのこと、「共感」と「意欲」がシンクロしている、あるいはシンクロさせる努力が必要だというわけです。

名前を挙げれば続々と、まさにそういうことをしてきた人たちが存在します。開発者、プロデューサ両方の側面ができる人もいます。マーケティングからやってきて、一生懸命理解しようとしてきた人たちもいます。そういう人たちは、自分ではなく、開発者を中心としたマンダラート、ユーザを中心としたマンダラートの両方を持っているゆえに、各ステイクホルダーとの調整ができるし、期待されているわけです。

OSS開発のステージの大きな変化

ところで、その対立構造とは異なるところで、不思議と同じ論点があり、そこでは相互に議論がものすごく盛り上がっているという動きがあります。 それは「コードを書く人」の中での話です。

いくつもの大きなベンダーやSIerがメインフレームの人間、ミッションクリティカル系技術者を駆り出してまでオープンソース開発セントラル組織を作り、実際にOSS開発を前提に基礎開発をばりばりやっています。この動きにより、OSSとは全く別のところにいた、よく訓練された技術者に新たなステージを与え、しかもこれが少なからぬ意欲を与えることに成功しつつあります。 これらが表面化するのは時間の問題でしょう。

最近、そういう方々を公の場でインタビューする機会がありました。(吉岡さんのレポート参照のこと)「メインフレーム屋」でありながら「OSS開発プロジェクト」をどうしていこうか真剣に考えている人たちです。 彼らの主な特徴としては、OSSの「自由な開発」「自由な意思決定」という部分はよく解らない。しかし、品質や時間の観念、障害解析に関するリテラシーはものすごく高い。これまで閉塞的なところから突然やって来たという意味で仙人のような人たちです。

一方、これまでの「みんなでふもとからコツコツ上がってきた人たち」は、そうした情勢の中で組織的に参入してくる「山から下りてくる仙人」とどのように共感し、分かち合っていくのかが大きなポイントとなります。Linux Kernel MLでのLinusのカーネルダンプ問題しかり、そこには大きなエネルギーがいります。 その議論をデフォルメして言えば、企業のミッションクリティカル要件にとって必要だから、壊れたときのための機能を作らなければならない、という集団と、壊れない良いものを作りたい、そういう作りたいものを作っていこうよ、という集団の議論です。 そこは、理屈よりも「共感」が必要な世界だし、目指す成果への「意欲」の問題でもあります。

それで、両者にある見解の違いを中心に、どうするのか議論が盛り上がっていることは、OSSの発展の歴史において、これまでにないすばらしいことです。この動きはソフトウエア開発モデルの歴史に残ることだと思います。 OSSプロジェクトにおいて新規に関係者が増えていく際に、とにかく議論のテーブルがあることは必須です。

まつもとゆきひろさんがおっしゃるスローガン、「コード書きの気持ちがわからないとオープンソース・エコシステムで成功できない」というメッセージは、孤立ではなく他者との関係で自分の目的を達成したい当事者においては、全員にひとしくあてはまると思います。俯瞰的に自分のポジショニングを確認するんなら、各立場からの観点で出されるメッセージを中心にマンダラートツールで思考をはじめていくと面白いですよ。開発者、ユーザ、支援者のどこをスタートとして書いていくにしても、最終的に大きな一枚の絵に描くにはなにが必要なのか思考する助けになるように思います。

いくつかの立場を理解できる人、客観的な目撃者として指摘できる立場にいる人間は、必然的に注目を免れない傾向があります。開発者自身、あるいはプロデューサ自身、ユーザ自身の意見よりも重く見られるために奥歯にものがはさまってしまう。そういう意味では、今回の件にまつわっては、皆さんストレートで、熱いメッセージが飛び交っています。吉岡さんしかりきんねこさんしかり・・・、反応リンク集まで。発展を目指して語る以上、議論を恐れてはいけないですよね。これからも、臆せずにメッセージを出していって欲しいですね。

マイクロソフト社のバルマー氏は、自身の講演においてLinuxについてどう考えているかについて示した際「Linuxのアキレス腱は誰も責任を負わないこと」だと述べています。これについて、いくつかのblogで「じゃあMSはどうなんだよ」との指摘を拝見しました。いずれの主張も、なにがしかの事実や現状を観察して出てきたものでしょう。ただ、残念ながらこの講演を直接聞いていないのですが、わたしがバルマー氏に質問できるのなら、ビジネスとしてどの局面において「責任を負う」ことが欠落していることを指摘したいのか、そこを尋ねたいですね。

「ソフトウエアそのものの責任を負う」?

LinuxカーネルにせよUNIXライクに統合されたものにせよ、複数の人間によるプログラムの複合体であることは言うまでもありません。プログラムが企業によるものであれ、個人によるものであれそのコードに対する責任をプログラマが負っていることは事実です。つまりプログラマが企業ハードウエアに対応するデバイスドライバをIBMやNECのような企業が作ってオープンソースとしてコントリビュートしているケースでも、個人が何かのコードをコントリビュートした場合でも、です。

対価は金銭とは限らないのは言うまでもありませんが、とにかくそれに対しその「責任を果たす」ということを、コードを公開し、著作権者を銘記し、フィードバックを集約していくことなどの方法で果たしています。それを怠ると、そのコードは、他人に引き継がれるか、オルタナティブコードの出現などにより淘汰されていきます。つまり、時の経過と共に、より効果的に責任を負う著作者によるコードへと選択されていきます。

別にオープンソースだから責任を果たしやすく、プロプライエタリだと責任を果たしにくいというハナシではありません。無責任なコードが永久的に許容されつづけないことをどう保証するのかについて、プロプライエタリなソフトウエアとオープンソースソフトウエアではアプローチが異なるだけです。(この部分はもう少し話したいことがありますが、今回はここで止めます。)

「ソフトウエアの利用に責任を負う」?

オープンソースソフトウエアによるビジネス実現に対価を得ることは構わないことになっています。プロプライエタリなソフトウエアは有償でライセンスを取得することにより、活用することができます。この局面で、インテグレータはMSのようなプロプライエタリなソフトウエアも、オープンソースソフトウエアも、どちらでも選択することができます。この場合に、MSのような主体者がないオープンソースソフトウエアに関する責任は誰がとるのか、という問題があるでしょうか?ありません。オープンソースインテグレーションの責任においては、シンプルな話、対価に対しその責任があるというのが答えです。

築地で寿司を食べる場合、客はその寿司のクオリティの責任を誰に求めますか?魚自身にですか?漁師ですか?市場関係者ですか?運送業者ですか?違いますね。寿司屋に求めます。なぜか。単純に、客は「寿司屋のサービス」に対価を払っているからです。それがインド洋のまぐろなのか、近海モノなのかなんてのは関心はあるかもしれません。が、責任という観点では、それはどうだっていいんです。「近海モノがおいしいらしい」という理由、あるいは最近見た「あるある大辞典」で知った知識をもとに(ものの例えです)、「近海モノ」を注文することがありますが、それでも「寿司屋のサービス」に対価を支払っているのです。

寿司屋は、その魚のクオリティを確保するために、あらゆる手段を使います。実際に海に出ている漁船を調査したり、市場関係者の特定の目利き人やディーラーに選定をアウトソースしたりと、さまざまな方法をとるわけです。どうするかは寿司屋が決め、寿司屋は素材に対しその対価を支払います。この連鎖の最後は「海」ですが、ここはオープンソースソフトウエアよりもはるかに「責任」の所在が見えない世界です。もっともはるかに安定し、完成しているように思いますが。いずれにしても私たちはそれに依存して生きているのです。神は偉大です。

もちろん、Redhat、TurboLinux、MiracleLinuxのようなディストリビューションベンダーが負うべき範囲は当然存在します。彼らは編集価値により対価を得ていますから、どのソフトウエアを自分たちのディストリビューションに含めるのかに関し、責任があります。自分たちも開発に参加することにより、その責任を果たしやすくなっているのでしょうが、それでも全部を自分たちで作る必要はありません。また、Debianのように、ボランタリで編集価値を生み出しているものもあります。彼らは彼らなりに「対価」が何であるかを知っています。

そこで、インテグレータは、どの方法で「素材」を調達するかを考え、選択します。良くないものは使わなきゃいい。ただ、シェア、評判、情報、あるいは経験など、どの根拠によって選択するにせよ、それが顧客の要件を満たしているものであることを証明する責任があります。それに対して対価を得ているのですから。

問題は、「オープンソースソフトウエアによるシステムの品質に責任を持つのは誰ですか?」と顧客から尋ねられたときに、SIerが「最終的に導入するインテグレータ、つまり私たち」だと明確に答えようとしないことではないでしょうか。最近、あるインテグレータ会社の社長さんと話していて、「この厳然たる事実を誰も明確に述べようとしない」と言っておられました。指をさして、「あいつのせいだ」と言いたい傾向のためです。マイクロソフトの製品がハングアップしてブルースクリーンを出しても、「うちのせいじゃありません、MSのせいです」と。食中毒を起こした客に、「最近の築地は良くなくてねぇ」とか言うのと大差ありません。

市場がないと寿司屋が経営できないのと同様、外部から調達したものをもりあわせてサービスにするという図式は非難の対象ではありません。むしろ、現状のITサービス提供連鎖においてエンドユーザから最大の対価を得る位置にいるインテグレータの目利き力不足で、かつ自分でロクに扱えないものをテキトーに扱って対価を得ているのであれば、それこそ非難されるべきだということです。オープンソースを扱ってなにがしかのサービスあるいは製品を提供する企業が、誰でも扱えるなどのメリットだけを享受し、その品質や性能に関しあまりにも無責任、という状況に問題があるのでしょう。

バルマーさんがこう言ったのであれば良かったのに。「オープンソースで無責任なビジネスをやる会社が多い」と。

ほんとはマイクロソフトさんこそお困りのはずですしね。あ、いや、矛先がそれてラッキーだったのかな?;-p