O aumento da popularidade de aplicações modulares e poliglotas reiniciou as discussões na OSGi Alliance sobre oferecer uma linguagem e uma versão do padrão neutra com relação a ambientes de execução. O objetivo seria permitir que uma grande variedade de linguagens participem de um sistema OSGi, sem que partes dos componentes precisassem ser implementadas usando a mesma linguagem ou ambiente de execução como os outros pacotes. As RFP-159 e RFP-156 foram propostas para tratar a padronização OSGi para JavaScript e implementações nativas em C/C++ respectivamente.
O OSGi poliglota foi originalmente introduzido na lista de emails OSGi em 2007 como "OSGi Universal", embora as conversas sobre suporte multi-linguagens tenham iniciado em 1999. O OSGi Universal, designado pela aliança como RFP-89, foi uma proposta de grande escopo com a intenção de tratar problemas comuns de modularidade do ponto de vista de todas as linguagens.
O sucesso do JavaScript nos últimos anos, como linguagem de programação tanto do lado do servidor como do lado do cliente, levou a comunidade JavaScript a começar a tratar os problemas de modularidade que a linguagem apresenta. O gerenciamento de pacotes, como o Node Package Manager (NPM) surgiu para organizar os benefícios da modularidade na linguagem, que não forneçam suporte nativo para o empacotamento e modularidade.
Através da RFP-159, a Aliança OSGi espera organizar as várias soluções caseiras predominantes no JavaScript, tornando a linguagem um alvo de primeira classe, para os conceitos do modelo de serviço do OSGi "registrar, procurar e vincular". O projeto Eclipse Orion abriu caminho para a padronização do JavaScript OSGi através do desenvolvimento do tão chamado "microserviço", implementação que fornece suporte OSGI a várias linguagens, dentro de uma aplicação baseada no navegador da IDE popular.
A seção 4.3 do RFP do OSGi Microservices indica que o principal motivo para a interoperabilidade com o JavaScript, é o fato de muitas empresas terem investimentos significativos no Java, desacoplar a implementação do serviço proporciona uma maior possibilidade de reutilização de código existente. A seção termina com um exemplo no qual uma empresa pode querer implementar um serviço em Node.js, sem ter que mudar a maneira que seu código legado Java faz uso do serviço.
O JavaScript não é a única linguagem além do Java que a OSGi Alliance tem como alvo, Como um subconjunto mais amplo da "Universal OSGI", a RFP-156 foi oficialmente apresentada para abordar a necessidade de implementações em linguagens nativas do modelo de serviço OSGi - especificamente C e C++. Essa discussão está sendo liderada pelos participantes dos projetos. como o nOStrum e o Apache Celix, que já tenham trabalhado para implementar conceitos do OSGi por conta própria.
Enquanto a RFP de Microserviços OSGi em JavaScript procura colher os benefícios da interoperabilidade Java, a seção "Descrição do problema" da RFP Native OSGi procura focar o OSGi nativo para "se concentrar exclusivamente na Core Specification". Essa seção também ressalta que, ao utilizar a camada OSGI, deve ser possível utilizar os serviços Java através de código legado nativo, a mesma "interoperabilidade com pacotes Java pode ser conseguida usando os serviços remotos", e, portanto, não é o foco principal da proposta.
Os conceitos que embasam tanto a RFP-159 como a RFP-156 já existem há mais de uma década, mas ainda está no começo o processo formal de focar a discussão mais ampla da OSGi Universal em conversas direcionadas para diferentes linguagens. Ambas as RFP-159 e a RFP-156 foram publicadas apenas em abril deste ano, e sua presença no bugzilla da OSGi Alliance foi tornada pública em junho.