OSGiアライアンスの次期仕様に関するレビュープロセスが開始された。組織内で行われた作業の結果を，誰でも確認することができる。従来は仕様が公開されるまで，提案内容の閲覧やコメントができるのはメンバと関係者に限られていた。
OSGiの提案(依頼)つまりRFP(Request for Proposal)は，RFC(Request for Comment)と並んで，OSGi仕様に新たな機能を追加するための手段である。OSGi仕様それ自体は，コア, コンペンディウム(Compendium/要約), エンタープライズの各リリースとして公開される。これらの仕様は，実際には独立したRFPの集合体であり，それを承認済みのコレクションとして取りまとめたものである。さまざまなAPIリリースのコレクションであるJ2EEスタックと同じ方法だ。このような構成のため，数多くの異なるAPIとして機能を提供しているOSGi 5をターゲットとしたアプリケーション開発も可能になる。
実行対象としているコアプラットフォームに含まれないAPI(Remote Service APIなど)も利用できるという意味においては，OSGi仕様はモジュール化されていると言える。Apache CXFやEclipseのECFのようにOSGi実装さえ追加すれば，そのバージョンのサービスが利用できるようになるのだ。
サービスは通常，特定のユーザの要求に応じる形で発生する。組み込み開発の世界であっても，エンタープライズ市場であってもこの点は同じだ。その後，これがスペックリードによって支援され，実行に移される。プロポーザルが提案され，コメントが集まる。このようなプロセスが，仕様の確定まで繰り返し実施される。確定した時点で，次のバージョンで適切なコレクションにそれを組み込むかどうか，OSGiアライアンス内で投票が行われるのだ。OBRやBlueprintなどのサービス，さらにはモジュール層それ自体もすべて，このようなプロセスを経てきた。
ひとつの仕様に対して，1つ以上の別々の実装が並行して開発されるのは珍しいことではない。異なるグループが異なる方法でサービスを実装することによって，スペックリードが想定していなかった方法でAPIをテストすることが可能になり，結果としてAPI定義がより強固になるからだ。(サーブレットなどのJava APIも，通常はこれと同じような方法で開発されている。)
これらのプロポーザルとRFCをすべてオープンにすることで，仕様の策定プロセスを広く共有し，APIに対する意見や改善提案のコメントが早い段階で得られるようになると，OSGiアライアンスは考えている。そうすれば，仕様が確定した終了時よりも，フィードバックを問題なく開発に取り込むことが可能になる。手順を簡単にするために，仕様はGitHubで公開される。コメントを参照するための公開Bugzillaも用意される。現時点では修正のプル要求はサポートされていないが，この方法によるフィードバックの受け入れも将来的には可能になる。
開発中のOSGi仕様に関する詳しい情報はGitHubの該当ページや発表，プレスリリースなどを参照してほしい。