值得关注的是，华为不再是第二大贡献者（截至2018年6月的一年中华为的贡献率为18%，2019年为10%）。取而代之的是，三星在最近一年中以占据9%的代码提交量跃居第二位，而在前几年则一直默默无闻。紧随三星之后的是爱立信（6%）、中国移动（6%）和诺基亚（5%）。从提交的代码数量来看，中兴通讯、Amdocs和IBM等此前的前五大贡献者最近不那么活跃了。
关于如何最好地使用ONAP意见不一
LFN终端用户咨询小组的一篇报告非常有趣，它讨论了ONAP的不同“使用”方式。该报告的贡献者来自于AT&T、中国移动、Orange、STC、阿根廷电信、TIM和沃达丰。一项调查询问了CSP如何计划使用ONAP。这个问题只有11个肯定回答，另外3个不确定，还有一个近期没有使用ONAP的计划。因此，为了获得更大的样本，Omdia在LinkedIn调查中提出了一个类似的问题。Omdia调查获得了41票回应，分配情况如下：
A（39％）：内部构建一个完整的ONAP系统；
B（17％）：外包ONAP系统的建设；
C（15％）：使用专业支持的ONAP发行版；
D（29％）：将ONAP视为参考实现。
受访者中包括一家新成立的亚洲移动运营商的CTO，一家欧洲Tier 1运营商的技术创新负责人，一家Tier 1跨国运营商的首席IT系统架构师，以及一家全球Tier 1运营商的集团网络战略主管。
令人惊讶的是，Omdia的调查发现，与LFN的调查相比，对“内部构建”方法的支持更多（39% vs. 27%），选择外包方法的较少（17% vs. 36%），对发行版的支持更多一些（15% vs. 9%），对参考实现方法的支持几乎相同（29% vs. 27%）。
ONAP的关键价值可能是作为一个参考实现
尽管有这个调查结果，但Omdia认为，由于缺乏资源，除了AT&T、贝尔加拿大和Orange外，很少有运营商会自己构建一个完整的ONAP系统。任何会这样做的企业可能都是在小范围内进行，例如，对单个国家在特定领域的单一业务线（例如Open RAN）进行部署。Omida猜测，很多公司会因为成本问题而将ONAP外包给供应商（例如Amdocs或Nokia），或者系统集成商（比如埃森哲或Tech Mahindra）。
乍一看，支持发行版的选项似乎不可行。明显的的候选者红帽和Canonical都不提供ONAP发行版。Aarna Networks提供，但这是一家拥有不到10名员工的公司。然而，LFN告诉Omdia，埃森哲和IBM都计划提供通用的ONAP发行版，而其他供应商计划提供“特定于客户”的发行版（这在一定程度上破坏了开源发行版的整体理念）。
这就留下了将ONAP作为参考实现的选项。其理念是， 诸如3GPP、ETSI、MEF和TM Forum这样的标准组织只提供关于它们的标准和接口应该如何工作的指导方针，实现则由每个供应商自行决定。
