クラスタ管理のMesosphereがデータのスケーラビリティのためにグラフデータベースのOrlyAtomicsを買収

分散プロセス(クラスタ群)の生成と、それらが適正に動くためのリソース管理をデベロッパ/アドミンに代わってやってくれるMesosphereが、分散/並列データベース技術(グラフデータベース)のOrlyAtomicsを、どうやら人材獲得を目的として買収した。OrlyAtomicsの4名の技術者は、ただちにMesosphereのチームに加わる。買収の価額などは、公表されていない。

Mesosphereは、オープンソースのMesosプロジェクトに便利なユーザインタフェイスを着せたサービスで、‘データセンターのオペレーティングシステム’を自称している。このMesosユーザインタフェイスの下では、どんなに複雑大規模なデータセンターでもまるで1台のPCのように簡単に効率的に管理できてしまうことが、メインの売りだ。一方OrlyAtomicsは、スケーラビリティのたいへん高いデータベース技術だ。クラスタ管理とデータベースでは一見互いに無関係なようだが、Mesosphereの協同ファウンダでCEOのFlorian Leibertによると、その下部構造は共通点がとても多い。

まずどちらもルーツがオープンソースで、どちらもC++で書かれている。だからOrlyAtomicsの連中はMesosphereに来たその日から一緒に仕事ができる。しかしLeibertによると、そういうレベルの互換性がすべてではない。プログラミングの技能以上に重要なのが、データ構造のスケーラビリティについて理解を共有することだ。

“大規模なシステムを管理し、大規模な分散システムの稼働状態を管理することは、言うは易く行うは難しの典型だ”、と彼は説明する。彼によると、OrlyAtomicsの連中が、これまでのMesosphereに欠けていたユニークな、そして願ってもないスキルセットを持参してくれたのだ。同社はOrlyAtomicsの知財をひとかけらも買い上げていないが、いずれにしてもオープンソースだから必要ならGitHubにアクセスすればよい。OrlyAtomicsのCEOだったPatrick Reillyは、いずれは同社の技術をMesosphereに合体させたい、と言っている。それはもちろん、データベースのプロジェクトを、という意味ではない。

“自分たちが築いてきたグラフストレージというビジョンには、今でも愛着がある。グラフデータベースによって人びとは、新しいクリエイティブなデータの利用方法に目覚めるだろう。これからはデータベースを作るのではなく、そういう機能をAPI的なプリミティブ集合として作っていく。もちろん、OrlyのオープンソースデータベースをMesosの上で動かしてみたいけどね”、とReillyは語る。

いずれにしても、Leibertによれば、Mesosphereにとって関心があるのはOrlyAtomicsの既存のプロダクトではなく、彼ら独特の技術能力と、彼らとの今後の協働関係だ。“プロダクトはそのままうちで利用できるものではない。むしろ貴重なのは、彼らがそれらを作りながら獲得した専門的知識と技術だ。それは巨大な分散システムが陥りがちな無秩序状態をすっきりまとめることに、関係がある”、とLeibertは言う。

どちらもC++で書かれているので、MesosphereとしてはOrlyAtomicsのチームがこれまでの経験から獲得した技能をMesosphereのプロダクトに持ち込んでくれることを期待している。Leibert曰く、“彼らはレイテンシを抑えスループットを上げることに邁進してきた。うちが大規模分散システムで実現したいと思っている価値も、まさにそれだ”。

Reillyのチームにとっても、魅力はそこにあった。彼曰く、“C++はパフォーマンスが高いから好きだ。Mesosに来てから最初のほんの数時間で、OrlyとMesosのコードを合体させると良さそうなところを、何箇所も見つけた。アプリケーションが何千もの専用コンテナに分散していて、それらが数十箇所ものデータセンターにまたがって動き、しかもそれらの全体がまるで一台の大きなコンピュータへと癒合しているようなMesosphereの世界は、すごくエキサイティングだ”。

LeibertがOrlyとの交渉を始めたのは4週間前だが、でも彼らは過去にすでに数週間、Mesosphereで仕事をした経験があるので、決心も早かった。Mesosphereの社員はわずか27名と少ないので、新しい社員を入れるにしても、相性がきわめて重要だった。

Mesosphereの社員たちは、一般の新入社員の場合と同じようにOrlyのチームを評価し、うまくやっていける、と判断した。

一方Reillyのチームは、Mesosphereのプロジェクトの大きさに感動し、また自分たちがそこに持ち込める貢献にもわくわくしていた。Reillyは曰く、“技術者はチャレンジすることが好きだが、大きな、そして複数のデータセンターの集まりを一台のコンピュータと見立てて、それのオペレーティングシステムを作るなんて、とてつもなくすごい。Mesosphereのコードベースを調べ始めてすぐに、そこがまるで自分の家のように感じた”。

Mesosphereから見ると、Orlyには同社の長期的な目標の実現に欠かせないものがある。“データセンターのためのオペレーティングシステム、という抽象を構築していくためには、データのコーディネーションが何よりも重要だ。彼らは、まさにそれをやっていたのだ”、とLeibertは語る。

オープンソースプロジェクトOrlyAtomicsは、ソーシャルディスカバリサイトTaggedで生まれた。後者は今、全世界に3億3000万のユーザがいるといわれる。Taggedはある時点で、データの大規模なスケーラビリティを実現するためのソリューションが必要になり、そこからOrlyAtomicsが生まれた。それはまさに、今のMesosphereが必要としているものだった。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


DockerがシリーズCで$40Mを調達、実際に使うのは来年再来年という絶好調の余裕

今ホットなDockerは、どれぐらいホットなのか? あまりにもホットなので、VCたちは同社が今使う予定のない資金までも、あげちゃうのだ。今日(米国時間9/16)同社が発表した4000万ドルの資金調達も、CEOのBen Golubによると、その金に手を付けるのは早くて来年の終わりごろだそうだ。

というか、細身で経営効率の高い同社は、今年の初めに獲得した1500万ドルがまだ十分に残っているのだが、でも、くれるというものは断らない主義なのだ。Golubによると、今回の投資によって市場は、同社の安定性と今後の長寿を理解したはずだ、という。

“これを使うのは来年遅くか、または再来年の初めだ。でも手元にこれだけあれば、今年中に思い切ってスケールできるし、市場には、あせって会社を売るつもりはない、という信号を伝えることができる”、と彼は説明する。資金の使い方にも、長期的な視点で臨む、ということだ。

彼曰く、“本物の起業家なら誰でも、最後まで自分でやるつもりで会社を作る。うちは、コミュニティからも投資家からも社員からもしっかりした支持と支援があるから、完全に自力で会社を育てることができる。投資家たちも早めの出口を望んでいない。彼らも、会社の中身をしっかり作っていくことに関心がある”。

同社が資金の賢い使い方をできる理由の一つは、経営がリーン(lean, 痩身, 無駄がなく引き締まっている)であることだ。営業やマーケティングはパートナーたちがやってくれるし、しかも彼らのやることを完全に信頼できる。開発の主力もコミュニティにあり、今やコントリビュータの数が600名に達している。さらに同社のアプリケーションストアにはDockerをラップするアプリケーションが35000本あり、それらの豊富なツールがコアプロダクトを一層充実させている。

こういうコミュニティ依存のやり方ではコントロールが行き届かないことをGolubも認めるが、それでも短所よりは長所の方がずっと大きい。結果について議論するのは、まだ早すぎる。“ある意味でうちは、パートナー営業とコミュニティ開発というモデルの正しい形とその成功事例を作り、そのやり方のリーダーにならなければならない。オープンソースの世界では何もかも自分でコントロールすることはありえないが、でもコミュニティの多様性と圧倒的なパワーが持つメリットは、完全なコントロールができないという小さなデメリットを大きく上回っている”、と彼は説明する。

Docker本体に関しては同社が全コードの80%を作り、筆頭メンテナの役を担っているが、コミュニティがそれに高い付加価値をつけ、また同社の中核的なデベロッパに対して現用チェックを提供している。多用な利用現場からのチェックだから、同社のデベロッパたちがひとりよがりになることが、防がれているのだ。

Golumによると、会社の方向性に対してコミュニティから異議が出たときは、間違っているのはだいたい会社の方だ、という。彼によると、コミュニティは企業内ではやれないようなエッジケース(未実証最先端ケース)にも取り組める。同社の技術者は最小限の数しか確保していないから、社内ではできないほどの大きなスケールでのテストも、コミュニティならできる。

今回のシリーズCのラウンドはSequoia Capitalがリードし、これにBenchmark Capital、Greylock Partners、Insight Ventures、Trinity Ventures、Yahoo!のファウンダJerry Yangらが参加した。Dockerの累積調達額は6500万ドルに達する。Dockerの前身であるdotCloudは、8月にcloudControlに売った

Dockerが作っているのは、現代的なアプリケーションのためのデリバリコンテナだ。Golubが指摘したように、5年前までは、一枚岩的で一台のサーバの上で動くアプリケーションが長年支配していた。しかし今では、それが完全に変わっている。アプリケーションは複数の部位で構成され、それらが多くのサーバに分散し、サーバの所在も頻繁に変化する。Dockerのコンテナは、そういうアプリケーションの各部位を“ドックに収容する”という意味であり、デベロッパたちがそのような分散アプリケーションを作って展開するのに適したツールだ。

Golubによると、それはデベロッパがデベロッパのために作ったプロダクトであり、そのモデルがこれまでのところ効果を発揮している。ユーザとデベロッパがそれぞれ別集団でないこのやり方は、Dockerの現状を見ても、確かに有効なようだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


EucalyptusのCEOの突然のOpenStackへの改宗はHPによる買収が下地だった

先月、長年OpenStackを批判していたEucalyptus *のCEO Mårten Mickosが突然心変わりした。昨日(米国時間9/11)は、彼の会社がHPに買収された。HPは、今年OpenStackで大きく稼ごうとしている企業だ。〔*: Eucalyptus, プライベートクラウドのためのIaaSでAWSのAPIを多用。〕

MickosがOpenStackに対して急に前向きになったのは、まさに、それがあったからだ、としか思えない。

彼は自分の会社のWebサイトのブログで、その心変わりを説明している。彼は、OpenStackと競合することでむしろOpenStackに貢献してきた、とジョークを言っている(初期には実際にOpenStackにコードを貢献している)。しかしMickosは、この爆弾投下(買収発表)の前に、来週シリコンバレーで行われるOpenStackのイベントでキーノートを担当する、と発表した。競合どころか今の彼は、OpenStackプロジェクトに真剣に寄与貢献しようとしているのだ。

Mickosはブログの記事にこう書いている: “私から見てOpenStackは何でもありのクラウドプロジェクトで、大小さまざまなベンダがそれを独自に複雑高度にカスタマイズしたパッケージを作って、展開していくものだ。それらは、〔Eucalyptusのように〕AWSとの互換性が必須要件となるような展開ではない”。

MickosがOpenStackに関して心変わりしたときSteven J Vaughan-Nicholsは自分のブログに、EucalyptusとOpenStackの併存は犬と猫が同じ部屋にいるようなものと書き、長年のオープンソース評論家である彼Vaughan-Nicholsは、Mickosの発言に“ぶったまげた”と言っている。Mickosの会社EucalyptusはOpenStackの宿敵AWSとベッドを共にしている。そんな両者が共存できるわけがない。でもMickosは、共存の道を見つけようとしているのだ。

IaaSとしてのOpenStackはいわば、Amazon Web ServicesやGoogle Cloud、Microsoft Azureなど、パブリッククラウドの強力な商用プロバイダたちの、オープンソース版だ。これらの商用サービスは、細部まで透明というわけにはいかないので、ユーザによってはそのことが問題になる。4年前にRackspaceとNASAが共同して、成長著しい大手パブリッククラウドプロバイダたち(中でもとくにAWS)に対するチェック機能としてOpenStackプロジェクトに着手した。それは完全にオープンソースなので、ITの人たちやデベロッパはコードベースに直接アクセスして、必要なカスタマイズを行える。それは、商用システムではできないことだ。

Mickosの会社はそうではなく、パブリックやプライベートなクラウドからAWSのクラウドへのブリッジを作った。しかし、彼自身資金力はあったが、市場はOpenStackをも含むさまざまな競合勢力に席巻されつつあった。

一方、今年になってHPはOpenStackに転向し、同社のこれまでのCloud OSに代わってHP HelionとOpenStackを主軸に据えることになった。しかもおもしろいことに、Helionへの移行と共にAWS APIのサポートをやめた

というわけで、知らない間に両社(HP, Eucalyptus)は、最初は互いに別の方向を向いてクラウドに取り組んでいたにもかかわらず、今ではOpenStackという共通項で結ばれようとしているのだ。

買収の話はかなり前から進んでいたはずだから、Mickosが突然OpenStackへの改宗を発表したときには、買収をめぐってHPとの会話を重ねていた、と見るのが自然だろう。

いずれにしてもHPはついに買収を決定し、Mickosを同社のクラウド事業部担当のSVPに任命することにした。つまりこれからは、MickosがHPのクラウド戦略の鍵を握る人物になる。HPのクラウドビジネスの今後の吉凶を、彼の手腕が決めるのだ。

企業世界で人気を高めつつあるOpenStackも、相当高度な専門知識および技能がないと実用化できないことが、難点と言われている。そこで先週HPは、OpenStackの実装を楽にしてくれる一連のサービスを発表したが、モバイル開発プラットホームKinveyのCEO Sravish Sridharの説では、HPは今回の買収を活用してOpenStackの実装を単純化するための総合的なシステム(ソフトウェアによるアプライアンス)を作ることもありえる。

“Eucalyptusを買収したことによってHPは、展開と管理の容易なクラウドアプライアンスを作れるプロダクト指向のチームを入手した。それは、OpenStackソフトウェアの弱点と言われていた部分だ”。

OpenStackによるクラウドの構築と展開と管理の面倒を見るサービスでHPは、VMwareやIBM、Red Hatなどなどと競合する。RedHatは最近、OpenStackのテストを容易にできるためのソフトウェアアプライアンスを発表した。たぶん同社はこれを皮切りに、OpenStackとそのまわりの実装を容易化するアプライアンスを次々と出していくつもりだろう。

この買収が表面的には奇妙な仲と見えても、HPの市場奪取努力としてはむしろ、きわめて分かりやすいし、これからも同社は、より魅力的なクラウド製品を提供することによって、競争の激しい市場で優位に立とうとするだろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


オープンソースソフトのバグフィクスにインセンティブを払うサービスシステムGit Bounty

オープンソースのソフトウェアを使っていてバグらしきものに遭遇したけど、自分にはバグフィクスのためにコードを精査しているひまもないし、原作者も今ほかのことで忙しいらしい、というときは、コミュニティの力に頼るしかない。そういうときのために、モントリオールからDisrupt SFのハッカソンに参加したフランス系カナダ人のチーム(一人は本物のフランス人)が考えたGit Bountyは、バグフィクスをやってくれるプログラマにインセンティブを提供する。直してもらいたいバグとお礼の金額を指定して、Git Bountyにポストするのだ。

Git Bountyを作ったAngus MacIsaacとAdam Burvill、Anton Shevchenko、Nathan Boiron、Martin Coulombeの5人は、モントリオールのデベロッパOsedeaで仕事をしている。これのアイデアを思いついたのは、先週の金曜日(米国時間9/5)だった。

“ハッカソンには、なにか有意義で便利なもので参加したかった”、OsedeaのCoulombeは言う。実は最近同社は、いつも使っているオープンソースのフレームワークのバグフィクスを、2000ドル払って第三者にやってもらったことがある。同社のチーム自身がバグフィクスをやると、人と時間を取られすぎて、本来の仕事が遅れてしまうからだ。

Git Bountyの正式ローンチはDisrupt SFの終了後を予定している。Coulombeが言うには、“こういうサービスの需要は十分あると思う。オープンソースのコミュニティがどれだけ利用してくれるか、結果を見たいね”。今後は、バグフィクスだけでなく、新しい機能、‘こういう機能がほしいけどなぁ、自分にはやってるひまがない’機能の実装も、インセンティブの対象にしたい、と。

チームはこのハッカソンに参加したことを機会に、新しいPHPフレームワークLaravelを勉強した。Git Bountyの通知機能にはTwilioのAPIを、支払決済にはStripeを使っている。

長期的には、インセンティブの額から同社がマージンを取ることを考えている。‘取る’というより、Git Bountyという活動への自発的な‘寄付’がいいかな、とCoulombeは言っているが。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


本誌TechCrunchがWordPress用非同期タスクライブラリAsync Taskをオープンソース化

[筆者: Nicolas Vincent, Alex Khadiwala]

2012年に本誌TechCrunchのデベロッパチーム(Nicolas Vincent, Alex Khadiwala, Eric Mann, John Bloch)が、TechCrunchのデザイン変更に取り組んだとき、主な目標のひとつがパフォーマンスの向上だった。その目標を達成するためにわれわれは、開発の一環としていくつかのツールを作った。

われわれが取ったアプローチの一つは、時間を消費するタスクをバックグラウンドのタスクにしてしまうことだった。WordPress(本誌の基幹エンジン)上でバックグラウンドタスクを構成するためのライブラリとして、WP Async Task(WordPress非同期タスク)というものを作った。

今年の6月に”Non-Blocking WordPress“(ノンブロッキングWordPress)と題するプレゼンテーションを行う機会があり、その中でわれわれは、パフォーマンスに対するわれわれのアプローチについて語った。そのときのオーディエンスは、われわれが実装した非同期タスクに大きな関心を示し、コードを入手して自分たちでも使いたい、と言われた。

そこで、本日(米国時間7/31)をもってわれわれは、WP Async TaskライブラリをオープンソースとしてGitHubから提供することにした。われわれは、オープンソースソフトウェアがもたらすパワーの熱烈な信者であり、われわれにこのパブリシングプラットホーム(WordPress)を提供したコミュニティに、お返しをしたいと思う。コードとドキュメンテーションをご覧頂いて、ご自分のコードにおけるこのライブラリの使い方を、ご理解頂きたい。

なぜタスクを非同期にするのか?

ページのロードがブロックされたり、ロードに長時間かかるのを防ぐためには、CPUを競合するプロセスの数を減らしたい。ページロードの長時間のブロックは、ほかのプロセスが、リソースが空く(自分の順番が回ってくる)ことや、何かの操作が終了することを待っているときに、よく起きる。

TechCrunchのサイトでは、企業や人物のデータベースCrunchBaseのカードを、今読まれている記事ページの上にロードするときに、サイトのスピードが鈍化する。そのときはプロセスがCrunchBaseのAPIを呼び出してカードを作ろうとしているからだ。パフォーマンスを上げるためにそれらのデータを約12時間キャッシュしているが、最初にデータを取り出すときや、キャッシュをリフレッシュするときには、そのためのAPI呼び出しがページロード時間に影響を与えないようにしたい。

そこでCrunchBaseからキャッシュにデータを取り出すときには、APIの呼び出しと実行が終了するのを待つのではなく、その処理を非同期のバックグラウンドタスクとして起動する。すでにキャッシュにデータがあるときには、カードでそれを使う。このようにすると、CrunchBaseのカードの表示がページのロードを邪魔しない。

TechCrunchの以前のデザインでは、ページのロードタイムが1ページにつき17秒以上かかることもあった。新しいデザインでは、WP Async Taskライブラリの実装により全体的なパフォーマンスは5倍から8倍は向上した。それには、バックエンドとフロントエンドの両方に対する、そのほかの改良も、大いに貢献している。

下のビデオは、2014年6月にサンフランシスコで行われたBig Media & Enterprise MeetupでプレゼンをやっているNicolasとAlexだ。10upのデベロッパ、John BlochとEric Mannにも感謝申し上げたい。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Adobe、Googleと提携して中国、日本、韓国語用にオープンソースフォントを公開

今日(米国時間7/15)、AdobeGoogleは、中国語、日本語および韓国語(CJK)のオープンソースフォント、6万5535グリフを公開したことを発表した。フォントは、印刷および画面表示のいずれにも最適化されており、Google FontsおよびAdobeのTypekitを通じて無料で利用できる。

両社のマーケティング部門のみが知る理由により、AdobeはこのフォントをSource Han Sansと呼び、GoogleはNoto Sans CJKと呼んでいる。フォントはAdobeのSourceForgeおよびGitHubでも入手可能で、同社は各言語で必要な部分からなるサブセットも提供する予定だ。

フォントは標準で、日本語、繁体字中国語(台湾および香港特別自治区を含む)、簡体字中国語、および韓国語(ハングルシラブル共)を含み、ギリシヤ語、ラテン語およびシシリーアルファベットも提供される。

AdobeとGoogleがオープンソースフォントで協力することについては、やや奇異に感じるかもしれない。Adobeのタイプ責任者、Caleb Belohlavekは、先週私に、両社は4年前からこのプロジェクトを検討していたと話した。汎用CJKフォントは以前からAdobeが作りたかったものであり、Googleも自社のデベロッパーコミュニティーにとって有用だと考えた。Googleにとってはオープンソースであることが必要であり、それはAdobeにとっては必ずしも自然なことではなかったが、当時すでにオープンソースフォントの作業を開始していた。最終的に二社はそれぞれのリソースを提供して、このプロジェクトを立ち上げた。

Belohlavekによると、プロジェクトが立ち上がると、Adobeの在東京シニアデザイナー、西塚涼子がフォントの全体デザインの作業を開始した。それは、Belohlavek曰く「スタイルのシンプルさによって伝統的アジア文字のデザインの持つ優美さを保つ」ものだという。数多くのグリフが4種類の地域バリエーションを持つことを考えると膨大な作業だ。Adobeによると、このフォントは既存のGoogle RobotoとNoto Sansファミリー、およびAdobe自身のラテン文字フォント、Source Sansとよく調和するという。

Adoboeが初期デザインの大半を担当し、Googleはプロジェクトの進行および、日本、中国、韓国の各パートナーに初期デザインを送り、フォントを仕上げる部分を担当した。いずれの言語の文字も、歴史的中国文字に由来しているが、長年の変遷を経て(その多くは微妙な)地域差が生まれており、このフォントにもそれを反映させる必要があった。

Adobeによると、全体で約100名がこのプロジェクトに参加した。フォントには種類のウェイト(太さ)がある。

[原文へ]

(翻訳:Nob Takahashi / facebook


文章と画像と動画だけではパンチが足りないと感じられる情報表現には、CartoDBのOdyssey.jsで対話的な地図を加えてみよう

どんなことにも、それが起きる“場所”があるはずだ。この論理をコンセプトとするオープンソースのツールOdyssey.jsは、地図を利用してデータを対話性のあるマルチメディアに変える。このツールは、プログラミングのスキルのない人でも使える。

Knight Prototype Fundから35000ドルの助成金をもらった、クラウドコンピューティングのプラットホームCartoDBの作者たちは、このオープンソースツールのベータを今日(米国時間7/8)リリースした。

CartoDBは、このツールによってストーリー展開の技法が拡大することを期待している。これまでのように、テキストと写真(〜静止画像)とビデオだけに限定されずに。

Knight Foundationのメディアイノベーション担当Chris Barrによると、この財団が作られたのは1年半前だ。財団の基金は、最新のテクノロジやイノベーションを目指す実験的プロジェクトに交付される。そのペースは1年に約1億ドルで、内3000〜4000万ドルはジャーナリズムとメディアのイノベーション事業へ行く。

Barrはこのプロトタイプファンドのトップでもあり、彼によると、助成金交付のペースを速めることによってジャーナリストやパブリッシャーたちが使う新しいツールを迅速に作っていきたい、という。

“これからの人びとは、毎日自分たちの前に現れる大量の情報やデータを、よりよく理解するためのツールやサービスをますます必要とするだろう”、と彼は語る。

CartoDBは地図作成技術を開発している。たとえば、何かのイベントやブランドについて述べているツイートを、対話性のある地図で視覚化するのだ。たとえばこの地図は、ワールドカップのブラジル/クロアチア戦のときのツイートをを表している。

Barrによると、CartoDBが考えているのは、ストーリーを語ることを地図の利用によってより豊かな体験にすることだ。そこで、テキストをHTML化するツールMarkdownJavaScriptを使い、Knight Foundationから得た資金でOdyssey.jsを作った。

CartoDBのそのツールは、CMSへの埋め込みも容易にできる。だからWordPressなどを利用しているパブリッシャーが対話的な地図を自分のサイトに加えて、ストーリーを展開するのも簡単だ。Odyssey.jsのJavaScriptライブラリは、誰もが自由に利用できる。

その目標は、メディアの大きなイノベーションだ、とBarrは言う。CartoDBの Odyssey.jsライブラリのような新しい表現ツールの登場で、情報の視覚的表現がTIV(text, image, video)という伝統的な三種の神器に縛られなくなり、あらゆるWebサイトは読者を増やし、読者の関心をより強く捉えるようになるだろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Red Hat Enterprise Linux(RHEL) 7.0がリリース、デフォルトで10年保証を提供

Red Hatが今日(米国時間6/10)、同社Linuxディストリビューションの企業向け商用製品Red Hat Enterprise Linux(RHEL)のバージョン7.0をリリースした。その主な特長は、Windowsとの相互運用性、新しいデフォルトのファイルシステム、Dockerによるコンテナ化、そして、今後のすべてのメジャー/マイナーなリリースを対象とする10年間保証だ。

LinuxのカーネルがRHEL 6.xの2.6.32から3.10にアップデートしたことも大きい。調査会社Forresterのインフラとオペレーション担当アナリストRichard Ficheraは、それはRHELの、待ちに待たれていた現代化が目的だ、と言う。

Ficheraは次のように言う: “カーネルを3.xにアップしたことは、SUSEに追いつき追い越す意味でも重要だ。顧客向けにも大量の便利な改良が提供されるだろう”。

Red Hatのマーケティング担当シニアディレクターMark Cogginは、10年保証によって顧客が得られる安定性と安心感も大きい、と語る。これはRed Hatの顧客へのコミットメントの真剣さを表しており、10年保証とはバグフィクスとセキュリティリリースと公式アップデートが今後10年提供される、という意味だ。

また今回のバージョンは、RHELのインストールと管理と展開を容易にすることにも力が注がれ、その一環としてWindows Active Directoryとの相互運用性、スクリプトによってアップグレードの過程を自動化、などの機能が導入された。Cogginは曰く、顧客先のシスアドはニーズの変化を十分に把握してから、それらに合わせてアップグレードのプロセスを進めなければならないが、今回はそのために役に立つ重要なツールをいくつかご提供した、と。カーネルの件も含めて、今回はかなり重要なバージョンアップだ、と彼は強調している。

Ficheraによると、そのために今回は、シスアドの仕事を楽にするという点で大きく進歩したという。“RHEL 7ではインストールが簡単になり、管理のオーバヘッドが下がり、ユーザがすぐに使い始めることのできる既存のRHELからの更新や、ロールバック、それに、“プロファイル”と呼ばれる、用意されたテンプレートからの展開などが導入された。プロファイルでは、各種の構成オプションをワークロードの特性に合わせて指定できる。またインストールが終わると、大幅に改良されたランタイム管理とモニタリングの機能が提供され、ランタイムのパフォーマンスの最適化が図られる。

IDCでサーバとシステムソフトを担当しているAl Gillenは、重要なのはDocker対応化だ、と言う。“今回のリリースからDockerがデフォルトでサポートされたことの意義は大きい。サービスプロバイダや、アプリケーションの複数バージョン間のポータビリティを重視する顧客は、コンテナのサポートをとても便利に感じるだろう。 Red Hatの連中も、それを言っていた”。

デフォルトのファイルシステムが、EXT4からXFSに変わった。ただし、必要に応じてそのほかのファイルシステムもサポートされる。ForresterのFicheraは、この点が重要だと言っている:

“今のLinuxカーネルには、いろんなファイルシステムがある。もっとも多く使われているのが改良版(今では‘4’)のEXTファイルシステム、0.5PBまでの巨大なファイルをサポートするXFS、“Better File System”の頭字語btrfsのベータバージョン、などなど”。

RHELのメジャーアップデートは3年半ぶりだが、顧客のニーズはどこにあったのか。連続性を重視したゆるやかなアップデートが、望まれているのではないか。この点に関してIDCのGillenは、業界は二分している、と言った:

“Amazon Web ServicesやMicrosoft Azure、Google App Engineなどのプラットホームは利用の連続性を保証しつつアップデートを行わざるをえない。これに対して古典的なITショップは、何をいつどのようにアップグレードするかを個別にいちいち自分で意思決定する。どちらを採るか。今業界は、その分岐点に来ていると思う”。

彼の説では、今でも後者のやり方を必要とする企業はある。とくに、政府などの厳しい規制下にある業種の場合だ。Red HatのCogginによると、同社はアップデートの配布方法について検討しているが、顧客自身が具体的な要望を持っている場合も多い、と言う。

“うちは商用Linuxのマーケットリーダーで、大量の顧客がリリースの一定のリズムやライフサイクルを暗黙裡に期待している。ただし、そのライフサイクルの内容的な意味を、われわれベンダとしてはしっかり見定める必要がある”。同社はすでに、頻繁なリリースを必要とする企業には特殊なソフトウェアやツールセットを提供しているが、しかし大半の顧客は安定性を重視している。同社としては、両方のタイプのアップグレードパスを提供しなければならない、とCogginは言う。

Cogginによると、RHEL 7のベータに参加した顧客は1万弱だった。そして、とくに熱心だった60社からは、今後も継続的にフィードバックをいただいていく予定だ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))
 


Dockerがついにv1.0に、サポートとドキュメンテーション完備で本格商用化へ

Dockerプラットホームを支える企業Docker, Incが今日、同社主催のカンファレンスDockercon14で、Docker 1.0のリリースと“Docker化”されたプロダクトのためのマーケットプレイスを発表した。

CEOのBen Golubによると、これらの発表は同社のこれまでの15か月にわたる集中的な開発努力の成果だ。Golubの説明によると、1.0は初めての、商用サポートとドキュメンテーションが完備したプロダクションクォリティーのバージョンである。彼曰く、これまでは多くの人たちが0.xバージョンの開発に従事してきたが、これからはコミュニティサポートではなく商用サポートがつくので、銀行などの保守的な企業でも安心してDockerを利用できる。

Docker 1.0はGoogleが開発した新しいコンテナ技術の実装系の一つで、アプリケーションを、これまでのように変更を加えたり、開発サイクルの新しいステージに入るたびに、まったく新たな再インストールや再構成を必要とせず、安全に配布できる。

これまではデベロッパと運用者(ユーザ、オペレーション側)は利害が相反していた。デベロッパは必要に応じて変更を加えたいし、運用者は安定性を欲する。しかし変更を加えたことによって、他の部分や構成要件などが変わって、オペレーションサイドを悩ませることが多かった。

“Dockerは、この面倒な問題でデベロッパを救った”、と彼は言う。“それと同時に、アドミンの苦労もなくなった。DevとOpsの両方がハッピーになった”。

彼の説明では、Docker 1.0ではデベロッパはラップトップの上でボタンを一つ押すだけであり、プロダクションや、ステージング、顧客環境の側では、すべてが従来どおりに動く。デベロッパが開発ワークフローの次のステップに移って何かを変えても、プログラムを壊したり、問題の原因究明に苦労することがない。

すなわちプログラムをDockerのコンテナに安全に収めることによって、デベロッパがその内部を変えても外側の状態は前と変わらない。

また、Docker 1.0と併せて発表されたDocker Hubは、デベロッパが“Docker化”されたアプリケーションを見つけたり発表する場だ。Docker化アプリケーションとは、Dockerを使って動かすように調整されているアプリケーション、という意味だ。このハブでデベロッパは、ほかのデベロッパとコラボレーションすることができるし、また、Dockerのメンテなたちに会うことができる。ここに寄与貢献されるものを、メンテナたちがフィルタして、特定のジョブやプラットホームに合ったものを見つけるのだ。

Golubが言うには、オープンソースで行くなら全身でその世界に浸らないとだめだ。今では社員35名(+1匹の亀さん) を450名のデベロッパのコミュニティが支え、Dockerの開発や、カンファレンスの開催に尽力している。始まってからまだわずか15か月なのに。

このコミュニティ集団こそが、DokcerプロダクトとDocker Hubのメンテナンスの中心的な力であり、彼らがあらゆるコンテンツのクォリティーをたえずチェックしている。また、彼らの寄与貢献に悪い部分があれば、市場から叱声が返ってくる。

カンファレンスについては、Golub曰く、たった二つの新製品だから、カンファレンスなんかたいしたことない、と最初は考えていた。でも日程を決めて実際に準備を初めてみると、すごい大仕事であることが分かった。“最初は、カンファレンスはいいアイデアだと思ったんだけどね”、と彼はジョークを言う。

数からいえば、大成功だった。最初は500名を予定していたが、先週金曜日には急遽100名追加し、それでも、チケットにあぶれた人が400名以上いた。

講演者はGoogle、IBM、Rackspace、Red Hatなど大物企業の人たちばかり。Wired誌は、GoogleがDockerに深くコミットしていると報じ、GooglerのEric Brewerが二日目に行ったスピーチは、Dockerの知名度と関心を大きく高めただろう。

最近同社は、シリーズBで1500万ドルを獲得した。本誌TechCrunchの記事によると、そのラウンドを仕切ったのはGreylock Partnersだ。参加した投資家はInsight Venture Partners のほかに既存の投資家Benchmark CapitalTrinity Venturesだ。なお、Yahoo!のファウンダJerry Yangも、初期に同社に投資している。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Red HatがCephベースのストレージサービスInktankを買収, ビッグデータ時代の超巨大クラウドストレージでトップをねらう

オープンソースソフトウェアのプロバイダRed Hatが、ストレージの市場でAmazonなどと張り合う気のようだ。同社は今日(米国時間4/30)、オープンソースのストレージシステムを開発しているInktankをキャッシュ1億7500万ドルで買収する、と発表した。Red Hatによると、同社はInktankの主製品であるInktank Ceph Enterpriseと同社のGlusterFSによるストレージ製品を併合させる、そして今回の買収により同社は、オブジェクトやブロック、ファイルシステムといった多様な高レベルのストレージシステムを支えるオープンなソフトウェア定義ストレージの、最大のプロバイダになる。

Red HatのEVPでCTOのBrian Stevensは、声明文の中で次のように述べている: “Inktankが作り上げたきわめて活気あるコミュニティを今後も尊重し、ソフトウェア定義ストレージのデファクトのチョイスをよりオープンにしていく仕事に、共に取り組んでいきたい。Inktankは、Cephを軸とする強力なエコシステムを組み立てるという、すばらしい仕事を成し遂げた。今後われわれは彼らと一緒になって、この成功をさらに拡大していきたい。これらの強力でワールドクラスのオープンストレージ技術は、顧客がソフトウェアベースの、スケールアウト*可能なストレージシステムに移行していくときに、無視することのできない能力をを提供するだろう”。〔*: scale-out, 分散化による規模拡大。〕

これは、公開企業であるRed Hatの9つめの買収だ。これまでで最大の買収はミドルウェアのベンダJBossを4億2000万ドルで買ったときだが、Inktankはこれに次ぐ。そのほか、オンラインストレージのGluster、1億3600万ドルも、大きな買収だった。Glusterは、Red Hatの現在のストレージサービスのベースになっていると思われる。

Ceph EnterpriseのベースであるCephは、レガシーのストレージシステムをリプレースするものとして開発されたが、実際にはAmazon S3など既存のストレージサービスに代わるもの、あるいはそれらと競合するものとも見られている。AmazonのS3やElastic Block Storageなどのように、各種のオプションを通じてユーザが構成を決めるのではなく、Cephではサービスプロバイダや企業などのユーザが独自のストレージシステムを組み立てられる。Cephのねらいは、エクサバイト級あるいはそれ以上の巨大なストレージシステム/ファイルシステムを、高いコスト効率で提供することにある。

Inktankの顧客はCisco、CERN、Deutsche Telekomなどで、パートナーはDell、Alcatel-Lucentなどだ。今後彼らは、Red Hatの顧客およびパートナーとしてCeph Enterpriseとの関係を持続する。

サンフランシスコに本社を置くInktankは、2012年の創業以来、およそ1440万ドルの資金を獲得してきた。主な投資家は、(Ubuntuの)CanonicalのファウンダMark ShuttleworthとクラウドホスティングDreamHostのオーナー企業New Dream Networkだ。後者の協同ファウンダSage Weil(Cephのデベロッパの一人)が、InktankのファウンダでCTOだ。

今回の買収によってInktankの主製品がRed HatのRHELなどと最初からセットになって売られる可能性が生じるため、Inktankにとっては大きな成長の機会になる。〔*: Ceph本体は最近のLinuxカーネルにデフォルトで含まれている。〕

Weilは、声明文の中で次のように述べている: “Red Hatとわれわれは、かねてから、オープンソースとオープンスタンダードと顧客の成功へのコミットメントを共有している。この二者がこのたび合体したことは、きわめてエキサイティングな事件である。われわれのオープンストレージテクノロジは、これからのクラウドコンピューティングの時代におけるデータ管理業務にとって、必須の技術になると確信している。Red Hatとの協働により、さらに重要なイノベーションを推進できるようになり、業界全体に大きな貢献を果たしていけるものと信ずる。とくに、OpenStackのような既存及び近未来のデータセンターのアーキテクチャが、オープンストレージのソリューションを統合していくことは確実であり、われわれはその需要にお応えしていきたい”。

Cephという奇妙な名前は、同社の注記によれば、ペットの蛸(たこ)のニックネームだ。社名やプロダクト名は、そこから派生している:

“Ceph”は、ペットの蛸、すなわちcephalopod(頭足動物)によくつけられる名前だ。Cephは最初、弊社のCTO Sage Weilの、UC Santa Cruz(カリフォルニア大学サンタクルーズ校)における博士論文のためのプロジェクトとして始められた。UCSCには前から、Sammyという名のウミウシのペットがいたが、蛸も軟体動物として、大人気のSammyの仲間である。蛸は複数の足を高度に並列で動かすことができるので、このプロジェクトの名前としても合っていた。そしてCephのプロダクトを作っていく企業を作ったときには、蛸が出す“インク”にあやかって、その社名をInktankとした。いわばわれわれInktankの社員一人々々は、Cephが放出するインクの一滴のようなものである。

買収の完了は、2014年5月と予定されている。

画像: Flickr

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


人気のHTML5 UIライブラリKendo UIがそのほとんどをオープンソース化

人気のUIライブラリKendoを作っているTelerikが今週、Kendo UIのツールとJavaScriptフレームワーク機能の大半をオープンソースにする、と発表した。その新たなパッケージKendo UI CoreはApache 2.0のライセンスでリリースされ、デベロッパはそれの商用利用と非商用利用の両方ができる。

Kendo UIのよく使われる機能のうち、grideditorstock chartsなどの図形化ツールは従来どおり商用ライセンスの下に置かれるので、Kendo UI Coreに含まれるのはKendo UIの全機能の約75%である。

それでもCoreには38のUIウィジェットが含まれ、Kendo UI Mobileもすべてあるので、ハイブリッドのモバイルアプリも作れる。また、テンプレート、データバインディング、入力検証など主なフレームワークはすべて含まれる。カラーピッカー、オートコンプリート、カレンダーなどのウィジェットもある。ライブラリはBootstrapと密に統合化され、UIウィジェットはAngularJSなど、多くの人気ライブラリとそのまま併用できる。

TelerikのKendo UI担当プロマネBrandon Satromによると、もっぱら企業が使っているツールの一部は手元に置くことにした。それらは今、同社の技術努力の多くが投じられている製品群でもある。

彼は曰く、“デベロッパのみなさんに、お返しをしたいんだ。HTML5の普及が今では相当進んでいるから、デベロッパには第一級のツールセットをご提供したい。ほかの企業がよくやるような、寿命の尽きかけた製品のオープンソース化ではない”。

今後Kendo UIのチームは、コミュニティからの貢献を受け入れていく。すでにGitHub上には、提案やバグの報告を受け付けるためのリポジトリをセットアップした。

Satromによると、同社は今回の動きをこれまでずっと検討していた。過去に、制約のきついGPLライセンスで公開したKendo UIの機能もある。しかしこの企画をもっと前進させるためには、幅広いツールをより緩やかなライセンスで公開すべき、という結論に達したのだ。

 

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Box、PyConに併せて社内資産のオープンソース化を行う「Box Open Source」を展開中

Boxが公開したBox Open Sourceはすでにチェック済みだろうか。Box内部で活用されていたオープンソース系ツールを、外部の開発者とシェアしようとするものだ。

この試みについてはBoxのブログにも記事が掲載されていて、CEOであるAaron Levieのツイートにて明らかにされた。

共同電話インタビューの席では、Levieおよびテクニカルオペレーション部門のプリンシパルディベロッパーであるBenjamin VanEveryがプロジェクトについての説明を行っていた。曰く、Box Open Sourceに公開したツール群はBoxが開発して何年も利用してきたものであるとのこと。「私たちがBoxで利用してきたツール群で、ぜひいろいろなご意見なども頂きたいと思っています」とVanEveryは言っている。「私たちのメインプロダクトで利用しているものを移植したものもありますし、いつか公開できるようにしようということで開発した便利ツールなども登録しています」。

自社開発のコードをオープンソース化するというのは、Facebook、Microsoft、Google、Netflixなども行っている。オープンソース化することについては2つの目的がある。ひとつは、良質のプロダクトを外部に公開することで、オープンソース文化に寄与しようとする側面だ。そしてその裏面として、外部からの有益なフィードバックが得て、企業としての利益にもつながることもある。

VanEveryによれば、Box Open Sourceは厳格な品質管理基準を採用しており、動作についての確認もしっかり行っているものばかりであるとのこと。細かいテストを経たプロダクトのみを公開しており、品質基準に見合ったテストを経ていないプルリクエストに応じることはないとのこと。「コードの品質を保つために、継続的にビルドの更新も行っていきます」ということだ。

Box Open Sourceのサイトを開いてみると、RotUnicodeFlakyなど、Pythonのプロジェクトが先頭に配置されている。実はBox Open Sourceは、モントリオールで開催されているPyConというプログラミングカンファレンスにあわせて公開されたもので、Pythonを強調するのはその関係もあってのことだ。

今後も、いろいろな言語を使ったツール類を公開していく予定にしているとのこと。「より大きな展開をしていくための、最初の一歩であるととらえていただいて良いと思います。私たちの持つ技術をオープンソース界に提供していくことで、相互に発展していければと考えています」とLevieは述べている。

原文へ

(翻訳:Maeda, H


Red Hat Enterprise Linuxのユーザはインストールをパブリッククラウド(Google Compute Engineなど)に自由に移せる

[筆者: Ron Miller]

Red Hatの本日(米国時間4/7)の発表によると、Red Hat Enterprise Linuxの顧客は、その利用権をGoogle Compute Engineなどのクラウドサービス上に移せる。そしてこれはRed HatとGoogle両社にとって有利な措置となる。

Red Hatが提供している“利用権移動(bring your own subscription)”プランにより、Red Hat Linuxのユーザはオンプレミスのインストールを、Google Compute Engineなど、Red Hatが承認しているクラウドベンダのパブリッククラウドへ移せる。

GCEなどへの移動にはRed Hatが提供しているツールを使用し、ユーザは今後もRed Hatのサポートを引き続き受けられる。ただしその場合、対象は単一のベンダでなければならない(複数のベンダがからむ問題はノー)。複数のベンダがからむと、問題の原因の同定などが困難になるからだ。

Google Cloud PlatformのプロダクトマネージャMartin Buhrは、今回の措置を、Googleのプラットホームの評価が定着した証(あかし)と見ている。“Red Hatの発表は、Googleのクラウドプラットホームへの信頼の表れだ。とくに、エンタプライズアプリケーションの展開に適したプラットホームと見なされている。これまでも、RHELをGCEの上で展開したいというリクエストは多かった。うちがこのプログラムに含まれる二番目のクラウドプロバイダであったことを、嬉しく思っている”、とBuhrは語った*。〔*: 利用権移動(bring your own subscription)”プラン承認プロバイダ)、(日本語ページプロバイダリスト)。〕

Red Hatにとってこのプログラムは、展開の仕方を各社自由にする、という方針の表れだ。各顧客の要件に応じて、物理的な展開(オンプレミス)と仮想(クラウド)のどちらでも認め、また両者の混成も認めていく。

Red Hatのクラウド部長Mike Ferrisによると、これによりエンタプライズユーザがパブリッククラウドを使いやすくなる。

彼はこう言う、“コンピューティングとネットワーキングとストレージとマネージメントの技術革新により、Google Compute Engineのようなエンタプライズ級の大規模なクラウドサービスが可能になった。顧客のビジネスニーズやオペレーションのニーズに柔軟に対応していくためには、オンプレミスとオフプレミスの臨機応変な使い分けが可能な環境を提供していかなければならない”。

オープンソース方面の長年の常連ライターSteven J. Vaughan-Nicholsは、これは両社にとって得だ、と言う。“Red Hatは今後ますますRHELのクラウド顧客を増やしたいし、GoogleはGCEの企業ユーザを増やしたい。これは、オープンソースの天国で結ばれた結婚だ”。

GoogleがRed Hatの認定クラウドプロバイダ事業に参加したのは、Google Compute Engineが一般公開される1か月前だった。先月末にGoogleは、AWS対抗策として、サービスの大幅値下げに踏み切った。

画像: Flickr/Karen Ka Ying Wong; CC BY-SA 2.0のライセンスによる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


CitusDBがPostgreSQL用の列取り出しツールをオープンソースで提供開始, 複雑なクェリの効率をアップ

[筆者: Ron Miller]

Oracleなどの大型旧勢力に対抗するデータベース分析サービスのCitusDBが、PostgreSQL用の初の列保存(columnar store)エクステンションCSTOREをリリースした。今日(米国時間4/3)から、無料でダウンロードできる。

“データをバッチでロードするときは、列保存が分析作業を大いに助ける”、と同社のブログ記事が言っている。つまり、このツールを使うとデータベースの利用パフォーマンスが上がる。CitusDBによると、クェリの効率は2倍アップ、データリードに要する時間は従来の1/10になる。同社のCEO Umur Cubukcuによると、分析クェリは高度な最適化によってさらに効率がアップし、また圧縮率も上がるためにストレージの費用も削減される。

“列保存は標準のPostgreSQLユーザは単一ノードで利用でき、またCitusDBの顧客はペタバイトのオーダーにスケールアウトしたPostgreSQLでも可利用である”、とCubukcuは説明する。CitusDBのプロダクトは後者が対象だが、ユーザはそれぞれ、自分の規模に合わせてこの新しいツールを利用できる。

Cubukcuによると、このツールは二つのアドバンテージを提供する。ひとつは、同じデータベースを利用目的によって、行ベースでも列ベースでも扱える。第二は、PostgreSQLの信頼性の高いエンタプライズ機能とHadoopのスケーラビリティを融合させるCitus Dataの方式を、最大限に有効利用できる。したがって全世界のビッグデータ分析を行う顧客に、シンプルで強力なデータベースを提供できる。〔社名はCitus Data、プロダクト名がCitusDB。〕

CitusDBは今年の2月の終わりに、そのコアプロダクトのバージョン3.0をリリースした。

同社はY Combinatorの2011年の卒業生で、2012年6月にそのプロダクトのバージョン1.0をリリースした。Alex Williamsは2013年2月の本誌記事で、次のように述べている: “CitusDBはGoogleのリアルタイムデータベース分析クェリシステムDremelを使用している。データベースに対するリアルタイムの対話的分析能力では、Hadoopの分析機能より優れている。その違いの主因は、並列コンピューティングの有効利用とSQL的な機能性にある。数千台のサーバ上に分散している数ペタバイトものデータに対するクェリとその結果の受領を、リアルタイムで行える”

CitusDBはこれまで、Data Collective、Bullpen Capital、SV Angel、Trinity Ventures、そして業界の指導的立場にあるエンジェルたちから165万ドルを調達している。顧客は、広告技術、eコマース、リテイル、セキュリティ、モバイルのアクセス分析など、多様な業種にわたっている。

この新しいツールは今日からGitHubで入手できるが、同社はコミュニティによる今後の改良や新機能の付加を期待している。

画像: Flickr/tec_estromberg; CC BY 2.0のライセンスによる license

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


誰もが容易に対話的学習コースを作れるGoogleのOppia, 完全オープンソース(拡張自由)でローンチ

Googleはこのところますます、教育の世界に手を伸ばしてきた。中でもとくに同社は、テクノロジが学習の方法をどう変えるのか、ということの探究に関心があるようだ。Google Play for EducationGoogle Playを統合したSamsungのAndroidタブレットで学校の教室に進出し、またMOOCなどのオンライン学習コースを立ち上げるなど、本格的な高等教育の分野にも手を出し始めている。

今日(米国時間2/26)のGoogleは、初等統計学を一般大衆に教えるMOOCコースと並ぶ、教育分野の第二の実験も開始している。Googleのオープンソース関連のブログ記事によると、その実験プロジェクトはOppiaと呼ばれ*、“誰もがオンラインの対話的な活動の場を容易に立ち上げることができて”、そこからほかの人たちが学べるようにすること、を目標としている。要するに、MOOCなどの既製の学習コースを提供するのではなくて、誰もが簡単に利用できる学習コース開設サービスを提供するのだ。〔*: Oppia, フィンランド語で「学ぶ」。〕

Googleの説明によると、Oppiaプロジェクトを立ち上げた動機は、たしかに今ではビデオやSMSなどで配布される教育コンテンツの量は増えているものの、その多くが静的で非同期(ノン・リアルタイム)であることだ。つまり講義をそのままデジタル化~オンライン化しても、インターネットが得意とする対話的諸活動やコミュニケーション、フィードバックなどの機能はまったく生かされない。

Googleがオープンソースで開始するこのプロジェクトのねらいは、Googleが提供するフレームワークの上で誰もが…デベロッパでない人でも…簡単迅速に対話的な学習体験を開設提供でき、それがGoogleのコンテンツ資産にもなることだ。また同時に教師たち、教える立場の人たちは、このサービスを自主的創造的に利用することによって、‘テクノロジに自分の仕事を奪われる’という不安や恐怖から完全に免れることができる。

つまりOppiaが提供しようとしているのは、人と人(eg.教師と生徒)とのリアルタイムの対話性をしっかりと温存したオンライン学習、それを、誰もが実現展開できるためのフレームワークだ。それにより、それぞれの生徒個体の特性に合わせた教え方が可能になる。GoogleはOppiaを説明する文の中で、これまでのオンライン教育は人を海辺の釣り場まで連れていくことはできるが、Oppiaはその“コンピュータの力を生かし個人化されたフィードバックシステム”により、人に実際に魚の釣り方を教えることができる、と述べている。

そのシステムは学習の過程で、対話(フィードバックや質問など)の進行の中から、その特定の学習者に関するデータを集め、それに基づいて教え方や教材の構成などを柔軟に調整する。また、教師が出した問題に学習者が答を提供した場合でも、システムが自動的に正解を教えたり間違いを指摘したりはしない。人間教師と生徒とのあいだの、重要な対話性の契機を、システムが奪い取ることはしないのだ。

生徒が犯した間違いの性質を把握して、それらに個別に適切に対応していくことは、あくまでも教師の仕事だ。Oppiaは、教師と生徒とのあいだの、そういうフィードバックのやりとりを、便利な入力インタフェイスなどで支援し、両者間のコミュニケーションを円滑に、そして迅速にできるようにする。

またOppiaが教師と生徒に提供する入出力インタフェイスの構造など、フレームワークとしてのOppiaのアーキテクチャは、完全にオープンソースなので、今後開発に参加してくるデベロッパが…教える側学ぶ側のニーズに対応して…自由に拡張できる*。そしてOppia上でユーザが作り、拡張改造していくレッスンは、ほかのWebページに埋め込むことができる。埋め込みはレッスンの特定のバージョンを参照するので、そのページのユーザがレッスンの将来のバージョンに惑わされることはない。そうやって複数のバージョンを保存できることは、教える側にとっても便利だ。〔*: たぶん科目の違い…外国語学習、初等電子工学、etc.…や、教師の考え方や個性で、構成を自由に変えられた方が、ありがたいだろう。〕

また、個々の教師が孤立することなく、レッスンの作成や変更に関してほかの人たちとコラボレーションできる。バージョンコントロールの仕組みもあり、また学習者にいろんなパラメータを結びつけて、より詳細で深い対話的な学習体験を作ることも可能だ。しかもOppiaにはすでに、応答性の優れたモバイル用のUIも用意されている。

Oppiaの場合おもしろいのは、Googleのプロダクトではない、とGoogle自身が明言していることだ。完全なオープンソースをベースとして、今後いろんなデベロッパやユーザの手によって、多様な形で作られていくもの、とGoogleは位置づけている。メンテナンスも当然、各コミュニティがやっていく。その方がむしろ、オンライン学習~オンライン教育の、あるべき姿かもしれない。静的固定的なものが最初からがっちりとあるよりは。

いずれにしても、完成されたプロダクトではなく、人びとが今後その上で教育/学習という名の多様なレッスンプロダクトを作っていくためのフレームワークであり、プラットホームでもあるOppiaは、今後実際にそれがどう使われていくかで評価が決まる。学習ツールではなく学習ツールを作っていくためのツールだから、可能性としてはものすごく広い層のユーザに対応する。個人だけでなく、企業や団体も利用したいだろう。そういった広い層の、文字通り誰もが有効にOppiaを利用できるために、Googleにはドキュメンテーションを多様に充実させてほしい、と願いたい。

Oppiaのホームページがここにある。説明のためのYouTubeビデオもある:

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Sonatypeのコンポーネントライフサイクル管理プラットホームがアップデート; オープンソースコンポーネントの安全な利用を促進

ソフトウェアのコンポーネントは、アプリケーション開発の重要な要素だ。今では、アプリケーションの中心的機能はデベロッパ自身が書くよりも既製のコンポーネントを使うことが圧倒的に多く、それらは何千ものソースから提供されている。でもそれは、損壊や改悪の被害に遭うことがある。たとえば昨年の夏には、中国のハッカーがStruts脆弱性を悪用した。StrutsはJavaでWebアプリケーションを作るためのオープンソースのフレームワークだが、長年その開発とメンテナンスを担当してきたApache Foundationは最近、それを手離すと発表した。今後サポートを引き継ぐところが現れなければ、このフレームワークの寿命は尽きたことになる。

こういった問題をなくすために、Sonatypeは同社のコンポーネントライフサイクル管理(CLM)技術をアップデートして、デベロッパが悪質なオープンソースのコンポーネントを使うことを防ごうとしている。粗悪なコンポーネントは、携帯電話にも、車にも、心臓のモニタにも、何にでも使われる可能性があるのだ。Sonatypeの技術は、コンポーネントの品質をソフトウェアのデベロッパに対して保証するために、一連のポリシーの強制過程を自動化する。

Sonatypeを利用すると、ソフトウェアの欠陥がそのソフトウェアの開発ライフサイクルの中で強制的に修復され、Strutsがハックされたときに露呈したような欠陥が、もっと早めに見つかるようになる。

ニューバージョンに導入された新しい機能として、デベロッパに対する通知項目の目録がある。それらは、セキュリティのリスク、古い版を使っている、ライセンスを更新していない、などなどの問題点のリストだ。使っているコンポーネントを、より安全なバージョンにリプレースさせる機能もある。CEOのWayne Jacksonは、とりわけ重要なのは、ソフトウェアに統合されているコンポーネントを同定する能力だ、と言っている(何の何版が使われているか…)。

Sonatypeはまた、著名なセキュリティエキスパートJosh CormanをCTOに迎えた、と発表した。Cormanはこれまで、451 ResearchやAkamai、IBMなどで仕事をしてきた人物だが、Sonatypeでは彼の得意分野である防御的インフラストラクチャや、アプリケーションのセキュリティ、物のインターネット(IoT)における脆弱性潰しなどが役に立つだろう、と言っている。“接続”が普遍的なキーワードとなっている今日の世界では、予防的防御的アプローチがますます重要になる。あらゆるものがあらゆるものと接続されているコンピューティングとネットワーキングの世界では、そういうすべての接続先を管理し制御することは不可能だからだ。しかもITの成長の速度に、セキュリティ技術の進歩が追いついていない。彼は最近(12月)のTEDの講演でも、この点を指摘している:

オープンソースのソフトウェアコンポーネントにも危険が潜んでいる、というと、要らざるFUDをまき散らすことになるだろうか? そんなことはない。むしろそれは、危機が生じてから対応するというこれまでの姿勢を、前もってセキュリティの脆弱性の悪用を予防しておくという、ディフェンシブな姿勢および考え方に、変えていくだろう。

[画像: Shutterstock]

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Google、Monotypeとの提携によりWeb Fontsをデスクトップ用にも提供開始

GoogleのオープンソースWeb Fontsコレクションが、デスクトップでも利用できるようになっている(MacおよびWindows)。「どういうことなのだ」と混乱する方もいらっしゃることだろう。Web Fontsとはそもそも、ウェブ上で自由にいろいろなフォントを利用できるようにするために用意されたものだ。デスクトップで利用できるもなにも、既にきちんと表示されるようになっているはずだ。ただ、表示の際にはフォントのデータをダウンロードする必要があった。これを予め手元にダウンロードしておけば時間の短縮になるというわけだ。

今回の機能実装にあたりGoogleは、フォントビジネスを展開しているMonotypeSkyFontsというツールを利用している。これを利用することにより、いったんダウンロードしたフォントに新たな文字が加わったり、何かしらの変更が加わった際には自動的に反映されるようになるのだそうだ。

GoogleがWeb Fontsの提供を開始したのは2011年のことだった。現在では620以上のフォントファミリーが利用できるようになっている。そして今回のサービス実装により、提供Web Fontsの全てがデスクトップでも利用できるようになったわけだ。ちなみにWeb Fonts提供開始時の目的は、使いたいフォントを利用するのに、Flashを使ったり、あるいは画像ファイルとしてページに埋め込むような方法から、デザイナーを解放しようということだった。そうすることで、タイポグラフィーの観点からも面白いページを作れるようにしようとしたわけだ。

もちろんこうした取り組みを行なっているのはGoogleだけではない。たとえばAdobeもTypeKitというフリーミアムモデルで同様の仕組みを提供している。またEdge Web Fontsでは、フリーでオープンソースのフォントを提供してもいる。

また今回、Googleがデスクトップ向けに提供し始めたフォントも、自分でダウンロードしてインストールすれば、デスクトップでも利用可能ではあった。

原文へ

(翻訳:Maeda, H)


フリーソフトウェア運動はどこで方向性を間違えたのか(そしてその修正方法)

ぼくの視野では、テク産業の過去10年における最大の変化は、ソーシャルメディアでもなければクラウドコンピューティングでもビッグデータでもITの消費者化でもなく、モバイルですらない。それは、業界の主流部分によるオープンソースの受容だ。それまでは、わずか10年前ですら、オープンソースは疑問視されていた。当時は、“オープンvs.プロプライエタリ”という議論が、あちこちの会議やパーティーで噴出していた。ベンダたちは、オープンソースに関するFUDをばらまいていた。しかし今では、あらゆるベンダが自分を“オープン”と呼びたがる。

なぜそうなったのか? ライターのEvgeny Morozovは、最近The Bafflerに寄稿した長文の中で、それをTim O’Reillyのメディア/カンファレンス帝国のせいだ、と言っている。

Morozovによると、O’ReillyはRichard Stallmanのフリーソフトウェア運動をハイジャックして、それを、より企業フレンドリーなオープンソース運動に変えた。そこからさらにO’Reillyは歩を進めて、Webの自由を、Googleのような企業がオンラインで好き勝手ができることへと定義変えし、オープンガバメントを政府に透明性と説明責任を持たせる運動ではなく、営利企業に無料で自由にデータ集合を与えることの必要性へと定義変えした。

フリーソフトウェアのフリーは“自由”の意味、“タダ/無料”ではない。

Morozovの記事は、ドットコムバブル期に話題になったカリフォルニア的イデオロギーと、その政治への影響をあらためて問い直している。つまりそれは、原理原則を犠牲にして実用主義を優先した結果、に対する問いだ。でもMorozovは、オープンソースがフリーソフトウェアを乗っ取ってしまった決定的な理由を、見落としているように思える。

Morozovは、オープンソースとフリーソフトウェアの違いを看過している。フリーソフトウェアのフリーは、その名の通り、言論の自由などと同じく“自由”という意味であり、free beer(無料のビール)のような“無料”という意味ではない。その自由をMorozovは、“ユーザがプログラムをどんな目的にでも使えること、その動作構造を調べられること、そのコピーを再配布できること、その改良バージョンを公開リリースできること”、と解釈している。

しかし(Open Source Initiativeの定義による)オープンソースソフトウェアもその多くは……(Free Software Foundationが定義する)フリーソフトウェアだ。では、何が問題なのか? 二つの運動の違いは、フリーソフトウェアが社会的な運動であるのに対して、オープンソースが方法論であることだ。Stallmanは”Why Open Source misses the point of Free Software“(なぜオープンソースはフリーソフトウェアを誤解しているのか)と題するエッセイで、フリーソフトウェア運動が増進に努めてきた自由をオープンソースの擁護者たちが無視している、と非難している。そして、だからこそ、オープンソースの正しい意味すら世の中に伝わっていないのだ、と。

Morozovは両者の違いについて、フリーソフトウェアはユーザの側面を強調し、オープンソースはデベロッパを強調する、と書いている。でも、フリーソフトウェアも、その主な関心はデベロッパではないだろうか。つまりその自由は、主にデベロッパの自由であり、ほとんど一般大衆とは無縁だ。しかしこの点にこそ、運動がコースを間違えた理由がある。

もちろん、デベロッパ以外の人たちにもソフトウェアの自由を気にする理由はある。活動家やセキュリティに関心のある人たちは、自分たちが使うソフトウェアを調べたい、あるいは信頼できる専門家たちに調べてもらいたい、と思う。でも、グラフィックデザイナーたちに、PhotoshopよりもGIMPを使え、後者ならコードを調べたり、書きかえたり、自分だけのバージョンをリリースできるから、と言ってみよう。あるいはデータアナリストに、ExcelではなくLibreOfficeを使うべき理由を、ミュージシャンにLogicではなくArdourを使うべき理由を述べてみよう。どんな結果になるだろうか。

そこで、こんな疑問が湧いてくる: オープンソースがフリーソフトウェアを日陰者にしてしまったのは、O’Reillyが天才的マーケターだったからか。あるいは、Stallmanが気にするような自由を人びとが全然気にしないからか? フリーソフトウェアの主なユーザがデベロッパであることは、むしろ当然ではないか?

企業とデベロッパがオープンソースソフトウェアを使ってプロダクトを作れると知ったとき、水門が一挙に開いた。

昔を知る人に言わせると、業界の主流部分をオープンソースに改宗させた第一の功績者はApacheだ。その理由は、1)オープンソースの(そしてフリーな)サーバがとても優れていた、2)企業が商用に利用してもおとがめなしのライセンス(カスタムソフトウェアとくっつけてもよい)。

企業とデベロッパがオープンソースソフトウェアを使ってプロダクトを作れると知ったとき、水門が一挙に開いた。その良い面は、オープンソースの技術を勉強する人たちが増えて、企業はオープンソースによる開発に多くの予算を割くようになったこと。オープンソースが今のように優勢にならなかったら、ブログはすべて、プロプライエタリなコンテンツ管理システム(CMS)の上で動いていることだろう。ColdFusionで書かれたコードが、Windows ServerやIISの上で動いているだろう。

O’Reillyがフリーソフトウェア運動に代えて描いた絵の中では、実用主義者たちが実用目的のために妥協を図ろうとしている。オープンガバメントも、企業にとってデータがオープンになりそれによって経済が刺激されなければ、離陸することはなかっただろう、という議論もある。だが、その今後の姿はまだ見えてこない。業界の主流部分(“mainstream, メインストリーム”)がオープンソースを受容したことによって、フリーソフトウェア派のデベロッパに雇用機会が生まれ、本もカンファレンスのチケットもたくさん売れるようになった。でもそれはイデオロギーの軽視であり、デベロッパたちが80年代の初めに夢見たようなソフトウェアの自由だけが受容されたのだ。

ぼくはデベロッパではないけど、ソフトウェアの自由は重視したい。でも、ほかにも重要な自由があると思う:

  1. ハードウェアドングルや執拗なオンラインの本人確認なしに、自分が買ったソフトウェアはどんなデバイスの上でも自由に動かしたい。
  2. 政府や企業から詮索/のぞき見されない自由。
  3. 自分のデータを複数のアプリケーション間で移動(==利用)できる自由。
  4. アプリケーションを異なるホスティングプロバイダ間で移動できる自由。
  5. 高額な年会費月会費に縛られない自由。
  6. 多くのWebサイトの利用規約の「私のやり方に従えないなら出ていって」からの自由。.

〔2番は、パーソナライゼーションへの個人データの利用など。〕

上の1番は、フリーソフトウェア運動にも含まれる。そのほかは、オープンWebや連邦型WebインディーWeb、それにベンダ関係管理(VRM)、などの主唱者たちが、今主張している項目だ。まだほかにも、重要な自由はいくつもあると思うが、それらも含めて、新しいフリーソフトウェア運動、ユーザの今日的なニーズにも対応するフリーソフトウェア運動の基盤が、そこにはあるべきだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


MapReduceのオープンソース実装を特許訴訟の対象にしないとGoogleが公式に誓約

Googleが今日(米国時間3/28)、同社のMapReduceプログラミングモデルのオープンソースバージョンを実装したユーザやディストリビュータやデベロッパを、それらの実装が本質的にはGoogleのパテントを侵害しているものであるにもかかわらず、訴訟はしないと公式に誓約した。たとえばApacheのHadoopはおそらく、Googleがこの技術に関して保有している10件のパテントを侵害している。同社法務部でパテント関連を担当しているDuane Valzは今日の発表声明の中で。“これをこの業界における範例としたい。弊社以外の特許保有者にも、誓約やそれ相当の自発的行動をとるよう、おすすめしたい”、と言っている。

今回の誓約の対象はGoogleが保有する特許のごく一部にすぎないが、しかしGoogleは誓約の対象範囲を長期的に拡大していくものと予想している。ただし、最初にGoogleの方が攻撃された場合には、公然と特許権を振りかざして相手と戦う、としている。

残念なことにパテントをめぐる抗争はソフトウェア業界で日常化しており、そのため、GoogleやRed Hat、Sony、IBMなどが支援する団体Open Invention Networkは、オープンソース製品の開発をパテントに関する懸念から解放しようと努力している。

Googleは今回の”Open Patent Non-Assertion Pledge” (特許公開非主張誓約, OPN誓約)が、業界の今後のモデルになると考えている。同社のパートナーや競合企業が同様の誓約をすることによって、この過程(特許公開非主張の過程)関し長年待望されていた透明性と、幅の広さとセキュリティが導入される、と同社は期待している:

  • 透明性: 特許保有者は誓約の対象となる特許と関連技術を正確に同定し、デベロッパと一般社会に対し特許権をめぐる透明性を提供する。
  • 幅広さ: OPN誓約による保護の対象は特定のプロジェクトやオープンソースの著作権ライセンスに限定されない(Googleはその種のライセンスの下に大量のコードを寄与貢献している。それらはApacheGNU GPLなどのライセンスであるが、特許からの保護に関してそれらは非力である)。それとは対照的にOPN誓約は、過去現在未来を問わず、誓約下のパテントに依存しているかもしれないいかなるオープンソースソフトウェアに対しても適用される。
  • 守勢の保護: Googleの製品やサービスに対して特許訴訟が起こされ、それらの特許がOPN誓約の対象であったときには、そのときにかぎり、攻勢の保護を行うために、非主張誓約は破棄される(==特許権を主張して公然と戦う)。
  • 永続性: 誓約は対象特許の寿命期間中有効であり、権利が他に移行された場合にも、有効である。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


LibreOffice 4.0がOffice 365難民を助けるべくリリース

LibreOffice 4.0

オフィススイートといえば、長年Microsoft Officeの天下だった。これまで多くの挑戦者が登場し、そして敗れた: WordPerfect、Corel、StarOfficeなどなど、数え切れないほど多い。中でもとくに、Sun MicrosystemのStarOfficeはのちにOpenOfficeへ変異し、これまで長く、MS Officeとの互換性では最良と認められていた。しかしOracleがSunを買収したため、デベロッパたちはOpenOfficeを捨て、そこからフォークしたバージョンとしてLibreOfficeを作り上げた。

このアプリケーションは、一部のオープンソースファンたちのあいだで、広く使われるようになった。2010年の終わりごろにThe Document Foundationという団体が作られ、このプロジェクトの維持管理を担当することになった。

今日(米国時間2/7)、そのThe Document Foundationが、LibreOfficeのバージョン4.0のリリースを発表した。その発表声明には、おもしろいデータがいくつか盛られている。

LibreOffice 3.6のブランチ以降、LibreOffice 4.0の全開発期間にあたるこれまでの7か月間、デベロッパたちは1万回以上のコミットを行った。週末や休日も含めて平均するとそれは30分に1度となり、このプロジェクトがいかに活発であるかを示す証拠の一つとなっている。

LibreOfficeの開発とメンテナンスには、500名あまりのデベロッパが参加している。今回の新バージョンでは、レガシーコードの残滓の多くが取り除かれ、より現代的な構文に変えられた。また25000行のコメントがドイツ語から英語に翻訳された。そしてその結果、よりクリーンで分かりやすい、新しいデベロッパでも容易に開発に参加できるコードに生まれ変わった。

これまで、オフィススイートというものを使った経験のある人なら誰もが、LibreOffice 4.0を快適に使いこなせるだろう。文書の作成機能では、とくに独自の先進的機能というものはなくて、むしろLinuxとMacとWindowsの三者に共通するスムーズで心地よいインタフェイスを実現している。LibreOffice 4.0でとくに興味深いのは、このオフィススイートのプレゼンテーションアプリケーションImpress(MS PowerPointに相当)をAndroidから音声でコントロールするアプリが、加わったことだ。今はいくつかのLinuxディストリビューションがサポートしているだけだが、次のバージョンではすべてのプラットホームでサポートされる。

そして、あの、敬愛すべきOpenOfficeはどうなるのか? OracleはそのコードをApache Software Foundationにライセンスして、今後の開発をまかせた。ApacheのOpenOfficeは今も健在で、最近はIBM Symphony(==Lotus Symphony)から大量のコードを寄贈された。

そしてさらに興味深いのは、MicrosoftがOfficeのLinuxへの移植を検討していることだ。近未来には、そこいらのどんな会社も、WindowsからLinuxに鞍替えしているかもしれない。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))