Redmine is Dead

ぶっちゃけ、私も “XX is Dead” という記事を書いてみたかっただけです。はい。

私はまだRedmineユーザです。Redmineは私をExcel地獄から救ってくれましたし、これまでにどれだけ助けられたかわかりません。Redmineを愛していると言ってもいいかもしれません。

ですが、使えば使うほど、競合製品/サービスに遅れを感じ、将来が不安になります。

なぜ私が「Redmineは死んだ」と考えるのか、それでもなおRedmineユーザであり続けるのかを書きたいと思います。

Redmineの死因

私が「Redmineは死んだ」と考える理由は大きく2点あります。

1. レガシーなシステムになってしまった

Redmineは現代のインテリジェンスな競合製品が標準的に持つ以下のような機能を持っていません。

我々Redmineユーザは、Redmineにこれらの機能を実装して現代的なソフトウェアになって欲しいと願っていますが、Redmineの開発者であるJean-Philippe氏やコミッターの方々はそうは考えていないように見えます。彼らは、Redmineを12年前のシステム開発のためのソフトウェアだと考えているようです（そんな印象を受けます）。

分散型バージョン管理システム（DVCS）のcloneやPull requestがサポートされていない

RedmineではSCMに使用できるDVCSとしてGitやMercurialをサポートしていますが、cloneやPull requestができません。これは、Redmineのリポジトリ機能がSubversionをメインターゲットとしている（たぶん）ことに由来していると考えています。

Subversionのような集中型バージョン管理システムにはリポジトリがひとつ（中央リポジトリ）しかありません。開発者は中央リポジトリからローカルにチェックアウトしてワークスペースを作り、ワークスペースから中央リポジトリに対してコミットを行います。コミット権限を持たないユーザはパッチファイルなどを作成してコミッターにコミットを依頼する必要があります。また、中央リポジトリはバージョン管理とコミットの受付するシンプルな機能しか持たないので、高度なGUIを備える必要がありません。ブランチのマージなどはワークスペース側の仕事ですし。このため、Subversionリポジトリサーバは純粋なリポジトリとしての機能に特化していることが多いように思います。このような理由により、Redmine自体が中央リポジトリとなる必要はなく、別に立っている中央リポジトリの情報を参照するだけで事足りるのです。

それに対し、GitのようなDVCSは各環境にリポジトリが存在し、集中型バージョン管理システムのように中央リポジトリが存在しないため、ハブとなるリポジトリを決める必要があります。社内の共有フォルダ上のリポジトリをハブにしてもかまいませんが、大体はGitHubやBitbucket、GitLabのようなプロダクトを利用します。各リポジトリ間の同期はコミット情報を連携して行います。これは、ハブリポジトリにPushする権限を持たないユーザの改修を取り込む際も同様ですので、そこで必要になるのがPull requestです。Pull requestを実装するということは、ハブリポジトリにはGUIが必要となります。GUIが存在するということは、その周りにゴテゴテと機能が追加されていき、その結果GitHubが誕生することになるのです。

つまり、DVCSをサポートするということはcloneやPull requestをサポートしてハブリポジトリとなることに他ならないのです。逆に言うと、それができないRedmineは、新規のDVCSベースのシステム開発に採用されることはまずないでしょう。

redmine.orgにもIssueは上がっていますが実現には遠いように思います。

シンタックスハイライトで使用できる言語/フォーマットが少ない

Redmineのシンタックスハイライトで使用できる言語/フォーマットは数えるられるほどしかありません。これは、Redmineで採用しているCodeRayというライブラリの制約によるものです。

巷の女子高生に大人気！ナウくてヤングなイケイケプログラム言語はたくさんありますが、それらはまったくサポートされていません。例えば、Kotlin、Scala、Rust、そしてSwiftまでもサポートされていません。シンタックスハイライトは必ずしも必要な機能ではありませんが、Redmineのメインターゲットはやはりシステム開発者ですので、自分たちが日常的に使用しているプログラム言語がサポートされているかどうかは重要なポイントになるでしょう。

CodeRayからRougeに変更する動きもありますが、今のところ実現には至っていません。1

SNS機能がない

Redmineにはフォロー、メンションなどのSNS機能がありません。フォローと似た機能に「ウォッチ」がありますが、ユーザをウォッチすることはできません。個人のフィードは見ることができます。

そもそもRedmineでは、Issueの担当者とステータスを変えることでIssueの受け渡しを行い、プロジェクトを推進します。「コーディングが終わったのでテストお願い」「テストでエラーが出たので差し戻し」のような感じです。この考え方自体は間違いではないのですが、「これどう思う？」のような気軽に意見を聞きたいときに、わざわざ担当者を変えるのは大げさです。このようなときにメンションできるとすごくいいですよね。

ちなみに、メンションを可能にするプラグインはありますが、やはりフォロー、メンションなどはRedmineがネイティブにサポートするべきのように感じます。

RedmineはGitHubのようなOSSホスティングサービスではなくプロジェクト管理ソフトウェアであるので、ターゲットが違うということなんでしょうが、今の時代テレワークなどもありますし、Redmineだけでコミュニケーションが完結できるのが望ましいですよね。

デスクトップ通知がされない

してほしいですね。

2. 開発体制への不安

では、今後ユーザと開発者の間のギャップが解消されていくかというと、そこには開発体制への不安があります。

コミッターがわずか数名しかいない

Redmineのアクティブなコミッターは数名しかいないそうです。昨年Redmine.JP/MyRedmineを運営しているファーエンドテクノロジーの前田さんがコミッターになられた際にもその辺を少し吐露されていましたが、今後に期待したいところですね。

開発の基盤をGit/GitHubに移してくれない

前述の「Redmineのリポジトリ機能はSubversionをメインターゲットとしている」と考える理由のひとつが、Redmineの開発自体がSubversionを基盤としている点です。Git/GitHubへの移行を要望するIssueも上がってはいますが、実現は難しいように思います。

Subversionがダメなわけではないですが（いや、ダメだと思いますが・・・）、パッチを作って提供するよりPRを出すほうがあきらかに垣根は下がりますので、世界中のエンジニアに対してコントリビュートの門が開かれるんじゃないかと思います。

それに・・・ほら・・・あれじゃないですか、パッチ提供じゃコミットログに自分の名前載らないじゃん。

OSS活動って奉仕活動じゃないと思うんです。やったぞ！という手応えというか、みんなが幸せになるだけじゃなくて頑張った自分だけの特別な何かが欲しいじゃないですか。メジャーリポジトリのコミットログに自分の名前が載ることはその一つだと思うんです。映画のスタッフロールに名前が載るようなもんですよ。モチベーションに繋がりますよね。まあ、金につながるのが一番いいんですけど。

redmine.orgがイケてない

redmine.org で使用されているバージョンがなんか古いです。おそらく2.xと思われます。ドッグフーディングできてないですよね。未解決のIssueだけ検索したいなぁ。。。Plugin directoryももうちょっとなんとかならんもんかなぁ。

Redmineからの移行する選択肢

GitHub

みんな大好きGitHub。Redmineはオンプレミス環境に立てていることが多いと思うので、移行するとなるとクラウドであることがネックになるのではないでしょうか。オンプレミスのGitHub Enterpriseもありますがちょっと高価かな。

Bitbucket

GitHubと双璧をなすアトラシアンのやつです。

Gitbucket

GitHubのクローンです。以前GitHubから似すぎと指摘されたことがあったそうです。現在のUIは当時とは別物ですね。クラウドサービスはないので、オンプレミス環境に構築する必要があります。

GitLab/GitLab.com

GitLabもGitHubのクローンと言われますが、現在は独自性が強く、オールインワンの超ヘビー級なシステムになっています。Redmineから移行を検討する際の最有力候補になると思います。RedmineのIssueとの連携できることも大きなメリットです。

GitLabのインストールは苦行と言われた時代がありましたが、現在はGitLab公式のDockerイメージもあり、簡単に立てることができます。

GitLabは以下の機能を持っています。

GitLab.comはGitLabのクラウドサービスです。GitLab.comがデータを消失し、バックアップが機能しておらず、リカバリ作業をYoutubeでストリーミング配信したのは大きな話題になりました。

私は現在、RedmineとGitLabを併用しています。できればGitLab一本にしたいと考えているのですが、なかなか実現できません。その理由を書きたいと思います。

GitLabに移行しきれない理由

1. Issue番号の採番の違い

RedmineではIssueの番号はインスタンスで一意になるように採番されますが、GitLabではプロジェクト毎に採番されます。GitLabでもIssueを別のプロジェクトに移動するができますがその際は番号が変わります。

ひとつのインスタンス内にプロジェクトがひとつだけでリポジトリもひとつだけ、であれば移行に問題はないのですが、プロジェクトが複数あったり、複数のリポジトリがある場合はIssueの番号が問題になります。

私はすべてをあきらめ、IssueはRedmineで管理しています。

また、RedmineからGitLabへのIssueの移行は、 Redmine のプロジェクトを GitLab Issues へ移行する - Qiita が参考になると思います。私も時間があるときに試してみたいと思います。

2. カスタムフィールドがない

カスタムフィールドは非常に便利な機能です。GitLabにはカスタムフィールド相当の機能がないので、どのように移行するか検討する必要があります。

GitLabの記法はMarkdownですので、Front Matterを書くことができます。特別なことはできないのですが、将来的に特別なことができそうな気がするので、どうしようもないカスタムフィールドはFront Matterに書いておくのも一案かなと思います。

---
ここに: YAML記法で書く
---
本文

3. IssueのDescription欄のヒストリが管理されない

RedmineではIssueの説明欄を更新した際にHistoryで差分をみることができますが、GitLabではDescription欄を更新したことはわかりますが変更内容がわかりません。この点についてはこのIssueでディスカッションされています。

4. Wikiがイケてない

Wikiがイケてない理由はいくつかあります。

TL;DR

なんだか「と思う」「たぶん」が多い要領を得ない記事になってしまいました。すみません。

もしRedmineが開発基盤をGitHubに移した暁には、ガシガシPRを書いてやりたいと思います。Rubyはそこまで得意じゃないけど。

その後のエントリっぽいものを書きました。

  1. 2018/12/9にリリースされた Redmine 4.0 でRougeに変更されました！ ↩︎