プログラミング言語のパッケージシステムとそれを中心にしたコミュニティについての研究がしたい

プログラミング言語におけるライブラリを解決するシステムについての研究をしたいという考えがあります．やりたいことをまとめるためにいろいろまとめてこの記事にまとめます．

markdownからそのままコピペした感じなのでちょっとおかしいところがあるかも

アウトライン

研究の概要

動機

パッケージマネージャの定義付け

研究段階

概要

プログラミング言語におけるパッケージマネージャと，そのコミュニティについて

適切に分類し

どのようなパッケージマネージャ，コミュニティが発達していくのかといったことを調べ

最終的には実際にその研究の理論を実際に運用し測定する

といったことをしたい．

動機

僕の好きな言語にDartというものがある．Googleによって開発された所謂AltJSだが，その他のAltJSとは違い，DartVMというVMをブラウザに搭載最終的にはJavaScriptを置き換えるという目標によって作られた．しかし，VMをブラウザに搭載するという目標を諦めReadableなJSにトランスパイルするdev_compilerを作り，所謂他のAltJSと同じように使っていくことを目標に切り替わっていった．現在でも開発が続けられている．

有り体に言ってしまえばDartは流行らなかった．反対に，Node.jsのパッケージマネージャであるnpmはどんどん発展していったように思う．そこでどのようなパッケージマネージャが発達するのか，ということをぼんやりと考えるうちに「発達するパッケージマネージャにはどのような要素があるのか」「そのコミュニティに何か特徴はあるのか」ということを実際に調査していきたいと考えるようになった．

今まで考えたこと・調査したことなどのメモ

パッケージマネージャシステムは図書館のような知識情報システムであるといえるのではないかということ

https://gyazo.com/fa9501206eefbf2d0f2623219fc90c95

Pはパッケージ

Hubはシステム

細かな部分を全てふっ飛ばしてざっくりと書くとパッケージマネージャはこのような図で表せると考える事ができる．

パッケージがHubに集められてきて，それがユーザーによって使われていく．

もちろんどのように使うのかなどの方法はそれぞれ異なってくる．

このシステムにおけるHubを図書館に，Pを本に置き換えると図書館のシステムを表していると考えることもできる．こちらももちろん細部は違うが．このようにパッケージマネージャは知識情報としてのパッケージをあつかうシステムであるとみなせるのではないかと考えている．

上の図はプログラミング言語のパッケージマネージャにかぎらず，apt，Homebrew，chocolateyといったソフトウェアパッケージマネージャや，UnityのAsset Storeなどに適用できるのではないかと考えている．

図書館などの情報システムとの差異

パッケージマネージャと図書館を情報システムとして比較していく．

パッケージマネージャ全体と図書館などの比較

扱っているものが情報であるか物理であるか

本は物理的に存在するが，パッケージマネージャが扱うパッケージは多くの場合データである．データはコピーが可能であり，またパッケージマネージャで扱われるデータはコピーされることが妥当であるためこれは大きな差異であると考える事ができる．電子書籍を扱う図書館の場合は除く．

この差異によって生まれる違いとしては次のようなものがあげられると考えられる．

貸出か取得か

図書館を運用する上では，誰が本を借りているか，いつまで借りているかなどの情報はシステムを運営する上で重要であると考えられる．一方でデータある場合コピーが可能なため，貸出ではなくそれぞれユーザが取得(多くの場合はダウンロード)し利用することができる．一方で，そのデータが有料で扱われている場合コピー可能なデータをどのように守るかなどの問題が発生する．

パッケージを登録するのがパッケージ作者であるかそうでないか

図書館はそれぞれの本を図書館の本として登録するために司書が活動している（はず）．一方でパッケージマネージャーでは多くの場合パブリッシュ時にユーザーが登録情報について記載する

たとえばpackage.jsonみたいなファイルにメタデータを書いてそれがvalidかどうかを判断する，みたいな仕組みが多い

つまりここがユーザーの手に渡ると中央にスタッフが必要なくなる

一方で質が保てるかみたいな問題もある

データフィールドの設定

パッケージマネージャシステムの多くはパッケージの作成者（公開者）に対しそのパッケージに関する情報を公開時に求めることができる（例:パッケージ名，パッケージの説明，パッケージの作者情報（メールアドレス，名前，その他サービスのアカウント名），依存関係，変更記録など）．これはシステムを作成する上でどのようにそのパッケージの情報を扱うかということを設計しやすいという利点がある

研究の流れ

基礎知識の補充

現状情報科学に関するある程度の知識はあるため，必要なものを考える

図書館情報学

社会学

もともとどういう分野か理解できていない部分があるのでそこを埋めてからじゃないとなんともいえない

社会学ではなさそう

コミュニティに入ってくる人間がどういう人間かがわかっていることが重要

それがわかっているとどういう生存戦略を立てるべきかがわかる

i先生ありがとうございます

情報工学

プログラミング言語論

ソフトウェア工学

あとなんだろ？いろいろある気がする……

パッケージマネージャー関連の調査

評価方法の確立

実装