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

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

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

2021 Contributions

Privateリポジトリも含めると大体1.5倍ぐらいなので、これは2020年と大体同じ比率なようです。

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

Issue/PR

  • PR: 302
    • 去年: 372
  • Issue: 226
    • 去年: 379

ちょっと減少傾向になってる。 Contributions見ても、深い緑が少ないので、新規に何か作り込むケースが少なかったのが要因な気はする。

作ったリポジトリ

https://github.com/search?q=user%3Aazu+user%3Aefcl+user%3Ajser+user%3Aalmin+user%3Atextlint+user%3Atextlint-ja+user%3Atextlint-rule+user%3AJXA-userland+user%3Ajs-primer+user%3Aecmascript-daily+user%3Aasciidwango+user%3Asecretlint+user%3Ahonkit+created%3A2021-01-01..2022-01-01+is%3Apublic&type=Repositories

  • 2021: 85
  • 2020: 111
  • 2019: 81
  • 2018: 69
  • 2017: 95

リポジトリの作成数自体はそこまで大きく変わらず。

この記事でも紹介していたように、今まではちょっと違うタイプのプロジェクトをやることが増えたからかも。

作ったもの

何を作っていたのかを振り返る。

philan.net

寄付した金額とか寄付先とかを管理するWebサービス。結果はSpreadSheetに記録される。

philan.netを始めた理由は、寄付とか慈善活動とかについてもっと考えてみようと思ったためです。 実際にやらないとわからないことは多いので、もっと考えるためには何かやってみようというのがスタートです。

色々な本とか文献を読んでいて、もっと理解するためにやってみることが早そうだったので、やるための仕組みを作っていた。

philan.netの予算を決めて寄付をするというアイデアは、The Science of Giving: Experimental Approaches to the Study of CharityのPrecommitment to Charityからきている。

philan.net 考えるのに結構時間は使ったけど、実装があんまりできていない。 SpreadSheetにデータを記録するのは正しい(データはユーザー自身のものであることを表現したい)けど、それが結構複雑ではある。

サブスクリプションの実装もGASベースで書いてはあるけど、複雑でGoogleの審査も必要でなんか止まっている(審査があると大体止まる)。 この辺もっといい感じに進めたいなー。VercelをやめてAWS(Serverless Next.js)に移動したいというのもあります。

あと事前に予測されていたように、どこへ寄付していいのかがわからないという状態が発生しやすいので現実かなとは思った。 これは、来年どうにか解決できるようにしていきたい。

philan.netのContributorはいつでも募集しています。

まずはもっとデプロイをもっと気軽にできる状態(コミットしたらされるけど安全性が微妙)にしないといけない感じはする。

JavaScript Primer

毎年のECMAScriptの仕様改訂(6月頃)に合わせて更新しようとしている。

来年はES2022で、Private Fieldなどのかなり大きめな変更が来る予定。 また、Node.jsのECMAScript Modules対応もどうするかという話もあリます。

ES2021に対応したJavaScript Primer 3.0を公開しました - JavaScript入門 | Web Scratchでも書いていましたが、 書籍もソフトウェアのようにオープンソースとして扱えるはずなので、参加したい人を募集しています。

jsprimerはコードや文章に対してもテストが用意されているので、文章に対してもソフトウェアのようにContributeできます。 Contribution Guideは次のページを参照してください。

ECMAScript 2022対応として新規トピックの追加というのもあるので、依存関係が強くない部分は新しく参加する人でも書ける可能性があるので、興味あるIssueあったらやってみたいというコメント書いてください！

まだ、Issueは色々あるので、興味ある人は見てみてください！

GitHub Sponsors

GitHub Sponsorsの募集を開始してから2年が経ちました。

GitHub Sponsorsの振り返り記事を書いていて、自分のGitHub Sponsorsに対するスタンスも書いています。

2021年末で100名以上の方にサポートされています。ありがとうございます！

最初に登録したGitHub Sponsorsのゴールは、とりあえずで入れた100でした。 色々な方の支援があってこのゴールに到達したので、ゴールを更新しています(GitHubのゴールは常に上書きかと思っていたけど、ちゃんと履歴が残る作りになっていました)

GitHub Sponsors Goal

記事の最後でも書いていますが、GitHub Sponsorsを目にする機会は増えたと思います。 ただこれはベースラインができたという感じで、まだまだ変わっていく可能性が高いです。

オープンソースにおける持続可能性は、続けるだけではなく変化する可能性が含まれていると思います。 変化しない持続は停滞と捉えられる可能性が高く、持続と変化はある種のセットだと考えています(かつてのNode.jsとiojsみたいな話)。 ここでの変化は安定とは対立しない概念な気もします。

そのような変化を見ていくには、やってみないとわからないことは多いです。 GitHub Sponsorsも実際にやってみていいところと微妙なところがわかってきた気がします(よくも悪くもGitHubは場所を提供してる感じで、細かいところはユーザーに任せている感じ)。

2年以上やっていますが、まだGitHub Sponsorsのバランスがきちんと取れている感じはしないです。 (これぐらいの支援がちょうどよくて、それぐらいなら支援される側の負担もちょうど良いみたいなバランス。またこういう支援方法が適切で、それに対するリターンはこういう形が適切みたいなバランス。企業のスポンサーにとって、こういう見返りが明示されていた方がやりやすく、それが誰にとっても納得感がある形など)

これからも変化を見ながら、GitHub Sponsorsなどのオープンソース周りでちょうどいいバランスを見つけられるように活動していきたいです。

textlint

textlintのルール自体は欲しくなった時にちょこちょこ作っています。 今textlint本来の出力する情報を改善しようとしています。

現在のtextlintは、エラーの開始位置しか基本的に含んでいないため、エラーの範囲を出力できるようにしようとしています。

また、エラーメッセージをキーで参照できるようにしてローカライズしやすくしたり、エラーだけではなくサジェスト(修正候補を選んで修正)、エラー時のドキュメントの改善(パターン化)のRFCを出しています。

元々、CLI/CIで動かす目的で始めたの部分があるので、エディタやtextlintを使ったプログラムからもより使いやすくする目的の変更をイメージしています。

こういうのがあるといいみたいな意見がある人は、GitHubやTwitterなどで教えてください。

JSer.info

JSer.infoはそろそろ11周年が近いです。 今年の初めてに10周年の記事を書きました。

JSer.infoは基本的に安定的な更新ペースになっています。

他の分野でもJSer.infoみたいなサイトが欲しいみたいな話はここ最近よく目にするようになった気がします。 そう言ったWeekly系のサイトは、一人だけだと続けるのは難しいし、個人でやるなら結構フレームワークに則って効率化しないと難しいです。 モチベーションに依存しちゃうと更新が止まりやすい(人には波がある)ので、ある種の更新の流れがあったり、更新が気持ち的に楽な状態を作っておく必要あります。

次の記事で、この辺のJSer.infoの更新の流れをどうやって作っていったかについて書いています。

結構この辺は情報サイトとしてある種パターンはあると思っているので、それを上手くフレームワークに落として、同じようなサイトをやる人がやりやすい状態を作りたいなと思っています。 HubMemoや上の方で書いていたazu/book-reviewもそれの実験材料です。

逆に、そういうサイトをやりたい人にとってどういうものがあると、参加しやすい/続けやすいのかが気になります。 また、一人だけで難しいなら複数人にやりやすい仕組みを作るのが適切だと思っているので、その形も見つけたいです。 JSer.info自体もそういう形を目指したいです。

JSer.infoのような情報サイトは、公開する場所(ブログ)などが重要なのではなく、そのプロセスが重要だと考えています。 公開した結果がモチベーションに繋がること(反応をもらうとか)はあると思いますが、継続的にやる場合には公開した結果ではなく公開することに対してモチベーションを維持する必要があります。 そのため、どちらかという公開する場所や結果より、公開までの過程に摩擦がなかったり公開すること自体が楽しいなどの形の方が継続しやすいと思います。

まとめ

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

  • 新しく深く面白いと思うものを作りたい
  • philan.netとか寄付周りの話はもっと深く見ていきたい
  • 引き続きGitHub Sponsorsやオープンソースの持続可能性について考えていきたい
  • textlintやJavaScript Primerで結構大規模な変更をやる予定なのでやり切りたい

移動しながらとか時間制限がつくと進みやすい気がするので、意図的にそのような状態をどう作るかを考えていきたい。