始めに：pandasの作者であるWes McKinneyさんがPythonのデータツール関連でとても興味深いblogを書かれているので、翻訳して日本のPyDataコミュニティに公開してもいいでしょうか、とお聞きしたところ、快諾をいただきましたので少しずつ訳して公開していこうと思っています。
2018/4/19（木）
オープンソースソフトウェアへの投資は複雑なことです。私は、データサイエンスのツールにおけるイノベーションをミッションとする独立の開発ラボとしてUrsa Labs（ https://ursalabs.org ）を設立しました。このことをお伝えできるのをとても嬉しく思っています。
私は、まずRStudio及びTwo Sigmaとパートナーとなっていただきました。これは、Ursa Labの運営の成長と管理を支援していただくこと、そして相互利用可能で複数言語にわたるデータサイエンスのためのコンピューティングシステムに関するエンジニアリングの作業を調整するためです。それらのシステムは、すべてApache Arrowを基盤とします。
このポストでは、Ursa Labsを立ち上げた理由と、将来的に期待していることを説明します。
オープンソースソフトウェアへの投資：メンテナンスとイノベーション
この数年間で、世界中の企業はこれまで以上にオープンソースソフトウェア（以下「OSS」）に依存するようになりました。どのように、そしてなぜそうなったのかは間違いなく将来の書籍や研究の題材となることですが、現時点で私たちはオープンソースが誰にとっても「うまく役立つ」状態を保つうえでの現実的な課題に直面しています。
私の経験では、オープンソースプロジェクトでは2つの典型的なモード、すなわちイノベーションとメンテナンスというモードがあることが特徴的です。イノベーションのステージは、しばしばプロジェクトに開始時期に生じます。ユーザーは少数で、ソフトウェアは頻繁に変化や進化を起こします。そして成功したプロジェクトは、もっと保守的になっていくことがあります。開発は安定性、バグフィックス、斬新的な変化と成長にシフトしていきます。ユーザーは多くなり、変化はプロジェクトの評価と将来にとって大きなコストになる可能性が生じます。これは特に「破壊的な」変化ならなおさらです。OSSのメンテナーは多くの場合ボランティアですが、増大するユーザーベースをサポートするというストレスの下で、彼らは日常的に「燃え尽きて」しまいます。ユーザーの中には、プロジェクトが存続し、メンテナンスされることを当然と考えている人もいます。
メンテナンスへの支援
OSSプロジェクトの中には、LinuxやOpenSSLのようなセキュリティライブラリなど、ユーザーからミッションクリティカルなインフラストラクチャのソフトウェアだと考えられているほど重要になったものがあります。インフラストラクチャのメンテナンスが滞ればどうなるかは、広く利用されているプロジェクトのショッキングなセキュリティの脆弱性がこの数年で明らかになったことについて、幅広く研究されてきました。
OSSのメンテナンスへの投資は難しいことではあるものの、OSSへの依存性に責任があると見なすようになってきている世界中の組織に対して明らかな価値命題を持ちます。RedHatのような会社は、LinuxなどのミッションクリティカルなOSSの周辺に精神の平穏を提供することでビジネスを構築しました。
私たちは、OSSのメンテナンスへの投資について新たなビジネスモデルが立ち上がっているのを目撃し始めています。たとえばTideliftは、RedhatやAngularJSといったミッションクリティカルなOSSフレームワークのパッケージの依存関係グラフに対して一種の「保険証券」の販売を始めました。ここで合意されているのは、こういった保険証券からの資金がこの依存グラフ内にあるプロジェクトのメンテナーに支払われ、トップレベルプロジェクト群に関するタイムリーなバグフィックスと健全な運用が提供されるようにすることです。
イノベーションへの支援
イノベーションのステージにあるOSSに対する投資は、リスクプロファイルが高くなるため難しい場合があります。新しいプロジェクトは、成功したり広く使われるようになったりすることもあれば、そうならないこともあります。
私がpandasの開発のための支援を得るために何年にもわたって苦闘してきたことは多くの皆さんがご存じでしょう。最終的に、私は2012年にAdam KleinとChang Sheを説得して、（Goldman SachsとCitigroupでの）実入りのいいニューヨークの金融の仕事から時間を割いて、pandasのプロジェクトの仕事をしてもらうようにしました。私の推定では、私たち3人が2011年と2012年にこのプロジェクトに投資した数千時間で給与を得られなかったことによる機会費用は少なくとも$500,000になっています。仮に私たちが家賃と家族の生活費に十分な資金を募ることができなければpandasを構築しなかったなら、このプロジェクトはおそらく今のような状況にはなっていなかったでしょう。
オープンソースのデータサイエンスソフトウェアは、世界がデータを分析し、機械学習やAIのプロダクションモデルを構築する方法として、その需要生を増してきました。Google、Facebook、そしてそのこの業界におけるその他の研究団体において、Pythonは機械学習における主要なインターフェースになりました。もしこのことをpandasを構築しはじめた2008年に私が聞いたなら、私は信じなかったかもしれません。
データサイエンスのためのOSSにおけるイノベーションに投資をしないことのリスクは多々あります。私がもっとも気にかけているのは以下の点です。
データサイエンティストの生産性が損なわれること。特にデータサイズが大きくなり続けていることに伴う損失。
世界のデータに対して効率的ではないコンピューティングツールが使われ、また処理が可能であるが故に、コンピューティングのコストが高いままに留まること。
組織がOSSを不適切なものと見なすことにより、柔軟性を欠き、高価なプロプライエタリソフトウェアに依存し続けること。
落とし穴とその回避方法
OSSの開発者は、自分たちの作業をサポートするため、直接の投資に代わる様々な戦略を採ってきました。それらはうまく行くこともありますが、「落とし穴」になってしまうこともあります。そういったありとあらゆる問題のいくつかのバリエーションは、私自身が体験しました。
コンサルティングの落とし穴：プロジェクトの創始者は、自分のソフトウェアのユーザーとのサービス契約に夢中になります。契約の締結に夢中になれば開発からは気がそれることになり、サービスそのものがプロジェクトの中核の開発からの注意を分断させることになります。
スタートアップの落とし穴：スタートアップは1つあるいは複数のオープンソースプロジェクトの利用の増大をマネタイズするビジネスを構築します。そういった企業の中には成功したものもありますが、オープンソースソフトウェアの創始者は概して注意をビジネスの構築とソフトウェアプロジェクトの構築とに分割しなければならなくなります。これは明らかにトレードオフです。ベンチャーキャピタルと収入があれば、大規模なエンジニアリングチームが構築できます。しかし、スタートアップはユーザーと開発者のコミュニティとの間でガバナンスの衝突を抱えてしまうことがあります。ハイブリッドなオープンソースモデルを持つ企業は、収入を伸ばせる作業のためにOSSの作業を短期間で変化させなければならないことがあります。 OSSに投資したいという企業の創始者の熱意は、通常はベンチャーキャピタルの投資者である経営陣からの期待と衝突してしまうかもしれません。場合によっては、残念なことにコストを切り詰めるためにOSSの開発者が解雇されてしまうこともあります。
企業ユーザーの落とし穴：OSSに依存する大企業は、そういったプロジェクトのイノベーションやメンテナンスを促進するために開発者を雇用したり育てたりします。場合によっては、企業がクローズドソースのプロジェクトを立ち上げ、後にそれをオープンソース化することもあります。このモデルでは、多くの問題が生ずる可能性があります。ある企業から離れた開発者が、自分たちがプロジェクトでやったことをサポートしている他の企業を見つけられないこともあります。企業がプロジェクトに対する関心を失い、開発者を別のプロジェクトにアサインすることもあります。企業が自分たちにとって必要な新しい機能を構築し、そのプロジェクトから必要なものを得るにつれて「姿を消していく」こともあるでしょう。大規模な開発チームを育てる開発者の能力は、彼ら自身のコントロールの及ばない予算の問題によって制約されてしまうかもしれません。
2013年から現在へ：DataPad、Cloudera、Two Sigma、そしてApache Arrow
2012年のpandasの離陸と私の著作「Pythonによるデータ分析入門（Python for Data Analysis）」の出版に続き、私はベンチャー投資を受けたスタートアップであるDataPadを起業しました。DataPadが目的としていたのは、データ製品を構築し、後にR&Dの資金をPythonエコシステムに投資して戻すことでした。私たちはpandasの日々のメンテナンスをJeff RebackやPhillip Cloudやその他の人々に手渡しましたが、彼らはこの5年間にわたってこのプロジェクトを成長させるという素晴らしい仕事を成し遂げてくれました。
2014年の中頃には、DataPadで私たちはエンタープライズ分析における複雑なシステムエンジニアリングの問題に取り組んでおり、これはもっと大きなエンタープライズソフトウェア企業であればより効率的に解決できるであろうことに気づきました。pandasの構築とDataPadの製品の開発という経験を経て、私はpandasのコンピューティング基盤に対する不平不満のリストを蓄積していました。その不名誉なまとめを発表したのが「pandasの10項目の課題」です。2014年9月には、DataPadのチームと私はClouderaに加わり、これらの問題やそれ以上のことに取り組みました。
Clouderaに加わった際の私の目的の1つは、ビッグデータと分析的なデータベースのコミュニティとのアライアンスを形成し、データサイエンスの世界にとっての利益になるよう、共有データシステムの問題をもっと効率的に解決できるようにすることでした。Cloudera時代の私の2つの大きな成果はSQLスタイルの実行エンジン向けの遅延コンピューティング表現フレームワークであるIbisと、多言語対応のインメモリデータフレームフォーマット及び分析開発プラットフォームであるApache Arrowです。
2016年の中頃には、ビッグデータインフラストラクチャ市場の競争と収益性への困難な道のりに直面し、ClouderaはApache Arrowの開発とデータサイエンスのためのコンピューティングシステムの改善のために私が参加できるチームを構築するうえで、良い立場にいなくなっていました。Python-on-Sparkを加速するために手の届く明確な成果もあったものの、Arrowに対する投資から得られるROIは全体として数年先のことであり、したがって大規模な予算割り当てを正当化するにはリスクが大きすぎると見なされました。
このころ幸運なことに、私はTwo Sigmaとのつながりができました。Two Sigmaは金融テクノロジーと投資管理企業で、OSS開発の実践を増やし、ペタスケールのデータウェアハウスをApache SparkとPythonデータサイエンススタックで活発に利用していました。私は2016年に、Apache Arrowプロジェクトを通じてPythonデータスタックのパフォーマンス及びスケーラビリティへの将来を見据えた長期的な投資を行う計画を持って、分析ツールグループのソフトウェアアーキテクトとしてTwo Sigmaに加わりました。Two Sigmaのエンジニアリングチームと共に働き、私たちはArrowに関連するいくつかの大きなマイルストーンの達成を支援しました。このプロジェクトは11回のリリースを行い、130人以上のコントリビュータを持つまでに成長し、Apache Spark（Apache SparkにおけるデータアクセスとPython関数の実行の高速化）、Berkeley RISELab（Ray及びApache Arrowによる高速なPythonのシリアライゼーション）、GPGPUコミュニティとのエキサイティングな協力関係を確立しました。
Apache Arrowがこの数年間で離陸するにつれて、私たちが取り組んでいる問題は、その範囲において単一の組織や、単一のプログラミング言語よりもはるかに大きなものであることが明らかになってきました。この数年間のプレゼンテーションで私が広く訴えてきた（Data Science Without Borders at JupyterCon, Memory Interoperability for Analytics and Machine Learning at Stanford’s ScaledML, Raising the Tides: Open Source Analytics for Data Science at the Newsweek AI and Data Science Conference）ように、私たちは同じ種類の問題をPython、R、あるいはその他の言語にわたって解決してきており、Arrowはデータサイエンスのための共有コンピューティングインフラストラクチャーを生み出すための統一的なテクノロジーを提供します。
Python、R、JVM、Julia、あるいはその他のデータサイエンスコミュニティと何年にもわたって共同作業を行い、そこから学ぶことによって、私は共有コンピューティングライブラリはデータサイエンスにメリットをもたらすだろうということを確信するに至りました。私が思い描いているのは、ポータブルかつコミュニティ標準であり、ほとんどあらゆるプログラミング言語においてネイティブのArrowベースのデータフレームの処理に活用できる「データサイエンスランタイム」です。これは巨大なプロジェクトです。主要な作業領域には以下のようなものが含まれます。
ポータブルなC++の共有ライブラリと、各ホスト言語（Python、R、Rubyなど）のためのバインディング
遅延データフレームの効率的な評価を行う、ポータブルでマルチスレッドなApache Arrowベースの実行エンジン
入出力としてArrowフォーマットを活用する関数を含む、再利用可能な演算子の「カーネル」。これにはpandasスタイルの配列関数と共に、SQLスタイルのリレーショナル演算子（結合や集計など）が含まれる。
LLVMを用いた演算子の「サブグラフ」のコンパイル。一般的な演算子のパターンの最適化。
ユーザー定義演算子や関数カーネルのサポート。
既存のデータ表現（たとえばR、pandasのデータフレーム / PythonにおけるNumPy）との包括的な総合運用性
ホスト言語のための新たなフロントエンドインターフェース（たとえばdplyrやその他の「整然とした」Rのフロントエンド、Python用のpandasの進化）
燃えよ ドラゴン 熊
この10年間のデータサイエンスソフトウェア構築における私の経験に照らし合わせて、私がオープンソースデータサイエンスの世界に最もよく貢献できる方法は、データサイエンスのための先進的な多言語対応コンピューティングシステムに特化した独立組織であるUrsa Labsを創設することだと信じています。この組織の直接的な目的は、急成長しているApache Arrowのエコシステムの一部であるデータサイエンスシステムの開発者を雇用し、支援することです。Ursa Labsは、大企業にパートナーとなっていただき、直接的な投資とエンジニアリングにおけるコラボレーションを通じて支援してもらうことになります。
開発チームを成長させるため、私は主に直接的な投資をしてくださる企業を探していますが、できればそのうちにさらに多くの開発者をサポートできるよう、もっと少額の寄付も直接Ursa Labsで受け付けたいと思います。
RStudioとのパートナーシップ
RStudioは、Ursa Labsの運営における管理面で私を助けてくれます（HR、給付、財務など。これらは大量の難しい仕事です）。私はUrsa Labsが調達した資金の管理を行います。この資金は、主にUrsa Labsチームのフルタイムのエンジニアの給与と給付に当てられることになります。Ursaチームと私は、RStudioの組織内で機能的に独立したエンジニアリンググループとして動き、R関連の開発作業についてRStudioのたのメンバーと共同作業を行います。私のように長い間Pythonの開発者だった者がRプログラマーのためのソフトウェアを構築している企業とパートナーシップを結ぶのは奇妙に見えるかもしれませんが、実際にはこれは完璧に理にかなっていることなのです。
2016年には、Hadley Wickhamと私はファイルフォーマットのFeatherをつくりだすために短期間の共同作業を行いました。FeatherはArrowベースの相互利用可能なデータフレームのためのバイナリファイルフォーマットで、PythonとRから利用できます。Featherの発想は、Apache Arrowを利用する相互利用可能なデータテクノロジーという概念を広めることでした。PythonとRは敵対していると「推測」されていたので、Hadleyと私が共同で作業を行ったことで多くの人々が驚いていました。実際には、Hadleyと私が考えていたのは、我々が解決しようとしている本当の問題がデータ分析のためのヒューマンインターフェースの設計であるのに、「言語戦争」などをしているのは愚かだということでした。プログラミング言語は、利用しやすく生産性の高いツールを作り出すための手段です。RとPythonでコードやシステムが共有しやすくないことは、長い間私にとってフラストレーションでした。これは、Arrowに取り組むことがこれほど私にとって重要であり続けた理由の一部です。Arrowは、データのレベルで相互運用を可能にすることによって、Pythonの外にあるシステムのコードを共有する経路を提供します。
Pythonと同様に、Rも高速でスケーラブルなインメモリデータ処理にまつわるシステムレベルでの問題に直面しています。私たちが解決しようとしている問題は、構造的に非常に似ているので、私たちは長い間PythonとRのコミュニティ間で広範囲にわたる共同作業が行われるべきだと信じてきました。自分が構築しているソフトウェアがPythonプログラマーと同じようにRのプログラマーにとってもうまく働くことは、私が目標とするところです。RStudioとの共同作業の一部として、Hadley WickhamはRユーザーのニーズに私たちが気を配れていることを保証するため、技術アドバイザーとしてこの作業に関わります。私たちはみな、彼がこうして関わってくれることでとても興奮しています。
この数年間で、私はRStudioの組織とその創設者にしてCEOであるJ.J.Allaireにとても強く感心させられました。Hadleyと私がデータサイエンスのイベントで知り合いになってから、私は自分たちがデータサイエンティストを力づけること、そしてオープンソースのユーザーコミュニティとのポジティブな関係を気づくことについて長期的なビジョンを共有していることに気づきました。非常に重要なことに、RStudioは「スタートアップの落とし穴」を避け、オープンソースの開発に大量のエンジニアリングリソースを投資し続けながら、持続可能なビジネスの構築に成功しました。J.J.がRStudio IDEを構築し始めてから9年近くが経過しましたが、多くの点でJ.J.やHadley、そして他の人々はまだ自分たちは始めたばかりのように感じています。
Two Sigmaとのパートナーシップ
Two Sigmaで過ごした間、私はTwo Sigmaのモデリングエンジニアリングの組織のトップであるMatt Greenwood、そしてTwo Sigmaのオープンソース活動を管理しているDavid Palaitisと共有したデータサイエンスツールのビジョンに向かって働いていました。ほとんど2年が過ぎたとき、私たちは私がApache Arrowで解決しようとしている問題は、1つの企業がサポートできるよりも大きなものであることを理解していました。最終的にはプロジェクトのスコープとニーズは、いかなる単一の組織の関心や能力を超えて広がります。
Two Sigmaにおける巨大なスケールでのデータサイエンスの真の問題に関われたことは、Ursaに対する私のビジョンへのヒントと検証づけとなりました。そして私がUrsa Labsを立ち上げるためにTwo Sigmaを離れたことは、Two Sigmaとの私の関係が壊れたということではありません。私が次の冒険を始めるにあたってTwo Sigmaとパートナーになることで、彼らがArrowのソフトウェアのアーリーアダプターとして作業をする中でのフィードバックループをオープンにしておけます。Arrowに対するTwo Sigmaの関心は、データサイエンスの生産的な未来を生み出すためのより大きなコミットメントの一部であり、これには中でもPandas、Ibis、Jupyter、Spark、Mesos、Tensorflowの周辺に構築されたコミュニティへのコミットメントが含まれます。
Ursa Labsに対するTwo Sigmaの貢献は、ArrowのようなUlsa Labsのプロジェクトへの従業員の貢献と、必要に応じた外部のオープンソース開発への投資を通じたものになります。Two Sigmaは、技術的なアドバイスやコミュニティへの支援の募集においても共同作業を行ってくれます。MattはNumFOCUS及びTS Venturesの役員としての立場を通じて、新たなイニシアティブの立ち上げを支援できます。私は引き続き、Jeff Reback（pandas）やPhillip Cloud（Ibis）といったTwo SigmaのコアOSSエンジニアと作業していきます。この先のPyDataでのJeff Rebackとのプレゼンテーションなど、共同で行うプレゼンテーションも楽しみにしていてください。
ご参加ください
いま私たちは、目前に伸びているデータサイエンスツールの最先端を前進させるという長い旅の端緒についただけにすぎません。
近いうちに私たちはフルタイムのエンジニアリングのポジションに関するポストをしますので、ソフトウェアエンジニアの方でUrsa Labsのミッションに参加することに関心があるなら、ぜひ注目しておいてください。それまでの間、Apache Arrowに関わってくださるならとても嬉しく思います。
企業で私たちの活動へのスポンサーとなれる立場の方、あるいは何らかの形で私たちのパートナーとなってくださる立場の方は、info@ursalabs.orgにご連絡ください。