OSSのある暮らし
この記事は CA22 Advent Calendar 2021 の2日目の記事です。
概要
今まで OSS のコントリビューターの1人だったエンジニアが、メンテナーになったことで起こった変化などについてのお話をします。
具体的にはメンテナーになるまでの経緯や、メンテナーになってからどういったことを行っているのかについて触れていこうと思っています。
「OSS のメンテナーやってみたいな」とか、僕と同じように「コントリビューターをしていたらメンテナーをすることになった、どうしよう」というような方々に向けた内容になります。
はじめに
はじめまして、Shutaっていいます。
Web フロントエンドをメインに Web アプリケーションの開発を行っているエンジニアです。
Web に 3DCG などを組み合わせて何か作るのが好きで、最近だと(もう半年以上前ですが)以下のような WebGL(Three.js) x React の組み合わせで色々な表現が出来ないかと模索するようなことをしていました。
いわゆる Canvas 芸人と呼ばれる人たちに憧れています。
前振り
上記のような WebGL を用いた実装をする際に Three.js, TWGL.js などの WebGL をラップしたライブラリを用いることが多いと思うのですが、僕はこの Three.js が好きでよく使っています。
WebGL の OpenGL っぽさ溢れる書き方を、うまく JS のクラスベースで記述出来ることや、画像や3Dモデルなどアセットの読み込み用モジュール、デバッグ用 Utils が用意されているなどといった素晴らしいライブラリになっています。
ただ1つだけ使っていて困る点として、Three.js と UI を記述するために入れている React のプログラミングにおけるパラダイムの違いがあります。
React は周知の通り JSX を用いた宣言的な記述が可能なのですが、Three.js は命令的に記述するため、例えば「この画面の左端に四角形の3Dオブジェクトを置いて回転させたい」と思ったとき、逐一処理を追ってどこに命令を追加するか考えるようなことが起こります。
せっかく React を使っているのでこの 3DCG のシーンの作成・編集も宣言的に出来ないものかと思っていました。
そこで出会った react-three-fiber から今日の本題の OSS の話が始まります。
メンテナーになるまで
react-three-fiber は前振りの中にあった、「Three.js を React のように宣言的に書きたい」を叶えるライブラリです。
少しだけ内部実装からライブラリの説明をすると、Three.js 向けの Render として、React Reconciler をラップし Three.js の表現に効率よく変換していくようなものになっています。
より詳しい話はメンテナーの CodyJasonBennett 氏の記事を読んでみてください。
これを作っている OSS コミュニティである Poimandres に興味を持ったので、色々と github でリポジトリを見て PR を投げてみたり、discord に入ってみたりしていたところ three-stdlib というプロジェクトに出会いました。
このライブラリは Three.js の examples フォルダーに入っているモジュール群をスタンドアロン化するようなものです。
react-three-fiber のエコシステムの1つ兼 Three.js 本体のサポートを目的として開発が行われています。
かねてからお世話になっている Three.js に何か貢献したいとは思っていたのですが、膨大なコード量と issue を見てどこから切り込めばいいか考えあぐねていました。
そういった中、外部から支援する形で関わるのも1つの手だと思い three-stdlib に対して issue や PR を送るようになりました。
初めはよくある good-first-issue 狩りをしていたのですが、ライブラリを見ていると部分的に TypeScript で記述(元のは全て JavaScript で記述)され始めており、置き換えの手がほぼ全く足りていないことに気づきました。
そこで「これやります」って issue でメンテナーに声をかけて、OK をもらってから取り組み始めました。
とりあえず黙々と進めて、issue に上げられていた置き換えタスクの全ての項目を終わらせました。
ちなみに1番激しい置き換えは 2000 行消して 2500 行追加！という感じでした。
JS → TS は経験がある方だったのですが ES5 風味の書き方で慣れないことや、@types/three の型や外部モジュールの型との差異で仕方なく @ts-expect-error や any で握りつぶすなど苦労が多かったです。
また Three.js 側の実装を正として、それに追従しつつ TS への置き換えを行うために、 Three.js と Three.js の型と three-stdlib のリポジトリを確認のために行き来しまくる必要があり、慣れるまではかなり時間がかかってました。
一方で JS → TS をする際に Three.js の examples や、それに関連した core の内部実装を読む必要があったので、 Three.js への理解を深められる良い機会になっていたと思います。
こんな感じで細々 JS → TS を続けていくか〜と思っていたところ、僕が立てた以下の issue がメンテナーの目に留まり、あれこれお話する形になりました。
この棚の端から端まで全部持ってこいみたいな issue です。
本当に思いつきだったのでかなり無茶を言っていた気がします。
やり取りの中でプロジェクトの方向性など、純粋に気になっていたことを質問していたところ「PR の働き振りいいね、人手とチェックの数が欲しいから入らない？」とのことで、「yes~」という感じで入りました。
大したことをやった記憶がなかったのでかなり驚いたものの、せっかくだしやってみるか！と思い飛び込みました。
メンテナーになってから
急にメンテナーになると「え、何したらいいの」と困ることがあると思います。僕がそうでした。
まだ全然歴は長くないので偉そうなことは言えないんですが、メンテナーになるとコントリビューターのときよりも手を付けられる範囲が増えるので、よりプロジェクト内で立ち回りやすくなります。
当たり前という感じですが一気に出来ることの幅が広がります。
でもほとんどコントリビューターの頃とやっていることは変わらず、実装を行って issue のタスクの消化もやっています。
ただ、今までは「これやってもいいですか？」とか逐一声をかけていたものを自分の判断でスムーズにやれるようになったり、他のメンテナーたちが手が空かないが故に見逃しているバグ報告にこまめに対応したりで、OSS への関わり方が多彩になってきた感があって楽しいです。
初めて PR を承認してマージしたときはビビり散らかしていましたが、最近は慣れてきたので数をこなすのがやっぱり大事なんだなと再確認しました。
別にマージでやらかしても淡々と revert するだけなので、めちゃくちゃ落ち込まなくてもいいです。ミスは少ないほうが良いですが...
あと英語がやっぱり大事です。やはり実装の意図や問題点の共有の際に適切なコミュニケーションをたくさん取れれば取れるほど良いです。
幸いにも OSS は英語でやり取りをするものが多いので、翻訳サイトに突っ込むよりも自力である程度読み書きできるように英語を身に着けておくと他でも使えてなお良いと思います。
僕から言えることとして、メンテナーになったけど何をやればいいか分からなくて困ったときは、とにかくコントリビューター時代と同様に振る舞いつつ、他のメンテナーに聞いてみたりリードメンテナーの指示を仰ぐようにすればいいと思います。
メンテナーになったけど何もしないはかなり良くないので、自分から行動を起こしていきましょう。
また何かしら OSS のメンテナーをやってみたい！という場合、そのプロジェクトに貢献していて楽しいかどうかで選ぶと良いと思います。
正直やっていて楽しくないと続かないです。
あと基本的にプロジェクトを仕切っているメンテナーは忙しいです。
issue や PR 全てに目を通せている訳ではないので、自分の作成したものが全く見向きもされない！と怒ったり落ち込んだりせず気長にやっていきましょう。
おわりに
OSSの1コントリビューターが1メンテナーになった感想のようなものをつらつらと書きました。
OSSコントリビュートについては、やってて楽しいかどうかで決めるということが結局1番伝えたかったことです。
もう少しギーク寄りの話はブログの方でそのうち書こうと思っているのでまた見てみてください。
ここまで読んでくださってありがとうございました。
素敵なクリスマスをお過ごしください！🎄
この記事が気に入ったらサポートをしてみませんか？