Middleware Library Guidelines


1  Introduction

This document is subject to the OpenNI Service Terms and Acceptable Use Policy and is intended for developers who want to share their Natural Interaction Middleware Library via the OpenNI website.

The objective of the OpenNI Arena website:

    • Share new middleware for OpenNI and enable many new apps in different areas.
    • Enable developers to show their talents and get feedback from the community.
    • Provide free groundbreaking middleware and applications to owners of OpenNI compliant sensors.
    • Make it easy for publishers to discover promising applications and Middleware Library developers.

This document assumes:

  • You know how to write middleware.
  • You are familiar with the basic concepts of the OpenNI software architecture.


All developers that wish to publish a middleware library via the OpenNI Arena will have to declare the OpenNI compliance of their Middleware.

2  The Middleware Library Format

A Middleware Library is a software layer inside an application that serves as an intermediary between the application code and lower level SDK code or system software. Middleware makes it easier for software developers to perform lower level processing on data (in this case, raw OpenNI output), so they can focus on the specific purpose of their application.

Your Middleware should be submitted in a ZIP/RAR file containing a folder with the binaries and resources elements (images, package info, config files, README.TXT, etc.).

Recommended Middleware Library name format: [MWNAME_VERSION.zip].

We recommend the ZIP file to include:

  • A “Samples” folder with pre-built samples ( ie example applications which uses the Middleware Library). In addition to the binary, we also recommend including the source code of the samples.
  • A README file explaining how to use the API and containing the following:
    • Installation instructions
    • Information about the developer of the library
    • List of any software prerequisites (other than OpenNI)
    • Getting started guide with basic instructions on how to use the library
  • Use case: A document explaining what capabilities the middleware provides to application developers
  • Reference: A document detailing all exposed classes, functions etc. in the Middleware Library.

OpenNI requires a folder named OpenNI2 with all its files under the working directory.

The software submitted can be a “free to try”/trial/limited/time limited version of the middleware libraries, as long as the demo uploaded on the OpenNI website is free.

If you need to add licensing conditions, EULA, etc. please place them as separated TXT files in the root directory. (Optional)

The source code files may also be published as a single ZIP file formatted [MWNAME_VERSION_Sources.zip]. You should compress the source files required to compile and run the Middleware, as well as provide instructions for compiling the Middleware Library. (Optional)

If including releases of sample source code that does not contain the core Middleware Library mechanics, they should be published under the following file name: [MWNAME_VERSION_Partial-Sources.zip]

The Middleware should be reusable by applications. It should contain an application programming interface (API) that enables a developer to build an application that uses the Middleware Library.

Note: OpenNI2 must be integrated into your Middleware package before you submit it
OpenNI2 and the submitted Middleware need to be combined into a single functioning system that can be used by a developer who wants to build an application. They must be submitted as a single package that can provide both the functionality of OpenNI2, and of the Middleware library.

3  Checklist before Middleware Library Submission

  • Test the Middleware Library using the latest released version of OpenNI2. Go to http://openni.org and view the Release Notes.
  • Make sure your Middleware Library does not contain anything that could be mistaken by end-users as malicious code.
  • No trademark, copyrighted text or logo, brand name etc. should appear in the Middleware Library name, description, readme.txt, prerequisites, or on-screen in the Middleware if you did not obtain written authorization from the associated legal owners.
  • Use the UTF-8 encoding scheme for file names
  • Mention the Open Source license you use for your project (BSD/GPL/LGPL…).
  • Prerequisites: Including/requiring prerequisite components is authorized and even recommended under the following conditions:
  • Any license that applies to the prerequisite package allows it to be included.
  • No purchase is required to use the prerequisite package.
  • The prerequisite is listed as such in the description on the OpenNI website.
  • Handle errors gracefully; in particular, implement self-explanatory error messages for missing prerequisites.
  • Make sure your Middleware is in compliance with the OpenNI Service Terms and Acceptable Use Policy.
  • Maximum size in the OpenNI Arena: 500MB.
  • All descriptions should be written in English.

4  Publish a Middleware Library

Elements required to upload your Middleware Library on the OpenNI site:

  • Choose a unique name
  • Specify required operating system type and version
  • Provide a one line summary description of your software
  • Provide a full description of your software (maximum of 500 words)
  • Specify minimum system requirements needed to use the package
  • Specify the license
  • Enter your version information (provide a version number if there is more than one version)
  • Select your software category
  • Provide a link to a YouTube or Vimeo video of an explicit sample (Optional)
  • Provide an icon for your library (Mandatory size: 80×80 JPG, GIF or PNG)
  • Up to 3 Screenshot images of a sample (Recommended)
  • Link to the software page of your website
  • Middleware Library (single ZIP file)
  • Middleware Library sources (single ZIP file) (Optional)

5  Middleware Library Review Process

The Middleware Library Review process evaluates the Middleware for release to the OpenNI Arena website. This evaluation checks to ensure that the Middleware adheres to guidelines listed in this document.

After submission, we will respond to the developer within a reasonable amount of time. At the sole discretion of the reviewer, we may request clarification on specific items or reject the middleware. In all cases, a notification will be sent to the developer’s registered email address.