オープンソースの体裁
—— 公開と開放の間にある溝

1. 公開されているが開かれていない

トキストレージには二つのリポジトリがある。lpはランディングページとエッセイ群、qrはTokiQRの本体。どちらもGitHub上でPublicに設定されており、誰でもソースコードを見ることができる。

だが、lpリポジトリにはREADME.mdがなかった。リポジトリを開くと、500以上のHTMLファイルが並ぶだけで、何のプロジェクトなのか、どう動かすのか、何も説明がない。qrリポジトリにはREADMEがあったが、数行の概要だけだった。

LICENSEファイルはどちらにもない。つまり、コードは見えるが、使っていいのかどうかわからない。法的には「著作権者の許諾なし」と同義だ。CONTRIBUTING.mdもない。コントリビュートしたくても、どこから手をつければいいのか、PRの作法は何なのか、言語は日本語でいいのか——何もわからない。

リポジトリのDescriptionは空。Homepage URLは未設定。Topicsもゼロ。GitHubの検索にも、トピック一覧にも、どこにも引っかからない。

公開されていることと、開かれていることは、まったく異なる。

2. 玄関をつくる——README

READMEは、リポジトリの玄関だ。初めて訪れた人が最初に目にするもの。ここに何も書かれていなければ、訪問者は中に入る手がかりを持たない。

lpのREADMEには、プロジェクトの概要（三層分散保管とは何か）、コンテンツの構成（114本のエッセイ、100以上のユースケース）、技術スタック（GitHub Pages、自前のアクセス解析）、ライブサイトへのリンク、ローカルでの起動方法を書いた。

qrのREADMEは全面的にリライトした。ASCIIのアーキテクチャ図で、録音からQRコード生成までのデータフローを視覚化した。Codec2のWASMモジュール、WebPエンコーダのSafariフォールバック、QRコード バージョン40の2,953バイト制約。ブラウザ互換表をテーブルで示し、URL形式のフォーマットを明記した。

READMEを書く行為は、自分のプロジェクトを他者の目で見直す行為でもある。「何が面白いのか」「何が独自なのか」「何が制約なのか」——自明だと思っていたことを言語化すると、自分自身の理解も深まる。

3. 契約書を置く——LICENSE

LICENSEファイルがないリポジトリは、法的にはAll Rights Reservedだ。コードが見えるからといって、使っていいわけではない。

MIT Licenseを選んだ。「このソフトウェアを自由に使って、改変して、再配布していい。ただし著作権表示を残してね。無保証だよ」——これだけのシンプルな契約だ。

1000年残すことを設計するプロジェクトに、制約の多いライセンスは似合わない。残すことの本質は、できるだけ多くの人が、できるだけ自由に扱えることだ。オープンであること自体が、プロジェクトの思想と一致する。

LICENSEは「使っていい」の宣言だ。
置かないことは、沈黙による拒絶になる。

4. 窓口を開く——Issue テンプレートとPRテンプレート

Issueは、外部からの対話の窓口だ。バグを見つけた人、機能を提案したい人、質問がある人——彼らが最初に触れるインターフェースがIssueテンプレートだ。

Bug Reportテンプレートには、再現手順、期待される挙動、実際の挙動、環境情報（ブラウザ、OS、デバイス）を用意した。qrリポジトリのテンプレートには、Codec2のモード（450/700C/1200/1600/2400/3200）の選択欄も追加した。音声コーデックのモードによって挙動が変わるこのプロジェクト固有の情報だ。

Feature Requestテンプレートには、概要、動機、提案する解決策、検討した代替案。qrリポジトリのテンプレートには制約リマインダー——「オフラインで動くこと」「サーバー依存なし」「QR Version 40 = 2,953バイト上限」——を組み込んだ。制約を事前に共有することで、実現不可能な提案を減らせる。

PRテンプレートには、Summary（何をしたか、関連Issue番号）とTest Plan（検証方法）。qrリポジトリのテンプレートには「ChromeとSafariの両方でテスト」を必須チェック項目にした。WebP WASMフォールバックがSafari固有の問題であることは、前のエッセイで書いた通りだ。

テンプレートは、コントリビューターへの「ここに書いてくれればいい」という道しるべだ。白紙のIssueフォームは、何を書けばいいかわからない人にとっては壁になる。

5. 居場所を示す——Description、URL、Topics

GitHubのリポジトリには、コードの外側にもメタデータがある。Description（説明文）、Homepage URL（ライブサイトへのリンク）、Topics（タグ）。

lpのDescriptionは空だった。「TokiStorage Landing Page — 存在証明の民主化。三層分散保管で声・画像・テキストを1000年残す。」と設定した。Homepage URLにtokistorage.github.io/lp/を指定した。Topicsにはpreservation、codec2、github-pages、open-sourceなどを追加した。

qrのDescriptionは古い表現だった。「Voice Memorial QR - 音声をQRコードで永久保存」——音声だけでなく画像もテキストも扱えるようになった今、実態と合っていない。「TokiQR — 音声・画像・テキストをQRコード1枚に。Codec2 WASM、完全オフライン対応。」に更新した。

さらに、プロフィールREADME用のリポジトリtokistorage/tokistorageを新規作成した。GitHubは、ユーザー名と同名のリポジトリにREADME.mdを置くと、プロフィールページに表示する。三層分散保管の概要と、lp・qrリポジトリへのリンクを記載した。

6. 見えない貢献——git config

すべての整備が終わったとき、ふと気づいた。GitHubのcontributionグラフ——プロフィールページの緑のタイル——が更新されていない。数百のコミットを重ねたのに、草が生えていない。

原因はシンプルだった。git configのメールアドレスが未設定で、コミットのAuthorメールがMacのホスト名から自動生成されたtokistorage@satouminanoMacBook-Pro.localになっていた。GitHubは、コミットのメールアドレスがアカウントの登録メールと一致しないと、contributionとしてカウントしない。

何百ものコミット、何十ものPull Request、500ページ以上のコンテンツ追加——その痕跡がプロフィールに一切反映されていなかった。

git config --global user.emailを正しく設定した。たった1行の設定変更で、今後のすべてのコミットがcontributionグラフに反映されるようになる。

設定の1行が、存在の証明を左右する。
コードを書いた事実は変わらないが、見える形で残るかどうかが変わる。

これは、このプロジェクト自体の思想と奇妙に重なる。トキストレージが解決しようとしている問題——声や画像が、適切な形式で保管されなければ消えてしまう——と、gitのメール設定が合っていなければ貢献が見えなくなる問題は、構造的に同じだ。存在していても、正しく記録されなければ、存在しなかったことになる。

7. 体裁は敬意だ

READMEを書き、LICENSEを置き、Issueテンプレートを整え、Descriptionを設定する。これらは「やらなくても動く」作業だ。コードは変わらない。サイトの表示も変わらない。機能は一つも増えない。

だが、これらは他者への敬意の表明だ。

READMEは「あなたの時間を無駄にしません、ここに概要があります」という敬意。LICENSEは「あなたが自由に使えることを保証します」という敬意。Issueテンプレートは「あなたの声を聴く準備ができています」という敬意。Descriptionは「あなたが探しているものかどうか、すぐにわかるようにします」という敬意。

ソロ開発者にとって、これらは後回しにしがちだ。自分だけが使うなら不要。自分だけがコードを読むならREADMEは要らない。だが「公開」を選んだ時点で、読者は自分だけではなくなる。

オープンソースの体裁を整えることは、コードを世界に開く行為だ。扉を開けて、「どうぞ」と招き入れる。その「どうぞ」がなければ、扉はただの壁に見える。