Site Tools



To improve activity level and able to expand across different verticals, IoTivity Steering Group has come up with new organization structure as shown below.



Porting to specific Operating System or Kernel is the scope of this project. Subsystems of this project will be various Operating Systems and Kernel to be supported.
Project Leader: TBD

IoT Device Framework:

Implementing IoT protocol and related security is the scope of this project. Subsystems of this project will be Connectivity, Protocol, Proxies & Device Security.
Project Leader: TBD

IoT Device Platform:

This is combination of Platform and Device Framework project. Subsystems of this project will be Kernel, Engine/Compiler/Interpreter & IoT Framework. 1st proof of concept will be based on TizenRT or Zephyr as light weight and easy to configure RTOS, Jerryscript a light weight Javascript engine and IoT.js an IoT framework powered by Jerryscript and compliant to OCF. Aim is to provide packaged solution for quick to market.
Project Leader: TBD

Gateway (Bridge/Edge):

Protocol translators or Plugins and Bridge security will be scope and subsystems of this project. Details yet to come.
Project Leader: TBD

Cloud: Cloud/Fog

interface, User/Device Management, Data Analytics, Cloud/Fog Security will be scope and subsystems of this project. Details yet to come.
Project Leader: TBD

[EXISTING] IoTivity Projects and Functions

IoTivity is divided into Functions and Projects, as specified in the IoTivity Governance. A Project is a unit of source code that accomplishes a given objective and is usually developed in lockstep. A Project may be a separate Git repository or a section of a repository. Think of Projects as subsystems of the main library.

A Function is an activity in the development process that either spans the majority of Projects or all of them.


Functions are led by a Function Leader. Leaders set the objectives and targets of that Function.

IoTivity Architecture

The IoTivity Architecture is a special IoTivity Function that is responsible for organizing the architecture of all the Projects as well as coordinating the development activities.

The IoTivity Architecture Leader is called the IoTivity Lead Architect.

Lead Architect: Jinguk Jeong
Deputy Lead Architect: Mats Agerstam (not active)


Function Leader: Christian Gran

The Planning Function is responsible for:

  • Interacting with IoTivity Projects and other Functions to:
    • Understand their needs, requirements and commitments
    • Understand the requests of users of IoTivity source code
    • Prepare a concrete strategy for IoTivity delivering on those requirements
    • Coordinate the planning in each Project and of the major tasks
  • Leading the creation of the IoTivity roadmap
  • Investigating features outside of IoTivity for future development
  • Tracking risks and challenges and the progress of development
  • Reporting readiness status and raising issues for consideration by the IoTivity development community and the IoTivity Steering Group

Release Management

Function Leader: Uze Choi

The Release Management Function is responsible for:

  • Planning for IoTivity continuous releases (nightly, weekly builds, etc.)
  • Planning for IoTivity official releases, including those that are compliant to the OIC specifications
  • Interacting with the Planning Function and IoTivity Projects to:
    • Plan and confirm what features and requirements are applied for which delivery
    • Track to meet requirements and commitments to each delivery
    • Track risks and challenges, progress of delivery, providing feedback to the Planning Function
  • Raising issues for consideration by the IoTivity community and the IoTivity Steering Group when goals may be affected


Function Leader: Dave Thaler

The API Function is responsible for:

  • Defining API guidelines
  • Reviewing public header files for clarity and for adherence to the guidelines
  • Ensuring that appropriate sample code exists


N.B.: As of January 1, 2019, QA Function is merged with Release Function and officially discontinued.

Function Leader: Mushfiqul Islam Antu

The Quality Assurance Function is responsible for:

  • Define IoTivity QA Scope
  • Manage IoTivity QA Process & Policy
  • Maintain the project and modules under QA
  • Executing Quality Assurance checks on the source code during development and prior to releases

Developer Community & Events Management

Function Leader: Thiago Macieira, Myungjae Lee

The Developer Community & Events Management Function is responsible for:

  • Maintaining the IoTivity web site and web presence
  • Raising IoTivity's profile and visibility
  • Coordinating IoTivity's activities in non-IoTivity events (eg., booths and stands, ensuring that IoTivity's key technical people attend those events)
  • Organizing IoTivity's own events
  • Driving recruitment of new community members, organizing the IoTivity key technical people around that goal
  • Interfacing with technical press and with the OIC marketing activities


Projects are led by a Project Maintainer and by a Project Architect. The Maintainer is responsible for the source code and incoming contributions, while the Architect is responsible for the overall organization, planning and anticipating the architectural needs of the Project.

Discovery & Connectivity

Architect: (vacant)
Maintainer: Ashok Babu Channa
Sub-Maintainers: Ziran Sun, Dan Mihai, Mike Fenelon
Gerrit Code Review Group: 'Connectivity Maintainers'

The Discovery & Connectivity Project is responsible for all the low-level network communication in IoTivity, including the discovery of services on the network, managing the communication with them. This project will often deal with providing abstraction layers for the other IoTivity Projects and interfacing with the target Operating System features.

Platform Support

Architect: Seokhee Lee
Maintainer: Seokhee Lee
Sub-Maintainers: Seokhee Lee (webOS), Rick Bell (Android), Phil Coval (Tizen, Ubuntu)
Gerrit Code Review Group: 'Platform Maintainers'

The Platform Support Project is responsible for all platform-specific support including Windows/Android/iOS and so on. The maintainer sets guidelines and organizes the framework, and each specific platform can have a sub-maintainer to handle details specific to that platform.

Primitive Service

Architect: Jay Oh
Maintainer: Uze Choi
Sub-Maintainers: Madan Kanth Lanka, Jungho Kim

The Primitive Service Project is responsible for the second layer in IoTivity, dealing with the basic communication protocol (application-level) between IoT devices. The Primitive Service Project often includes the next layer and defines the specifics of communication between certain types of devices (i.e. “services”).

IoTivity Cloud

Architect: Ondrej Tomcik
Maintainer: Ondrej Tomcik
Sub-Maintainer: Peter Rafaj, Jozef Kralik

The IoTivity Cloud Project is responsible for extending accessibility of IoTivity devices and scenarios using some techniques like Http to CoAP proxy, OAuth 2 over CoAP and so on. Users can access their devices under their prefer accounts through cloud. Also when user share credential to other services, they can access to user devices for automated control.


Architect: (vacant)
Maintainer: Aleksey Volkov
Sub-Maintainers: Nathan Heldt-Sheller, Kevin Kane, Greg Zaverucha
Gerrit Code Review Group: 'Security Maintainers'

The Security Project is responsible for the low-level security-releated aspects of IoTivity, such as encryption mechanisms used, authentication and authorization, and the high-level concepts such as privacy, data integrity, etc. In addition to that, the Security Project acts as a Function in establishing secure coding practices and, if necessary, conducting audits in the source code belonging to other Projects.


Architect: (vacant)
Maintainer: Todd Malsbary
Sub-Maintainers: (vacant)

The Bridging Project is responsible for providing a framework and plugins to provide external mappings of other ecosystems into the OCF ecosystem. The framework is called “Mini Plugin Manager” (MPM) and some sample plugins already in place are for Philips Hue, Honeywell Lyric, and Google Nest. For more information, please see the wiki article on it here:


Architect: Rick Bell
Maintainer: Rick Bell
Sub-Maintainer: George Nash

UPnP Bridge is an open source software framework that discover existing UPnP devices/services. UPnP-Bridge then translates UPnP devices/services/actions into IoTivity devices/services and registers them as IoTivity devices through Resource Container. This allows existing UPnP devices/services/action to be managed and used through IoTivity like any other IoTivity device.


Architect: Todd Malsbary
Maintainer: Todd Malsbary
Sub-Maintainer: (vacant)

AllJoyn Bridge is an open source software framework that implements generic on-the-fly translation between AllJoyn and IoTivity devices (both AllJoyn consumers/producers and IoTivity clients/servers).

Web Service Interface

The Web Service Interface is responsible for providing the interfaces to web services by supporting user-device association, device identity management, data format conversion and provisioning and configuration functions. These features will help service developers to bring their services into the IoTivity network and tailor their services for the IoT context.


Architect: (vacant)
Maintainer: Towhidul Islam
Sub-Maintainer: Mushfiqul Islam Antu

The Test Project is responsibile for maintaining the testing relevent source code such like API TC, test application and test automation script.

IoTivity-Constrained Framework

Architects: Kishen Maloor, Thiago Macieira
Maintainer: Kishen Maloor
Sub-Maintainer: Flavio Ceolin, Otavio Pontes

The IoTivity-Constrained framework is a new, lightweight implementation of the Open Connectivity Foundation (OCF) standards. Distinct from the IoTivity Project, IoTivity-Constrained’s design is geared towards targets that are power and memory-constrained edge devices that run small footprint, real-time operating systems.

IoTivity-Constrained can currently run on Linux, Zephyr, RIOT OS, Contiki, MyNewt, and Tizen.

Mapping of IoTivity Projects to the repository structure

IoTivity has multiple projects, although most of the work happens in the project named iotivity. This table shows who the iotivity project maintainers are based on where you are modifying. If you are looking for reviewers, you can also look for the review group mentioned in the project above (there isn't one for every area).

Source path Project or note Active Maintainer, Sub-maintainers and experts
resource Discovery & Connectivity
Primitive Service
Jon Cruz, Habib Virji, Ashok Babu Channa, Dan Mihai, Mike Fenelon
Uze Choi
resource/csdk/security Iotivity Security Aleksey Volkov, Nathan Heldt-Sheller, Kevin Kane, Greg Zaverucha
resource/c_common Platform Support Dave Thaler
resource/c_common/windows Dave Thaler
android Rick Bell
tools/arduino Arduino support removed in master
tools/darwin TBD
tools/tizen Phil Coval
service Primitive Service Uze Choi, Madan Lanka, JungHo Kim, Markus Jung
cloud Iotivity Cloud JeeHyeok Kim, Ziran Sun, Habib Virji
extlibs/libstrophe Remote Access old RA inactive
test Test Towhidul Islam, Mushfiqul Islam Antu
*/SConscript, etc. Build system Mats Wichmann

Maintainers and sub-maintainers in the list above are in bold.

TODO: the other projects need such a table. Here are the projects gerrit reports: iotivity-alljoyn-bridge iotivity-constrained iotivity-contrib iotivity-node iotivity-test iotivity-upnp-bridge iotivity-voice iotivity-xmpp

projects_and_functions.txt · Last modified: 2019/01/07 06:34 by i.mushfiq