モジュール形式の多言語アプリケーションスタックに対する人気の高まりを受けて，OSGi Allianceでは，言語とランタイムに依存しないバージョンの標準提供に向けた議論を再開した。全体としての目標は，同じ言語あるいは実行環境を用いるバンドルが，個々にコンポーネント部品を用意する必要をなくすことにある。これを実現することで，さまざまな言語を使ってOSGiシステムに参加できるようにしたい，という考えだ。すでにRFP-159とRFP-156の２つが，JavaScriptとC/C++によるネイティブなOSGi実装をそれぞれ標準化する目的で提出されている。
多言語(Polyglot)OSGiは当初，2007年のOSGiメーリングリスト上で "Universal OSGi"として紹介されたものだが，それに先立って，複数言語サポートに関する議論が1999年に始まっている。OSGi AllianceによってRFP-89に指定されたUniversal OSGiは，モジュール化に関わる懸案にすべての言語の立場から対処しようという，極めて広い範囲を対象とした提案であった。
JavaScriptは近年，サーバとクライアントのどちらにおいても，プログラミング言語として成功を収めている。このような状況からJavaScriptのコミュニティでは，この言語の問題点である中途半端なモジュラリティを解決しようという動きが始まっている。さらに，元来はパッケージやモジュールをサポートしない言語であるJavaScriptでモジュール化のメリットを実現するため，NPM(Node Package Manager)のようなパッケージマネージャも現れた。
RFP-159を通じてOSGi Allianceは，JavaScriptに蔓延する自家版モジュール化ソリューションの問題が解決されることを望んでいる。JavaScriptをOSGiの "登録(Register)，検索(Find)，結合(Bind)" モデル構想の最初のターゲットにしたいのだ。JavaScript OSGi標準化への道を開いたのはEclipse Orionプロジェクトだ。"マイクロサービス(Microservice)" と呼ばれる実装の開発を通じて，人気のIDEであるEclipse上で，言語間を越えたOSGiサポートをブラウザベース実装で実現している。
OSGiマイクロサービスRFPの4.3章には，JavaScriptのOSGi相互運用性に対する最大の開発動機として，Javaでの実績が特に記されている。多くの企業が多大な投資をした結果，Javaでは，サービス実装の分離による既存コード再利用性の大幅な向上という成果をあげたのだ。同じ章の最後には，既存のJavaコードでのサービスの利用方法を変更する必要なく，サービス側をNode.jsで実装する，という事例が示されている。
Java以外でOSGi Allianceがターゲットとしている言語は，JavaScriptだけではない。より広い意味での "Universal OSGi" の一部として，ネイティブ言語 – 特にCとC++ – によるOSGiサービスモデル実装のニーズに対処するため，RFP-156が公式に導入された。このRFPに関する議論は，nOStrumやApache Celixなど，すでに独自のOSGi実装を保持している参加プロジェクトが中心となって進められている。
JavaScriptに関するOSGiマイクロサービスRFPでは，Javaとの相互運用性によるメリットの実現が特に取り上げられているのに対して，ネイティブOSGi RFPの "問題の説明" の章では，ネイティブOSGiに関する議論の対象として "コア仕様のみに注目する" ような，狭義の捉え方をしている。既存のネイティブコードからJavaサービスを使用する目的でOSGiレイヤを活用することも可能なはずだが，同じような "Javaバンドルとの相互運用性は，リモートサービスでも実現できる" ため，この提案ではそれほど重視されていないという事情もある。
RFP-159とRFP-156に相当するコンセプトは，いずれも10年以上前からあった。しかしながら，Universal OSGiに関する広範な議論から，異なる言語間での対話へと目標を変えるという公式なプロセスは，まさに緒に就いたばかりだ。RFP-159とRFP-156はともに今年４月に作成され，6月にOSGi Allianceのbugzillaトラッカを通じて告知されている。