Kengo's blog

Technical articles about original projects, JVM, Static Analysis and TypeScript.

OSSコントリビュータとしての私の歴史

来週木曜日、@ikeike443 さんに教えていただいた以下のイベントに参加します。

で、話す前に考えをまとめとかなきゃーということでこの14年弱で起こったことや感じたことをまとめておきます。

フリーソフトウェア作者時代(2000〜)

高校入学祝としてWindows MEを買ってもらったことがすべての始まりです。BASICなどいくつかの言語を渡り歩いてからHSP 2.5に出会い、ソフトウェアの作成を趣味として楽しんでいました。ただこの時期はライセンスやOSSについてはほぼ関心がなく、なんか書いてF5押すとなんか動く!ということ自体を楽しんでいました。

ソースを公開するよりも前に、ウェブサイト上での実行ファイルの公開やBBSでの回答(「eller site:hsp.tv」でググると157件ヒットする)、Wikiを通じた資料作成や他の方々の作品へのフィードバックなどを手がけていました。OSSにコントリビュートという認識はほぼなく、使ったら気づいたことあったし自分もフィードバックもらったとき嬉しかったから自分も伝えよう、くらいのノリです。
ソース公開はきっかけと場所がなくて行っていなかったのですが、HSPLetの真似をしてZIPにソースを同梱したのをはじめ、2007年ごろからブログでの公開を開始しています。このブログがけっこういろんな方に利用いただけて、クロノス・クラウンさんのリンク集などで紹介いただけました。

他にも、漁ってみたらHSPLetのREADMEに名前を載せていただいてたり、HSPのドキュメントに名前を載せていただいたり、Footy2のコミット権限いただいたりと意外にいろんなことやっていたんだなーという感じです。
当時の*1HSPコミュニティはちょっとのプロとたくさんのアマチュアがいて、ユーザ間のコミュニケーションが活発でした。各自がやりたいこと・すべきと思ったことを自由にやっていて、知識面でも実績面でも人格面でも尊敬できる方が多数いらっしゃいました。またこのコミュニティから多くのフィードバックをいただけたことが、開発者としての自負や自身に繋がっていると思います。

このころはソーシャルコーディングという呼び名はありませんでしたが、 どう書く?orgCodeReposなんかが出てきてWWWでコードを見せ合うのが普通になり始めた時期だったのかなとも思います。

プロフェッショナル突入時代(2008〜)

2008年からプロの開発者になりまして、JavaやらCOBOLやらJavaScriptやら従来とは違った色合いの技術に触れるようになりました。このころフリーソフトウェアオープンソースソフトウェアの違いを認識したり、GPL・MIT・APLv2といったライセンスについて理解を深めたりといった変化を遂げました。これは調査研究や技術基盤構築を担う部署に配属されたことが大きく効いています。先輩のお陰でライセンスに苦手意識を持たずに済んだのは、今思うとすごい儲けものだったのかもしれません。

オフではRGSSにちょっと手を出しました。歯車の城さんなどで公開されているコードを読んで、OOPならではのコードの読みやすさを学びました*2。コードを読むことの効果、特に普段使わない言語を読むことの大切さを改めて認識したきっかけになっています。

この時期のはじめはインプットばかりでコントリビュートはほぼありませんでした。2009年になって少しずつサンプルコードの量が増え、2010年からはJVMの構造理解やパフォーマンス問題といったことに関する言及が増えているようです。新領域での仕事に頑張って慣れていた頃なのだと思います。

ソーシャルコーディング時代(2011〜)

2011年が私にとってのGitHub時代の始まりです。今までJIRAやSourceForgeに感じていたとっつきにくさをGitHubが解消してくれました。args4j、enchant.js、FindBugs、fluentd、Jenkins、RocketMQ、SonarQubeといった各種プロダクトへのバグ報告やPRをけっこう気軽にやっています。コントリビュート回数では間違いなくこの時期が最多でしょう。

MavenそしてMavenリポジトリを理解したのもちょうどこの頃で、コンポーネントやその依存関係は宣言的にきれいに管理できるし自分の製品もそう利用されることを意識して実装しなければならないという意識が強まったきっかけになりました。
公開側の立場としては、PARTAKEのテストと運用に関わったのが大きな変化でした。ウェブサービスOSS化することの難しさと課題に直面しています。また会社でもOSS公開を推進する立場になり、価値あるソフトウェアを作り公開して利用してもらうことをどう仕事にするかということを考えています。

そしてnpmやbowerに触れることで、作品の公開をコマンドがサポートしていることやソーシャルコーディングサービスを前提とした開発環境構築が常識になりつつあることを知りました。開発環境だけでなく本番環境でもGitHubやCDNやAWSコンポーネントといったシステム外の資源を有用に活用するという発想は、従来のオンプレミス開発*3からはなかなか想像できないものでした。公開し共有されるものはライブラリやミドルウェアだけでなく、サービスやデータベースにも及ぶのだという考えが自分の中で普通になった時代です。

まとめ

  • 14年前とやってることは変わってない
    • PR送る動機は、自分がされたら嬉しいから・感謝の気持ちで貢献したいから。フィードバックは製品を改良する最良の素材。
    • 不純な動機(?)として、手元でforkをメンテナンスするのが面倒だから本家に変更を反映したいというケースはある。
  • コントリビュートされやすい環境を作るのは結構大事かも
    • 昔はパッチ送れと言われても、メールのルールとかコードの書式とかうるさいプロジェクトが多い印象があった。「コントリビュートしたい場合はこのページを読むこと!」という注意書きがあったり。
    • どのプロジェクトにもほぼ統一されたUIでコントリビュートできるPRと、レビューや感謝をさくっと伝えられるPR内コメントがあることが、私がGitHubを長く愛用している理由なのかもしれない。
    • npmのようなコミュニティへの貢献を助けるための仕組みはとても便利。
  • 先輩大事
    • つまづきどころで苦手意識を持たせないのは地味に重要。ライセンス、コミットコメント、コーディング規約、英語、issueの書き方、とか?
    • 多少変なフィードバックが来ても、(HSPコミュニティの先輩方がやってくださったように)あたたかく見守ったり注意を促したりすると良い
  • オープンにできるもの、貢献のカタチはいろいろ
    • 直接的なフィードバック、資料公開、ブログ執筆、BBSでの回答、翻訳、サービス提供、データベース充実(Mavenセントラルにjar置くとか)
    • 高校時代に自然とやっていたことが今意識的にやっていることとほぼ変わらないってことは、貢献とは誰かにやり方を教わらなくてもできるものだということでは
    • 貢献を目的にするのではなく、楽しそうに見えたことをやってみるとか作った物がもったいないから公開するとか、そんなレベルで始めていいはず

*1:今のは存じ上げないです

*2:HSPのモジュールでは実現できないような可読性向上が多かった

*3:必要なものを全部入りで提供する