Johnson氏は、2005年後半からwraptastic.orgでRPM開発ツリーを維持してきた。ほとんどのLinuxディストリビューションではRPM 4.4.2が使われるが、Johnson氏はその後もバグの修正と機能の追加を続けていた。現在バージョン4.4.9になったこの開発ツリーがrpm5.orgの活動の土台である。バグ修正のほか、4.4.2にはなかった目覚しい改良が加えられている。RPM本体と言語バインディングのソースtarボールと.rpmパッケージは、rpm5.orgのFilesセクションからダウンロードできる。
使用されなくなった古いロックをRPMデータベースに自動的に検出し、削除する新機能は、エンドユーザの注目を集めるだろう。このようなロックは、パッケージのインストールなどの処理中にデータベースがスタックし、RPMプロセスがフリーズまたはクラッシュを起こした場合に生じる。ロックの状態が修復されるまで（そして、おそらくはデータベースが修復されるまで）、新しい変更は行えない。
4.4.9の改良の多くは、開発者とパッケージメンテナが使う機能を使いやすくすることが目的である。Johnson氏が一番重要な改良として挙げたのは、削除の順序指定機能（パッケージを削除する順序を指定できるのでアンインストールの安全性が高くなる）と単純なマルチライブラリパッケージング（32ビットと64ビットのバイナリが混在するシステム向けのパッケージを作成する）の2つだ。
また、依存関係のチェックも強化され、不在依存（あるパッケージが存在しないことに別のパッケージが依存する関係）、ランタイムプローブ（run-time probe）依存、二重リンクアップグレードチェーン（アップグレードの追跡が可能）などの複雑な依存関係を扱えるようになった。さらにJohnson氏が強調するのは、RPMがNative POSIX Thread LibraryをLinuxで初めて使ったプロジェクトだという点だ。
コミュニティの再確立
Johnson氏は、RPMの将来のリリースについて既に技術的な目標を心に決めているが、rpm5.orgの開設については、断片化し、分岐した（と彼は表現した）RPMコミュニティベースを統一するための布石であると説明する。彼によると、ベンダの規模が大きくなったことから、RPMのようなコアユーティリティの変更に伴うリスクの係数が本質的に大きくなり、必然的に開発が停滞し、逸脱に向かったのだという。
よって、RPMを前進させるには、まず現状の分岐を一本化し、すべてのパッチを統合する必要がある。この統合を進めた結果、RPM 5.0は“どこでも互換性のある”リリースになるだろうと、Johnson氏は言う。
彼の予想では、“どこでも互換性がある”という言い回しの意味を定義することはパッチを統合することより難しいが、特定のベンダに偏らない開発の場を設けることは目標を達成する正しい取り組み方であり、これに関して彼は楽観的だ。彼は既に技術者の募集を終えた。
「チームを集めるのは簡単でしたね。ここ数年の電子メールやIRCやバグレポートを通じて、RPMの開発者はほぼ全員知ってましたから」。このチームの名簿はrpm5.orgで誰でも閲覧できる。また、ロードマップの素案も公開されている。
ディストリビューションと標準サポート
しかし、RPM開発の再興に取り組んでいるのはJohnson氏だけではない。2月にレポートした（翻訳記事）とおり、Red Hatも同社のディストリビューションで使っているRPMパッケージを整理し、開発を促進するためにチームを設立した。多くのディストリビューションと同様にRed HatもJohnson氏のアップデート版ではなくRPM 4.4.2を使い続け、このリリースに対するrpm.orgによる整理と最新化の作業に基盤を置いている。
2本の開発ツリーが同時に進行するのは、RPMベースのディストリビューションにとってジレンマである。万が一でも互換性が途絶えれば、どちらをサポートするかディストリビューションは選択を迫られる。
互換性が維持されている間でさえ、時間と人的リソースをどこに集中するかを決断しなければならない。Novellはrpm.orgプロジェクトに関してRed Hatと手を結んだが、Mandriva、cAos、PLDはJohnson氏のrpm5.orgに協力することを決めた。
RPMパッケージ形式は、Linux FoundationのLinux Standard Base（LSB）仕様でも重要なコンポーネントである。Filesystem Hierarchy Standardなどの他のLSBコンポーネントと違って、RPMはLinux Foundationの管理下にない。
Linux Foundationマーケティング・ディレクターのAmanda McPherson氏は、RPMパッケージ形式の分岐は問題の種であると認めるが、解決策はあるとする。
LSB仕様ではRPMの現在の機能の一部しか要求されないため、RPMファイル形式に新しい機能を追加しても互換性が失われる可能性は低い。「そう決めた最大の理由は、alienとの互換性を保つためです」と、McPherson氏は説明する。同様に、分岐したリリースでファイル形式の変更が決定され、互換性が失われた場合でも、alien型の変換ユーティリティを使うことで問題は解決できる。
長期的にはLSBは優勢な方に従うだろう、とMcPherson氏は考えている。「もし分裂したら、私たちは難しい決断を迫られます。ですが、ほとんどのディストリビューションでどちらか一方が採用されるようになれば、喜んで大勢に従います。一般に、ディストリビューションによる採否を通して大まかな収束が見えてくるものです。LSBプロセス自体がそういったコンセンサスを後押しするのです」
ただし、Johnson氏はこのような収束に至る可能性はほとんどないと見ている。「取り入れる価値があるなら、rpm.orgのパッチを喜んでrpm5.orgに統合しますよ」。自分のものではないことを理由にパッチを拒絶するなら、それはベンダごとの逸脱を強めたそもそもの要因である排他的な考え方を繰り返すことになるだろう、と彼は指摘する。
Johnson氏は、パッチ統合作業の成果として今年の末までに最初のRPM 5.0パッケージをリリースしたいと語った。