DRAFT

Project Definition and Structure

Project Charter

• To provide an Open-Source software development toolkit and enable collaboration on the development of a platform that provides client virtualization technology with high assurance security properties that are rooted in the platform hardware.

...

• To engage with upstream software projects and contribute developments with the dual aims of increasing the use of OpenXT technologies and decreasing the specialization of OpenXT.

• To continually raise the security capabilities of the OpenXT platform and upstream projects.

...

• To satisfy the OpenXT Priority Use Cases.

Priority Use Cases

• Provide the software platform for a Multi-Tenant Client Desktop.

• Track upstream component developments and enable their introduction into the platform.

• Enable hardware-based security technologies to used effectively.

• Enable support for new generations of hardware platforms.

• Enable opportunistic use of other Open Source technologies.

• Provide the software platform for a hardened Single-VM endpoint.

• Enable effective lockdown of a client machine to increase the challenge presented to a local adversary.

• Be the best-in-class Open Source toolchain for support of measured launch into a virtualized environment.

• Academic research platform for work on hardware-based security technologies.

• Production software environment for validation of new hardware-based security technologies.

Organizational Entities

• Individual Contributors

• Software developers

• Documentation authors

• Program managers

Technical Subject Matter Experts

• Corporate and Institutional Contributors

• Contributing Customers

• Subcontractors

• Software Developers

• Hardware Vendors

• Consumers of the project software

• Technical Advisory Board

• Governance Committee

• Component Maintainers

• System Administrators of project infrastructure

Roles and Responsibilities

Repository Maintainer, Source Code Committer

...

Structure of the Governance Committee

• <n> Individual Contributor positions

• <m> Corporate and Institutional Contributor positions

• <n> + <m> must be an odd number.

• Formal positions: Treasurer, Chairman, Primary Technical Advisory Board representative

: 7 positions on the board.

Responsible for ensuring that decision making is effective within the project and acting as the decision maker of highest authority, for setting the project charter and for driving project activities in pursuit of project goals derived from the charter.

[ TODO:
The Project Governance Committee should be designed to accurately reflect the actual power structure present within the project and further its goals. It should also be able to be changed with such a process so that it continues to do so.

]

Proposed: ….

Project Technical Advisory Board

Structure of the Technical Advisory Board

• Project contributors with demonstrated technical contribution to the project sustained over time.

• Must be respected within the community as having sound technical judgement.

• Must have no structural conflict of interest in being able to evaluate software against the Platform Definition and Security Properties.

• In aggregate, the board must have sufficient breadth of expertise to be able to consider changes to any part of the platform.

Responsible for providing expertise to the Governance Committee to enable them to ensure that the OpenXT platform maintains properties that are important to the project.
eg.

• Ensuring continuing support for priority Use Cases when significant changes are proposed. Requires understanding the details of the Use Cases and representing the interests of the users of actual deployments.

• Evaluating new technologies or changes to upstream components for relevance to OpenXT work.

• Directing attention of the Governance Committee to important decisions to be made.

Guidance from the Technical Advisory Board should be aimed at maintaining technical strengths and differentiation of the OpenXT platform.

Community Code of Conduct

• Bug fixing is to be done in the open:

• File a JIRA ticket at the point the defect is identified, to enable early participation from others in the community.

• Presentation of a complex fix PR out of the blue is to be avoided, especially if it introduces new software dependencies or technologies, or changes security properties.

Processes

• Decision making in the GC

• Decision making in the TAB

Authorization of Pull Requests

• Decision makers for Pull Requests

• 1. Component Maintainers

• 2. Technical Advisory Board

• 3. Governance Committee

...

Criteria for evaluation of Pull Requests

...

Syntax and Completeness of the request

• JIRA ticket filed with description

• RFC document and mailing list thread, for “significant” specification changes

...

Taxonomy of Change Types:

• Security-related fix : import from external project

• Security-related fix : OpenXT-specific patch

• Bug fix : no specification change

• Bug fix : with change of specification / loss of functionality as a side effect

• Enhancement / Change of specification

• Additive

• Subtractive

• Dead component elimination

• Change relevant to the software license (eg. trademark introduction)

• Infrastructure change : no specification change

• Test coverage change : no specification change

• Additive

• Subtractive

• Introduction of third-party software

• Software license is the same as the existing license of linked material

• Software license is a new license

• Removal of third-party software

• Relicensing of a software component

...

RFC procedure

...

Reference to the OpenXT Platform Definition and Security Properties

...

Pull Request Process

Decision making for Pull Requests

Voting: not currently in use in practice because it doesn’t work and the community appears to have acknowledged that.

eg. balancing many members of a single organization versus a smaller number of opposing votes from individual contributors.

In practice, if an argument is made by any community member that the proposed change adversely affects the existing security properties of the system, especially if they are relevant to the Priority Use Cases, and the argument is not refuted, then the change is not approved.

• If the argument ends in a stalemate, then the decision should progress to the Technical Advisory Board.

Method of Public Record of Decision Making

<JIRA and mailing lists.>

Process to add and remove members from the GC

Process to add and remove members from the TAB

...