The Open Network Edge Services Software (OpenNESS) is a MEC software toolkit that enables highly optimized and performance edge platforms to on-board and manage applications and network functions with cloud-like agility across any type of network. This open source distribution is designed to foster open collaboration and application innovation at the Network Edge and On-Premise Edge, making it easier for cloud and Internet of Things (IoT) developers to engage with a worldwide ecosystem of hardware, software and solutions integrators to develop solutions for 5G and Edge.

OpenNESS offers unique capabilities to accelerate application development at the Edge:

  • Abstracts out the network complexity for Cloud and IOT developers making migration of applications from the cloud to the edge easier
  • Enables secure on-boarding and management of applications with an intuitive web-based GUI
  • Built on a modular, microservices based architecture, it provides the building blocks for various functionalities such as access termination, traffic steering, multi-tenancy for services, service registry, service authentication, telemetry, application frameworks, appliance discovery and control. To learn more about OpenNESS and its features, click here
  • It is built on top of consistent and standardized APIs exposed to the developer community

The Intel® Distribution of OpenNESS toolkit is also available and includes all features and capabilities of the open source distribution as well as additional functionalities and optimizations offered as part of the proprietary distribution. To learn more and request access to this free proprietary distribution, click here.

Technical Steering Committee Charter


The scope of this body is limited to the questions directly related to the development in the following organization:

The decision making process will be based on a simple vote majority from the TSC members. In the event of a deadlock the Technical Board Chair shall have the casting vote.


Any contributor can ask to add a topic to the TSC agenda by sending an email to This email address is being protected from spambots. You need JavaScript enabled to view it.. The board members will add any topic of interest to the agenda. Minutes of Technical Board meetings will be published within a reasonable time following their approval by the Technical Board.


  • Any new project repositories must be approved by the Technical Board
  • Resolving any technical disputes. Anybody who is unhappy with the resolution of a technical issue can request that the Technical Board review the issue and make a decision on it. This is only expected to happen in exceptional cases. Before escalating to the Technical Board it is required that all reasonable steps to resolve the dispute via consensus are taken. If the Technical Board Chair does not feel that this has happened, they can refer the issue back to the complainant for further action to be taken before escalating it to the Technical Board. The decision of the Technical Board on any technical disputes will be final and all project contributors are expected to comply. If a Maintainer fails to comply with a decision of the Technical Board, the Technical Board will be empowered to take any necessary steps to enforce its decision.
  • Voting on all matters requiring a decision from the Technical Board.


There will be a 2 Maintainers for the OpenNESS project – one Maintainer for the Edgenode and one for the Edgecontroller


Act as a gatekeeper to the code - ensuring coding standards, quality, and functionality of code is maintained by the developers. Any additions to the source code must be approved by the relevant maintainer before they are added. The role includes:

  • Ensuring any code submitted is of the appropriate quality
  • Ensuring that any code submitted has been reviewed by peers
  • Ensuring that the relevant documentation is kept up to date with the code
  • Ensuring that any identified bugs in the relevant code is captured in the JIRA backlog
  • Ensuring that the unit, integration, and regression tests are appropriate for the relevant components
  • Educate users on Warranties, IP, and the implications of the open source license
  • Answer questions/emails on the relevant areas of the OpenNESS code base