時の経つのは早いもので、The Document Foundation (TDF)とLibreOfficeが公式に立ち上がってから3ヶ月目になる。立ち上がった直後は正直どうなることかと思ったが、実際にこの3ヶ月に経験したことを振り返って見るとやはりフォークして正解だったと思う。
OOo時代の時にはコードの改良や開発効率の向上などの案はあってもそれが提案できる環境ではなかった。コミュニティから来る提案は全てOracle勢のフィルターにかけられ、それが彼らの内部の開発陣やマネジメントからOKされなければ、いくら外部の我々の効率の向上に繋がろうとも許可は降りなかった。それどころか決定権は、常にOracle内部(というかハンブルグ開発陣内部と言った方が的確か)の限られた人間が常に握っていた。で、その意思決定のプロセスは外部には常に説明されることは無く、外部の人間にはその決定内容だけが享受される、という仕組みであった。透過性など全くあったもんでは無かった。こんな状況で、やる気のあり経験もあるハッカーが集まってくるわけがなかろう。自分もよくあんなところで3年間もよく我慢してたなぁと逆に感心さえしてしまう。Novellから給料もらって仕事としてやっていたからこそ我慢できていたからであって、そうでなければさっさと辞めていたと思う。と言うか自分は一度離れる決意をしているんだよね。その後すぐにNovellに拾われた、と言うわけだ。
前にも散々言ったと思うがOOoのコードは古くて汚いコードで充満している。STLやC++の標準化がなされる前に書かれたコードであるから変なマクロとかがそこら中にある。前々からそれらのコードをもっとSTLやBoostを使って見やすく綺麗にして、コード自体をもっとシンプルに読みやすくするのが夢であったが、上で説明したような官僚的な状態であったので、それを提案するのも億劫であった。というか提案するだけ無駄である。以前不要になったコードの一層削除を申し出たこともあったがそれすらも却下されてしまった。ひどい状態だった。それがLibreOfficeになった今、そのような理不尽な制約が取れて、意思決定も我々開発陣の手で出来る用になった。ようやく手にした自由である。
僕はコードベースというのは家のようなものである、と思っている。普段は多少散らかっているかもしれないが、人が訪ねて来る度にある程度綺麗にする。これは常識である。ここで言う訪問者というのがハッカーであって、新しいハッカーを寄せ集めるためにはまずコードベースを綺麗にしておく必要がある。そうでなければ誰も来たがらない。これもまた常識である。でも住んでる人間にとってはもうその散らかった状態に慣れてしまっているので、どんなに散らかっていてもあまり気にならない。そんな環境に何十年も住んでいると、もう綺麗にするという必要性さえ全く感じなくなってしまう。それどころか誰かが綺麗にしようとすると、それに反発さえしてしまう。だから最終的には誰も寄ってこなくなる。
LibreOfficeになってから、やっとコードベースの大掃除が出来るようになった。とはいえうちらもバグの修復や機能の実装などもしなくはならないので、四六時中コードの整理整頓ばかりはしてられないのだが、幸いにも同じような考えを持つ有志達が現れたお陰で結構なペースでclean upの作業は進んでいる。この3ヶ月の間だけでもLibreOfficeのコードは大分綺麗になったくらいだから、1年後にどのくらい綺麗になってるかは想像すらできない。以前とは雲泥の差である。コードを綺麗にすると、なぜか作業効率が上がったような錯覚に陥る。いや、それは錯覚ではなく事実なのかもしれないが、いずれにせよ気分は良い。この点だけでもLibreOfficeが出来た甲斐があると思う。
ただLibreOfficeになってから大変になった部分もある。インフラはもはやOracleの提供するものには頼れないので自分達で調達する必要がある。LibreOfficeのような大規模なプロジェクトの場合は特にそれに一苦労する。でもふたを開けてみたらなんとかなるものである。GitレポジトリやBugzilla等は、Go-OO時代からお世話になっているFreeDesktop.orgのを使い、ダウンロードのミラーはMirrorbrainにお願いし、メーリングリストとウェブサイトだけをTDFでなんとかする、という手筈になった。で、それらを運営できるだけの資金がありがたいことに集まってきたようなので、取り敢えずは安泰である。
全体的に見て、とりあえずLibreOfficeは良いスタートを切ったと言いきれるだろう。この勢いを止めることなく、LibreOfficeのために自分の出来る限りのことをとことんやり続けるのが自分の今の目標である。
Saturday, December 11, 2010
Thursday, October 28, 2010
FacebookやmixiでLibreOffice
LibreOfficeの日本語用ファン・ページをfacebookで作ってみた。
http://www.facebook.com/home.php#!/pages/LibreOffice-ri-ben-yu/162804050405413
で、mixiでもLibreOfficeのコミュを作ってみた。
http://mixi.jp/view_community.pl?id=5298956
興味のある人は参加されたし。両方ともまだ閑古鳥状態だからねぇ...(苦笑)。
http://www.facebook.com/home.php#!/pages/LibreOffice-ri-ben-yu/162804050405413
で、mixiでもLibreOfficeのコミュを作ってみた。
http://mixi.jp/view_community.pl?id=5298956
興味のある人は参加されたし。両方ともまだ閑古鳥状態だからねぇ...(苦笑)。
Tuesday, September 28, 2010
LibreOffice by The Document Foundation
という訳で、やっとの事で公開までこぎつけました。これが何かと言うと、LibreOfficeの前身であるOpenOffice.orgからの派生で、元々OOoのコミュニティメンバーだった人達によって設立されました。うちらNovellもその一員に加わっています。このプロジェクトは成るようにして成った,という感じですね。まぁ僕に言わせれば10年遅かったという気がします。ただ派生とは言ってもある意味ではOracle版のOOoの方が従来のコミュニティ・ベースの形式から遠ざかって行ってしまったので、うちらから言わせれば向こうの方が派生版なんですけどね。
このプロジェクトの目的は、一つの企業(つまりOracle)に依存しない、開発者が中心となった、健全で非官僚主義的なコミュニティの育成を第一にしています。これは今までSunやOracleの手では成し遂げられなかったものです。でも健全なオープン・ソースプロジェクトを育成するにはここから出発しなければなりません。
で、当面は、Go-OOのコードが基盤となってその上に新しいものを構築していく予定です。Go-OOはLibreOfficeによって取って代わることになるので、その名前は徐々に消えていくことになるかと思います。
最後に、このプロジェクトが成功するか失敗するかは全てコミュニティの手にかかっています。応援のほどよろしくお願いいたします。手を貸してくれる方は大歓迎です。
Labels:
go-oo,
libreoffice,
novell,
openoffice.org,
oracle
Sunday, September 19, 2010
OSC Tokyoの感想
9月の始めに東京に出張だったわけだが、ちょうどいい時期に立川でOpen Source Conference (OSC) Tokyoが開催されてたので、出張期間を1日延長して初日・金曜日だけですが顔を出してみました。で、その時の感想を幾つか。
まず、Novellがゴールド・スポンサーになってた、のはいいのですがNovellの東京支社からは誰も来てなかった。東京支社の誰かと会えると楽しみにしていたのですがこれは誤算。あのMicrosoftだってブース出してたのに...。東京支社の人とは同じNovellとはいえ余り一緒に仕事をする機会はないので殆ど交流が無いのがちょっと悲しい。
ホテルが一緒だった会津若松市の目黒さんと会場まで同行して、MeeGoや他の自治体でのOSSの使用状況の講演に出席。で、最終的に目黒さん自身の講演も拝聴しました。あと、OOoのサポートを有償で提供するアシストの小川さんという方と少しおしゃべり。そこで思ったのは、日本ではまだまだOSSはそれを使ってコスト削減、という側面が重視されていて、開発コストの共有,という側面まではまだまだ浸透していない、ということ。この状況が将来的にどう発展するかに興味が沸く。まず始めの一歩は有償でサポートを提供する会社がどれだけ一般的になるか、という面である。それが一般的になれば、次のステップとして有償の開発サポートも実現可能になるであろう。OOoに関して言えば、ユーザー側はとりあえずバグを報告してそれを開発をスポンサーしてくれている企業に「直してね」とお願いする図式に現在ではなっているのであるが、これは長い目で見たら長続きはしないであろう。というのもバグを一つ直すのにも開発費がどこかで発生して、誰かがそれを支払わなくてはならないからである。将来的にはせめてパッチをバグ報告後に上げられるような状況を日本の市場でも持っていけるようになるよう切に願う。で、もっと将来的にはコア開発に参加出来るような人材を育てられると一番よい。つまりパッチ書いてあとはよろしく、ではなく最後にintegrateされるまで見届けられる人たちの育成である。僕自身はそれくらいは日本でも可能であると思うのだが、どうでしょう。
まぁそうはいっても現在のOracle中心の開発形態は、Oracle企業自体がかなりの秘密主義であるために、外部の人間の開発への参加は本当に限られたレベルでしか出来ないのが現状である。これをうちらGo-OO陣営は直そうとしているのだが、まぁ現在のユーザーの視点から見たら(とりあえず誰かが開発して無料で使えさえすれば)全く関係の無い話なんだろうな、ということは想像が出来た。悲しいがこれが現実であろう。ただ将来的にコア開発出来る人を育成するにはこの点を直さないとダメである。それは確実に言える。
あと、オフィス・スイートに関して言えば、ユーザーの必要としてる機能のレベルは日本ではかなり低いものだというのもわかった。つまり、はっきり言ってしまえばOOoの今の機能でもそばで教えてくれる人が居さえすれば十分使える、という点である。ということはだ、仮に明日Oracleが開発から手を引いたとしても、バグさえ直してくれる人達が取りあえず数人居てくれればしばらくは安泰、ということになる(のかな?)
そうそうopenSUSEのブースにも立ち寄って見た。渡辺さんという方がブース番をしていた。openSUSEについていろいろとお話をした。松本さんにも会えるかな,と思ったけど無理みたいだった(笑)。
ちなみに、以前同僚のCedric Bosdonnatから名前だけは耳にしていたフランス人のJean-Christophe Helaryさんとも顔を会わせることが出来た。日本語がかなり上手かったのがすごかった。もうネイティブであるアレは。日本はもう15年目だってさ。
とまあこんなところでしょう。日本は生ビールが美味しかったです。あと明星大学の学食は安くて美味しかった。結構日本の大学の学食というのは侮れない。そのうち学食ツアーとか企画してみるのも面白いかも(笑)。
Saturday, April 3, 2010
レガシーコード
吉岡氏のブログは常に目を通しているが、以下のブログ
http:// d.haten a.ne.jp /hyoshi ok/2010 0403
は得に目についた。僕自身も激しく共感する内容である。で、こんなのを読むとOOoのコードベースがいかにレガシーで、いかに危険でいかに未来がないかがわかる。
テストのないコードは危険である。だが多くの開発プロジェクトはテストが書かれること無く開発が進められている。中にはOOoのような大規模なプ ロジェクトもこれに含まれる。一応VCLTestToolという、OOoの機能を一通りチェックするテストは存在するが、それは「統合テスト」であって 「単体テスト」ではない。で、統合テストというのはないよりはマシであるが、それ以上でもそれ以下でもない。
テストのない大規模なプロジェクトに長年関わってると、それが当たり前になってしまい、テストを書くというくせが出来ないしテストを走らせるとい うこともしない。だから、コードを書くときもテストが書きにくいような書き方をする。OOoはそのようなコードで充満されている。救いようがない。だから 1から始める必要がある。
ちなみにそのようなレガシーコードにいざ単体テストを設置しようとしても、莫大な労力を必要とし、しかも他の開発陣がそれを意識せずテストできな いコードをどんどん増やしていくと、無駄な努力となる。なのでそのようなコードを蘇生させるには、テスト・ハーネスが設置されるまで新しいコードがチェックインされるのを全て廃止する必要がある。大抵のプロジェクトの場合はそんなのは不可能なので、フォークする必要があるという訳だ。
ちなみに、この吉岡氏が使っている本の引用をよく見ると、僕が持ってる本の一冊によーく似ている。と思ったら、実はその本の日本語訳みたいである(笑)。
ちなみに僕の持ってるのは
Working Effectively with Legacy Code, by Michael C. Feathers
http:// www.ama zon.com /Workin g-Effec tively- Legacy- Michael -Feathe rs/dp/0 1311770 52
で、SlickEdit時代に買った本。OOoの開発にも恐ろしいほど当てはまる、読んでて笑えてくる(でも半分涙目)本である。
http://
は得に目についた。僕自身も激しく共感する内容である。で、こんなのを読むとOOoのコードベースがいかにレガシーで、いかに危険でいかに未来がないかがわかる。
テストのないコードは危険である。だが多くの開発プロジェクトはテストが書かれること無く開発が進められている。中にはOOoのような大規模なプ ロジェクトもこれに含まれる。一応VCLTestToolという、OOoの機能を一通りチェックするテストは存在するが、それは「統合テスト」であって 「単体テスト」ではない。で、統合テストというのはないよりはマシであるが、それ以上でもそれ以下でもない。
テストのない大規模なプロジェクトに長年関わってると、それが当たり前になってしまい、テストを書くというくせが出来ないしテストを走らせるとい うこともしない。だから、コードを書くときもテストが書きにくいような書き方をする。OOoはそのようなコードで充満されている。救いようがない。だから 1から始める必要がある。
ちなみにそのようなレガシーコードにいざ単体テストを設置しようとしても、莫大な労力を必要とし、しかも他の開発陣がそれを意識せずテストできな いコードをどんどん増やしていくと、無駄な努力となる。なのでそのようなコードを蘇生させるには、テスト・ハーネスが設置されるまで新しいコードがチェックインされるのを全て廃止する必要がある。大抵のプロジェクトの場合はそんなのは不可能なので、フォークする必要があるという訳だ。
ちなみに、この吉岡氏が使っている本の引用をよく見ると、僕が持ってる本の一冊によーく似ている。と思ったら、実はその本の日本語訳みたいである(笑)。
ちなみに僕の持ってるのは
Working Effectively with Legacy Code, by Michael C. Feathers
http://
で、SlickEdit時代に買った本。OOoの開発にも恐ろしいほど当てはまる、読んでて笑えてくる(でも半分涙目)本である。
Subscribe to:
Posts (Atom)