Project Structure

The task of defining the organizational structure has been delegated to the project structure working group. This page is a work-in-progress.

Organization

Key organizational characteristics:

  • Not-for-profit company
  • Membership based
  • Members elect a board of directors
  • One director per organization
  • Formal voting process
  • Dispute resolution process
  • Intellectual property process
  • Non-active committer process

An operating agreement will be developed, but due to the initial and ongoing cost associated with setting up a company, company registration will be put on hold.

Policy

There will be a board of directors responsible for developing and implementing policy. At its earliest opportunity, the board will establish a technical steering group comprising key stake holders (e.g. application developers). This steering group will review all technical documents, and provide feedback and recommendations to the board.

Documentation and Planning

The board will be responsible for ensuring that appropriate documentation and planning is undertaken. At a minimum, the following documents and plans will be provided:

  • An initial design
  • An implementation plan
  • A testing/release plan

Documentation changes will required board approval.

Membership

Membership of the organization will be open.

Committers

Committers are developers who make frequent and valuable contributions to the project. Committers have write access to the source code repository and voting rights.

  • There will be an initial list of committers selected from the group participants
  • Committer rights will be governed by meritocracy

Voting

Voting will be an important part of a committers responsibilities:

  • There are three voting responses: +1 (yes), 0 (abstain), or -1 (no)
  • Unless otherwise stated, at least three positive votes and no negative votes are required for a successful vote

New Committers

The process of adding a new committer will be open and transparent. The process will be as follows:

  • New committers will be nominated by an exisiting committer
  • All committers will vote on the nomination
  • The nominee will be recommended to the board for final approval

Obligations

In order to retain committer rights, a committer will be required to:

  • Make contributions on a regular basis
  • Subscribe to developer mailing lists
  • Track, participate in, and vote on relevant discussions
  • Monitor, report, and fix bugs

License

The working group recommended that one of two licenses be adopted:

  • BSD-compatible, with explicit grant of patent rights for each committer
  • EPL

Disputes

TBD

Intellectual Property

All contributions must be made by the rightful copyright holder and under the STCI license. All committers are required to sign a committer agreement that stipulates all of their contributions are their original work and are being contributed under the license.

Source code related to all contributions which are developed outside of the STCI development process are subject to an additional approval process. This process includes analyzing selected code contributions to try to ascertain the provenance of the code and license compatibility.

Infrastructure

Indiana University has agreed to host the infrastructure (web site, mailing lists and source code repository).

Technical

Language

In determining the appropriate language for the infrastructure, the following factors should be considered:

  • Performance
  • Object code issues, such as compilers and linking
  • Portability
  • Language bindings

The working group recommendation is that the infrastructure be developed in C99. Language bindings should be provided to allow plugins/agent to be written in other languages.

Portability

In order to ensure that the source code is as portable as possible, and to simplify the platform dependencies, it is recommended that the autoconf system be used.

Components

The working group recommended that a component-based approach for the design be used. Components will encompass clearly defined functional units. The infrastructure will support dynamic discovery, loading, and unloading of components.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License