User Tools

Site Tools


projects_and_functions

[2017] PROPOSED NEW IoTivity ORGANIZATION STRUCTURE

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

Projects

Platform:

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

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)

Planning

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

QA

Function Leader: Mushfiqul Islam Antu

The Release Management 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

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: Dave Thaler
Maintainer: Dave Thaler
Sub-Maintainers: Dave Thaler (Windows), Rick Bell (Android), Phil Coval (Tizen, Ubuntu)

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

Maintainer: JeeHyeok Kim
Sub-Maintainer: Ziran Sun, Habib Virji

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.

Security

Architect: (vacant)
Maintainer: Randeep Singh
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.

Bridging

Architect: (vacant)
Maintainer: Todd Malsbary
Sub-Maintainers: Mandeep Shetty, Joseph Morrow
Gerrit Code Review Group: 'Bridging Maintainers'

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: https://wiki.iotivity.org/bridging_project

UPnP-Bridge

Architect: Rick Bell
Maintainer: Rick Bell
Sub-Maintainer: George Nash
Repository: https://gerrit.iotivity.org/gerrit/iotivity-upnp-bridge

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.

AllJoyn-Bridge

Architect: Todd Malsbary
Maintainer: Todd Malsbary
Sub-Maintainer: (vacant)
Repository: https://gerrit.iotivity.org/gerrit/#/admin/projects/iotivity-alljoyn-bridge

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.

Test

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

Currently, IoTivity has a single source code repository, containing the source code for all of the Projects.

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
resource/oc_logger
resource/include
resource/src
extlibs/bluez
extlibs/cjson
extlibs/gtest
extlibs/libcoap
extlibs/tinycbor
extlibs/zigbee
plugins
resource/csdk/security Iotivity Security Randeep Singh, Nathan Heldt-Sheller, Kevin Kane, Greg Zaverucha
ca_adapter_net_ssl.c
extlibs/asn1cert
extlibs/mbedtls
extlibs/sqlite3
extlibs/tinydtls
resource/c_common Platform Support Dave Thaler
extlibs/boost
extlibs/timer
resource/c_common/windows Dave Thaler
android Rick Bell
extlibs/android
java
java/iotivity-android
java/iotivity-linux
tools/arduino Jon Cruz
extlibs/arduino
tools/darwin TBD
tools/tizen Phil Coval
service Primitive Service Uze Choi, Madan Lanka, JungHo Kim, Markus Jung
extlibs/rapidxml
extlibs/yaml
cloud Iotivity Cloud JeeHyeok Kim, Ziran Sun, Habib Virji
extlibs/libstrophe
extlibs/raxmpp
extlibs/wksxmppxep
test Test Towhidul Islam, Mushfiqul Islam Antu, Masud Bhuiyan, Imtiaz Hoassain

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

projects_and_functions.txt · Last modified: 2017/06/29 07:55 by Junghyun Oh