堀口の履歴(No.21)

研究概要†

↑

要旨†

企業発オープンソースプロジェクトのコミュニティネットワークについて、その構造と統計量の時系列データの変化と、プロジェクトの品質（バグの量、保守性、機能の数とか？）の時系列データの変化を見て、どんなコミュニティ構造や統計量が、プロジェクトの品質に良い/悪い影響を与えるのか調べる。
コミュニティネットワークの分析においては、企業の開発者とコミュニティの開発者の区別や、周辺的な参加者と中心的な参加者を区別したコミュニティ構造と統計量（企業の開発者の人数、コミュニティの開発者の人数、人数の割合）を盛り込むことで、新規参加者が、周辺的な参加者から中心的な参加者に役割を変化していく様子も捉える。
企業発オープンソースプロジェクトの品質向上に向けたコミュニティの設計に貢献できる。

↑

新しい点†

企業発オープンソースプロジェクトに着目して、コミュニティネットワークの変化とプロジェクトの品質の変化の関係を調べる
企業の開発者とコミュニティの開発者や周辺的な参加者と中心的な参加者を区別した統計量を使う

↑

ToDo:†

リサーチクエスチョンを決める
Yes/Noで答えられる形式にすると分かりやすい。
まずは研究の目標を決め、それに対して結論が出せるような質問（RQ）を設定する。
組織がスポンサーをする動機について調べる→組織は何がしたいのか
個人がOSSコミュニティに参加する動機について調べる→個人は何がしたいのか
これが分かれば、この研究では組織、個人がしたいことについて、どのように貢献できるかが明らかになる。

ネットワーク全体のSNA、ネットワーク自体の性質を調べる
- クラスタリング係数　→　
- 平均経路長　→　コミュニティのサイズがわかる
- 次数分布　→　
- モジュラリティ
- コミュニティ中心性
コミュニティ抽出法を使う
- 抽出したコミュニティの性質を見る
- 抽出したコミュニティごとの分析
スポンサー付きオープンソースプロジェクトに関する既存研究から、歴史の長いプロジェクトを見つける
論文を読む
- The Emergence of a New Commercial Actor: Community Managed Software Projects

↑

研究MTG†

↑

9/12†

やったこと

分析対象のリポジトリを選んでみた
2010年以前にGitHubに登録されたリポジトリをfork数で降順ソートして上位5つを選択。
その中から、コントリビュータの数が一番多いrailsリポジトリを選択(2番目と比べて約3倍のコントリビュータがいる)。
分析対象のコントリビュータを選んでみた
https://github.com/rails/rails/graphs/contributorsから、コミット数が多い順にコントリビュータを並べたグラフを見て、
リポジトリ登録から2年以降に初めてのコミットがあり、コンスタントにコミットを続けているコントリビュータ上位4名選択。
分析対象のコントリビュータのコミットを集めてみた
途中

↑

9/5†

やったこと

論文を読んだ
- OSSプロジェクトへの新規参入者のための研究
  - Overcoming Open Source Project Entry Barriers with a Portal for Newcomers
    OSSプロジェクトの新規参入者をサポートするために作成されたポータルを作成。次の内容を表示する。
    貢献を始めるためのステップバイステップのフロー、簡単なタスクのリスト（プロジェクトによって提供されるタグに基づいてフィルターされたタスク）、
    プロジェクトに必要なスキル、コミュニティが提供するチュートリアルへのリンク、コミュニティとの対話のためのメッセージテンプレート、
    ドキュメントに関連する整理された情報、コーディングスタイルなどのコード関連のドキュメントへのリンク。
    65人の学生にポータルを使用してOSSプロジェクト（LibreOffice, JabRef）に参加してもらい、日記、アンケートなどの定性的データから有用性を評価。
  - Hipikat: A project memory for software development
    タスクに関連するソースコード、ドキュメント、ディスカッション等のアイテムを推奨するツールを作り、新規参入者を支援する。
    関連しているアイテム同士にリンクを張り、リンクされているアイテムを推奨アイテムとして表示。
    評価は、Eclipse Bugzillaから修正済みバグレポートをサンプリングし、ツールにバグを入力した際に、実際にバグに関連したソースファイルを推奨できるかprecisionとrecallの測定、
    Eclipseの過去に完了した機能拡張に関するタスクに取り組んでもらう。その際にツールを使用してもらい、ツールの有用性を確認するためのインタビューを実施。
    また、Eclipseの開発メンバー数人にツールを利用せずに同様のタスクに取り組んでもらい、ツールを利用する新規参入者と利用しない熟練者の結果を比較。
- バグレポートの要約に関する研究
  - Summarizing Software Artifacts: A Case Study of Bug Reports
    バグレポートの要約を正確に行えるかどうかを検討。
    7人の大学院生に計36個のバグレポートの要約を作成してもらい、これらを用いて抽出型のサマライザを学習し、学習していないサマライザとのROC曲線と、AUROCの比較。
  - Unsupervised Deep Bug Report Summarization
    AutoEncoderモデルを使った、抽象型のサマライザを実装。
    公開されているバグレポートの要約を使ってサマライザを学習し、precison、recall、F-score、Rouge-Nで以前のアルゴリズムと比較。

自分がOSSプロジェクトに参加するのに役立つこと
- これらが分かりやすく示されていると参加しやすい
  - 歴史
  - 現在抱えている問題、議論と、これらに助けが必要かどうか。問題に関連するソースコードやドキュメント等。

↑

8/20†

やったこと

An Empirical Study of Long Lived Bugsを読んだ
長期間解決されないバグについての分析。
すぐ解決されるバグに比べて特筆すべき特徴や傾向はなし。
ソフトウェアのクラッシュやデータの損失など、重大なバグの中にも放置されているものもあった。
オープンソースプロジェクトに参加してみようとした
- 現在の開発状況が分かりにくい（どこまで作業が完了していて、今何を議論していて、何をやろうとしているのかわかりにくい）
- Slackなどの縦に流れるチャット履歴を追うのがしんどい
PRを送ってみた
issuehuntでお金が着いているissueの中で、good first issueのラベルが付いているissueに取り組んだ。
単純な修正だったので即承認してもらえたが、プログラムを考える時間よりも、ドキュメントや周辺のソースコードを読むのに時間がかかった。

次のMTGまでにやること

自分がコミュニティに参加するのに役立つようなことを考える
コミュニティの履歴やチャンネルでの議論の可視化、要約
- どんな要約があったらいいかを考える
- 既存の可視化、要約技術について調べる
  - CodeCity: モジュールを街(建物)に見立てて可視化
  - Gource: プロダクトを開発者が作り上げる過程を可視化
issueの難易度の推定
- 開発者の実績を基にバグをアサインするバグトリアージに近い？
- good first issueラベルを使う
- 素人とエキスパートの解決するissueの違いについて調べる

論文を読む
- SocialBarrier関連で初心者向けに要約を行う論文がある
  - Overcoming Open Source Project Entry Barriers with a Portal for Newcomers
- APIドキュメントの要約などの論文を読み、どのような評価が行われているか調べる
  - Generating query-specific class API summaries
- 素人と熟練者が取り組んだissueやコードの違いを比較した論文がないか調べる

↑

8/7†

やったこと

どんなOSSを対象にした研究がしたいか考える
- 開発者は完全にボランティア
  例: Apache
  Apacheは財団があるが、開発者は完全なボランティアで、財団からの給料は出ていない。
  他の会社に勤めていて、かつApacheのOSSにフルタイムで開発にあたっている人もいるかもしれないが。
  TODO: Linuxカーネルとかディストリとかはどうなんだろう？
- コア開発者がフルタイムで開発にあたっている
  つまり、コア開発者はそれを本業の仕事として給料をもらい、生計を立てているようなOSS
  例: React(Facebook), TensorFlow(Google), VSCode(Microsoft), etc.

研究対象のOSS開発者がどういった問題を抱えていそうか調査してみる
コア開発者がフルタイムで開発にあたっているOSSであるvscodeについて、issue、PRで、更新が古い順かつ、開いているものを5つ程見てみた
- issue
  - 一番古いのは4年前
  - MS社員が担当者の任命やラベル付けはしているが、コメントがない
  - 議論がされているものの、結論が出ていない。途中で止まっている
- PR
  - 一番古いのは2年前
  - 社員にケチをつかられて、PRを立てた人が追加の変更をしないまま放置
  - PRを立てた人が実装を途中であきらめた
  - 社員によるレビューが何回か行われているのに、途中で行われなくなった（理由は謎）
  - issueに基づくPRではあるが、プランに含まれていないという理由で1年以上Backlogに放置（issueの方もオープン状態）
- その他issueとPRを見てて分かったこと
  - issueのコメントでいろんなユーザが「はよこの機能追加してくれ」と言っているが社員のレスポンスがないものがあったりする（issueの参加者は65人）

来週までにやること

研究対象のOSS開発者がどういった問題を抱えていそうか調査してみる(継続)

↑

7/25†

やったこと

以下の論文を流し読みしました
- Two case studies of open source software development: Apache and Mozilla
  上位15名の開発者が、コード生成への貢献の約80%を占めていることがわかった。
  コア開発者は新機能の開発、ペリフェラル開発者はバグ修正を主なタスクとしていることがわかった。
- Who Gets a Patch Accepted First? Comparing the Contributions of Employees and Volunteers
  ボランティアは従業員よりも26倍多くrejectされていることがわかった。
  プルリクが作られてからマージされるまで、従業員は2日なのに対して、ボランティアは11日かかっていることがわかった。
  - 気になったこと
    時間がかかると貢献から遠のいてしまうのではないか？
    ボランティアが遠のくと、OSSの品質（細かなバグ）に影響が出るのでは？
    パッチ受け入れとOSSの品質に関係する論文を探す

その他気になっていること
- OSSを収益化すれば、OSSが廃れる？
  社会規範から市場規範へ切り替わることで問題は発生するのか？
  OSSの持続可能性を高めるため, OSSを収益化する動きがある.
  - GitHub Sponsors(GitHub, Inc.): 5000ドルばらまくキャンペーン
    GitHubのOSS開発者への寄付が可能.
  - Issuehunt(BoostIO, Inc.): 資金調達1億円
    Issueに報酬を設定し, PRが承認されれば報酬を得る.
  - Beerpay
    オープンソースプロジェクトへの寄付が可能.
  - Dev(FRAME00, Inc.):
    オープンソースプロジェクトに対して毎月仮想通貨を配布.

これによる問題
OSSコミュニティに市場規範が持ち込まれると, 今まで金銭的見返りを求めずに貢献されていたものに対して, 対価を求めるようになるのではないか？
今までは非金銭的な動機でOSSに貢献していたのが、金銭的な動機に切り替わるのか？
金銭的見返りのないコミュニティ（社会規範のコミュニティ）に, 優秀な貢献者が来なくなる？金銭的見返りのないコミュニティが廃れていくのでは？
市場規範: 金銭的なつがりを基に価値判断される世界の規範. 賃金を払う. 対価を求める社会規範: 社会的なつながりを基に価値判断される世界の規範. ギフト経済. 金銭的見返りを求めない

来週までにやること

↑

7/18†

やったこと

以下の論文を流し読みして、オープンソースプロジェクトの新参者に関する研究について少しわかってきた
- オープンソースプロジェクトへ初めて参加する際の社会的障壁に関する論文
  - Socialization in Open Source Software Projects A Growth Mixture Modeling Approach
  - Social Barriers Faced by Newcomers Placing Their First Contribution in Open Source Software Projects
- One-Time Contributorsに関する論文
  - One-Time Contributors to FLOSS Surveys and Data Analysis
  - Understanding the impressions, motivations, and barriers of one time code contributors to FLOSS projects a survey
- 読んでて気になったこと
  そもそもコア開発者とペリフェラル開発者の割合ってどのくらい？One-Time Contributorの割合は？どれくらい貢献してる？
  昨日それっぽい論文見つけたので来週までに読んできます

来週までにやること

コア開発者やペリフェラル開発者について知るため
- https://dl.acm.org/citation.cfm?id=567795
- More Common Than You Think: An In-Depth Study of Casual Contributors
  コア開発者、ペリフェラル開発者の割合、ペリフェラル開発者が実際どの程度役に立っているのかわかりそう。
- How does contributors involvement influence open source systems
  コア開発者、ペリフェラル開発者によって投稿されたパッチのビルドの成功率の比較。ペリフェラル開発者が投稿するパッチの質が分かりそう。
めっちゃ読みたい論文
Who gets a patch accepted first?: comparing the contributions of employees and volunteers
企業のオープンソースプロジェクトにおいて、従業員の開発者とボランティアの開発者の提出したパッチの受け入れに関する違いについて調査した論文。
ボランティア開発者が何かしらの問題に直面してそう。

↑

6/17†

やったこと

CytoscapeのAPI機能を利用して、ネットワークの図の作成を自動化した
GitHubから適当なリポジトリを選んで、Cytoscape Core AppsのNetwork Analyzerを使って分析してみた（結果を見せる）

問題点

CytoscapeのNetwork Analyzerは機能が限定的で、かゆいところに手が届かない
⇒ pythonのSNAライブラリNetworkXに移行する

進行中

issueやissue_commentの数が多いリポジトリのからのデータの取得
issueやissue_commentの数が多いリポジトリからネットワークを抽出する

↑

6/10†

やったこと

GitHub APIから特定のリポジトリの全てのissue(open and closed)とそれに対応するcommentを取得する
issue投稿者とcomment投稿者のノードを作り、コミュニケーションをとった人同士でエッジを作って、1か月ごとにDBに保存する

↑

6/3†

やったこと

研究概要を考える

↑

5/23†

やったこと

The Role of Participation Architecture in Growing Sponsored Open Source Communitiesを読んでいます。

↑

5/7†

やったこと

グラフ描画のツール作成
「Contrasting Community Building in Sponsored and Community Founded Open Source Projects」を読んだ
アメリカ合衆国退役軍人省の医療情報システム(public domain)を分析して、コミュニティ主導のオープンソースプロジェクトとスポンサー付きのオープンソースプロジェクトの主要な課題を明らかにした。
スポンサー付きのオープンソースプロジェクトでは、健全なコミュニティの構築、優秀なコントリビュータを惹きつけること、所有権とコントロールに関する曖昧さの解決、つまり、スポンサー付きのオープンソースプロジェクトでは所有権とコントロールに関することが曖昧になるということが課題であると述べていた。

↑

4/18†

やったこと

mysqlの設定を変更して、ghtorrentのデータをにインポートを高速化した
今のペースだと最低1か月以上かかるので、
日別に分割されたmongoのダンプファイルが公式から出てるので、これを使ってみる？

「Two Case Studies of Open Source Software Development: Apache and Mozilla」の一部を読んだ
アブストラクトとイントロダクションのRQの部分を訳した。
この論文が何を明らかにしようとしているのかは分かった（多分）。

↑

Templates†

添付
[添付]

堀口 の履歴(No.21)

研究概要†

要旨†

新しい点†

関連研究†

ToDo:†

研究MTG†

9/12†

9/5†

8/20†

8/7†

7/25†

7/18†

6/17†

6/10†

6/3†

5/23†

5/7†

4/18†

Templates†

堀口の履歴(No.21)