GitHubはオープンソースのプロセスを標準化した

「GitHubはオープンソースのプロセスを標準化した」記事の感想をメモ。

【参考】
GitHubはオープンソースのプロセスを標準化した。これからはコード開発以外にも使われていく。AWS Summit Tokyo 2015 － Publickey

akipiiさんはTwitterを使っています: "そうなのか？RT @koyhoge: Redmine にパッチを投げる不便さを解決するところから GitHub は生まれたのか。 #awssummit #key02"

akipiiさんはTwitterを使っています: "ふむー。RT @toshihirock: Github以前、svnにもアクセスできないからソースコードをダウンロードして、パッチ作ってみたいな大変。そしてやりとりをredmineで。そして個人的な功績は残らない。しんどい　#AWSSummit"

akipiiさんはTwitterを使っています: "同感。RT @mesaka2009: 昨日のGithubの人の講演。たった10年でこれだけ変わった。と言う事の一つに、Redmineでやり取りしていたのがGithubになった。とあったけど、日本の企業にはまだまだRedmineは現役だぞい！"

GitHubの偉大さは、Publickeyの記事の通り、オープンソースの開発プロセスの事実上のデファクトスダンダートになったことだろう。
オープンソースで何かしらの貢献をしたい開発者は、GitHubにアカウントを持ち、フォークしてパッチを送る方法をプルリクするやり方を学ぶ必要がある。
GitHubにないソースの保守は、とても面倒だ。

上記の記事の通り、以前は、diffコマンドを作り、patchコマンドでtrunkにDiffパッチを取り込むやり方を行なっていた。
そして、メーリングリストでダラダラとやり取りしていた。

あるいは、ReviewBoardというコードレビューWebシステムがあったが、その機能は、Subversionのtrunkに対し、patchを添付するとWeb上でDiffが表示されて、そのDiffを中心にコミッタと開発者がコメントし合うやり方だった。

ReviewBoardでプレコミットレビュー: プログラマの思索

ReviewBoardを使うプロセスとは？: プログラマの思索

でも、GitHubのおかげで、全てはプルリク駆動の開発プロセスで標準化された。
好きなだけフォークして、ブランチを作り、マージ依頼をプルリクすればいいだけ。
このやり方で、より高速な開発が可能になったし、ソースに関するすべての作業がWeb上で公開されているので、開発プロセスの透明化にもつながった。

但し、Redmineを過去の遺物で紹介されたのはちょっと違和感があった。
RedmineとGitHubは、利用シーンも使い方も目的も全く違う。

GitHubはソース中心のプルリク駆動開発であり、Issue管理の機能は正直弱い。
チケット集計機能もないし、Issueにコメントをやり取りするのが中心で、ステータス管理もシンプル。
チケットはフロー型。
チケットは完了したら捨てる。
チケット管理の機能はそもそも不十分だし、それでいいと割り切っている。

逆に、Redmineはチケット管理機能がすごく充実している。
Redmineのチケットはストック型。
チケットに作業や課題、障害などの情報を記録し、後で検索できるように蓄積していくべきもの。
Redmineは「チケット駆動開発」が本来の使い方だと僕は思う。

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

つまり、RedmineとGitHubの違いは、チケット駆動開発とプルリク駆動開発の違いであり、その優劣を言い合っても意味が無い。
使う用途が全く違うのだから、利用シーンに応じて使い分ければいい。