2024 年のオープンソース活動の振り返りと GitHub Sponsors での収入をまとめた記事です。 いつもは別々に書いていましたが、内容的にどちらもオープンソースの話が被っているのでまとめました。

今までの振り返り

オープンソース活動の種類

自分のオープンソース活動の種類として、次のようなものがあると思います。

オープンソース関係の収入の種類

自分のオープンソース関係の収入1は、ほぼ GitHub Sponsors 経由となっています。

GitHub Sponsors では Monthly と One-Time でのサポートができます。 自分の場合は、GitHub Sponsors の Monthly での支援がベースとなっています。

また、今年からJavaScript Primerの Open Collective を開始したので、来年はここからもいくらか経費申請をする予定です。(jsprimer への Contributor への支払いものこの Open Collective の予算から行なっています)

今年は自分は経費申請してないので、今年のオープンソース活動に関する収入は GitHub Sponsors のみです。

オープンソース関係の収入の合計金額

2024 年の GitHub Sponsors の収入は 約 259 万円となりました。

GitHub Sponsorsの収入 year

月毎で見ると次のようになります。

GitHub Sponsorsの収入 month

テーブルにすると次のようになります。

Date 金額(円)
2024/01 148,267
2024/02 232,138
2024/03 170,552
2024/04 187,441
2024/05 211,506
2024/06 194,666
2024/09 899,839
2024/10 179,029
2024/11 186,958
2024/12 184,130

7月~8月がなくて 9月にまとまってるのは、GitHub Sponsors の設定を更新し忘れていて一時的に積んでいたのが原因です。

また、6月にトヨクモ株式会社さんのThanks OSS Award presented by Toyokumoの 2024 年度(1月~6月)に選ばれたので、9月はその分増えています。

Thanks OSS Award とは私達の製品開発で使用しているライブラリ/ツールなどにおいて、 年度単位で選出した開発者の方々にその開発の継続を金銭的に支援しましょうという活動です。

この記事は 2024 年での収入なのでまだ含まれていませんが、Thanks OSS Award presented by Toyokumoの 2024 年度(7月~12月)にも選ばれたので、重ね重ねありがとうございます！

GitHub Sponsorsは、2019年10月から始めています。 今までのGitHub Sponsorsでの収入の推移は、次のとおりです。

GitHub Sponsorsの収入 history

GitHub Sponsors を始めた経緯については、次の記事にまとめてあります。

今までのまとめは、次のページで公開しています。

継続的なサポートをしてくれている人の数

GitHub Sponsors で継続的にサポートしていくれている人の推移は次のとおりです。

GitHub Sponsors Count

GitHub の API でいい感じに表現するのが難しいため、この人数は現在も継続している人数だけを出しています。 そのため、one-time の場合や今は中断している方は含まれていません。

Monthly Estimated Income(単位は$)は次のようになっています。

GitHub Sponsors Count

GitHub Sponsorsに感謝

GitHub Sponsors でご支援いただきありがとうございます！

GitHub Sponsors

画像はSponsorKitを使って作成しています

2024 年にご支援いただいた企業さんもありがとうございました！

最近ではOpen Source Pledgeという 開発者数 * $2000 per year をオープンソースに支払うイニシアチブに参加を宣言する企業も増えてきています。(金額自体は購買力が地域で異なるので適正な値かという議論もあります。Account for purchasing power disparities · Issue #36 · opensourcepledge/opensourcepledge.com)

こういった議論は増える傾向にあると思いますが、実際に行動へと移している方々に感謝しています。

オープンソース活動の振り返り

次は、2024年のオープンソース活動の振り返りです。

Contributions/Issues/PR

  • Contributions: 10157
  • 作成したリポジトリ: 59
  • 作成した Issue: 58
  • 作成した Pull Request: 214

今年はそこまで新しいものは作ってなくて、メンテナンスだったりバグレポートとかを色々していた気がします。 あと、個人的にも Issue 管理にLinearを使うようになったので、Issue の数が少なめです。

  • azu/type-safe-env: Type Safe /Environment Variables snippet for Node.js
    • Node.js で型安全な環境変数を扱うスニペット | Web Scratch
    • ENV の読み込みを TypeScript で型安全にするためのスニペット的なものです
    • 個人的には ENV に型変換は求めてない(boolean とか)ので、かなり小さなスニペットだけど実用的な感じがします
    • NODE_OPTIONS='--import ./env.local.js' と allowJs で、型安全に環境変数の設定までできるところまで行けたのは結構面白いポイント
    • 来年ぐらいには、Node.js が.ts を普通にロードぐらいまではいけると思うので、NODE_OPTIONS='--import ./env.local.ts'とできる気はします
  • azu/octocov-viewer
    • octocovという CodeCoverage ツールの結果を GitHub の Pull Request の Diff にカバレッジ情報を表示するブラウザ拡張
    • 動くところまで書いて、メンテナンスどうしようかなーというところで止まっている
    • 仕組み的に必要なものとかはわかっているので、カバレッジに熱意にある人に任せたい感じがしていて止まっている
    • 目的としては、Codecovのような外部 Saas/またはセルフホストはしないで GitHub 上だけでカバレッジの可視化ができるとレビューしやすいよねってのを実現させるためのもの
  • azu/nextjs-trace-to-tree: Next.js trace-to-tree CLI
  • azu/jsconf-jp-2024-schedule: Schedule Tool for JSConf JP 2024
    • JSConf JP 2024 Scheduler
    • JSConf JP のスケジュール組むのが難しすぎてv0 by Vercelを使って作って調整した
    • こういうワンタイムウェブサイトが楽にできて便利だった
  • azu/ts-to-json
    • 昔からスキーマをスキーマとして書くのが好きではないので、TypeScript の型定義からいい感じにしたいという発想がある
    • TypeScript の型定義からバリデーションコードを生成するツールを書いた | Web Scratch とかもそうだった
    • 値の指定自体は手動だけど、その指定は型安全にしたいというケースは、TypeScript の型定義だけがあれば良いはずという仮説がある
    • たとえば、ENV の指定とかルーティングの指定とかは、値自体は自動生成じゃなくて手動で指定してるはず
    • とはいえ、デバッグ時には値自体も欲しいことがあったりするので、その辺をいい感じにしようとした時に依存を最小限にして実現する方法を考えてた
    • よくよく考える typescript はあらゆるところに入っていて、typescript パッケージ自体にパーサがついてるので、これベースで型定義からコード生成すればいいじゃんという発想のサンプル
    • ts-morphとかはあるけど、これを使うと結構依存として大きくなる気がしたので、typescriptだけで手軽にできるパターンを考えていて書いたサンプル
    • まだそこまで出来てないけど、もう何回かか書けばデバッグ用途ならこれで十分みたいな感じのことができるような気がしている
      • デバッグ用途なのでコード生成ツールみたいな厳密なパースとか生成を省いていいみたいな前提でいい感じにしたい

全体的にライブラリを作るというより、最小限のものをどうやって作るかというのを考えていた気がします。

JavaScript Primer

今年のJavaScript Primerでは、ES2024 に対応したv6.0.0をリリースしました。

大きな変更としては、Node.js のユースケース周りの書き直しとJavaScript Primer - Open Collectiveの開始があります。

最近の Node.js は Deno や Bun の登場もあってコア部分への変更も多く入って、Node.js 本体だけでできることがかなり増えています。 jsprimer もそこへの対応を追従していて、node:utilのparseArgs関数に対応したり、テストをnode:testで書くように変更したりしています。

最近も Node.js 本体(実際には SWC を利用している)で TypeScript の実行をサポートする変更も入ってきています。

そのため、この辺はどうやって対応していくかは考えていく必要がありそうです。

また、ECMAScript 自体も大きなアップデートが来る予定で、ES2025 では Iterator Helpers など基礎文法と読んでいた部分にも変更が大きく入りそうです。jsprimer では、こういった変更に対応する仕組みを作りたくて、JavaScript Primer - Open Collectiveを始めました。

Open Collective は GitHub Sponsors と似たオープンソースを支援する仕組みですが、Collective というプロジェクト単位での金銭的な支援ができます。また、Collective への支援金額をそのプロジェクトの Contributors に経費精算という形で支払うことができます。

今年の ES2024 の対応でも手伝っていただいた Contributors の方には、Open Collective から Contribution に応じてお支払いしています。 この支払いルールはContributing Expenses Policyという形でまとめています。(繰り越した予算については深くは考えずに設計したので、来年もルールは更新していくとは思います。)

次の記事は今年の ES2024 の対応に関するものですが、そろそろ ES2025 の内容も確定するので ES2025 の対応を進めていく必要があります。

まだ特に Issue とかは切ってないですが、このへんやっていきたいとかあったら気軽に Discussions のスレッドを作ってもらえると助かります。

時間的な制約もあるので、レビューの仕組みをちゃんと作って回るようにしていきたいです。

secretlint

今年のSecretlintでは、Secretlint を単一のバイナリファイルとして配布できるようにしました。 以前から Docker 対応はしましたが、ただのバイナリの方が使いやすい場面もあったので、Bunを使って Single-file executable binary として配布するようにしました。

次の記事では詳しく解説していますが、Node.js 向けに書いたツールでもバイナリとして配布ができて普通に動くので、CI で動かす時とかに便利になりました。

Secretlintやtextlintは動的に Node.js のパッケージを読み込むプラグインの仕組みを持っていますが、このようなツールもバイナリにできたのでほとんどのツールは動かせる仕組みだと思います。

textlint

今年のtextlintも結構大きな変更を入れていました。 textlint v14 で、Old API を非推奨にしました。

Old API New API
textlint use @textlint/legacy-textlint-core or @textlint/kernel
TextLintCore use @textlint/legacy-textlint-core or @textlint/kernel
TextLintEngine use createLinter and loadTextlintrc
TextFixEngine use createLinter and loadTextlintrc

次のメジャーアップデートで非推奨となった API は削除していく予定です。

また、textlint は Secretlint での学習を取り込んでいくことが多いのですが、Secretlint で実装した Single-file executable binary にするための仕組みも textlint にも実装してあります。

そのため、textlint も Bun で単体のバイナリとして作ることはできると思います。

他の課題としては、@textlint/editorやvscode-textlintなどのエディタ周りもののメンテナンスの問題がありそうです。

エディタ固有に作っていくのはやっぱりコストが高い部分もあるので、Language Server Protocol(LSP)のような汎用的なものに乗れるといいんですが、LSP 自体も大きいため大変そうです。 エディタとの連携が簡単にできて、ブラウザでも簡単に動かせるような仕組みがあるいい感じの落とし所があるといいのですが、なかなか進んでいないのが現状です。

この辺は何かいいアイデアが欲しいです。

JSer.info

JSer.infoは相変わらず更新しています。

情報の収集方法は私の JavaScript の情報収集法 2024 年版 | Web Scratchあたりから特に変わった感じはしないですが、最近ちょっとまとめて作業してる感じが出てきているので、もっと細かく情報を集められる仕組みが必要そうな気がしています。

なんだかんだ更新はずっと PC でやっているので、そろそろスマホだけで回るような状態は作った方がいいのかなという気もしました。 (実際の作業自体はスマホでもできるが、あくまでできるレベルなので、効率的にできるようにしたい)

情報見る時に一つ変わったこととしてはKagi Searchをメインの検索エンジンとして使うようになったことです。

1 年ぐらい使ってみて、検索してみてアレ?って感じのことはかなり少ないので、多分このまま使うと思います。 高度な機能を使ってるわけじゃないですが、ちゃんと検索できてその検索結果をちゃんとコントロールできるのが良いです。 qキーを押して Quick Answer で、検索結果のサマライズを見たい時に見れるというのも意外と便利です。 (AI 機能が欲しいんじゃなくて、検索機能があってそこにサマライズ機能が付属してるぐらいの感覚です。)

まとめ

今年は今までの中でもかなり忙しくて、ペース配分は結構難しかったです。 それでもJSer.infoとかは、そこまで大きなズレはなく更新し続けられていたので、「更新コストを小さくして継続できる形を作る」というのは大事だなーと思いました。 「更新コストを小さくして継続できる形を作る」については、次の記事では書いています。

JavaScript Primerも、ある種サイクルがあるもの(ECMAScriptは毎年更新される)なので、この更新コストをどうやって分散していくかというのは課題になっています。時間的な分散か人的な分散かの方法は色々ありますが、色々組み合わせてやる方法を考えていきたいです。

特に結論はないですが、来年も引き続きオープンソース活動を続けていきたいと思います。

こういったまとめ記事を書いてるのは、振り返りの意味もありますが、GitHub Sponsorsに関する情報はやっぱり少ないので、公開することで他の人の参考になるかなと思っているためです。 実際に去年の記事を書いた後に、GitHub Sponsorsに関する情報をまとめてる人もいたみたいでした。

  1. 📝 報酬にしなかったのは定義が難しいのと、見返りを設定してるわけでないため。“所得”は税を引いた後の金額で、GitHub Sponsorsの振込額には源泉徴収はなくて確定申告するまで実際の金額が決まらないので不適当そう。IncomeやRevenueが妥当な表現と思ったため”収入”と表記している。 ↩