You are here

Project Governance

The IoTivity project is sponsored by the Open Connectivity Foundation (OCF), yet is independent from that organization. In addition to an open source license, IoTivity uses an Open Source Project approach, welcoming everyone to participate, contribute, and engage with each other through the project.

Contributors who show dedication and skill are rewarded with additional rights and responsibilities. Their opinions weigh more when decisions are made, in a fully meritocratic fashion.

Functions and Projects

A Project is a unit of the source code that accomplishes a specific objective, a subsystem of IoTivity. Projects are established by the development community on a per-need basis. They are hosted on the IoTivity infrastructure, follow the rules of community and of development, and follow the coding guidelines established by the IoTivity community. Each Project is led by the Project Maintainer, who is supported by a Project Architect. New Projects can be suggested by any member of the Community, but the final decision on hosting said project rests with the IoTivity Steering Group. Projects that are no longer active are archived and do not have assigned Maintainers and Architects.

A Function is an activity that spans the majority or the entirety of Projects and requires coordination as well as a global direction. Alternatively, Functions may be non-technical in nature, such as outreach activities or community management. Like Projects, Functions may be suggested by any member of the community and are officially created if the IoTivity Steering Group decides to adopt it.

The list of IoTivity Projects and Functions can be found in the Wiki.

Project roles

IoTivity recognizes the following formal roles: Contributor, Maintainer, Architect and Function Leader.

Informally, the community may organize itself and give rights and responsibilities to the necessary people to achieve its goals.

A Contributor is anyone who wishes to contribute to the project, at any level. Contributors are granted the following rights, to:

  • Contribute code, documentation, translations, artwork, etc.;
  • Report defects (bugs) and suggestions for enhancement;
  • Participate in the process of reviewing contributions by others;
  • Initiate and participate in discussions in the mailing lists;
  • Approach any member of the community with matters they believe to be important.

Contributors are required to:

  • Abide by decisions, once made. They are welcome to provide new, relevant information to reopen decisions;
  • Assume responsibility for issues and bugs introduced by one’s own contributions;
  • Respect the rules of the community (see below);
  • Provide constructive advice whenever participating in discussions and in the review of contributions.

Contributors who show dedication and skill are rewarded with additional rights and responsibilities. Their opinions weigh more when decisions are made, in a fully meritocratic fashion.

A Project Maintainer is a Contributor who is also responsible for the maintenance of a particular area of code or of an IoTivity source code project. Maintainers have the following rights and responsibilities, in addition to those listed for Contributors:

  • Right to to set goals for the short and medium terms for the Project being maintained, alongside the Project Architect;
  • Right to exceptionally make more invasive changes to the source code, when required;
  • Right to approve own contribution, after discussing with other Contributors;
  • Right to delegate responsibilities to Sub-maintainers;
  • Right and responsibility to participate in the feature development process (“Request for Comments”)
  • Responsibility to ensure all contributions to the Project have been reviewed within reasonable time;
  • Responsibility to ensure the quality of the code to expected levels;
  • Responsibility to monitor discussions in the mailing list(s);
  • Responsibility to participate in the quality verification and release process, when those happen.

A Sub-maintainer is a Contributor to whom a Maintainer has delegated part of his/her duties. This is done to ensure there are no gaps in maintainership activity, either due to skills gap or to time contraints. This may be done by an announcement on the Project’s mailing list and may be revoked by the Maintainer the same way. The Maintainer retains the ultimate responsibilities for the Project and does not relinquish such responsibility by appointing sub-maintainers. In particular, they are responsible for the activities that this sub-maintainer does on his/her behalf.

A Project Architect is a Contributor who is also responsible for knowing, directing and anticipating the architectural needs of a given IoTivity source code project. As such, Architects have the right to set the overall organization of the source code in the Project, and the right to participate in the decision-making of the Project, in conjunction with the Project Maintainer. Their responsibilities include ensuring that the Project they're responsible for will work together with the other Projects, including future directions those may go through. Architects are required to participate in the feature development process ("Request for Comments").

A Function Leader is a Contributor who is responsible for leading an activity that affects many or all of the IoTivity source code projects or a non-technical activity. Leaders are responsible for setting the goals for the short and medium term for the activity they lead, interacting with the other Contributors and guiding them towards the common goals. Leaders are members of the IoTivity Steering Group.

The up-to-date list of maintainers, architects and leaders can be found on the IoTivity Wiki.

Selection of Maintainers, Architects and Leaders

Exactly one Maintainer and Architect is selected for each Project. Similarly, exactly one Leader is selected for each Function. Therefore, a new Maintainer, Architect or Leader can be selected only for areas where there currently is no one at that position.

A candidate for the Maintainer role should be one of the Contributors who has done work in that Project for some time and has shown characteristics consistent with the requirements of the Maintainer role.

The selection process should be achieved by consensus of the affected parties, such as Contributors active in that Project, Maintainers and Architects of other Projects, etc. If consensus cannot be achieved, the IoTivity Steering Group will make the decision and all decisions must be ratified by the IoTivity Steering Group.

In the case of a Maintainer vacancy, the Lead Architect works with the developer community to make a recommendation to the IoTivity Steering Group for a replacement. The IoTivity Steering Group is responsible for approving the recommendation.

In the case of a sub-maintainer vacancy, the Maintainer is responsible for finding a replacement (if needed) and informing the Lead Architect first, then the IoTivity Steering Group and the developer community. As in all matters, the IoTivity Steering Group has the right to reject a sub-maintainer for cause.

Project Steering

The IoTivity project governance – including maintainership, project architect appointment, function leadership, etc. - is managed through the OCF Open Source Work Group (OSWG).  For decisions which exceed the scope of OSWG, the OSWG uses the Technology Steering Committee (TSC) to gather any necessary input.  If a decision is broader in scope even that the TSC – for example, a decision that might impact member company business strategy, or which has strategic marketing implications – the OSWG and TSC may escalate to the OCF Board of Directors.  The majority of project management decisions however take place at the OSWG level, and members interested in participating in those decisions are encouraged to contact the OSWG Chair, email the OSWG mailing list, or attend OSWG meetings.

Rules of community

All community members must abide by rules of common sense, civility and good neighborhood. Frank discussion is welcomed and encouraged with the goal of arriving at the best technical solution possible. Discussion about the people participating in development is not welcomed and ad hominem attacks will not be tolerated.

Community participants must adhere to these simple rules:

  1. Respect and acknowledge all contributions, suggestions and comments from the community;
  2. Listen and be open to all opinions, which are subject to open discussion;
  3. Help each other and the other Projects;
  4. Assume people mean well
  5. Keep the Projects open-source friendly by using the mailing list(s) and IRC as the primary communication channels and keeping these open and friendly.

Lazy Consensus means that contributors may proceed with work when they have reason to believe that other Contributors in the community will agree with the direction, and need not stop to initiate unnecessary discussion about the work. In this case, they should publish their work rapidly (that is, merge proposals to version control) to allow others to raise objections when there are any. When the contributor is not sure there will be consensus, they should raise a proposal on the appropriate mailing list. The second principle will apply in this case.

Silent Consent means that those who do not offer a reasoned alternative in course of the discussion implicitly agree with the proposal.

These principles are valid for discussions in the public mailing lists. Consensus reached in other ways (such as face-to-face discussions or IRC communication) are to be considered proposals until submitted to the relevant, public mailing lists, thus giving dissenting opinions the opportunity to be voiced.


All decisions need to be made by consensus, respecting the principles and rules of the community. When consensus cannot be achieved among Contributors, the decision-making proceeds as follows:

  • Project decisions are made by Maintainer and Architect together
  • Function decisions are made by the Function Leader
  • If there is overlap of responsibility between Projects and Functions, then respective Maintainers, Architects and Leaders make joint decisions

Finally, if the Maintainers, Architects and Leaders cannot reach consensus for a joint decision, the issue is brought IoTivity Steering Group for decision.


Responsibilities in the Project (including decision making) are given to those who exhibit both technical skill and dedication to the Project via their ongoing valuable contributions. Decision-making happens inside the community with more weight given to those most familiar with the code.


All activities affecting the source code should be done in the open, so all Contributors can follow the development. This is especially valid, but not limited to, discussion about technical features or future suggestions, tracking of reported bugs, release criteria and requirements.


All participants in the community are requested to make it a welcoming place, by helping new arrivals to the community as they familiarize themselves with the rules and procedures.

Decision-making in IoTivity

Decisions in IoTivity are made always at the lowest level possible that is applicable for the decision in question. Deciders only need to keep in mind the rules of community and the IoTivity goals and roadmap.

  • Individual Contributors are making decisions every time they submit changes in the form of deciding what to implement and how to go about it.
  • Two or more Contributors also make decisions when participating in discussions in the mailing list, on bug or feature reports, in reviewing of commits. Their arguments in why a given decision should be made are part of the consensus that needs to be reached for the decision. At this level, the principle of meritocracy is important, as the opinion of those who have contributed more will be given more weight in the consensus-building.
  • If those Contributors cannot agree and reach consensus on a decision, then IoTivity provides for decisions to be made by a single person or group of people, avoiding stalemates:
    • Decisions affecting a single Project are made together by the Project's Maintainer and Architect
    • Decisions affecting a single Function are made by that Function's Leader
    • Decisions that overlap more than one Project and/or Function are made in conjunction by the Maintainers, Architects and Leaders affected
  • Finally, if there's no agreement even between those empowered, the decision is made by the IoTivity Steering Group following its own decision-making process