2022年のオープンソース活動の振り返り記事です。

今までの振り返りの一覧です。

2022年のGitHubのPublicなContributionsは7000~8000ぐらいを推移していました。

2022 Contributions

Privateリポジトリも含めると大体1.5倍ぐらいなので、あんまり変わってない感じがします。

データの取得には次のツールを使いました。

Issue/PR

  • 作ったリポジトリ数: 53
  • 作ったIssue: 231
  • 作ったPR: 318

グラフにすると次のようになってます。

Notion Plotlyを使って作成しています。

"https://notion-plotly.netlify.app/line.html?"+
"Repository.y=" +prop("Repository") + "&Repository.x="+prop("Year") +
"&Issue.y=" +prop("Issue") + "&Issue.x="+prop("Year")+
"&PR.y=" +prop("PR") + "&PR.x="+prop("Year")+
"&sortBy=x"

2022年は、新しいものはあんまり作れてなくて、既存のものを大きく更新する方に時間を使っていた感じがします。 JavaScript Primerやtextlintに大きく更新を加えていた感じがします。

作ったリポジトリ

作ったリポジトリを眺めながら、今年の活動を振り返ってみます。

Maintainer Month

GitHubが6月にMaintainer Monthというイベントをやってて、6月の後半になってその存在に気づいた。

気づいたのは、GitHubからスポンサーされて通知が来てたからだったと思う。

オープンソース活動の透明性について色々考えていたので、色々書いてみるかーと思って1週間で5記事ぐらい書いた。

オープンソース活動と支援のスタンスはこの辺でも色々書いている。

自分の生活の中にはオープンソースがある気はしているけど、オープンソースに生活は依存しないようにしてる気もする。 これは、“オープンソースと報酬”の話でよくある反応だけど、オープンソースだけで生活できるだけの報酬が(まだ)得られないみたいな反応を見る気がする。

個人的には、報酬の金額を別にしても、趣味的なオープンソースの報酬だけで生活するのは健全的にやるのが難しいと思ってる。 生活がその報酬に依存してる場合、その報酬がなくなると生活が止まるので、それは実質仕事としてやらないといけないということになる。 GitHub Sponsorsとかは特にそうだと思うけど、オープンソースのスポンサーとは別に契約書を結んでいるわけじゃないので、スポンサーをやめるのは自由だと思う。 普通の仕事なら契約を結んだり労働法での保護があるので、突然止まった場合も対応ができるけど、そうじゃない場合は突然止まってしまう。

なので単純に同一なもの(十分な金額があるから生活できる)と扱うのは難しいと思ってて、精神的にもそういう意識でやるものは別のものとなる気がする。

GitHub Sponsorsの募集を始めてから2年が経ったので振り返るでも書いていたけど、 基本的な生活費は労働で稼いで、消耗品の費用負担とかをオープンソースで稼ぐくらいのバランスの方が良いのかなと思う。

このバランスを変えようと思ったら、趣味的なオープンソースを労働として扱うように変化するとかになっていく気もする。 もしくは、趣味の範囲を拡大解釈してしまうとかもありそう(自分はこっちのタイプ)。

JavaScript Primer

2022年の前半は、jsprimerのES2022対応をやっていてECMASCriptのアップデートに合わせてリリースできた。

Sandpackを使ったエディタとかも組み込んだので、色々学習しやすくなったと思う。

あとは、来年はJavaScript Primerの出版版を改訂する予定なので、その改訂作業をやっていた。 全体的に見直して、リファクタリングしたり、図を追加したり、コードを更新したりしている。

こういう文章のリファクタリングが気軽にできるのは、textlintとpower-doctestで大量のテストを作ってるからな気はします。 一方で、文章に対して新機能をPull Requestをする人はやっぱり少ないという現状があるので、これをどうにかしたい。

来年はJavaScript Primerのメンテナンス体制の仕組みを作っていきたい。

今考えていることとしては、Open Collectiveなどでスポンサーを募集して、そのスポンサーの費用をjsprimerの更新のための資産として扱うというのを考えている。 JavaScript Primerは、毎年ECMAScriptのアップデートに合わせて更新していて、その対応に大体1ヶ月分ぐらいの作業時間がかかるイメージ。 その1ヶ月分の作業となる費用を目標値に設定してスポンサーを募集し、その費用でメンテナンスできる人を増やしていく、というのが考えている仕組み。 (LiberapayやOpen Collectiveを触ってみたいという理由もあります。Open Collectiveはちっちゃい会社みたいだなと思った)

個人というよりは企業がスポンサーになるイメージで、何かいいバランスの仕組みがないかなと考えている。 Railsガイドの協賛プランとかの話は、だいぶ近いのかもしれない。

実際にデータがまだ整理されてないので、それを整理するところから始める気がします。 実際にスポンサーすることで何かができると嬉しいのかやデータとして何があると嬉しいのかとか、その辺がわかってないので興味ある方は [email protected] または @azu_reへ連絡してください。 (会社でよく参照されてますとかそういうレベルでもいいです)

jsprimerのアクティブユーザー数

jsprimerのアクティブユーザー数は大体月2万人

この話は先ほどの個人のオープンソース活動とはちょっと別で、チームとしてのオープンソース活動について考えていて出てきた内容です。 ソフトウェア中心のオープンソースの中でも深く参加する人が少ない印象のドキュメント系(翻訳はちょっと例外っぽい)のオープンソースについて、どうしたらより多くの人が参加できるかを考えたいです。 ソフトウェアはメンテナーが交代するのはよくあることなのに、文章や書籍は著者が変わらないのは不思議だなーと思って考えていました。

textlint

textlint は、Node.jsのESM対応という難題に対処し始めました。

ESMは非互換性がとにかく広くなりがちなので、フラグで切り替えられるようにして、古い実装と共存できる方針で対応しました。 CLIの場合はあまり気にすることはないですが、パッケージとして参照される場合の非互換性はかなり広いと改めて思いました。

v12.3.0で中身をかなり書き換えているので、だいぶスッキリした気がします。 古い実装が消せれば、かなりメンテナンスしやすくなるんじゃないかなと思います。

これは、5年ぐらい前にmonorepoにしたりTypeScriptにしたりした時のリファクタリングがなかったらできなかった気もします。

このときに関数に対するユニットテストは脆い部分があるのがわかって、CLIというインターフェースに対するテストを追加してました。 また、実際のパッケージを使ったテスト(Example Testと呼んでいる)や実際にtextlintを使ってるプロジェクトに対するE2Eテストなども増やしていました。 これらのレイヤーの高めなテストがあったので、今回の内部実装を丸っと切り替えるときに同じテストがほとんど使えて、かなり安心して実装できた気がします。

textlint自体をESM化するというのもやりたいので、ここに興味がある人は是非言ってください。 多分、もう技術的な問題はないので、あとは書き換えていくのをどうやるかという話になると思います。

その他

今年は習慣を変えたり、昔から引っかかってたものをだいぶ整理してた気がします。 あと旅行というかワーケーションみたいなことをよくやってたので、33/365ぐらいは家にいなかったみたいでした。

特にコード的に何かあるわけじゃないですが、Notionを使って整理することが増えたかなーという感じがします(NotionはDBとして認識してる)。

あとは、オープンソースとセキュリティはかなり近くなってきてるので、メンテナーがそれを考えないといけない感じになっている気がします。

この辺は、うまくカバーできないと負荷が集中しやすい領域なので、その辺は常に見ておきたいです。 1Password for Open Source Projectsの申請をしたとかも、使うものはちゃんと使うというところからスタートしてる気がします。 パスワード管理/MFA管理の戦略とかに取り組んだもの、ずっと頭に残りがちなやつだったためです。

Open Source向けのプラン

次のサービスでオープンソースのメンテナー向けのプランを利用させてもらっています。

まとめ

毎年、その時に思ってることをとりあえず書いてるだけなのでまとめはないです。

  • オープンソース、JavaScript Primerのメンテナンス、透明性について考えたい
  • textlintのESM対応を完了させる
  • 新しいものを作る
  • 本を読む、聞く、書く
  • オープンソースとセキュリティとメンテナーの関係を考える